worker_rlimit_nofile需配合用户级ulimit生效：必须在前台启动前执行ulimit -n 65535，且配置须位于main块；验证需检查/proc//limits中软硬限制是否均为设定值，并确保≥worker_connections×worker_processes。
在非系统守护进程模式（即以普通用户身份前台运行，不通过 systemd、supervisord 等服务管理器启动）下，worker_rlimit_nofile 是 Nginx 配置指令，用于设置工作进程能打开的最大文件描述符数。但它的生效依赖于运行时环境的权限和资源限制，**仅写入 nginx.conf 并不能直接突破系统对当前用户的限制**。验证其是否真正生效，需分三步：确认配置加载、检查进程实际 limits、比对内核级限制。
确认 Nginx 已加载该配置并正常启动
确保 worker_rlimit_nofile 出现在主配置块（不在 http/server/location 内），例如：
worker_processes 2;<br>worker_rlimit_nofile 65535;<br><br>events {<br> worker_connections 4096;<br>}
然后以非 root 用户前台启动：
./nginx -c /path/to/nginx.conf -g "daemon off;"
启动后立即检查是否报错：
- 若提示
invalid number of file descriptors或setrlimit(RLIMIT_NOFILE) failed，说明当前用户无权设到该值，配置未生效； - 若静默启动成功，继续下一步验证。
查看运行中 worker 进程的实际文件描述符限制
Nginx 启动后，找到任一 worker 进程 PID（如 ps aux | grep nginx | grep -v master），再查其 limits：
cat /proc/<pid>/limits | grep "Max open files"</pid>
输出类似：
Max open files 65535 65535 files
注意两点：
- 软限制（soft limit）和硬限制（hard limit）都应等于你配置的数值（如 65535），否则说明
worker_rlimit_nofile被忽略或降级； - 若显示为系统默认值（如 1024/4096），常见原因是启动前 shell 的 ulimit 未调高，或用户未被授予足够权限。
验证是否受用户级 ulimit 限制影响
非守护进程模式下，Nginx 继承启动 shell 的资源限制。必须在启动前显式提升：
ulimit -n 65535<br>./nginx -c /path/to/nginx.conf -g "daemon off;"
若跳过这步，即使配置了 worker_rlimit_nofile 65535，Nginx 仍只能拿到 shell 当前的 soft limit（通常较低）。可提前检查：
ulimit -Sn # 查看当前 soft limit<br>ulimit -Hn # 查看当前 hard limit
若 hard limit 不足，需修改用户 limits 配置（如 /etc/security/limits.conf），或使用 prlimit 启动时覆盖：
prlimit -n65535:65535 ./nginx -c ...
补充验证：用 worker_connections 反向印证
worker_rlimit_nofile 必须 ≥ worker_connections × worker_processes，否则 Nginx 启动时会警告或自动下调 worker_connections。可故意设一个略高于当前 ulimit 的值（如 ulimit=1024，配置 worker_rlimit_nofile 2048），观察日志：
- 若 error.log 中出现
could not raise the maximum number of file descriptors，说明配置被拒绝； - 若无此日志，且
worker_connections按预期生效（如设为 1024，且压测时连接数稳定达 2000+），基本可确认限制已提升到位。
