根本原因是worker_rlimit_nofile未配置导致文件描述符不足，nginx worker进程无法为高并发连接分配socket，致使上游连接失败而返回502；需同步配置worker_rlimit_nofile、系统limitnofile及内核fs.file-max参数。
当 Nginx 的 worker_connections 设为 10000，但未配置 worker_rlimit_nofile，就容易在高并发时出现 502 Bad Gateway。根本原因不是 Nginx 配置本身报错，而是工作进程打开的文件描述符（file descriptor）数量受限，导致无法为新连接分配 socket，上游服务连不上，Nginx 被迫返回 502。
为什么 worker_rlimit_nofile 必须配？
Nginx 每个 worker 进程能同时处理的连接数，受两个限制共同约束：
-
worker_connections：Nginx 配置层的软上限 - 操作系统对单个进程的
nofile限制（即 ulimit -n）：硬上限
如果 worker_rlimit_nofile 不显式设置，Nginx 默认继承启动用户的 ulimit 值（常见为 1024 或 4096）。哪怕你设了 worker_connections 10000，实际仍卡在系统限制上——连接到约 1000–4000 就开始失败，日志里常伴随 connect() failed (24: Too many open files) 或 recv() failed (104: Connection reset by peer)，最终表现为 502。
怎么确认是这个原因？
分三步快速验证：
- 查当前 worker 进程的 fd 使用量：
ls /proc/$(pgrep nginx | head -1)/fd | wc -l - 查该进程的 nofile 限制：
cat /proc/$(pgrep nginx | head -1)/limits | grep "Max open files"（看 “Soft Limit” 是否远小于 10000） - 查 error.log 中是否有：
connect() to [upstream] failed (24: Too many open files)
三者若同时成立，基本可锁定问题。
正确配置方法
需在 nginx.conf 的 main 上下文中设置，并同步调大系统级限制：
- 在
nginx.conf最外层（events块上方）加：
worker_rlimit_nofile 10240; - 确保
events { worker_connections 10000; }≤ 上面值（建议留 200+ 余量） - 修改系统限制（以 systemd 启动为例）：
编辑/etc/systemd/system/nginx.service.d/override.conf，加入：
[Service]
LimitNOFILE=10240 - 重载 systemd 并重启 Nginx：
systemctl daemon-reload && systemctl restart nginx
额外提醒
别只改 Nginx 配置就以为完事。内核参数 fs.file-max 也要够用（可通过 sysctl fs.file-max 查看），一般设为 10 万以上较稳妥；另外，上游服务（如 PHP-FPM、Node.js）自身的文件描述符限制也得同步检查，否则瓶颈会前移到它们身上，照样 502。
