worker_rlimit_nofile是单个nginx worker进程文件描述符上限，必须与系统ulimit、内核fs.file-max及events中worker_connections协同配置，否则将触发502错误或静默回退；需置于main上下文，通过/proc/pid/limits验证生效。
调高 worker_rlimit_nofile 是释放 Nginx 在高并发场景下文件句柄瓶颈的关键一步，但它本身不“释放”句柄，而是为每个 worker 进程设定可打开文件数的上限，避免因系统限制导致连接被拒绝或 502/503 错误。
理解 worker_rlimit_nofile 的作用边界
该指令设置的是单个 worker 进程能打开的最大文件描述符数量（包括 socket、日志文件、临时文件等），它不会自动回收已用句柄，也不影响系统全局限制。若设得过低（如默认 1024），在万级并发时极易触发 “Too many open files”；若设得过高但未同步调整系统级限制，Nginx 启动会失败或静默回退到系统默认值。
- 它只对 fork 出来的 worker 进程生效，master 进程不受此限制
- 实际可用值受操作系统
ulimit -n和/proc/sys/fs/file-max双重约束 - 需配合
events.use（如 epoll）和worker_connections协同配置
正确配置的三步联动
单独改 worker_rlimit_nofile 无效，必须与系统层、Nginx 层参数对齐：
-
查当前系统限制：运行
ulimit -n（当前 shell）、cat /proc/$(pidof nginx)/limits | grep "Max open files"（确认 worker 进程实际生效值） -
提升系统级限制：编辑
/etc/security/limits.conf，添加：
nginx soft nofile 65536
nginx hard nofile 65536
并确保 systemd 服务未覆盖（检查/etc/systemd/system/nginx.service.d/override.conf是否含LimitNOFILE=） -
匹配 Nginx 配置：在
nginx.conf的 main 上下文中写：
worker_rlimit_nofile 65536;
events {
worker_connections 65536;
use epoll;
}
验证是否真正生效
配置后 reload 并观察三项指标是否一致：
- Nginx error.log 中无 “open() failed (24: Too many open files)” 报错
-
lsof -p $(pidof nginx) | wc -l显示的句柄数稳定在预期范围内（通常略高于并发连接数） - 用
ab或wrk压测时，错误率下降、平均延迟收敛，且netstat -an | grep :80 | wc -l能接近设定的worker_connections
常见踩坑点
很多问题不是参数没设，而是被其他机制抵消：
- systemd 默认限制
LimitNOFILE=1024，即使 limits.conf 改了也无效，必须显式覆盖 -
worker_rlimit_nofile必须放在 events 块之外（main 上下文），放错位置会导致语法错误或忽略 - 多个 worker 进程共享系统总句柄池，若
worker_processes auto在 32 核机器上启 32 个进程，总需求 = 32 × 65536，可能超出fs.file-max，需同步调高：sysctl -w fs.file-max=2097152
