nginx高可用集群中请求中断需通过连接稳定性保障、故障感知转移与客户端协同三者配合实现：调高超时参数并启用keepalive复用连接，配置health_check与proxy_next_upstream实现失败自动流转，前端须实现幂等重试与websocket自动重建。
在 Nginx 作为反向代理接入高可用集群时，请求链路中断重连不是靠“自动重试”解决的，而是通过**连接稳定性保障 + 故障感知转移 + 客户端协同**三者配合实现。Nginx 本身不重连后端（它只转发一次请求），但可以大幅降低中断概率，并让失败请求快速落到健康节点上。
确保长连接不被中间层切断
HTTP/1.1 keep-alive 和 WebSocket 这类长链路极易被超时机制误杀：
-
调高超时参数：将
proxy_read_timeout、proxy_send_timeout设为后端心跳间隔的 2 倍以上（例如后端 ping/pong 每 30 秒一次，则设为60s或更高） -
启用连接复用：在 upstream 中配置
keepalive 32（保持 32 个空闲连接），并确保后端支持 HTTP keep-alive -
避免系统级干扰：检查防火墙、云厂商 SLB、内核
net.ipv4.tcp_fin_timeout等是否过早回收连接
让失败请求自动流转到健康节点
Nginx 不会重发已发出的请求，但可通过以下配置让下一次请求或重试请求命中正常后端：
-
启用健康检查：使用
health_check interval=5s fails=2 passes=2（需 nginx plus 或开源版配合第三方模块如nginx_upstream_check_module） -
配置失败重试逻辑：在 location 块中加入
proxy_next_upstream error timeout http_500 http_502 http_503 http_504，并在upstream中设置max_fails=2 fail_timeout=10s -
合理设置重试次数与间隔：默认最多重试一次（即原始请求 + 1 次转发），如需多次可配合
proxy_next_upstream_tries和proxy_next_upstream_timeout
客户端侧需配合做容错设计
服务端无法解决所有中断，终端或前端必须承担部分重连责任：
-
WebSocket 场景：前端监听
onclose事件，延迟 1–3 秒后自动重建连接（避免雪崩重连） - HTTP 接口调用：SDK 或请求库开启幂等重试（如 5xx 错误自动重试 2 次，带 jitter 避免同步冲击）
-
心跳保活：客户端定期发送轻量探测请求（如
/health），发现不通立即切换备用域名或触发重连流程
关键日志与可观测性支撑
没有监控的重连策略是盲调：
- 开启
log_format upstream_log '... $upstream_addr $upstream_status $upstream_response_time'；记录每次转发的目标和结果 - 用
tail -f /var/log/nginx/access.log | grep "50[2-4]"快速定位上游失败批次 - 结合 Prometheus + nginx-vts-exporter 监控
upstream_fails、upstream_health等指标，设置异常告警
