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

upstream读取时超时(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有一堆超时指令。我不知道我是不是错过了什么重要的东西。任何帮助将高度赞赏....


当前回答

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

其他回答

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

wsl -l -v

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

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

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

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

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

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

参见:原文

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

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

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

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

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