我正在运行Nginx,以将请求传递给两个Thin服务器。该网站大约90%的时间都可以正常运行,然后每隔一段时间就会变得无响应,并且我会收到类似的错误消息

2014/11/28 21:40:05 [error] 21516#0: *1458 upstream timed out (110: Connection timed out) while reading response header from upstream, client: X.X.X.X, server: www...com, request: "HEAD / HTTP/1.1", upstream: "http://127.0.0.1:5001/", host: "www.example.com", referrer: "http://www.example.com/"

我在网上搜索解决方案,但是不幸的是,大多数问题都与这个问题无时无刻不在发生。在这种情况下,通常意味着Thin根本就没有运行。就我而言,我的网站大部分时间都在工作。我可以ping Thin服务器本身。尽管在站点无响应时我没有尝试ping通它们。这可能使我对问题有了更多的了解。

这是我的nginx.conf和网站可用
user www-data;
worker_processes 2;
pid /var/run/nginx.pid;
events {
  worker_connections 768;
  multi_accept on;
}
http {

  sendfile on;
  tcp_nopush on;
  tcp_nodelay on;
  keepalive_timeout 70;
  types_hash_max_size 2048;

  include /etc/nginx/mime.types;
  default_type application/octet-stream;
  client_max_body_size 100M;

  access_log /var/log/nginx/access.log;
  error_log /var/log/nginx/error.log;

  gzip on;
  gzip_disable "msie6";

  gzip_static on;

  gzip_comp_level 6;

  gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/octet-stream;

  ssl_session_cache shared:SSL:10m;
  ssl_session_timeout 10m;

  include /etc/nginx/conf.d/*.conf;
  include /etc/nginx/sites-enabled/*;
}

和启用网站/默认
map $http_upgrade $connection_upgrade {
 default Upgrade;
 ''      close;
}
upstream example {
  server 127.0.0.1:5000;
  server 127.0.0.1:5001;
}
upstream websocket {
  server 127.0.0.1:5001;
}
server {
  listen 80;
  listen 443 ssl;
  keepalive_timeout 70;
  root /data/example/;
  index index.html index.htm;
  server_name www.example.com;
  ssl_certificate     <PATH>;
  ssl_certificate_key <PATH>;

  location ~ ^/assets/ {
    include /etc/nginx/block.list;
    expires 1d;
    add_header Cache-Control public;
    add_header ETag "";
    proxy_set_header  X-Real-IP  $remote_addr;
    proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header  X-Forwarded-Proto $scheme;
    proxy_set_header Host $http_host;
    proxy_redirect off;
    proxy_pass http://example;
  }

  location /websocket {
    include /etc/nginx/block.list;
    proxy_set_header  X-Real-IP  $remote_addr;
    proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header  X-Forwarded-Proto $scheme;
    proxy_set_header Host $http_host;
    proxy_redirect off;

    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
    proxy_pass http://websocket;
  }

  location / {
    include /etc/nginx/block.list;
    proxy_set_header  X-Real-IP  $remote_addr;
    proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header  X-Forwarded-Proto $scheme;
    proxy_set_header Host $http_host;
    proxy_redirect off;

    proxy_pass http://example;
  }
}

我做的最后一件事是删除配置文件中的一些if语句。我不确定这没有做任何事情。从那以后,这个问题就没有发生过,但是我认为它已经不够长时间了。

编辑:问题确实返回。我回到正题。
if (-f $request_filename/index.html) {
   rewrite (.*) $1/index.html break;
}
if (-f $request_filename.html) {
    rewrite (.*) $1.html break;
}
set $flags "";
if (!-f $request_filename) {
    set $flags "${flags}R";
}
if ($flags = "R") {
    proxy_pass http://example;
    break;
}

最佳答案

结果证明很简单。这个问题使我花了更长的时间才弄清楚它本来应该拥有的。

事实证明,Google Compute Engine具有防火墙规则,可以在10分钟后断开空闲的TCP连接。这意味着Thin到数据库的连接已断开。

但是,Thin是而不是抛出超时错误。这使得很难确定Nginx超时的来源。因此,可能不确定这是Thin中的错误,我不确定,但确实在短时间内在Thin配置中设置了超时参数。

解决方案本身就是设置keepalive设置,以使TCP连接即使在空闲时也保持 Activity 状态。有关详细信息,请参见此处:https://cloud.google.com/compute/docs/troubleshooting#communicatewithinternet

关于ruby-on-rails - 在从上游读取响应 header 时,使用Nginx,Thin/Rails使上游超时,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/27197091/

10-12 23:29