NGINX：从上游读取响应头时上游超时（110：连接超时）

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

proxy_read_timeout 3600;

有了这个，NGINX 将等待一个小时（3600 秒）让它的上游返回一些东西。

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

我通过清除连接保持活动标志并根据此处的答案指定 http 版本来解决此问题：https://stackoverflow.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;
    }
}

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

首先通过查阅 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

在您的情况下，它有助于对代理进行一些优化，或者您可以使用“#time out settings”

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

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

然后在此基础上调整 proxy_read_timeout、fastcgi_read_timeout 或 uwsgi_read_timeout。

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

在此处了解更多详情Nginx upstream timed out (why and how to fix)

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

正如许多其他人在这里指出的那样，增加 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;

另请检查上游服务器的 keepalive_timeout。

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

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

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

从上游读取响应标头时上游超时（110：连接超时）

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

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

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

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

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

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

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

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

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

wsl -l -v

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

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

new 向 location 或 nginx.conf 添加一行配置，例如：proxy_read_timeout 900s；