超时（连接上游时上游超时）

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

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

我已经在这里尝试了build议的解决scheme，但似乎没有效果。这仅仅发生在我们每分钟1-3次的知识上，但是我只是closures这些日志。如果客户在请求超时之前刷新页面或浏览，似乎没有logging。

错误消息显然表明连接到上游服务器有问题，但为什么这种情况很less发生？在导致此问题的URL中也绝对没有任何模式，并且代理的应用程序仍然可用，据我所知。这是我们的NGINXconfiguration的一个想法：

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

底部的服务器模块会针对多个子域重复使用，而/apipath通常指向不同端口上的相同服务器。一个子域获取大量的stream量。上游服务器（示例中为1.2.3.4）configuration了EC2安全组，以允许从NGINX服务器访问。显然，错误信息表明运行Express应用程序的上游服务器可能有问题，但是我们的日志中没有任何内容表明正在发生这种情况。

最后要注意一些事情：

我最近把worker_connections从768人增加到了10000人，这似乎使问题发生得less一些。但是，我们从来没有达到任何接近连接限制的地方，连接也正在closures。
在这个增加之后，每次在NGINX上完成reload ，我们在10分钟左右都不会收到这些错误。这是我认为NGINX是罪魁祸首的主要原因，但我不是专家。
在Google上searchproxy_set_header Host $host;时，我确实看到了以前的postproxy_set_header Host $host; 声明可能会造成这种情况，这对我来说没有什么意义，但应该考虑一下。我还没有testing删除这个。
具有快速应用程序的API服务器总是显示正常运行，并且该服务器没有受到我们所知的重负载
在cloudfront的代理上不会发生此问题

任何人有什么明显的或想要进一步调查什么？可能真的在这里使用一些帮助，因为我们很迷茫。

更新：我build议添加一些额外的variables日志，并能够将错误绑定到访问日志。这里是相关的variables：

 { "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" }