Nginx超时机制由多组参数协同控制：client_header_timeout和client_body_timeout管理客户端请求阶段；send_timeout控制响应发送；proxy_connect_timeout、proxy_send_timeout和proxy_read_timeout调控反向代理通信；keepalive_timeout与keepalive_requests优化连接复用。
Nginx 的超时机制不是单一参数，而是一组相互协作、作用于不同环节的控制开关。配错一个，就可能引发 408、504 或连接中断；配太松，又会堆积空闲连接拖慢整体性能。关键在于分清“谁对谁超时”，再按场景调整。
客户端请求阶段的超时
这部分控制 Nginx 如何等待用户发来完整请求，适用于所有 HTTP 请求（无论是否代理）：
- client_header_timeout：等待客户端发送完整请求头（如 GET /path HTTP/1.1）的最长时间。默认 60 秒，公网环境建议调低至 10–20 秒。若用户网络极差或恶意慢速攻击，过长等待会占用 worker 进程。
-
client_body_timeout：请求头收完后，等待请求体（比如 POST 表单、上传文件内容）到达的间隔超时。注意：它不是整个上传耗时上限，而是“两次数据包之间”的静默容忍时间。大文件上传场景建议设为 10–30 秒，配合
client_max_body_size使用。
响应返回阶段的超时
这部分决定 Nginx 向浏览器发数据时的耐心程度：
- send_timeout：向客户端发送响应的超时。从发送第一个字节开始计时，两次写操作之间的空闲时间不能超过该值。默认 60 秒，高延迟链路（如跨国 CDN 回源）可适当放宽，但不建议超过 120 秒，避免连接长期挂起。
反向代理通信的超时
当 Nginx 作为代理转发请求时，这三项直接影响后端交互成败：
- proxy_connect_timeout：Nginx 建立到后端（如 Tomcat、PHP-FPM）TCP 连接的最长等待时间。跨机房或容器网络不稳定时，可设为 3–5 秒（非 60 秒），避免阻塞。
- proxy_send_timeout：Nginx 向后端发送完整请求（含 body）的总时限。大文件上传、长耗时 API 调用需调高，例如设为 3600 秒（1 小时）——前提是后端真能处理这么久。
- proxy_read_timeout：Nginx 等待后端返回响应的最长时间。这是解决 504 错误最常调整的参数。若后端执行耗时任务（导出报表、AI 推理），应与实际业务耗时匹配，而非盲目设大。
连接复用与资源回收
keepalive 不是“永远不断”，而是精细控制连接生命周期：
-
keepalive_timeout：空闲连接保持秒数。默认 75 秒，但多数浏览器只认 60 秒左右，设为
60更稳妥；高并发 API 服务建议 15–30 秒，静态资源站可设 5–10 秒。 - keepalive_requests：单个 keepalive 连接最多处理请求数，默认 100。高 QPS 场景下可提高至 1000，减少 TCP 握手开销。
- 注意：
keepalive_timeout 60 60表示服务端保持 60 秒，同时在响应头中声明Keep-Alive: timeout=60，让兼容浏览器主动配合关闭。
