Nginx轮询默认无状态感知，需依赖被动或主动健康检查实现可用性保障：被动检查通过max_fails、fail_timeout和proxy_next_upstream配置实现失败重试；主动检查需扩展模块，探测/actuator/health并校验响应，配合状态暴露与告警闭环。

Nginx 默认轮询调度本身不感知后端服务器状态，它只按配置顺序机械分发请求，既不看响应时间、连接数，也不主动判断节点是否存活。真正的状态感知必须靠额外机制补足。

轮询默认行为：无状态、无反馈

• 请求严格按 server 声明顺序循环分配（如 A→B→C→A），每台权重默认为 1
• 不检查后端是否响应、是否返回 5xx、是否超时——哪怕某节点已宕机，只要没被标记为 down，轮询仍会把请求发过去
• max_fails=1 和 fail_timeout=10s 是被动触发的兜底机制，但需真实请求失败后才起作用，存在滞后性

必须搭配健康检查才能“看清”状态

仅靠轮询无法实现可用性保障，需组合以下两类机制：

• 被动健康检查（开箱即用）

  

  Nginx Hosting

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

  下载
  • 在 upstream 的每个 server 行添加 max_fails=3 fail_timeout=30s
  • 配合 proxy_next_upstream error timeout http_502 http_503 http_504，让失败请求自动重试其他节点
  • 日志中记录 $upstream_addr $upstream_status $upstream_response_time，用于回溯分析单点异常

• 主动健康检查（需扩展支持）

  • 开源版需编译 nginx_upstream_check_module，配置 check interval=3 rise=2 fall=3 type=http
  • 探测路径设为 /actuator/health，用 check_http_expect_alive http_2xx + 自定义响应体校验（如 "status\":\"UP"）
  • 禁用原生 max_fails（设为 0），避免被动与主动机制冲突

状态要能被看见、被使用，才算闭环

• 暴露 /status 接口（如 check_status 或 Lua 动态聚合），返回各节点 IP、当前状态、失败次数、最后探测时间
• 限制访问来源（如 allow 10.0.0.0/8; deny all;），防止信息泄露
• 对接 Prometheus 抓取指标，对 upstream_down == 1 设置告警；或在 balancer_by_lua_block 中读取健康评分，实时跳过低分节点

不复杂但容易忽略