Nginx需通过短connect_timeout（内网3–5秒、跨机房8–10秒）快速识别后端崩溃，配合max_fails=2与fail_timeout=30s自动摘除故障节点，并依据错误码（111/110）精准定位崩溃或网络问题。
后端服务崩溃时，Nginx 无法建立连接或收不到任何响应，此时超时不是“等太久”，而是“根本连不上”或“连接被拒绝”。处理的关键是让 Nginx 快速识别故障、及时返回明确错误（如 502），并避免用户长时间等待或请求堆积。
快速识别连接失败，防止卡死
当后端进程已退出、端口未监听，或防火墙拦截通信，Nginx 在 proxy_connect_timeout 阶段就会失败。这个值必须足够短，才能避免用户干等：
- 内网环境设为 3–5 秒，超过即判定不可达，立即返回 502 Bad Gateway
- 跨机房或公网部署可放宽至 8–10 秒，但不宜超过 15 秒
- 该参数只控制 TCP 握手完成时间，不包含 SSL 协商；若用 HTTPS 后端，需额外预留 1–2 秒
配合健康检查自动摘除故障节点
单靠超时不能解决集群中个别节点崩溃的问题。必须启用 upstream 的主动探测与自动剔除机制：
- 在 upstream 块中配置 max_fails=2 fail_timeout=30s：连续两次 connect 失败（含超时）即标记为不可用，30 秒内不再转发请求
- 搭配 proxy_next_upstream error timeout，确保连接失败时自动尝试下一个节点
- 对关键路径（如 /api/healthz），可单独加 location 并设极短的 proxy_read_timeout 2s，加速探活
日志与监控要能准确定位崩溃源头
仅返回 502 不够，运维需要知道是“后端挂了”还是“网络断了”。关键日志线索包括：
- upstream connect() failed (111: Connection refused) → 后端进程未启动或端口未监听
- upstream timed out (110: Connection timed out) → 网络不通、防火墙拦截或后端系统负载极高导致 SYN 包无响应
- 错误日志中反复出现同一 upstream server 的失败记录，基本可确认该节点已崩溃
避免误判：区分崩溃与临时抖动
偶发连接失败不等于服务崩溃。为防误摘，建议：
- fail_timeout 时间应 ≥ 2 × proxy_connect_timeout，给瞬时抖动留出恢复窗口
- 不要把 proxy_connect_timeout 设得过短（如
- 配合外部监控（如 Prometheus + Blackbox Exporter）做独立健康验证，与 Nginx 自身判断交叉印证
