nginx超时需分阶段管控：client_header/body_timeout须≤proxy_connect_timeout，三代理超时应层级递增，send_timeout专管响应发送节奏，特殊路径须局部覆盖而非全局统一。

要让 Nginx 的代理超时和客户端超时真正“衔接”起来，核心不是数值对齐，而是分阶段守好各自边界：客户端侧管“进来的节奏”，代理侧管“出去的节奏”，两者不重叠、不抢断、不互相掩盖问题。

客户端超时必须先于代理连接超时生效

client_header_timeout 和 client_body_timeout 是第一道闸口。它们控制用户发请求的速度，不是总耗时。如果设得太小（比如都只设 5 秒），弱网或 TLS 握手慢的请求还没发完头或体，Nginx 就直接返回 408，根本不会走到 proxy_connect_timeout 阶段。

• 内网服务建议：client_header_timeout 15s，client_body_timeout 20s
• 公网/移动端上传场景：client_header_timeout 30–60s，client_body_timeout 120–300s（注意是“两次数据包间隔”，不是总上传时间）
• 关键原则：这两个值必须 ≤ proxy_connect_timeout，否则 Nginx 还没开始连后端，客户端连接已断

代理超时之间要有明确的层级差

proxy_connect_timeout、proxy_send_timeout、proxy_read_timeout 各管一程，不能等同设置。后端处理慢时，你希望它先断；后端卡在建连或发请求体阶段，Nginx 才该干预。

linux-sysadmin

Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...

下载

• proxy_connect_timeout：仅管 TCP 握手，设为后端监听就绪时间 + 1–2 秒抖动（如 Java 冷启需 8 秒 → 设 10s）
• proxy_send_timeout：要 ≥ 后端接收完整 body 耗时（大文件上传、长 JSON 解析需重点调）
• proxy_read_timeout：必须 > 后端业务超时（如 Spring Boot server.tomcat.connection-timeout=12s → Nginx 设 20–25s）
• 错误做法：三者全设成 60s —— 一旦后端在 58 秒因 GC 断连，Nginx 收不到 FIN，报 502 而非 504，问题难定位

响应发出阶段要用 send_timeout 衔接终端体验

send_timeout 管的是 Nginx 把响应内容发给用户时的节奏，尤其影响大文件下载、SSE、流式接口。它和 proxy_read_timeout 没有依赖关系，但共同决定用户是否看到“卡住”或“突然中断”。

• 普通页面响应：send_timeout 20–30s 即可
• 导出报表、视频流、AI 推理结果流：建议 60–120s，并确保后端也启用 HTTP/1.1 分块传输（Transfer-Encoding: chunked）
• 注意：它不控制首字节延迟，只管两次 write() 之间的空闲时间；设太小会导致流式响应被意外切断

特殊路径必须局部覆盖，不能全局一刀切

全局统一配置是基线，但上传、健康检查、长轮询等路径必须差异化调整，且只写需要改的参数，其余自动继承。

• /upload/：延长 proxy_read_timeout 和 client_body_timeout（如都设 300s），但 proxy_connect_timeout 保持不变
• /api/healthz：大幅压缩 proxy_read_timeout（如 2s），加快故障发现，避免健康检查拖慢摘除速度
• /ws/ 或 /sse/：重点调高 proxy_read_timeout 和 send_timeout，同时禁用 proxy_buffering off
• 所有 location 中的 proxy_* 参数，只覆盖必要项；多写一个可能破坏继承逻辑

不复杂但容易忽略