本质是连接“该关不关”导致fd堆积，需从生命周期管理入手：先验证长连接是否滞留（查ss、lsof），再检查WebSocket/proxy超时配置是否生效，最后通过reload优雅清理并启用主动探活。
遇到长连接超时未断开、进而触发 worker_rlimit_nofile 耗尽报警，本质是连接“该关不关”，堆积在 Nginx worker 进程里持续占用文件描述符（fd）。这不是单纯调大上限就能解决的问题，而是要从连接生命周期管理入手，定位滞留原因并切断无效长连接。
确认长连接是否真在堆积
别只看错误日志里的 “Too many open files”，先验证是不是长连接没释放导致 fd 持续上涨：
- 查当前活跃连接数：
ss -tn state established | grep :80 | wc -l（替换端口），对比worker_processes × worker_connections是否接近上限 - 查 worker 进程实际打开的 fd 数：
ls /proc/$(pgrep nginx | head -1)/fd/ | wc -l，若稳定在 6w+ 且缓慢爬升，大概率是连接滞留 - 抓取连接归属：用
lsof -p $(pgrep nginx | head -1) | grep TCP | awk '{print $9}' | sort | uniq -c | sort -nr | head -10，看是否有大量来自同一客户端 IP 或后端服务的长时间 ESTABLISHED 连接
检查 WebSocket 或 HTTP/1.1 长连接配置是否失控
WebSocket 和启用了 keepalive 的 HTTP 反向代理最容易造成连接滞留，尤其在后端异常或网络抖动时：
- WebSocket 场景下，必须确保
proxy_read_timeout和proxy_send_timeout显式设为合理值（如 3600s），不能留默认值（60s）；否则客户端静默断网后，Nginx 仍会维持连接等待读写事件 - HTTP keepalive 到上游（upstream）时，
keepalive 32后需配proxy_http_version 1.1和proxy_set_header Connection ''，否则连接复用可能失效，反而新建更多连接 - 检查是否漏配
proxy_next_upstream error timeout http_502，当后端异常但连接未断开时，Nginx 不会主动探活或重试，导致“僵尸连接”长期挂起
验证超时参数是否真正生效
很多问题出在配置写了但没生效，或者被更高优先级设置覆盖：
- 确认
proxy_read_timeout所在作用域：它必须在location或server块内，且不能被嵌套的if或更内层块意外覆盖 - 检查是否被 systemd 或 ulimit 截断：运行
cat /proc/$(pgrep nginx | head -1)/limits | grep "Max open files"，若 Soft Limit 远低于你设的worker_rlimit_nofile，说明系统级限制未同步，Nginx 自动降级使用低值 - 用
curl -v http://your-domain/ws/ --header "Connection: Upgrade" --header "Upgrade: websocket"模拟握手，再断开客户端网络，观察 Nginx 日志中该连接是否在proxy_read_timeout秒后关闭（日志应出现client closed connection或upstream timed out）
强制清理与兜底防护
对已堆积的连接，不能只等超时，需主动干预并加防复发机制：
- 重启前先优雅清空：执行
nginx -s reload，新 worker 启动后旧 worker 会逐步处理完剩余连接并退出；避免直接 kill -9，否则 fd 不释放 - 启用连接主动探活：在 upstream 中加入
check interval=3 rise=2 fall=3 timeout=1 type=http（需 stream-lua-module 或 commercial 版本），定期探测后端可用性，及时摘除失联节点 - 内核级兜底：调大
net.ipv4.tcp_fin_timeout（默认 60s）意义不大，反而延长残留；更有效的是降低net.ipv4.tcp_keepalive_time（如设为 600），让内核更快发现死连接并发送 RST
