worker_connections 是 nginx 内部并发连接上限，worker_rlimit_nofile 是其依赖的系统级文件描述符资源池上限；前者必须 ≤ 后者×0.7～0.85，且需系统 ulimit、systemd limitnofile 和内核 fs.file-max 协同调优才生效。
worker_connections 和 worker_rlimit_nofile 不是并列配置项，而是上下级资源约束关系：前者是 Nginx 内部定义的“并发连接处理上限”，后者是它能调用的“系统级文件描述符（fd）资源池上限”。没有后者兜底，前者就是一纸空文。
它们必须满足数值约束逻辑
worker_connections 的值必须显著小于 worker_rlimit_nofile，不能相等或反超。原因在于每个连接只是 fd 消耗的一部分，其余还要预留：
- 日志文件句柄（access.log、error.log 等）
- 上游服务连接（反向代理时每个后端连接也占 1 个 fd）
- SSL session 缓存、OCSP stapling、证书加载等 TLS 相关开销
- 临时文件、缓存文件、DNS 查询 socket（尤其多域名场景）
推荐比例范围是：worker_connections ≤ worker_rlimit_nofile × 0.7～0.85。例如设 worker_rlimit_nofile 为 65535，则 worker_connections 最好不超 52428（约 80%）。
配置位置与生效前提完全不同
二者虽常一起出现，但作用域和生效条件截然不同：
-
worker_rlimit_nofile 必须写在 nginx.conf 的 main 上下文（即 events 块和 http 块之外、全局最外层），否则启动报错：
"worker_rlimit_nofile" directive is not allowed here -
worker_connections 只能出现在
events { }块内，且需搭配use epoll;（Linux）等事件模型才真正发挥高并发能力 - worker_rlimit_nofile 单独配置无效——它只是“申请”额度，是否获批取决于系统层：用户 ulimit、systemd LimitNOFILE、内核 fs.file-max 三者都得同步放宽
配比错误会引发两类典型故障
压测或高峰时表现差异明显：
- worker_rlimit_nofile ：Nginx 启动可能成功，但新连接建立阶段就失败，错误日志常见
accept() failed (24: Too many open files)，错误集中爆发在接入层 - worker_rlimit_nofile ≥ worker_connections 但无余量：连接可建，但后续 SSL 握手、日志写入或 upstream 连接时突然耗尽 fd，表现为偶发 502、连接重置、SSL handshake timeout 等非直观错误
验证是否真生效，不能只看配置文件
改完必须检查运行中 worker 进程的实际限制：
cat /proc/$(pgrep nginx | head -1)/limits | grep "Max open files"输出的 Soft Limit 值应与你配置的 worker_rlimit_nofile 一致；同时确认 worker_processes × worker_connections 不超过该值，并留有余量。若不符，说明系统层某处没对齐，需回溯检查 limits.conf、systemd override 或用户启动环境。
