仅 Chrome 中的超慢预检选项
Super slow preflight OPTIONS in Chrome only
我最近一直在为只发生在 Chrome 中的一个超级奇怪的问题而苦苦挣扎：因为我的 API (NodeJS) 在不同的子域上，我需要使用 CORS 来访问它来自我的前端 (EmberJS)。
它工作得很好，但我经常（95% 的时间）有非常非常慢的 OPTIONS 查询，延迟任何 API 调用大约 3 秒。
大部分时间都花在下载空内容上：
当我在我们使用类似架构制作的另一个网站上尝试这个时，遇到完全相同的问题时，它变得更加奇怪。
我试过的其他一些东西：
- 我一直在 Firefox 和 Safari 上尝试这个，没有任何延迟。
- 我一直在本地或在生产中尝试这个，试验相同的延迟。
- 我一直在使用隐身模式（没有扩展）尝试这个，但我遇到了完全相同的问题。
我们在后端 NodeJS 上使用 CORS package。
现在，我不知道问题出在 Chrome60、NodeJS、CORS 包还是 EmberJS + jQuery.
有人也遇到过这种情况吗？
请注意：这似乎是一个 chrome 错误
我使用具有两个 DNS 名称的服务器使用唯一域中的服务重现了该问题
https://domain1.com --> https://domain1.com (No CORS, no delay)
https://domain2.com --> https://domain1.com (CORS, delay)
响应两个名称的是完全相同的服务，所以我正在测试完全相同的请求、客户端和服务器代码（DNS 名称可以互换）
测试
- Chrome 61.0.3163.100 (Windows) -->延迟
- Chrome 62.0.3202.84 (Android) -->延迟
- Chrome 62.0.3202.84 (iOS-Ipad) -->确定！！！
- Firefox-->确定
- 边缘 --> 确定
解决方法（在我的例子中）。在我的主机中创建代理以响应同源 DNS 并避免 CORS
我一直在寻求调试，它似乎是一个 chrome 错误，因为我们遇到了同样的问题。
作为参考，我在此处向 Chromium 提交了错误报告：CORS pre-flight and subsequent requests are very slow only on Chrome
我在这里添加这个是为了帮助阻止更多的开发人员花半天时间调查它；）当我们从 Chromium 那里获得更多信息时会更新。
错误报告概述如下：
用户代理：
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36
重现问题的步骤：
- 有app.domain.com
- 列表项
- 有api.domain.com
- 在 API 上启用 CORS 以启用访问权限
- 在 DevTools 中检查响应，查看 OPTIONS 和 GET 请求最多需要 300 毫秒+
预期的行为是什么？
响应时间应该准确。
哪里出了问题？
我们正在使用 Go 微服务并注意到浏览器之间的时间差异很大 - chrome 最慢达 100 倍。
当我们从后端检查了时间后，响应最多需要 10 毫秒，大多数不到 1 毫秒。在 devtools 下检查时间时，相同的响应在 ~100ms~1s 时出现。
这个以前有用吗？
N/A
Chrome 版本：63.0.3239.132 频道：稳定
OS版本：10.0
Flash 版本：
在 Firefox（和任何其他浏览器）中，与预期完全相同的请求 return 在 ~1-20 毫秒内。
为了进一步诊断，我们使用 Telerik 的 Fiddler 检查实际网络响应时间，并确认 Chrome 在我们预期的时间内发送和接收它们。我们可以得出的唯一结论是 Chrome 内部的某些东西正在减慢这些请求的处理速度。
我们尝试了 chrome://flags#out-of-blink-cors 和 chrome://flags#enable-site-per-process 的所有排列，这是我们发现的两个似乎模糊相关的选项。似乎没有任何帮助。
我们还发现许多关于类似问题的 Stack Overflow 文章提到它是一个 Chrome 错误，但我无法在此处找到它的报告：
- https://github.com/corydolphin/flask-cors/issues/147
- Slow cors preflight OPTIONS Request in Chrome
我们刚刚在 MacOS 上测试了 Chrome，这似乎不是问题 - 因此可能仅限于 Windows。
Chrome:
边缘：
火狐：
我找到了适合我的案例的解决方案，我会在这里分享它。
我在 Windows，使用 Chrome 版本 70，在同一台服务器上运行 AngularJS 前端和 nodeJS 后端以及 restify。我正在使用 fiddler 来监视请求，并且 OPTIONS 请求有时可能需要 1 秒，而有时仅 < 5 毫秒。停止使用 Filler 可将最长时间降低到 300 毫秒，但仍被认为很长。这种延迟发生在 Chrome 中，但不会发生在 Firefox 中。我没有测试其他浏览器。
我的情况可能与问题不同，因为我查看了 Chrome 网络时间线，当 Fiddler 存在时，有 1s waiting(TTFB) 延迟。当 Fiddler 未打开时，DNA 查找和初始连接之间存在 300 毫秒的间隔。
我终于找到了这个AJAX query weird delay between DNS lookup and initial connection on Chrome but not FF, what is it?
只需将后端连接 URL 从 localhost 更改为 127.0.0.1 即可完美解决我的问题。
我最近一直在为只发生在 Chrome 中的一个超级奇怪的问题而苦苦挣扎：因为我的 API (NodeJS) 在不同的子域上，我需要使用 CORS 来访问它来自我的前端 (EmberJS)。
它工作得很好，但我经常（95% 的时间）有非常非常慢的 OPTIONS 查询，延迟任何 API 调用大约 3 秒。
大部分时间都花在下载空内容上：
当我在我们使用类似架构制作的另一个网站上尝试这个时，遇到完全相同的问题时，它变得更加奇怪。
我试过的其他一些东西：
- 我一直在 Firefox 和 Safari 上尝试这个，没有任何延迟。
- 我一直在本地或在生产中尝试这个，试验相同的延迟。
- 我一直在使用隐身模式（没有扩展）尝试这个，但我遇到了完全相同的问题。
我们在后端 NodeJS 上使用 CORS package。
现在，我不知道问题出在 Chrome60、NodeJS、CORS 包还是 EmberJS + jQuery.
有人也遇到过这种情况吗？
请注意：这似乎是一个 chrome 错误
我使用具有两个 DNS 名称的服务器使用唯一域中的服务重现了该问题
https://domain1.com --> https://domain1.com (No CORS, no delay)
https://domain2.com --> https://domain1.com (CORS, delay)
响应两个名称的是完全相同的服务，所以我正在测试完全相同的请求、客户端和服务器代码（DNS 名称可以互换）
测试
- Chrome 61.0.3163.100 (Windows) -->延迟
- Chrome 62.0.3202.84 (Android) -->延迟
- Chrome 62.0.3202.84 (iOS-Ipad) -->确定！！！
- Firefox-->确定
- 边缘 --> 确定
解决方法（在我的例子中）。在我的主机中创建代理以响应同源 DNS 并避免 CORS
我一直在寻求调试，它似乎是一个 chrome 错误，因为我们遇到了同样的问题。
作为参考，我在此处向 Chromium 提交了错误报告：CORS pre-flight and subsequent requests are very slow only on Chrome
我在这里添加这个是为了帮助阻止更多的开发人员花半天时间调查它；）当我们从 Chromium 那里获得更多信息时会更新。
错误报告概述如下：
用户代理：
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36
重现问题的步骤：
- 有app.domain.com
- 列表项
- 有api.domain.com
- 在 API 上启用 CORS 以启用访问权限
- 在 DevTools 中检查响应，查看 OPTIONS 和 GET 请求最多需要 300 毫秒+
预期的行为是什么？
响应时间应该准确。
哪里出了问题？
我们正在使用 Go 微服务并注意到浏览器之间的时间差异很大 - chrome 最慢达 100 倍。
当我们从后端检查了时间后，响应最多需要 10 毫秒，大多数不到 1 毫秒。在 devtools 下检查时间时，相同的响应在 ~100ms~1s 时出现。
这个以前有用吗？
N/A
Chrome 版本：63.0.3239.132 频道：稳定 OS版本：10.0 Flash 版本：
在 Firefox（和任何其他浏览器）中，与预期完全相同的请求 return 在 ~1-20 毫秒内。
为了进一步诊断，我们使用 Telerik 的 Fiddler 检查实际网络响应时间，并确认 Chrome 在我们预期的时间内发送和接收它们。我们可以得出的唯一结论是 Chrome 内部的某些东西正在减慢这些请求的处理速度。
我们尝试了 chrome://flags#out-of-blink-cors 和 chrome://flags#enable-site-per-process 的所有排列，这是我们发现的两个似乎模糊相关的选项。似乎没有任何帮助。
我们还发现许多关于类似问题的 Stack Overflow 文章提到它是一个 Chrome 错误，但我无法在此处找到它的报告：
- https://github.com/corydolphin/flask-cors/issues/147
- Slow cors preflight OPTIONS Request in Chrome
我们刚刚在 MacOS 上测试了 Chrome，这似乎不是问题 - 因此可能仅限于 Windows。
Chrome:
边缘：
火狐：
我找到了适合我的案例的解决方案，我会在这里分享它。
我在 Windows，使用 Chrome 版本 70，在同一台服务器上运行 AngularJS 前端和 nodeJS 后端以及 restify。我正在使用 fiddler 来监视请求，并且 OPTIONS 请求有时可能需要 1 秒，而有时仅 < 5 毫秒。停止使用 Filler 可将最长时间降低到 300 毫秒，但仍被认为很长。这种延迟发生在 Chrome 中，但不会发生在 Firefox 中。我没有测试其他浏览器。
我的情况可能与问题不同，因为我查看了 Chrome 网络时间线，当 Fiddler 存在时，有 1s waiting(TTFB) 延迟。当 Fiddler 未打开时，DNA 查找和初始连接之间存在 300 毫秒的间隔。
我终于找到了这个AJAX query weird delay between DNS lookup and initial connection on Chrome but not FF, what is it?
只需将后端连接 URL 从 localhost 更改为 127.0.0.1 即可完美解决我的问题。