代理到 Node/Express 上游時不常見的 NGINX 錯誤/超時（連接到上游時上游超時）

Question

我們部署了一個 Express Web API，它在通過 NGINX 代理的 EC2 ubuntu 服務器上運行時獲得了不錯但仍然相對較少的流量（平均每秒大約 10 個請求）。 每隔一段時間，一個請求就會掛起，如果客戶端等待足夠長的時間，包含以下內容的行將輸出到 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 上reload ，我們在大約 10 分鍾內不會收到任何這些錯誤。 這是我認為 NGINX 是罪魁禍首的主要原因，但我不是專家。
• 谷歌搜索proxy_set_header Host $host;時，我確實在某處看到了以前的帖子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

在我的情況下，我遇到了完全相同的問題，並且在與之關聯的私有子網和 NAT 網關中有一個 NGINX 反向代理。

問題是分配給 NGINX 實例的可用連接數 - 在 NAT 網關上設置 - 不夠並且沒有自動擴展。

這不是 NGINX 的問題，也不是 NGINX 背后的后端 API 的問題。

對於 GCP，此設置可在 CloudNAT 控制台中修改。 具體可以參考這個回答。