Chrome中的超慢速预检OPTIONS

Question

最近我一直在努力解决Chrome中出现的一个非常奇怪的问题：由于我的API（NodeJS）位于不同的子域，我需要使用CORS从我的前端（EmberJS）到达它。 / p>

它工作得很好，但我经常（95％的情况下）OPTIONS查询非常慢，将任何API调用延迟大约3秒。

大部分时间用于下载空白内容：

当我在另一个使用类似架构制作的网站上尝试此操作时，它会变得更奇怪，遇到完全相同的问题。

我尝试过的其他一些事情：

• 我一直在尝试使用Firefox和Safari，并且没有任何延迟。
• 我一直在本地或在制作中尝试这种方法，试验同样的延迟。
• 我一直在尝试使用隐身模式（没有扩展程序），而且我遇到了完全相同的问题。

我们在后端NodeJS上使用CORS package。

现在，我不知道问题出在Chrome 60，NodeJS，CORS包还是EmberJS + jQuery上。

任何人都有这样的经历吗？

Answer 1

就像一个注释：这似乎是一个铬虫

我使用具有两个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） - ＆gt; DELAY
• Chrome 62.0.3202.84（Android） - ＆gt; DELAY
• Chrome 62.0.3202.84（iOS-Ipad） - ＆gt; OK !!!
• 火狐 - ＆GT;确定
• Edge - ＆gt;行

解决方法（在我的情况下）。在我的主机中创建代理以响应相同的源DNS并避免CORS

Answer 2

我一直在寻找调试此功能，它似乎是一个Chrome错误，因为我们遇到了同样的问题。

作为参考，我在这里向铬提交了一份错误报告：CORS pre-flight and subsequent requests are very slow only on Chrome

我在这里添加这个以帮助阻止更多开发人员花费半天时间来调查它;）我们会更多地从Chromium更新。

错误报告概述如下：

UserAgent：

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36

重现问题的步骤：

1. 有app.domain.com
2. 列表项
3. 有api.domain.com
4. 在API上启用CORS以启用访问
5. 检查DevTools中的响应，请参阅OPTIONS和GET请求最多需要300ms +

预期的行为是什么？

响应时间应该准确。

出了什么问题？

我们正在使用Go微服务，并注意到浏览器之间的时间差异很大 - 铬是最慢的，达到100倍。

当我们检查后端的时间时，响应最多需要10毫秒，大多数是1毫秒。在检查devtools下的时序时，相同的响应在~100ms~1s时出现。

之前有效吗？

不适用

Chrome版本：63.0.3239.132频道：稳定 操作系统版本：10.0 Flash版本：

在Firefox（以及任何其他浏览器）中，完全相同的请求按预期返回~1-20ms。

在尝试进一步诊断时，我们使用Telerik的Fiddler检查实际网络响应时间，并确认Chrome在我们预期的时间内发送和接收。我们可以得出的唯一结论是，Chrome内部的某些内容正在减慢这些请求的处理速度。

我们尝试了chrome://flags#out-of-blink-cors和chrome://flags#enable-site-per-process的所有排列，这是我们发现的两个似乎含糊不清的选项。似乎没有任何帮助。

我们还发现了很多关于类似问题的Stack Overflow文章，提到它是一个Chrome错误，但是我无法在这里找到它：

• Super slow preflight OPTIONS in Chrome only
• https://github.com/corydolphin/flask-cors/issues/147
• Slow cors preflight OPTIONS Request in Chrome

我们刚刚在MacOS上测试了Chrome，但这似乎不是问题 - 因此可能仅限于Windows。

铬：

边：

火狐：

Answer 3

我为我的案件找到了解决方案，我将在这里分享。

我在Windows上，使用的是Chrome版本70，在同一服务器上运行带有nodeJS后端的AngularJS前端和restJS后端。我正在使用提琴手来监视请求，而OPTIONS请求可能需要1秒钟的时间，而有时只需<5毫秒。停止使用Filler可以将最大时间降低到300毫秒，但仍被认为很长。这种延迟发生在Chrome中，但在Firefox中却没有。我没有测试其他浏览器。

我的情况可能与问题不同，当我查看Chrome网络时间轴时，当Fiddler存在时，会有1秒的等待（TTFB）延迟。而且，当Fiddler不打开时，DNA查找与初始连接之间存在300 ms的间隔。

我终于找到了这个AJAX query weird delay between DNS lookup and initial connection on Chrome but not FF, what is it?

只需将后端连接URL从 localhost 更改为 127.0.0.1 ，即可完美解决我的问题。