Nginx后端健康状态由upstream块的故障判定逻辑主导，Server块超时参数仅作配合：proxy_connect_timeout控制TCP连接建立超时（建议3–10秒），proxy_read_timeout设定两次读操作最大空闲间隔，proxy_next_upstream开启重试机制，需与max_fails、fail_timeout协同生效。
不能只靠 Server 块里的超时参数来“精准把控”后端健康状态。真正起作用的是 upstream 块中的故障判定逻辑，Server 块里的超时设置只是配合它生效的必要条件。
proxy_connect_timeout 决定“连不上”的判断边界
这个值设得太长，Nginx 会傻等很久才放弃连接；设得太短，又可能把临时繁忙的后端误判为宕机。生产环境建议控制在 3–10 秒之间：
- 默认是 60 秒，对多数服务来说太保守
- 若后端部署在同一局域网，可设为 3s；跨机房或高延迟链路，建议 5–8s
- 该超时仅作用于 TCP 连接建立阶段，不包含 TLS 握手（如用 HTTPS，实际耗时会更长）
proxy_read_timeout 控制“响应卡住”的识别窗口
它不是整个请求处理时间上限，而是两次读操作之间的最大空闲间隔。比如后端流式返回数据，只要每 10 秒内有新数据到达，就不会断连：
- 设为 30s 可覆盖大多数同步业务接口
- 对长轮询、SSE 或大文件下载，需调高（如 120s），否则连接会被提前关闭
- 注意：它和 max_fails 共同影响被动健康检查——一次 read timeout 就算一次失败
proxy_next_upstream 是健康转移的开关
没有它，哪怕后端返回 502 或超时，Nginx 也不会换节点重试，等于健康检查形同虚设：
- 至少要启用 error timeout，这是基础项
- 强烈建议加上 http_500 http_502 http_503 http_504，覆盖常见服务级错误
- 避免写成 off，也别漏掉 timeout —— 否则超时不会触发重试
必须和 upstream 参数协同才有效
Server 块里所有超时配置，最终都要服务于 upstream 中的 max_fails 和 fail_timeout：
- 例如设了 proxy_read_timeout 30s，但 max_fails=1 fail_timeout=10s，那只要一次读超时，节点立刻被踢出 10 秒
- 合理搭配示例：max_fails=3 fail_timeout=60s + proxy_read_timeout 20s，意味着 60 秒内容忍最多 3 次 20 秒级卡顿
- backup 服务器不参与健康统计，只在全部主节点不可用时启用
