nginx默认轮询模式采用被动健康检查，依赖真实请求结果判断后端状态；通过proxy_next_upstream、max_fails和fail_timeout协同实现失败统计与节点摘除，各worker独立维护状态，恢复靠首个成功请求试探触发，无主动心跳探针。

Nginx 在默认轮询模式下不主动发心跳探针，它的健康检查是被动触发的，完全依赖真实业务请求的执行结果来判断后端是否可用。

被动健康检查靠 proxy_next_upstream + max_fails/fail_timeout 协同工作

• proxy_next_upstream 决定哪些错误类型会触发重试并计入失败统计
  比如配置 proxy_next_upstream error timeout http_502 http_503，只有连接失败、超时、或返回 502/503 时才重试并记为一次失败；500 或 404 不在其中，就不会影响节点状态

• max_fails 和 fail_timeout 共同定义“摘除”逻辑

  

  Nginx Hosting

  通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

  下载
  • max_fails=3 表示允许连续失败 3 次
  • fail_timeout=30s 表示这个“连续”是在 30 秒窗口内统计的，且节点被标记为 down 后也会屏蔽 30 秒

• 每个 worker 进程独立维护该节点的失败计数和时间戳
  不同 worker 可能对同一后端有不同判断，没有跨进程状态同步机制

超时参数直接影响失败判定时机

• proxy_connect_timeout 控制建连阶段是否超时（建议设为 3–5 秒）
• proxy_read_timeout 控制等待响应头的时间（应略大于后端 P95 响应时长，通常 ≤15 秒）
• proxy_send_timeout 在大请求体场景才关键，一般保持默认或设为 10 秒内即可

这些 timeout 触发后，若匹配 proxy_next_upstream 列出的条件，就会走重试流程，并增加对应 server 的失败计数。

恢复逻辑是“试探性”的，不是自动轮询

• 节点被标记为 down 后，在 fail_timeout 时间结束后，Nginx 不会立刻恢复流量
• 下一个到达的请求如果成功连上并得到正常响应，该节点就重新标记为 up
• 没有后台定时任务去“轮询”恢复状态，全靠真实请求驱动

真实请求才是唯一触发源

• 没有用户请求进来，后端即使已恢复，Nginx 也不会主动探测
• 如果某节点长期无流量，它可能一直停留在 down 状态，直到新请求打过去才被验证

这种设计轻量、无额外开销，但也意味着故障发现延迟取决于请求频率，低频服务容易出现“假死”滞后。