worker_rlimit_nofile是Nginx worker进程最大文件描述符数限制，须≤系统hard limit，需同步配置limits.conf和systemd LimitNOFILE并重启生效，且worker_connections应≤其70%~80%。
调优 worker_rlimit_nofile 是解决 Nginx 在反向代理高并发场景下出现“too many open files”错误的关键一步，但必须配合系统级限制和进程级配置协同生效，单独修改往往无效。
理解 worker_rlimit_nofile 的作用范围
该指令设置的是 Nginx 工作进程（worker process）能打开的最大文件描述符数，属于进程软限制（soft limit），不能超过系统对用户或进程设定的硬限制（hard limit）。它不改变系统全局句柄上限，也不影响 master 进程，仅作用于每个 worker 进程。
- 若设为
worker_rlimit_nofile 65535;，每个 worker 最多打开 65535 个句柄（含连接、日志文件、上游 socket 等） - 实际可用值取：
min(系统 hard limit, 配置值)，超出部分会被静默截断 - 需确保
worker_processes数量合理——句柄总数 = 单 worker 限额 × worker 数，避免过度预留
同步调整系统级文件句柄限制
Nginx 启动时继承启动用户的 limits，因此必须先提升系统层面的限制，否则 worker_rlimit_nofile 设置再大也无效。
- 编辑
/etc/security/limits.conf，为运行 Nginx 的用户（如www-data或nginx）添加：
nginx soft nofile 1048576<br>nginx hard nofile 1048576
- 确认 systemd 服务未覆盖限制：检查
/lib/systemd/system/nginx.service或/etc/systemd/system/nginx.service.d/override.conf，确保包含：
[Service]<br>LimitNOFILE=1048576
- 重载 systemd 配置并重启：`systemctl daemon-reload && systemctl restart nginx`
验证配置是否真正生效
不要只看配置文件，要查运行中 worker 进程的实际 limits。
- 查当前 worker 进程 PID：
ps -eo pid,comm | grep nginx | grep -v master - 查该 PID 的限制：
cat /proc/，输出应类似：/limits | grep "Max open files"
Max open files 1048576 1048576 files
- 若显示仍是 1024 或 65536，说明 limits 未正确加载，重点检查用户 session 是否重启、systemd override 是否生效、Nginx 是否由 root 启动但降权失败
结合 upstream 和 keepalive 控制真实句柄消耗
即使句柄上限调高，若后端连接管理不当，仍可能快速耗尽。反代场景下，每个客户端连接 + 每个上游连接各占至少 1 个 fd，长连接复用可显著降低压力。
- 在
upstream块中启用连接池：
upstream backend {<br> server 127.0.0.1:8000;<br> keepalive 32;<br>}<br><br>location / {<br> proxy_pass http://backend;<br> proxy_http_version 1.1;<br> proxy_set_header Connection '';<br>}- 避免 upstream 中使用过多 server 或频繁 health_check 导致连接预热开销过大
- 监控真实句柄使用：`lsof -p
| wc -l`，对比配置值判断余量是否健康
