Nginx代理超时独立生效，不传递也不理解下游超时语义；微服务链路需分层人工对齐超时值，呈“外紧内松”梯度，并可选通过Header显式透传剩余超时以支持动态决策。
Nginx 代理超时本身不传递超时值，它只做本地阶段控制。微服务调用链路中的超时传递，靠的是各环节主动协商与显式配置，不是自动继承或透传。
Nginx 不转发、不理解、也不转换下游服务的超时语义
它不会把 proxy_read_timeout 120s 自动变成 HTTP Header 发给后端，也不会读取后端返回的 X-Timeout: 30s 去调整自己的行为。它的超时是独立生效的“守门人”策略：在哪个环节卡住、超了谁的时间，就由谁负责中断并返回对应错误（408 / 502 / 504）。
必须分层对齐超时边界，避免错配
微服务链路通常包含：客户端 → Nginx → Service A → Service B。每个环节的超时需人工对齐，否则会出现“上游等得久、下游早放弃”或“下游已超时、上游还在等”的撕裂现象。关键对齐点包括：
- 客户端发起请求时，自身 HTTP 客户端要设
timeout=90s（含连接、写、读） - Nginx 的
proxy_connect_timeout（如 5s）、proxy_send_timeout（如 30s）、proxy_read_timeout（如 90s）应 ≤ 客户端总超时，且 ≥ 后端服务承诺的最长处理时间 - Service A 调用 Service B 时，其 SDK（如 Feign、RestTemplate、OpenFeign）也必须单独配置
connectTimeout=3s、readTimeout=60s，不能依赖 Nginx 的 proxy_read_timeout - 所有环节的超时值建议呈“外紧内松”梯度：客户端 90s → Nginx 90s → Service A 85s → Service B 75s，留出网络和序列化开销余量
用 Header 显式透传业务级超时（可选但推荐）
虽然 Nginx 不自动处理，但你可以手动注入剩余超时时间，辅助下游做动态决策：
location /api/ {
proxy_pass http://service-a;
# 计算剩余可用时间（示例：固定减去 Nginx 已耗时，实际需结合 upstream 配合 Lua 或 OpenResty 实现动态计算）
proxy_set_header X-Request-Timeout "85";
}Service A 收到该 Header 后，可据此缩短自己调用 Service B 的超时，实现链路级弹性收缩。注意：纯静态设置（如全链路统一设 60s）不如按路径动态协商可靠。
别漏掉健康检查与熔断联动
仅调大超时只是“拖慢失败”，不是“提升可用”。Nginx 层应配合 health_check 检测后端存活，并与上游熔断器（如 Hystrix、Resilience4j）协同：当某节点连续超时，Nginx 主动摘除 + 熔断器触发降级，双保险防止雪崩。
