当 Nginx 出现连接数耗尽，用户可能看到连接超时、502/504，错误日志中出现 worker_connections are not enough 或 Too many open files。扩大参数只能暂时缓解，必须区分客户端连接、上游连接、长连接和操作系统限制。
一、确认故障现象
date
uptime
systemctl status nginx --no-pager
nginx -t
tail -n 200 /var/log/nginx/error.log
ss -s
ss -ant | awk 'NR>1 {print $1}' | sort | uniq -c | sort -nr
ss -ant sport = :443 | wc -l如果 ESTAB 很高，关注真实并发和长连接；TIME-WAIT 高要检查短连接；SYN-RECV 高要排查突发流量、攻击、丢包和后端处理慢。
二、检查 Nginx 实际配置
nginx -T 2>/dev/null | grep -E 'worker_processes|worker_connections|worker_rlimit_nofile|keepalive_timeout|keepalive_requests'理论连接上限大致为：
最大客户端连接 ≈ worker_processes × worker_connections但反向代理场景中，一个请求通常同时占用客户端连接和上游连接，实际承载量会更低。WebSocket、SSE 和长轮询也会长期占用连接。
三、检查文件句柄限制
pgrep -a nginx
cat /proc/<worker_pid>/limits | grep -i 'open files'
ls /proc/<worker_pid>/fd | wc -l
cat /proc/sys/fs/file-nr
sysctl fs.file-max
systemctl show nginx -p LimitNOFILE
systemctl cat nginx不要只看 /etc/security/limits.conf。systemd 启动的 Nginx 可能由 LimitNOFILE 控制。修改后需要重载 systemd，并再次读取 /proc/<pid>/limits 验证实际进程限制。
四、检查连接集中在哪里
ss -antp | grep nginx | head
ss -ant | awk '{print $5}' | sed 's/::ffff://' | cut -d: -f1 | sort | uniq -c | sort -nr | head结合 access log 分析请求来源、URI、状态码和耗时。若启用了 stub_status，观察 Active、Reading、Writing、Waiting。
上游连接也要检查：
ss -ant dst <upstream_ip>:<port> | awk 'NR>1 {print $1}' | sort | uniq -c
curl -s http://127.0.0.1/nginx_status大量连接卡在 Writing 或上游 ESTABLISHED，可能是后端响应慢、客户端下载慢或代理缓冲配置不合理。
五、应急处理步骤
确认是否有异常来源或热点接口，必要时在负载均衡/WAF 层限速。
缩短不合理的空闲长连接时间，但不要让正常客户端频繁重连。
在操作系统允许范围内提高文件句柄和
worker_connections。后端服务变慢时，先扩容或降级后端，而不是只扩 Nginx。
配置修改后执行
nginx -t，再平滑重载。观察旧 worker 是否正常退出，避免旧连接长期不释放。
六、示例配置与风险
worker_processes auto;
worker_rlimit_nofile 200000;
events {
worker_connections 32768;
multi_accept on;
}该数值只是示例，必须结合内存、内核参数、负载均衡容量和压测结果。盲目扩大上限可能把压力传递给应用和数据库，造成更大范围雪崩。
七、长期治理
监控活跃连接、请求率、响应时间、5xx 和连接拒绝。
监控进程 FD 使用率，而不仅是系统
file-max。对 WebSocket、上传下载和普通 API 分开规划入口与超时。
对热点 URI、异常来源和慢客户端建立可观测性。
容量评估同时计算客户端连接、上游连接、TLS 开销和内存。
通过压测验证连接上限和降级策略。
连接数故障的核心是判断“连接为什么不释放”，而不是把所有限制调到无限大。