我目前有以下 Nginx 配置。它大部分时间都运行良好。出于某种原因，有一定比例的请求需要很长时间，但它们不会丢失。可能最多几分钟。
然后它们通过，以每秒 5-10kbs 的速度发送文件，而正常请求可能会达到每秒几兆的速度，并在几秒钟内开始。
任何有关调试此问题的帮助都将不胜感激。
user sysadminguy;
worker_processes auto;
pid /run/nginx.pid;
worker_rlimit_nofile 25000;
events {
worker_connections 1080;
# multi_accept on;
}
http {
##
# Basic Settings
##
access_log off;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
# server_tokens off;
# server_names_hash_bucket_size 64;
# server_name_in_redirect off;
include /etc/nginx/mime.types;
default_type application/octet-stream;
##
# Logging Settings
##
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
#limit_req_zone $binary_remote_addr zone=mylimit:100m rate=10r/m;
##
# Gzip Settings
##
gzip on;
gzip_disable "msie6";
##
# Virtual Host Configs
##
upstream backend {
least_conn;
server 1.1.1.2:3292 fail_timeout=10s weight=1;
server 1.1.1.3:3292 fail_timeout=10s weight=1;
server 1.1.1.4:3292 fail_timeout=10s weight=1;
server 1.1.1.5:3292 fail_timeout=10s weight=1;
server 1.1.1.6:3292 fail_timeout=10s weight=2;
server 1.1.1.7:3292 fail_timeout=10s weight=2;
}
server {
listen 80;
server_name server1.example.com;
location / {
return 301 https://$server_name$request_uri;
}
}
server {
listen 443 ssl http2 default_server;
server_name server1.example.com;
ssl on;
ssl_certificate /etc/letsencrypt/live/server1.com-0001/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/server1.com-0001/privkey.pem; # managed by Certbot
location = / {
return 301 https://example.com;
}
location / {
#limit_req zone=mylimit burst=20;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_read_timeout 3600;
proxy_request_buffering off;
proxy_buffering off;
proxy_pass http://backend;
}
location /nginx_status {
# Turn on stats
stub_status on;
access_log off;
# only allow access from 192.168.1.5 #
#allow 192.168.1.5;
#deny all;
}
}
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
答案1
尝试keepalive_timeout通过将该值设置为 来禁用它0。
您的配置中最让我印象深刻的是这一行：
keepalive_timeout 65;
根据 Nginx 官方文档，默认值为keepalive_timeout是 65 秒。但根据我的经验，任何 Web 服务器（Nginx、Apache 甚至 IIS）的保持活动设置都应该在 2 到 3 秒左右。
知道我将设置该值以0有效地禁用 Nginx 中的保持活动功能，如下所示：
keepalive_timeout 0;
然后重新启动 Nginx 并查看是否解决问题。
理解保持活动设置的最佳方式是，保持活动仅在服务器上才有价值，在服务器上，与 Nginx 的一个连接将一次向客户端浏览器传递大量相关资产。
想象一下一个图片库页面，里面有几十张图片。设置一个较高的 keep alive 设置可能帮助通过一个 Nginx 连接干净高效地一次性传送所有这些图像。
这是理论。在实践中，最好禁用保持活动设置，或者简单地将其设置为足够低的值以便实用。知道你可能想要尝试将该值设置为 2 秒左右，如下所示：
keepalive_timeout 2;
重启 Nginx 并查看效果如何。应该与将该值设置为 一样高效0。
话虽如此，或许fail_timeout配置的值也upstream与该问题有关。
但深入研究一下您的配置，我看到了以下设置：
upstream backend {
least_conn;
server 1.1.1.2:3292 fail_timeout=10s weight=1;
server 1.1.1.3:3292 fail_timeout=10s weight=1;
server 1.1.1.4:3292 fail_timeout=10s weight=1;
server 1.1.1.5:3292 fail_timeout=10s weight=1;
server 1.1.1.6:3292 fail_timeout=10s weight=2;
server 1.1.1.7:3292 fail_timeout=10s weight=2;
}
根据我自己的经验，该fail_timeout设置不应该如此10s，而应该0如此配置：
upstream backend {
least_conn;
server 1.1.1.2:3292 fail_timeout=0 weight=1;
server 1.1.1.3:3292 fail_timeout=0 weight=1;
server 1.1.1.4:3292 fail_timeout=0 weight=1;
server 1.1.1.5:3292 fail_timeout=0 weight=1;
server 1.1.1.6:3292 fail_timeout=0 weight=2;
server 1.1.1.7:3292 fail_timeout=0 weight=2;
}
重新启动 Nginx 并查看其工作原理。根据您的描述，后端池中的每个节点似乎都会等待 10 秒才会失败。因此，例如，如果存在一些整体网络连接问题，则该池中的节点可能要等到 60 秒后才能访问（每个节点 6 次 10 秒延迟）。
如果由于某种原因，最终导致出现 503（服务不可用）错误，那么也许可以为fail_timeouthas value 设置一个实际值。也许将其设置为 3s，然后看看效果如何？
总的来说，我认为keepalive_timeout背景是这里的核心问题。fail_timeout 可能起到一定作用，但我对更深层次的设置了解不够，无法对此做出判断。