Nginx代理超时需分层配置：常规API设connect 3–5s、send 15–30s、read 45–60s；文件上传调高client_body_timeout至60–300s；长任务仅延长read至300–1800s并异步通知；健康检查则严格设为connect 1s、read 1–2s。
Nginx 代理超时配置不是填数字，而是根据业务链路中“谁在等谁、等什么、能等多久”来分层决策。不同场景下，各参数的取值逻辑差异明显，核心是平衡用户体验、系统稳定性与后端真实能力。
常规 API 接口（如用户登录、订单查询）
特点是响应快、路径短、失败需快速反馈。不能让前端长时间白屏或转圈。
- proxy_connect_timeout：设为 3–5 秒。内网服务启动快，建连不应拖太久；超时即返回 502，避免请求堆积
- proxy_send_timeout：15–30 秒。普通 JSON 请求体小，发完很快；设太高会掩盖后端写阻塞问题
- proxy_read_timeout：45–60 秒。覆盖绝大多数 DB 查询+缓存+简单逻辑；超过说明后端异常，应返回 504 而非让用户干等
- client_header_timeout / client_body_timeout：统一设为 15 秒。防慢速攻击，也匹配移动端弱网容忍度
文件上传接口（如 /upload/）
重点不是“总耗时”，而是“数据流是否持续”。上传中断常因两次数据包间隔过大，而非总时间长。
-
client_body_timeout：设为 60–300 秒。这是关键——只要客户端每分钟内有数据到达，Nginx 就继续收；配合
client_max_body_size使用 - proxy_send_timeout：60–120 秒。大文件 Body 发送耗时长，尤其跨机房或 TLS 加密开销大
- proxy_read_timeout：120–300 秒。后端可能需要校验、转码、存 OSS，但不宜无上限；建议搭配进度回调或分片上传
- 不调 send_timeout：响应通常是轻量 JSON，保持默认 30 秒即可
长周期任务接口（如报表导出、AI 推理、批量同步）
这类请求本就不该走同步 HTTP 响应流，但若必须支持，超时配置要“只保通路，不保结果”。
- proxy_read_timeout：设为 300–1800 秒（5–30 分钟），并明确告知前端“任务已提交，结果异步通知”
- proxy_connect_timeout 和 proxy_send_timeout 仍保持保守（5s / 30s）：建连和发请求不能慢，慢说明后端不可靠
-
务必配 location 级覆盖：只在
location /report/或location /infer/中改，避免污染其他接口 - 配套做健康检查降级：这类路径若后端宕机，应快速返回 503，而不是卡满 timeout 后才报 504
健康检查与内部探针（如 /api/healthz）
目标是秒级发现故障，不是容忍延迟。
- proxy_read_timeout：1–2 秒。健康检查应极轻量，超 2 秒未返回基本可判为异常
- proxy_connect_timeout：1 秒。建连都超 1 秒，说明网络或后端进程已严重失常
- 禁用 client_* 类超时延长：不接受弱网、不处理 Body，所有 client 超时保持最小值（5–10 秒）
- 建议加 proxy_next_upstream error timeout：一次失败立即切到备用节点，加速故障隔离
