需协同调大Nginx进程级、系统级、用户级三处文件描述符限制，即配置worker_rlimit_nofile、/etc/security/limits.conf及systemd的LimitNOFILE，并确保worker_connections≤worker_rlimit_nofile。
要解决反向代理在海量连接下因系统句柄不足导致的 worker_rlimit_nofile 相关错误（如 accept() failed (24: Too many open files)），核心是**协同调大 Nginx 进程级、系统级、用户级三处文件描述符限制**，而非仅改一个配置项。
确认当前瓶颈位置
先判断问题是否真出在 Nginx worker 进程的打开文件数限制上：
- 查看 Nginx 错误日志中是否有
Too many open files或accept() failed报错 - 运行
cat /proc/$(pgrep nginx | head -1)/limits | grep "Max open files"，检查实际生效的 soft/hard limit 值 - 对比该值与
worker_rlimit_nofile配置值是否一致——若不一致，说明系统或用户限制覆盖了 Nginx 配置
正确配置 worker_rlimit_nofile
该指令需放在 main 块（即全局上下文），不能写在 http 或 server 块内：
user nginx;
worker_processes auto;
<h1>必须在 main 块中设置，单位是每个 worker 进程可打开的文件数</h1><p>worker_rlimit_nofile 65535;</p><p>events {
use epoll;
worker_connections 65535;
}注意：worker_connections 应 ≤ worker_rlimit_nofile，否则 worker 无法建立满额连接；若启用多 worker（如 4 个），则系统总并发能力理论上限为 worker_rlimit_nofile × worker_processes。
同步调整系统级和用户级限制
Nginx 启动时会继承启动用户的 ulimit 设置。若未显式提升，worker_rlimit_nofile 可能被截断：
- 编辑
/etc/security/limits.conf，为 nginx 用户（或其所属组）添加：
nginx soft nofile 65535 nginx hard nofile 65535 * soft nofile 65535 * hard nofile 65535
- 确保 systemd 管理的 Nginx 能读取 limits：编辑
/etc/systemd/system/multi-user.target.wants/nginx.service或使用 drop-in：
[Service] LimitNOFILE=65535
然后执行 systemctl daemon-reload && systemctl restart nginx。
验证最终生效值
重启后再次检查：
- 确认 Nginx 主进程 PID：
pgrep nginx（主进程通常 UID 较低） - 查看其 limits：
cat /proc/<pid>/limits | grep "Max open files" - 输出应显示 soft = 65535，hard ≥ 65535；若仍为 1024 或 4096，说明 limits.conf 或 systemd 配置未生效
- 同时用
ss -s观察 ESTAB 连接数是否明显提升，且错误日志不再出现句柄耗尽报错
不复杂但容易忽略：Nginx 的 worker_rlimit_nofile 是“申请上限”，真正能否拿到，取决于它启动时所处环境的资源配额。三者（Nginx 配置、用户 limits、systemd 限制）必须对齐，缺一不可。
