文件描述符泄漏是Nginx中隐蔽高发的502根源，表现为连接缓慢失败、偶发拒绝；通过error.log报错、lsof对比ulimit、错误时间规律三步可快速锁定，再分层定位Nginx worker、上游服务或Unix Socket源头，结合重启、调高nofile限制、配置worker_rlimit_nofile及常态化监控实现缓解与根治。
文件描述符（file descriptor，简称 fd）泄漏是 Nginx 环境中一种隐蔽但高发的 502 根源——它不报错、不崩溃，却会让上游连接缓慢失败、偶发拒绝、最终批量返回 502 Bad Gateway。这类问题常被误判为“后端挂了”或“网络抖动”，实际是系统级资源耗尽在悄悄拖垮代理链路。
确认是否真是 fd 泄漏引发的 502
先别急着调配置，用三步快速锁定：
• 查 Nginx error.log 中是否高频出现 connect() failed (24: Too many open files) 或 accept() failed (24: Too many open files)
• 执行 lsof -p $(cat /var/run/nginx.pid) | wc -l，对比结果与 ulimit -n 输出值——若接近或等于上限（如 1024/65535），风险极高
• 观察 502 出现前是否有明显时间规律（如每 12 小时陡增）、是否伴随请求量平稳但错误率爬升
定位泄漏源头：Nginx 自身还是上游服务？
fd 泄漏可能发生在任一环节，需分层验证：
• Nginx worker 进程：运行 lsof -p $(pgrep nginx | head -1) | grep socket | wc -l，持续观察 5 分钟内 socket 数是否只增不减
• 上游服务（如 PHP-FPM/Node.js）：查其主进程 fd 数（lsof -p $(pgrep php-fpm | head -1) | wc -l），特别留意大量 REG（普通文件）或 IPv4 连接堆积
• Unix Socket 文件：若用 fastcgi_pass unix:/run/php/php-fpm.sock，检查该 sock 文件权限及父目录 inotify 句柄是否异常占用（ls -l /proc/*/fd/ | grep inotify | wc -l）
临时缓解与永久修复措施
发现泄漏后，先保服务再根治：
• 立即生效：重启 Nginx（nginx -s reload）可重置 worker fd 计数；若上游也泄漏，同步重启（如 systemctl restart php-fpm）
• 加固上限：修改 /etc/security/limits.conf，为 nginx 用户加两行：nginx soft nofile 65535nginx hard nofile 65535
并确保 systemd 未覆盖（检查 /etc/systemd/system/nginx.service.d/override.conf 是否含 LimitNOFILE=）
• 配置兜底：在 nginx.conf 的 events 块中显式声明：worker_rlimit_nofile 65535;
避免依赖系统默认值
预防性监控与日志线索
靠人工排查太被动，建议加入日常巡检：
• 在 crontab 加一条每 5 分钟执行的脚本：lsof -p $(cat /var/run/nginx.pid 2>/dev/null) | wc -l >> /var/log/nginx/fd_count.log
• 启用 Nginx stub_status 模块，通过 curl http://127.0.0.1/nginx_status 关注 Active connections 与 Reading/Writing/Waiting 的长期趋势是否失衡
• 上游服务开启连接池健康指标（如 PHP-FPM 的 pm.status_path = /status），重点盯 listen queue len 和 max listen queue ——若前者持续非零，说明新连接进不来，fd 已卡死
