worker_rlimit_nofile是Nginx main上下文指令，用于为每个worker进程单独设置文件描述符上限，必须同步配置系统limits、systemd LimitNOFILE及内核fs.file-max才生效，且值需大于worker_connections并预留日志等开销。

worker_rlimit_nofile 是 Nginx 全局块（main context）中的指令，用于统一限制每个 worker 进程能打开的最大文件描述符数量（即句柄数），直接影响并发连接能力与资源隔离强度。

它控制的是每个 worker 进程的上限，不是全局总和

该值不作用于整个 Nginx 实例，而是为每个 worker process 单独设限。例如：
worker_processes 4;
worker_rlimit_nofile 65535;
表示每个 worker 最多可打开 65535 个文件描述符，整机理论上限为 4 × 65535（实际受系统级限制约束）。

必须配合系统级配置才真正生效

Nginx 不会自动突破内核限制。需同步调整操作系统层面的设置：

• 临时生效：用 ulimit -n 65535 启动 Nginx 前设置（推荐在 systemd service 文件中通过 LimitNOFILE=65535 固化）
• 永久生效：修改 /etc/security/limits.conf，添加如 nginx soft nofile 65535 和 nginx hard nofile 65535
• 确认内核参数足够：sysctl fs.file-max 应远大于所需总量（如设为 2097152）

合理取值要考虑实际并发与资源开销

并非越大越好。每个连接至少占用 2–3 个 fd（监听 socket、客户端 socket、可能还有 upstream socket），还需预留日志、配置文件、共享内存等开销：

• 轻量服务（静态资源为主）：1024～4096 通常足够
• 中高并发（HTTP API 或反向代理）：8192～65535 更稳妥
• 超大规模部署：需压测验证，避免因 fd 耗尽导致 accept() 失败、连接被拒绝

验证是否生效的方法

启动后检查实际限制是否匹配：

• 查 Nginx 配置是否加载成功：nginx -t
• 查 worker 进程当前限制：cat /proc/$(pgrep nginx)/limits | grep "Max open files"
• 观察错误日志是否有 accept() failed (24: Too many open files)