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

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

upstream timed out (110: Connection timeout) while reading 来自upstream的响应头

如果我直接查询我的上游没有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有一堆超时指令。我不知道我是不是错过了什么重要的东西。任何帮助将高度赞赏....

560695 次浏览
小开

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

小开

在你的情况下，它有助于优化代理，或者你可以使用“#超时设置”

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;
}
小开

从我们这边来看，它使用spdy代理缓存。当缓存过期时，我们得到这个错误，直到缓存被更新。

小开

你应该总是避免增加超时时间，我怀疑你的后端服务器的响应时间在任何情况下都是问题。

我通过清除连接保持活跃标志和指定http版本来解决这个问题: https://stackoverflow.com/a/36589120/479632 < / p > 

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;
}
}

不幸的是，我无法解释为什么这是有效的，也没有设法从链接中提到的文档中破译它，所以如果有人有一个解释，我很有兴趣听到它。

小开

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

upstream从upstream读取响应报头时超时(110:连接超时)

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

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

小开

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

然后在此基础上，你可以调整proxy_read_timeout， fastcgi_read_timeout或uwsgi_read_timeout。

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

更多细节在这里Nginx上游超时(为什么和如何修复)

小开
这是因为你的上游花了太长时间来响应请求，NGINX认为上游已经在处理请求时失败了，所以它响应一个错误。 只要在location配置块中包含并增加proxy_read_timeout即可。 同样的事情也发生在我身上，我在工作中使用了1小时的内部应用超时:

proxy_read_timeout 3600;

这样，NGINX就会等待一个小时(3600秒)等待上游返回一些东西。

小开
首先，通过查看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;
...
}

看:最初的发布

小开

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

小开

正如很多人在这里指出的，增加NGINX的超时设置可以解决你的问题。

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

解决方案在于这个论坛线程，它说的是，你应该把你的超时设置< em > / etc / nginx / conf.d / timeout.conf < / em >(如果这个文件不存在，你应该创建它)。我使用了线程中建议的相同设置:

proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;
小开

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

设置resolver_timeout对我来说是有效的，因为我知道产生上游超时消息需要30秒。例如无法解析me.atwibble.com(110:操作超时)。

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

小开
在location或nginx.conf中添加一个line config，例如: 900年代proxy_read_timeout; < / p >
小开

请检查上游服务器的keepalive_timeout。

我得到了一个类似的问题:随机502，在nginx日志中有Connection reset by peer错误，发生在服务器负载过重时。最终发现这是由nginx'和upstream's(在我的情况下是gunicorn) keepalive_timeout值不匹配引起的。Nginx的速度是75秒，仅在几秒钟内就上升了。这导致上游有时会超时并断开连接，而nginx不明白为什么。

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

小开

我们在保存内容(自定义内容类型)时遇到了超时错误。通过添加以上所有超时，http客户端配置到600s，并增加php进程的内存到3gb来修复这个问题。

小开

如果你在windows 10上使用wsl2，通过下面的命令检查你的版本:

wsl -l -v

你应该在版本下面看到2。 如果你没有，你需要安装wsl_update_x64

小开

如果你像我一样使用AWS EC2实例运行Linux，你可能还需要重新启动Nginx，以便在将proxy_read_timeout 3600;添加到etc/nginx/nginx.conf后生效，我做了:sudo systemctl restart nginx


提交答案