对于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”。

请检查上游服务器的keepalive_timeout。

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

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

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

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

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