如何处理 Nginx Worker 进程的句柄泄露-Nginx-PHP中文网

nginx worker进程句柄泄露是连接或文件描述符长期未释放导致的缓慢堆积，需通过lsof持续观察、file-nr核对及limits比对确认真泄露；重点排查open_file_cache、ssl_session_cache、proxy_buffering等配置，对齐后端keepalive超时，并启用keepalive复用与socket保活。

如何处理 nginx worker 进程的句柄泄露

Nginx Worker 进程出现句柄泄露，不是“突然爆满”，而是连接或文件描述符长期未释放，缓慢堆积直至耗尽。它常表现为：accept() failed (24: Too many open files) 错误持续出现、lsof -p [worker_pid] | wc -l 数值持续攀升、/proc/[pid]/fd/ 目录下大量残留句柄，且重启后短期内又快速回升。

关键不是加上限，而是找出“该关没关”的源头。需从配置、连接生命周期、后端协同三方面入手。

查清真实泄露迹象，别只看报错

先确认是不是真泄露，而非单纯容量不足：

执行 lsof -p $(pgrep -f "nginx: worker" | head -1) | wc -l，连续观察 5 分钟，若数值稳定在 worker_connections × 1.2 附近，属正常；若每分钟涨几十甚至上百，且不回落，就是泄露
检查 /proc/sys/fs/file-nr，看 allocated 是否持续逼近 file-max，排除系统级池子枯竭干扰
对比 cat /proc/[pid]/limits | grep "Max open files" 中的 soft limit 和当前打开数，差值小于 500 时才需怀疑配置不足；差值仍很大但句柄数还在涨，基本可锁定泄露

重点排查 Nginx 配置中易滞留句柄的模块

很多“泄露”其实是配置与业务不匹配导致的资源滞留：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

open_file_cache：启用后若 inactive 时间设得过大（如 300s），而业务大量访问短命静态文件（如图标、JS 片段），缓存条目不会及时淘汰，对应 fd 无法释放。建议设为 20s～60s，并开启 open_file_cache_errors on 主动剔除失效项
ssl_session_cache：共享内存区满时，新握手退化为全握手，不仅 CPU 升高，还会临时分配堆内存和 fd。检查 $ssl_session_reused 变量统计命中率，低于 70% 就需扩容或调优超时（如 ssl_session_timeout 4h）
proxy_buffering off：关闭缓冲时，Nginx 会为每个 upstream 响应预分配大缓冲区（可能达几 MB），若后端响应体大、延迟高或中断，这些缓冲区及关联 fd 易堆积。建议保持 on，并合理设置 proxy_buffer_size 和 proxy_buffers
access_log 路径含变量（如 $host、$request_uri）：每次匹配都可能打开新日志文件，句柄数随请求多样性线性增长。应统一用固定路径，或启用 open_log_file_cache 缓存句柄

对齐 Nginx 与后端的连接生命周期

反代场景下，90% 的句柄堆积发生在 upstream 连接侧：

后端应用（Spring Boot/Node.js/PHP-FPM）的 keepalive 超时必须短于 Nginx 的 keepalive_timeout，否则连接在后端空闲等待，Nginx 却认为仍可用，造成“半开连接”堆积

在 upstream 块中明确启用连接复用控制：

upstream backend {
    server 127.0.0.1:8080 max_fails=3 fail_timeout=30s;
    keepalive 32;  # 复用连接池大小
}

在 location 中强制透传 HTTP/1.1 并清空 Connection 头：

proxy_http_version 1.1;
proxy_set_header Connection '';
proxy_socket_keepalive on;  # 启用 socket 层保活探测

后端服务必须绑定 127.0.0.1 或内网地址，严禁 0.0.0.0；防火墙禁止外部直连后端端口，杜绝绕过 Nginx 的非法连接

验证与持续监控不能省

调优后不验证，等于没做：

重启 Nginx 后，立刻查 cat /proc/$(pgrep -f "nginx: worker" | head -1)/limits | grep "Max open files"，确认 soft/hard limit 已生效
用 watch -n 1 'lsof -p $(pgrep -f "nginx: worker" | head -1) | wc -l' 观察句柄数变化趋势，压测 10 分钟看是否收敛
启用 stub_status，通过 curl http://127.0.0.1/nginx_status 关注 Active connections 与 Writing 状态比例，若 Writing 长期占比过高（>30%），说明响应发不出去，fd 卡在写阶段

不复杂但容易忽略