要让nginx稳定支撑海量静态资源高并发，需同步调高系统级limitnofile、进程级ulimit及nginx的worker_rlimit_nofile，并合理配置worker_connections与events参数。
要让 Nginx 稳定支撑海量静态资源的高并发访问，worker_rlimit_nofile 必须调高，但不能只改这一项——它只是“申请上限”，真正起作用的是系统给 nginx 进程分配了多少文件描述符。句柄溢出（Too many open files）本质是资源没配齐，得从系统层、进程启动层、Nginx 配置层三处同步动手。
确认当前限制瓶颈在哪
先别急着改配置，查清真实限制值：
- 看 nginx 用什么用户跑：
ps -eo pid,comm,user | grep "nginx: worker" | head -1 - 切到该用户查软硬限制：
sudo -u nginx bash -c 'ulimit -Sn; ulimit -Hn' - 查 systemd 是否覆盖了限制：
systemctl show nginx | grep LimitNOFILE - 查已运行 worker 进程实际生效值：
cat /proc/$(pgrep -f "nginx: worker" | head -1)/limits | grep "Max open files"
如果 Soft Limit 是 1024 或 4096，而你压测时并发刚过几千就报错，那这就是根因。
同步放宽系统级文件描述符限制
根据你的部署方式选一种，不能跳过：
-
用 systemd 启动（主流）：新建
/etc/systemd/system/nginx.service.d/override.conf，写入：[Service]<br>LimitNOFILE=65536
然后执行：sudo systemctl daemon-reload && sudo systemctl restart nginx -
用 limits.conf（传统方式）：编辑
/etc/security/limits.conf，添加两行（用户名替换成实际运行用户，如nginx或www-data）：nginx soft nofile 65536<br>nginx hard nofile 65536
并确认/etc/pam.d/common-session中有session required pam_limits.so
注意：硬限制（hard nofile）必须 ≥ 你要设的 worker_rlimit_nofile 值，否则 Nginx 启动会失败并报 setrlimit(RLIMIT_NOFILE) failed。
在 nginx.conf 中正确设置 worker_rlimit_nofile
打开 /etc/nginx/nginx.conf，在最外层（main 上下文）、events 块上方添加：
worker_rlimit_nofile 65536;
- 必须放在
http、server、location外面，否则启动报unknown directive - 数值建议 ≤ 系统硬限制的 90%，比如硬限制是 65536，这里设 65535 更稳妥
- 不要设得远高于实际需要——静态资源服务虽不涉及大量 upstream 连接，但仍需预留 fd 给日志、临时文件、SSL 会话缓存等
关联调优 worker_connections 和 events 参数
光有足够句柄还不够，得让 Nginx 知道怎么用：
- 在
events块中设置：events {<br> use epoll;<br> worker_connections 50000;<br> multi_accept on;<br>} -
worker_connections应 ≤worker_rlimit_nofile × 0.75～0.8，例如设了 65536，这里最多配 50000 - 确保
worker_processes合理：静态资源场景 CPU 不是瓶颈，auto即可；若为容器环境，建议匹配分配的 CPU 核数 - 开启
epoll（Linux）和multi_accept on可提升短连接吞吐，减少 accept 队列积压
理论最大并发 ≈ worker_processes × worker_connections，但真实承载还取决于磁盘 I/O（静态文件读取）和网络带宽。
