应先查nginx运行用户硬限制，再确认systemd的limitnofile设置，最后通过/proc/pid/limits验证worker进程实际限制，并以journalctl日志定位setrlimit失败原因。
直接检查 worker_rlimit_nofile 是否过大，不能只看配置文件写了多大，而要查它在运行时是否被系统拒绝——常见报错是 setrlimit(RLIMIT_NOFILE ...) failed (1: Operation not permitted)，这说明 Nginx 主进程尝试申请的值超出了系统允许的硬限制。
先确认系统对 nginx 用户的实际硬限制
该值决定 worker_rlimit_nofile 的上限，必须优先查清：
- 查 Nginx 运行用户：运行
ps -eo pid,comm,user | grep nginx | grep master，记下用户名（如www-data或nginx） - 查该用户的硬限制：执行
sudo -u nginx bash -c "ulimit -Hn"（把nginx换成实际用户名），输出就是当前生效的hard nofile - 若输出是
1024或4096，那配置worker_rlimit_nofile 65535必然失败
检查 systemd 是否覆盖了限制（主流部署方式）
用 systemctl 管理 Nginx 时，LimitNOFILE 会覆盖用户级 limits：
- 运行
systemctl show nginx | grep LimitNOFILE - 若输出为
LimitNOFILE=4096或为空（即未设置），说明 systemd 没放行，Nginx 启动时仍继承默认低限 - 此时即使
/etc/security/limits.conf改了也无效，因为 systemd 不读它
验证运行中 worker 进程的真实限制
配置改完后不重启，或只 reload，worker_rlimit_nofile 不会生效。必须 restart 并验证：
- 取一个 worker 进程 PID：
pgrep -f "nginx: worker" - 查其实际限制：
cat /proc/PID/limits | grep "Max open files" - 重点看 Soft Limit 是否等于你配置的值；若仍是
1024或远小于配置值，说明某一层没对齐
语法检查本身不会报“过大”错误，但启动日志会暴露问题
nginx -t 只校验语法和路径，不检查系统资源限制是否满足。真正发现问题要靠启动日志：
- 执行
sudo systemctl restart nginx后，立即查日志：sudo journalctl -u nginx -n 20 --no-pager - 搜索关键词：
Operation not permitted、setrlimit、Too many open files - 若看到
worker process xxx exited on signal 25: setrlimit(RLIMIT_NOFILE 131072) failed (1: Operation not permitted)，就明确是系统硬限太低
