应直接查看nginx master进程的/proc/[pid]/limits，软限制值（左数）即实际生效值；若为1024，需逐层验证系统file-max、nginx用户ulimit、systemd limitnofile及nginx.conf中worker_rlimit_nofile是否对齐。
直接查进程实际限制值，别依赖 ulimit -n 或猜配置是否生效。Nginx 报 “Too many open files”，大概率是某一层限制卡在 1024，而你改的那层根本没作用到它身上。
看 Nginx master 进程当前生效的限制
这条命令最真实：
sudo cat /proc/$(cat /var/run/nginx.pid)/limits | grep "Max open files"
输出类似 Max open files 1024 4096 files，左边数字就是当前真正起作用的软限制。如果它是 1024，说明 Nginx 启动时没拿到你设的高值。
顺藤摸瓜查四层限制是否对齐
逐层验证，缺一不可：
-
系统全局上限：运行
cat /proc/sys/fs/file-max，建议 ≥ 200000 -
nginx 用户的 ulimit 值：用该用户身份执行
sudo -u nginx bash -c 'ulimit -Sn; ulimit -Hn' -
systemd 服务限制（如适用）：检查
sudo systemctl show nginx | grep LimitNOFILE，或直接查服务配置sudo systemctl cat nginx | grep LimitNOFILE -
Nginx 自身配置：确认
/etc/nginx/nginx.conf中有worker_rlimit_nofile 65535;，且在 events 块中worker_connections不超过该值
常见“改了却无效”的三个关键点
limits.conf 生效失败，九成卡在这三处：
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
-
没写 nginx 用户专属行：只写
* soft nofile 65535不够稳妥，必须加nginx soft nofile 65535和nginx hard nofile 65535 -
PAM 模块未启用：Ubuntu/Debian 查
/etc/pam.d/common-session，RHEL/CentOS 查/etc/pam.d/login，确认含session required pam_limits.so -
systemd 覆盖了 limits.conf：用 systemd 启动的 Nginx，即使 limits.conf 正确，也必须显式设置
LimitNOFILE=65535（通过systemctl edit nginx）
验证 worker 进程是否真拿到新限制
master 进程限制调高了，不代表 worker 就自动继承。执行：
ps --ppid $(cat /var/run/nginx.pid) -o %p | sed '1d' | xargs -I{} cat /proc/{}/limits | grep "Max open files"
如果输出仍是 1024 4096，说明前面某一层没打通——重点回头查 systemd 配置和 PAM 是否就位，而不是去调 worker_connections。
