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

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

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

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

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

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

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

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

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

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

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

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

我通过清除连接keep-alive标志并根据这里的答案指定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;
    }
}

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