Nginx 中 Worker Process 如何处理后端服务超时

Nginx Worker 进程通过事件驱动与红黑树定时器实现非阻塞超时管理：请求发出后立即处理其他连接，超时由内核通知触发回调，关闭连接、标记失败并按proxy_next_upstream策略重试，全程不挂起、不轮询、毫秒级精准。

Nginx 的 Worker Process 并不“主动等待”后端超时，而是靠事件驱动机制异步响应——它把请求发出去后立即去处理别的连接，等内核通知“超时了”或“有数据来了”，才回来处理。整个过程不阻塞、不挂起，一个 worker 能同时管成百上千个连接。

超时判定由事件循环自动触发

Worker 进程启动时会初始化红黑树管理所有定时器事件（比如 proxy_read_timeout）。每个发往后端的请求都会在树中注册一个超时节点，时间一到，epoll/kqueue 就通知 worker 执行超时回调：

• 若 proxy_read_timeout 到期且还没收到后端响应头或首块体，Nginx 立即关闭当前 upstream 连接，并标记该 backend 失败（触发 max_fails）
• 若配置了 proxy_next_upstream timeout，且还有可用节点，worker 会立刻选下一个 server 发起新请求，全程不中断事件循环
• 超时不是轮询判断，而是内核级事件通知，毫秒级精度，无 CPU 空转

超时后行为取决于配置组合

Worker 不会凭空决定怎么处理，而是严格按以下指令协同动作：

• proxy_connect_timeout 控制建连阶段：连不上就换节点，不占 buffer，也不进重试计数
• proxy_send_timeout 控制发请求体阶段：发送卡住超时，直接断连，不重试（除非明确配置 error 或 timeout）
• proxy_read_timeout 是最常触发的：响应迟迟不来，worker 清理缓冲区、关连接、记失败、可能重试
• proxy_next_upstream_tries 和 proxy_next_upstream_timeout 共同限制重试边界——前者管换几个后端，后者管从第一次发起到最终放弃总共花多久

避免 worker 卡死的关键设计

即使后端彻底失联，worker 也不会被拖住，因为：

• 所有超时都走统一定时器红黑树，不依赖线程 sleep 或 busy-wait
• 重试是状态机跳转：失败 → 检查策略 → 选新节点 → 异步发请求，中间不等待
• 旧连接超时后，内存 buffer 和 socket fd 会被立即释放，不残留“僵尸连接”
• 如果启用了 reset_timedout_connection on，超时直接发 RST，加速回收 TIME_WAIT

真实场景中的典型流程

以一个 POST 请求为例：

• Worker 接收客户端请求，解析完 header 后，异步向 backend A 建连并发送 body
• 注册 proxy_read_timeout=12s 定时器；同时监听该连接的可读事件
• 12 秒内没收到任何响应，epoll 返回超时事件 → worker 执行超时 handler
• 检查 upstream 配置允许重试 timeout，且 tries=3 还剩 2 次 → 选择 backend B，复用 keepalive 连接或新建
• 整个过程耗时约 12.05s，但 worker 在这期间已处理了其他 50+ 客户端请求