我正在使用webpack-dev-server proxy:
devServer: {
proxy: {
'/api': {
target: 'http://mybackedn.url',
changeOrigin: true
}
}
}
为什么会这样?如何解决这个问题?
答案 0 :(得分:3)
请求时间图中的灰色部分称为停滞时间,浅灰色部分(灰色之后)为排队时间。如果将鼠标悬停在瀑布图上,则可以看到相同的内容。这是引起问题的原因,停滞时间意味着什么。
停转/阻止
请求等待发送之前花费的时间。此时间包括在代理协商中花费的任何时间。此外,此时间将包括浏览器在等待已建立的连接可供重新使用时的时间,并遵守Chrome的maximum six每个原始规则的TCP连接。
(如果您忘记了,Chrome会在悬停工具提示和“时间”面板下提供一个“说明”链接。)
基本上,您会看到这的主要原因是因为Chrome一次只能在每个服务器上下载6个文件,并且其他请求将被暂停,直到连接插槽可用为止。
这不一定需要解决,但是避免停滞状态的一种方法是将文件分布在多个域名和/或服务器上,并在需要时牢记CORS,但是HTTP2可能是一个更好的选择。资源捆绑(例如JS和CSS串联)也可以帮助减少停顿的连接量。
或者,您可以取消请求的优先级,然后在结束时花费很长时间,以便其余请求不会等待运行缓慢的人。
答案 1 :(得分:2)
我遇到了类似的问题,其中每个代理请求都花费了5秒钟或更长时间来进行如下设置:
"proxy": [
{
"context": [
"/api",
],
"target": "http://my-backend-server.local:1234",
"secure": false
}
]
在主机文件中:
127.0.0.1 my-backend-server.local
127.0.0.1 some-other-hostname.local
127.0.0.1 a-few-more-of-these.local
当我将代理更改为指向IPv6环回地址时,问题就消失了。像这样:
"proxy": [
{
"context": [
"/api",
],
"target": "http://[::1]:1234",
"secure": false
}
]
为了能够在代理配置中使用实际的主机名而不是回送地址,我编辑了hosts文件,使其在一行上包含所有主机名条目,并将它们指向IPv4和IPv6回送地址。像这样:
127.0.0.1 my-backend-server.local some-other-hostname.local a-few-more-of-these.local
::1 my-backend-server.local some-other-hostname.local a-few-more-of-these.local
现在,延迟消失了,它可以按预期工作。