NGINX:从上游读取响应头时上游超时(110:连接超时)

Posted

技术标签:

【中文标题】NGINX:从上游读取响应头时上游超时(110:连接超时)【英文标题】:NGINX: upstream timed out (110: Connection timed out) while reading response header from upstream 【发布时间】:2013-09-15 10:40:46 【问题描述】:

我让 Puma 作为上游应用服务器运行,Riak 作为我的后台数据库集群。当我发送一个请求,该请求为大约 25K 用户减少一大块数据并将其从 Riak 返回到应用程序时,我在 nginx 日志中收到错误:

读取时上游超时(110:连接超时) 来自上游的响应头

如果我在没有 nginx 代理的情况下直接查询我的上游,使用相同的请求,我会得到所需的数据。

一旦放入代理就会发生Nginx超时。

**nginx.conf**

http 
    keepalive_timeout 10m;
    proxy_connect_timeout  600s;
    proxy_send_timeout  600s;
    proxy_read_timeout  600s;
    fastcgi_send_timeout 600s;
    fastcgi_read_timeout 600s;
    include /etc/nginx/sites-enabled/*.conf;


**virtual host conf**

upstream ss_api 
  server 127.0.0.1:3000 max_fails=0  fail_timeout=600;


server 
  listen 81;
  server_name xxxxx.com; # change to match your URL

  location / 
    # match the name of upstream directive which is defined above
    proxy_pass http://ss_api; 
    proxy_set_header  Host $http_host;
    proxy_set_header  X-Real-IP  $remote_addr;
    proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_cache cloud;
    proxy_cache_valid  200 302  60m;
    proxy_cache_valid  404      1m;
    proxy_cache_bypass $http_authorization;
    proxy_cache_bypass http://ss_api/account/;
    add_header X-Cache-Status $upstream_cache_status;
  

Nginx 有一堆超时指令。我不知道我是否遗漏了一些重要的东西。任何帮助将不胜感激......

【问题讨论】:

它应该只在 600 秒后超时是吗?您可以通过在 127.0.0.1:3000 上设置一个 tcp 服务器来伪造它来计时,该服务器只接受连接并且不对其进行任何操作,以查看需要多长时间。应该是600s... 【参考方案1】:

发生这种情况是因为您的上游响应请求的时间太长,并且 NGINX 认为上游已经无法处理请求,因此它响应错误。 只需在 location 配置块中包含并增加 proxy_read_timeout 即可。 同样的事情发生在我身上,我在工作中为内部应用程序使用了 1 小时超时:

proxy_read_timeout 3600;

这样,NGINX 将等待一个小时(3600 秒)让它的上游返回一些东西。

【讨论】:

请注意,在 http 部分中包含proxy_read_timeout 可能无济于事。我在 location 部分中有 proxy_pass 指令,只有 proxy_read_timeout 设置有所不同。 (nginx 1.16.0) 对我来说似乎在 http/server/location 中工作......也许事情已经改变了 :) 您可以查看指令文档here 只是意识到您可以在http serverlocation 块中定义它【参考方案2】:

您应该始终避免增加超时,我怀疑您的后端服务器响应时间无论如何都是这里的问题。

我通过清除连接保持活动标志并根据此处的答案指定 http 版本来解决此问题: https://***.com/a/36589120/479632

server 
    location / 
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_set_header   Host      $http_host;

        # these two lines here
        proxy_http_version 1.1;
        proxy_set_header Connection "";

        proxy_pass http://localhost:5000;
    

不幸的是,我无法解释为什么会这样,也无法从链接的答案中提到的文档中破译它,所以如果有人有解释,我很想听听。

【讨论】:

如果您知道代理(即使对于特定 URL)需要更多处理时间,为什么不调整 proxy_read_timeout 嗨!我不记得确切的问题了,但我认为它与 url 的实际时间无关,而是在没有这些设置的情况下无法正确处理超时。 +1 ...这看起来像一个尴尬的黑客,但实际上这是来自官方文档 :) nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive 我有一个稍微不同的问题“从上游读取响应标头时上游过早关闭连接”当我将上游指令与 keepalive 一起使用时,使用这两行似乎可以修复它。 我喜欢人们所说的“你应该总是这样做”..“或者永远不要那样做”..每个人的情况都不同..就像我的情况一样,我有人上传大 (300MB) 文件世界各地..在不同的互联网连接上..互联网速度快的人可以高速发送..发展中国家的人互联网速度慢,可能需要2个小时才能完成..服务器必须等待,服务器不能说“你的互联网太慢了,所以我终止了连接”。所以在这种情况下,我增加了超时时间。 @TimDavis 我明白了,也许这样更好。我想这可能取决于流量,就像在这篇文章中说它是 WebSockets 所必需的:serverlab.ca/tutorials/linux/web-servers-linux/…【参考方案3】:

首先通过查阅 nginx 错误日志找出哪个上游速度变慢 文件并相应地调整读取超时 就我而言,它是 fastCGI

2017/09/27 13:34:03 [error] 16559#16559: *14381 upstream timed out (110: Connection timed out) while reading response header from upstream, client:xxxxxxxxxxxxxxxxxxxxxxxxx", upstream: "fastcgi://unix:/var/run/php/php5.6-fpm.sock", host: "xxxxxxxxxxxxxxx", referrer: "xxxxxxxxxxxxxxxxxxxx"

所以我必须在我的服务器配置中调整 fastcgi_read_timeout

 location ~ \.php$ 
     fastcgi_read_timeout 240;
     ...
 

见:original post

【讨论】:

这是一种添加计时信息的方法,无法查看您“需要”多少才能将其增加到:***.com/questions/18627469/… FWIW【参考方案4】:

在您的情况下,它有助于对代理进行一些优化,或者您可以使用“#超时设置”

location / 
        

  # time out settings
  proxy_connect_timeout 159s;
  proxy_send_timeout   600;
  proxy_read_timeout   600;
  proxy_buffer_size    64k;
  proxy_buffers     16 32k;
  proxy_busy_buffers_size 64k;
  proxy_temp_file_write_size 64k;
  proxy_pass_header Set-Cookie;
  proxy_redirect     off;
  proxy_hide_header  Vary;
  proxy_set_header   Accept-Encoding '';
  proxy_ignore_headers Cache-Control Expires;
  proxy_set_header   Referer $http_referer;
  proxy_set_header   Host   $host;
  proxy_set_header   Cookie $http_cookie;
  proxy_set_header   X-Real-IP  $remote_addr;
  proxy_set_header X-Forwarded-Host $host;
  proxy_set_header X-Forwarded-Server $host;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

【讨论】:

对我来说,在 location 部分中进行这些设置确实会有所不同。将它们放在 http 部分并没有帮助(可能是因为我在 location 部分中也有 proxy_pass 你究竟在用这些声明优化什么? 加载时间较长的页面没有超时。正在传递可能正在使用的标头并将缓冲区设置为限制。 很高兴在一个地方看到所有超时设置的列表。对我来说,我需要知道要缩短哪一个,以使我的错误响应及时将行为不端的上游丢弃。【参考方案5】:

我建议查看error_logs,特别是在 upstream 部分,它显示特定的上游超时。

然后在此基础上,您可以调整proxy_read_timeoutfastcgi_read_timeoutuwsgi_read_timeout

还要确保您的配置已加载。

更多详情在这里Nginx upstream timed out (why and how to fix)

【讨论】:

当心该链接有一个非常侵入性的全屏广告,当您滚动时会弹出......然后实际上并没有提供太多实际信息。【参考方案6】:

我认为发生此错误的原因有多种,但它可能特定于您正在使用的模块。例如我看到这个使用 uwsgi 模块,所以必须设置“uwsgi_read_timeout”。

【讨论】:

我认为 uwsgi_read_timeout 3600; proxy_send_timeout 3600; proxy_read_timeout 3600;为我工作。【参考方案7】:

正如许多其他人在这里指出的那样,增加 NGINX 的超时设置可以解决您的问题。

但是,增加超时设置可能不像这些答案中的许多建议那样简单。正如这些线程中的几乎每个人所建议的那样,我自己也遇到了这个问题,并试图在 /etc/nginx/nginx.conf 文件中更改我的超时设置。这对我一点帮助都没有。 NGINX 的超时设置没有明显变化。现在,几个小时后,我终于设法解决了这个问题。

解决方案在于this forum thread,它的意思是你应该把你的超时设置放在/etc/nginx/conf.d/timeout.conf (如果这个文件不存在,你应该创建它)。我使用了与线程中建议的相同的设置:

proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;

【讨论】:

【参考方案8】:

我遇到了同样的问题,导致 Rails 控制器中出现“每天”错误。我不知道为什么,但是在生产中,puma 一次又一次地运行错误导致消息:

从上游读取响应头时上游超时(110:连接超时)

可能是因为 Nginx 试图一次又一次地从 puma 获取数据。有趣的是,即使我在控制器中调用不同的操作,错误也会导致超时消息,因此,一个拼写错误会阻止所有应用程序.

检查您的 log/puma.stderr.log 文件,看看是否是这种情况。

【讨论】:

【参考方案9】:

请同时查看上游服务器的keepalive_timeout

我遇到了类似的问题:随机 502,nginx 日志中出现 Connection reset by peer 错误,发生在服务器负载过重时。最终发现它是由 nginx' 和上游(在我的例子中是 gunicorn)keepalive_timeout 值之间的不匹配引起的。 Nginx 在 75s 和上游只有几秒钟。这导致上游有时会超时并断开连接,而 nginx 不明白为什么。

提高上游服务器值以匹配 nginx 的值解决了这个问题。

【讨论】:

【参考方案10】:

从我们这边来看,它使用的是带有代理缓存的 spdy。当缓存过期时,我们会收到此错误,直到缓存已更新。

【讨论】:

【参考方案11】:

对于proxy_upstream 超时,我尝试了上述设置,但这些都不起作用。

设置resolver_timeout 对我有用,因为我知道生成上游超时消息需要 30 秒。例如。 me.atwibble.com 无法解析(110:操作超时)

http://nginx.org/en/docs/http/ngx_http_core_module.html#resolver_timeout

【讨论】:

【参考方案12】:

我们在保存内容(自定义内容类型)时遇到问题,出现超时错误。通过添加上述所有超时、http 客户端配置为 600 秒并将 php 进程的内存增加到 3gb 来解决此问题。

【讨论】:

超时,在 nginx.conf、php.ini 和 settings.php 中添加了其他更新。 Drupal 现在非常臃肿而且根本不健壮。与它困扰您的严重麻烦相比,使用 DRupal 可能带来的任何好处都是不值得的。 Wordpress Sitecore 要好得多【参考方案13】:

如果您在 Windows 10 上使用 wsl2,请通过以下命令检查您的版本:

wsl -l -v

您应该在版本下看到 2。 如果没有,则需要安装 wsl_update_x64

【讨论】:

【参考方案14】:

希望它可以帮助某人: 我遇到了这个错误,原因是对phpfpm的日志文件夹的权限错误,在更改它以便phpfpm可以写入之后,一切都很好。

【讨论】:

【参考方案15】:

new 向 location 或 nginx.conf 添加一行配置,例如: proxy_read_timeout 900s;

【讨论】:

完全没有帮助

以上是关于NGINX:从上游读取响应头时上游超时(110:连接超时)的主要内容,如果未能解决你的问题,请参考以下文章

上游从上游、客户端(nginx、varnish)读取响应头时发送了太大的头

从上游读取响应头时,Nginx uwsgi(104:由对等方重置连接)

NGINX *7060 上游超时(110:连接超时)

AWS ElasticBeanstalk NodeJS-502错误:从上游读取响应头时,recv()失败(104:对等连接重置)

nginx tomcat7 错误:-“从上游读取响应标头时,recv() 失败(104:对等连接重置)”

从上游读取响应头时失败(104:由对等方重置连接)