nginx 的 worker_processes 不直接处理超时，而是通过控制并发进程数影响超时执行效果；每个 worker 独立管理连接池与定时器，超时由其事件循环配合配置指令实现；过少或过多的 worker 进程均会降低超时检测精度与及时性；合理配置需匹配 worker_processes 与 worker_connections，并依业务调整各类 timeout 值。
Nginx 的 worker_processes 本身不直接处理连接超时逻辑，它只是控制并发工作的进程数量；真正执行连接超时判断和断连动作的，是每个 worker 进程内部的事件循环（如 epoll/kqueue）配合配置中的超时指令。两者是协同关系：worker 进程数决定了并行处理能力上限，而超时设置决定了每个连接在该进程内能“存活”多久。
worker_processes 对超时行为的影响
- 每个 worker 进程独立维护自己的连接池和定时器队列，所有超时检查（如 keepalive、header、body、send 超时）都在各自进程中完成；
- 如果
worker_processes设置过少（比如 1 个），高并发下所有连接都挤在一个进程里，定时器精度下降、响应延迟升高，容易导致超时误触发； - 反之，过多进程（远超 CPU 核心数）会增加上下文切换开销，反而削弱超时检测的及时性，甚至因资源争抢延长实际等待时间。
超时配置必须与 worker 配合调整
-
worker_connections应与worker_processes匹配：总可用连接数 =worker_processes × worker_connections；若超时时间设得太长（如keepalive_timeout 300），空闲连接长期不释放，很快耗尽连接池，新请求被拒绝（503 或直接丢包）； -
keepalive_timeout值需参考平均请求间隔：若业务中用户频繁刷新或短连接密集，设为 15–30 秒更稳妥；若大量 AJAX 长轮询，可局部（location 块）延长，但不宜全局拉高； -
client_header_timeout和client_body_timeout过短（如 60s）则易被慢速攻击利用——这类判断由每个 worker 在读事件就绪后启动计时器执行，超时即关闭 fd 并记日志（状态码 408）。
实际配置建议（万级并发场景）
-
worker_processes auto;（自动匹配 CPU 核心数，避免手动错配）； -
worker_connections 8192;（配合系统ulimit -n调整，确保足够承载）； -
keepalive_timeout 25;（平衡复用率与资源释放速度）； -
client_header_timeout 12; client_body_timeout 12; send_timeout 25;（防止慢客户端拖垮单个 worker）； - 启用
epoll（Linux）并设置multi_accept on;，让每个 worker 尽快收完一批就绪连接，减少超时判定延迟。
本质上，worker 是“执行者”，超时是“规则”；规则写得合理，执行者才能高效运转。
