Nginx Worker进程句柄泄露是连接或文件描述符长期未释放导致的缓慢堆积，需通过lsof持续观察、file-nr核对及limits比对确认真泄露；重点排查open_file_cache、ssl_session_cache、proxy_buffering等配置，对齐后端keepalive超时，并启用keepalive复用与socket保活。
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 配置中易滞留句柄的模块
很多“泄露”其实是配置与业务不匹配导致的资源滞留：
-
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 卡在写阶段
不复杂但容易忽略
