502错误在高并发下由文件描述符耗尽引发，表现为系统拒绝分配新fd导致上游连接失败；需通过error.log中“Too many open files”等提示确认，并同步调大limits.conf、ulimit及worker_rlimit_nofile三层次限制。
高并发下 Nginx 报 502，若由文件描述符（file descriptor, fd）耗尽引发，通常不是直接“Nginx 崩了”，而是它在尝试建立连接或转发请求时，系统拒绝分配新 fd——此时上游连不上、连接被拒、或后端响应中断，最终以 502 形式暴露。排查需从日志线索出发，逐层验证系统限制、Nginx 配置与运行态资源占用。
看 error.log 中的关键错误提示
打开 /var/log/nginx/error.log，搜索以下两类典型报错：
- “worker_connections are more than open file resource limit”：明确说明 Nginx 的 worker_connections 设置超过了当前进程允许打开的最大 fd 数；
- “connect() failed (24: Too many open files)” 或 “accept() failed (24: Too many open files)”：表示 accept 新连接或主动 connect 上游时，系统已无可用 fd。
这两类日志是 fd 耗尽的直接证据。没有它们，就不要优先怀疑 fd 问题。
查 Nginx 进程实际能用多少 fd
fd 限制分三层：系统级（/etc/security/limits.conf）、启动 shell 级（ulimit）、Nginx 自身配置级（worker_rlimit_nofile）。需确认三者是否对齐：
- 查当前 nginx 主进程的 fd 限制：
cat /proc/$(pgrep -f "nginx: master")/limits | grep "Max open files"； - 查启动 nginx 的用户（如 www-data）的 ulimit：
sudo -u www-data bash -c 'ulimit -n'； - 确认 nginx.conf 中是否设置了
worker_rlimit_nofile 65536;（必须放在 events 块外、http 块上方）。
若三者数值不一致（尤其 proc 中显示仍是 1024），说明 limits 没生效或 nginx 未重载。
验证系统级 fd 是否真被占满
fd 耗尽不一定是 Nginx 单独造成的，可能是其他服务或残留进程长期持有：
- 统计所有进程打开的 fd 总数：
lsof -nPi | wc -l； - 按用户统计 fd 占用：
lsof -u www-data | wc -l； - 查 top 占用 fd 的前 10 进程：
lsof -nPi | awk '{print $1}' | sort | uniq -c | sort -nr | head -10。
如果 nginx worker 进程单个已打开近 65536 个 fd，且持续增长，再结合 error.log 提示，基本可锁定为 fd 不足导致 upstream 失败，触发 502。
临时缓解与长期修复
临时缓解可快速释放 fd（但治标）：
- 重启 nginx：
sudo systemctl reload nginx（注意 reload 不会清空已有连接，restart 更彻底）； - 检查并 kill 异常长连接或僵尸 fd：
lsof -i :80 | grep CLOSE_WAIT | awk '{print $2}' | xargs kill -9（慎用）。
长期修复要同步打通三层限制：
- 修改 /etc/security/limits.conf，加入：
www-data soft nofile 65536<br> www-data hard nofile 65536
（用户名按实际替换）； - 确保 systemd 启动 nginx 时继承限制：编辑 /etc/systemd/system/multi-user.target.wants/nginx.service，在 [Service] 下加：
LimitNOFILE=65536； - Nginx 配置中启用
worker_rlimit_nofile 65536;，并调大worker_connections至匹配值（如 65536）； - 最后 reload nginx 并验证：
sudo systemctl daemon-reload && sudo systemctl restart nginx，再查 proc limits 确认生效。
