Nginx并发能力受限于单个worker进程的文件句柄数，需同时配置系统limits、systemd LimitNOFILE和nginx.conf中worker_rlimit_nofile，并结合CPU核心数合理设置worker_processes与multi_accept等参数优化。
Nginx 采用多进程模型（一个 master 进程 + 多个 worker 进程），每个 worker 进程独立处理连接，因此系统级的文件句柄（file descriptor）限制会直接影响其并发能力。句柄数不足时，常见表现是 accept() failed (24: Too many open files) 错误，连接被拒绝或响应变慢。
worker 进程与句柄数的关系
每个 worker 进程能打开的最大文件句柄数，受限于操作系统对单个进程的 ulimit -n 设置，而非全局总量。例如：系统总限制为 65536，但若未显式提升单进程限制，worker 默认可能只能用 1024 个句柄——即便有 8 个 worker，实际可用连接数仍卡在 1024 左右（因为每个连接至少占用 1 个句柄，静态资源、上游连接等还会额外消耗）。
关键点：
- Nginx 不自动继承系统级的高句柄限制，必须显式配置 worker 的最大打开数（
worker_rlimit_nofile） -
worker_rlimit_nofile值不能超过当前用户进程的ulimit -n软限制 - 每个活跃 TCP 连接通常占用 1 个句柄；HTTPS、代理场景中，后端连接、SSL 上下文等会显著增加句柄消耗
正确设置句柄限制的步骤
需同时调整操作系统和 Nginx 配置，缺一不可：
- 修改
/etc/security/limits.conf，为运行 Nginx 的用户（如www-data或nginx）设置软硬限制：nginx soft nofile 65536nginx hard nofile 65536 - 确保 systemd 启动时加载 limits（若使用 systemd）：在
/etc/systemd/system/nginx.service的[Service]段添加：LimitNOFILE=65536 - 在
nginx.conf的全局块中设置：worker_rlimit_nofile 65536; - 重启 nginx 并验证：用
ps aux | grep nginx找到 worker 进程 PID，再执行cat /proc/[pid]/limits | grep "Max open files"确认生效
合理分配 worker 与句柄的协同优化
并非句柄数设得越高越好，也并非 worker 数越多越优。需结合 CPU 核心数与 IO 特性平衡：
- 推荐
worker_processes auto;，让 Nginx 自动匹配 CPU 核心数 - 每个 worker 的句柄上限建议不超过系统总限制 / worker 数 × 1.2（预留缓冲），避免单个 worker 耗尽全部句柄导致其他 worker 饿死
- 启用
multi_accept on;可让 worker 在一次事件循环中接受多个新连接，减少因 accept 延迟导致的句柄瞬时堆积 - 配合
use epoll;（Linux）提升事件处理效率，降低句柄等待开销
监控与排查建议
持续观察句柄使用情况，可及时发现泄漏或配置偏差：
- 实时查看某 worker 的已用句柄数：
ls /proc/[pid]/fd | wc -l - 统计所有 worker 总句柄占用：
pgrep nginx | xargs -I{} ls /proc/{}/fd 2>/dev/null | wc -l - 在 Nginx 日志中开启
error_log ... debug_event;（临时）可定位 accept 失败的具体原因 - 注意检查是否有长连接未正常关闭（如 keepalive timeout 过长、客户端异常断连），造成句柄滞留
