关键在于按环节精准设限：客户端请求头/体读取超时需匹配网络条件，proxy_read_timeout应基于后端p95延迟加余量，keepalive_timeout与keepalive_requests需按服务类型配置，send_timeout要适配弱网场景。
关键不是一味拉长超时，而是按环节精准设限：让慢请求及时释放连接，又不误杀正常业务。
客户端请求头/体读取超时要匹配真实网络条件
这两个参数决定 Nginx 在建立连接后，等待客户端发完 header 或 body 的最久时间。设太短会频繁返回 408；设太长则易被 Slowloris 类攻击拖住 worker 进程。
- 普通网页（HTML/CSS/JS）：client_header_timeout 10s、client_body_timeout 10s 足够
- 含上传的后台系统（如 CMS 表单）：client_header_timeout 30s、client_body_timeout 300s（5 分钟可传百 MB）
- 移动端接口（TLS 握手延迟+代理重传常见）：统一设为 60s 更稳妥
注意：client_body_timeout 不限制整个上传耗时，只管两次 TCP 数据包之间的空闲间隔。
反向代理交互超时必须基于后端真实响应分布
proxy_read_timeout 是引发 504 错误的主因——它不是“等后端多久”，而是“从后端读数据的最大空闲时间”。若后端 P95 响应是 75s，proxy_read_timeout 至少设为 90s（加 20% 余量）。
- 先用 curl -w "@format.txt" 测线上接口的 P95 延迟，再加安全余量
- proxy_send_timeout 设 60s 即可，极少需要调大；它只在 Nginx 向后端发请求卡住时生效
- 流式接口（SSE、长轮询）必须关 proxy_buffering 并设 proxy_read_timeout ≥ 3600
长连接生命周期需兼顾复用效率与资源释放
keepalive_timeout 控制空闲连接保持时间，keepalive_requests 限制单连接最大请求数。两者配合才能防资源泄漏。
- 静态资源服务：keepalive_timeout 60s + keepalive_requests 10000，复用充分且不积压
- 动态 API 服务：keepalive_timeout 30s + keepalive_requests 1000，更快释放连接，适配高并发短连接场景
- 该配置仅支持 http 或 server 级，不能写在 location 里
响应发送阶段也要设底线
send_timeout 是服务器向客户端发响应时，两次写操作之间的最大空闲时间。后端虽已返回，但客户端弱网或中断接收时，Nginx 仍会卡在 send 阶段。
- 常规服务设 30s 即可，比 client_body_timeout 略长一点
- 对移动端或弱网用户较多的服务，可放宽到 60s
- 值过小会导致大响应（如报表 PDF）被意外截断
