nginx后端容错需keepalive与超时重试协同：客户端设keepalive_timeout 60s和keepalive_requests 100；upstream配keepalive 32、proxy_http_version 1.1及清空connection头；重试限于error/timeout/502-504且最多2次，超时参数梯度设置。
要让 Nginx 在后端波动或瞬时故障时不中断核心业务，光靠单点转发远远不够。关键不是“不挂”，而是“挂了也能自动绕过、重试、恢复”。Keepalive 和超时重试不是两个独立配置，而是一套协同机制：前者管连接复用与资源效率，后者管容错与请求韧性。下面从三个实际起效的层面讲清楚怎么配、为什么这么配。
客户端长连接要稳住，别让浏览器先断
用户浏览器和 Nginx 之间若频繁建连断连，不仅增加延迟，还会在故障时放大抖动。重点配两参数：
-
keepalive_timeout 60s 60s：空闲 60 秒才关闭连接；第二个 60s 会写进响应头
Keep-Alive: timeout=60，告诉现代浏览器（如 Chrome、Firefox）按此维持连接； - keepalive_requests 100：单个连接最多处理 100 个请求，防内存泄漏或句柄耗尽；对上传大文件、长轮询等场景，可适当调高，但不宜设为 0（无限）。
注意：HTTP/1.1 默认启用 Keep-Alive，无需加 Connection: keep-alive 请求头；Nginx 也不需要手动设置该响应头——它由协议自动协商。强行加反而可能干扰某些客户端行为。
上游连接池要够用，避免反复握手拖慢后端
当 Nginx 作为反向代理，后端是 Tomcat、Spring Boot 或 Go 服务时，每次新建 TCP 连接都带来毫秒级开销。启用 upstream keepalive 能显著降低延迟和系统负载：
- 在
upstream块中加 keepalive 32：表示每个后端服务器最多保留 32 个空闲长连接；数值建议按后端实例数 × 8～16 预估，比如 3 台后端，设 24～48 合理； - 必须配合 proxy_http_version 1.1 和 proxy_set_header Connection ""：清空原始 Connection 头，防止后端误判连接状态；
- 不要写
proxy_set_header Connection "keep-alive"—— 这是 HTTP/1.0 兼容写法，Nginx 1.1+ 下多余且易引发连接复用异常。
超时与重试要分层设防，拒绝盲目转发
默认的 proxy_next_upstream error timeout 很危险：一次超时就换机器，POST 提交可能重复入库。真正可靠的策略是“有选择地重试”：
-
缩小重试范围：只对幂等操作重试，例如
proxy_next_upstream error timeout http_502 http_503 http_504，排除http_403http_404等明确语义错误； -
限制重试次数：加
proxy_next_upstream_tries 2，最多尝试 2 次（含首次），避免雪球式扩散； - 匹配超时梯度： client_header_timeout 10s（读请求头） proxy_connect_timeout 5s（连后端） proxy_send_timeout 30s（发请求体） proxy_read_timeout 60s（等后端响应） 这些值需略大于后端平均处理时间，但不能远高于 P99 延迟，否则掩盖真实问题。
