多层 nginx 级联代理中，超时必须按层级角色逐级收紧：l1 接入层面向公网，proxy_connect_timeout 设 3–5 秒（同机房）或 8–12 秒（跨地域），proxy_read_timeout 不宜超 30 秒；l2 路由层部署于内网，proxy_connect_timeout 压至 200–500ms，proxy_read_timeout 控制在 8–12 秒，并启用 keepalive 降低开销；所有层需匹配物理路径 rtt 特征，且必须通过 error_log、tcpdump 和健康检查协同验证。
多层 Nginx 级联代理中，超时不能统一拉长，必须按层级角色逐级收紧——越靠近客户端的层越要快失败，越靠近后端的层越要精准匹配真实链路延迟。
接入层（L1）：面向公网，强调快速失败
这一层直面不可控网络（如移动运营商、跨境链路），首要目标是避免用户长时间等待 502/504。所有超时应设为最短且可验证的值：
-
proxy_connect_timeout 设为 3–5 秒（同机房）或 8–12 秒（跨地域），配合
max_fails=2 fail_timeout=15s加速摘除异常节点 -
proxy_read_timeout 不宜超过 30 秒；若业务允许，建议设为 15 秒并启用
proxy_next_upstream error timeout http_502，不重试已超时请求 - 禁用
proxy_next_upstream_tries，防止故障在 L1 就被放大传递到下一层
路由层（L2）：内网调度，聚焦连接稳定性
L2 通常部署在 VPC 或同一可用区内，网络质量可控，但承担实际负载分发，需平衡响应及时性与后端容错能力：
- proxy_connect_timeout 压至 200–500ms，确保能快速识别后端端口未监听、防火墙拦截等硬故障
- proxy_read_timeout 控制在 8–12 秒，略高于后端 P95 响应时间，避免因偶发抖动误判
- 必须开启
keepalive 128和keepalive_timeout 75s，复用连接降低三次握手开销；该值应略小于下游交换机或 WAF 的 idle 超时阈值
路径对齐：让每层超时匹配其所在网络段特征
超时不是孤立参数，而是对物理路径的建模。例如：
- 若 L1 到 L2 经过公网专线（RTT ≈ 15ms），则 L1 的
proxy_connect_timeout应 ≥ 3×RTT + 内核调度余量 → 建议 50–80ms - 若 L2 到 Java 后端走的是 Kubernetes Service（iptables 模式），实际建连延迟可能达 3–8ms，此时 L2 的
proxy_connect_timeout设为 200ms 更合理 - 所有层的
proxy_send_timeout均建议 ≤proxy_read_timeout，因为发送请求通常比等待响应快得多；设为 10–30 秒即可
验证与协同：单改超时不解决问题
只调参数不验证，等于没调。必须同步做三件事：
- 在每层 Nginx 开启
error_log ... debug，搜索upstream timed out日志，确认触发的是哪一阶段超时（connect / read / send） - 用
tcpdump -i any port <backend_port></backend_port>抓包，区分是 SYN 未响应（connect 阶段），还是三次握手完成但无数据（read 阶段） - 健康检查间隔（
health_check interval）必须大于对应层的proxy_connect_timeout，例如 L2 设了 300ms connect 超时，健康检查至少设为 1s，避免探测本身被误判为失败
