代理到节点/Express上游时不常见的NGINX错误/超时（连接到上游时上游超时）

Question

我们部署了一个Express web API，它获得了相当大的但相对较小的流量（平均每秒约10个请求），这些流量运行在通过Nginx代理的EC2 ubuntu服务器上。每隔一段时间，一个请求就会挂起，如果客户端等待的时间足够长，就会将包含以下内容的行输出到NGINX错误日志中：

upstream timed out (110: Connection timed out) while connecting to upstream

我已经试过这里建议的解决办法，但似乎没有效果。这只发生在我们的知识大约1-3次每分钟，但我只是离开这些日志。如果客户机在请求超时之前刷新页面或导航离开，则似乎没有记录。

错误消息显然表明连接到上游服务器时出现了错误，但为什么这种情况会如此罕见呢？在URL中也绝对没有导致此问题的模式，并且代理的应用程序仍然可用，据我所知。下面是我们的NGINX配置的一个想法：

user www-data;
worker_processes 4;
pid /run/nginx.pid;
events {
worker_connections 10000;
}
worker_rlimit_nofile 25000;

http {
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
client_max_body_size 15M;
include /etc/nginx/mime.types;
include /etc/nginx/conf.d/ *.conf; //Added space before star because so formatting was turning it into a comment


include /etc/nginx/sites-enabled/ *;
default_type application/octet-stream;

log_format nginx_json '{ "timestamp": "$time_local", '
                      ' "request_ip": "$remote_addr", '
                      ' "request_user": "$remote_user", '
                      ' "request_bytes_sent": "$bytes_sent", '
                      ' "response_status": "$status", '
                      ' "request": "$request", '
                      ' "request_method": "$request_method", '
                      ' "http_referrer": "$http_referer", '
                      ' "http_user_agent": "$http_user_agent", '
                      ' "request_id": "$request_id", '
                      ' "server_name": "$server_name",'
                      ' "response_time": "$upstream_response_time" }';

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

gzip on;
gzip_disable "msie6";
ssl_prefer_server_ciphers on;
ssl_session_cache shared:SSL:10m;
ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:ECDHE-RSA-AES128-GCM-SHA256:AES256+EECDH:DHE-RSA-AES128-GCM-SHA256:AES256+EDH:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_dhparam /etc/ssl/certs/dhparam.pem;

resolver 127.0.0.1 valid=30s;

server {
 listen 80;
 server_name a.mysite.com;
 return 301 https://$server_name$request_uri;
}

 server {
     listen 443 ssl;
     server_name a.mysite.com;
     add_header Strict-Transport-Security "max-age=31536000";
     add_header Cache-Control no-cache;
     location /api {
         proxy_pass http://1.2.3.4:3001;
         proxy_set_header Host $host;
         proxy_set_header X-Request-Id $request_id;
         proxy_set_header Connection "";
         proxy_http_version 1.1;
     }
     location /ui2 {
         set $uiHost https://abc.cloudfront.net/ui2/index.html?v=1503438694163;
         proxy_pass $uiHost;
     }
     location / {
         set $uiHost https://abc.cloudfront.net/ui/index.html?v=1504012942606;
         proxy_pass $uiHost;
     }
     ssl_certificate /path/to/certificate;
     ssl_certificate_key /path/to/certificate/key;
 }

底部的服务器块对于多个子域是重复的，/api路径通常指向不同端口上的同一服务器。一个子域获得了大量的通信量。上游服务器（本例中为1.2.3.4)配置了EC2安全组，只允许从NGINX服务器进行访问。显然，错误消息表明运行Express应用程序的上游服务器可能有问题，但我们的日志中没有任何信息表明发生了这种情况。

最后要注意几件事：

• 我最近将worker_connections从768增加到10000，这似乎使问题发生的频率略有降低。但是，我们从未达到接近连接限制的任何位置，并且连接正在关闭。
• 在此增加之后，每次在NGINX上执行重新加载时，我们在大约10分钟内不会得到任何这些错误。这是我认为NGINX是罪魁祸首的主要原因，但我不是专家。
• 我在搜索时确实看到了之前的一篇文章，指出proxy_set_header Host$Host，语句可能导致了这种情况，这对我来说没有太大意义，但值得思考。我尚未测试删除此内容。
• 带有express应用程序的API服务器似乎总是正常运行，从我们可以看出，该服务器并没有承受太大的负载
• 此问题不会出现在CloudFront的代理上

有人对进一步调查有什么明显的想法吗？我们真的很需要帮助，因为我们很迷路。

更新：我按照建议在日志中添加了一些额外的变量，并能够将错误与访问日志联系起来。以下是相关变量：

{

    "offset": 64270628,
    "response_status": "504",
    "upstream_header_time": "60.001",
    "input_type": "log",
    "source": "/var/log/nginx/access.log",
    "request_method": "GET",
    "http_user_agent": "Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko",
    "@timestamp": "2017-08-30T15:29:15.981Z",
    "upstream_connect_time": "60.001",
    "request_user": "-",
    "response_time": "60.001",
    "request_bytes_sent": "345",
    "request_id": "90a41e2224cc4b2c1d3c23d544b9146c",
    "timestamp": "30/Aug/2017:15:29:15 +0000"
  }

Answer 1

在我的例子中，我遇到了完全相同的问题，并且在一个私有子网内有一个NGINX反向代理&与之相关联的NAT网关。

问题是分配给NGINX实例的可用连接数（在NAT网关上设置）不够，而且不能自动伸缩。

这不是NGINX的问题，也不是NGINX背后的后端API的问题。

对于GCP，可以在CloudNAT控制台修改此设置。有关具体情况，请参阅本答案。