client_header_timeout 和 client_body_timeout 应按业务场景设置：普通页面设10s，文件上传系统设30s和300s，移动端接口统一设60s；proxy_read_timeout需基于后端P95响应时间加20%余量，proxy_send_timeout设60s即可；keepalive_timeout和keepalive_requests应区分静态与动态服务优化，且前者仅支持http/server级配置。

client_header_timeout 和 client_body_timeout 怎么设才不丢请求

这两个参数控制 nginx 等待客户端发送 HTTP 请求头和请求体的最长时间。设得太短，用户在弱网或大文件上传时容易触发 408 Request Timeout；设得太长，又可能让慢速攻击（如 Slowloris）长期占用 worker 进程。

推荐值取决于业务场景：

• 普通 Web 页面（html/css/js）：client_header_timeout 10s、client_body_timeout 10s
• 含文件上传的后台系统（如 cms、表单提交）：client_header_timeout 30s、client_body_timeout 300s（5 分钟足够传百 MB 文件）
• 移动端 app 接口（网络波动大）：建议统一设为 60s，避免因 TLS 握手延迟或中间代理重传导致 header 超时

注意：client_body_timeout 不影响已开始传输的 body，只限制两次 TCP 包之间的空闲时间。如果客户端断续发送数据，每次间隔不能超过该值。

proxy_read_timeout 和 proxy_send_timeout 影响后端交互稳定性

这两个是反向代理场景下的关键超时项，直接影响 Nginx 与 upstream（如 python flask、java spring Boot）之间通信是否“假死”。

proxy_read_timeout 是 Nginx 从 upstream 读响应的超时（比如后端生成报表要 2 分钟），proxy_send_timeout 是 Nginx 向 upstream 发送请求的超时（极少触发，除非 upstream 拒绝接收）。

常见误配：

• 把 proxy_read_timeout 设成 60，但后端接口实际耗时 90s → Nginx 中断连接，返回 504 gateway Time-out
• 没配 proxy_send_timeout，上游服务偶发卡住写 socket → Nginx 无限等待，worker 连接被占满

实操建议：

• 先用 curl -w "@format.txt" -o /dev/NULL -s http://your-api 测真实后端 P95 响应时间，再加 20% 安全余量作为 proxy_read_timeout
• proxy_send_timeout 设为 60 即可，比 proxy_read_timeout 小或相等都合理，不必更大
• 若 upstream 支持流式响应（如 SSE、长轮询），proxy_read_timeout 必须设得足够大（例如 3600），并配合 proxy_buffering off

keepalive_timeout 和 keepalive_requests 容易被忽略的资源泄漏点

这两个参数管的是 HTTP/1.1 长连接生命周期，不是“连接多久没数据就关”，而是“连接空闲多久关”+“一条连接最多处理几个请求”。设错会导致 TIME_WaiT 暴增或连接复用率低。

典型问题：

• keepalive_timeout 75（默认值）太长，客户端浏览器关了页面但连接还挂着，Nginx worker 无法释放 fd
• keepalive_requests 100（默认）太小，高并发下频繁建连，TLS 握手开销大、TCP SYN 飙升

优化方向：

• 静态资源服务（CDN、图片站）：keepalive_timeout 15 + keepalive_requests 1000
• 动态 API 服务（前后端分离）：keepalive_timeout 5 + keepalive_requests 100（短连接更稳妥）
• 若启用了 HTTP/2，keepalive_timeout 实际无效（HTTP/2 自带连接管理），但 keepalive_requests 仍生效，建议设为 1000

验证方式：用 ss -tan state established | grep :443 | wc -l 对比调参前后连接数变化。

timeout 相关指令必须放在 location 还是 server 块里

绝大多数 timeout 指令（client_header_timeout、proxy_read_timeout 等）支持在 http、server、location 三个作用域使用，但行为不同：

• 在 http 块设，是全局默认值，会被下级覆盖
• 在 server 块设，仅对本虚拟主机生效
• 在 location 块设，只对该路径生效 —— 这是最常用也最安全的方式，比如给 /api/upload 单独加大 client_body_timeout

特别注意：keepalive_timeout 在 location 块中设置无效，Nginx 会直接忽略，只能在 http 或 server 级配置。

一个典型的安全配置片段：

location /api/ {     proxy_pass http://backend;     proxy_read_timeout 300;     client_body_timeout 300; } 
location /static/ { alias /var/www/static/; expires 1h;
这里不需要 proxy_* 参数
}

超时参数不是越长越好，也不是越短越安全。真正难的是结合监控（如 Nginx stub_status、upstream 状态码分布）和真实流量特征做动态校准 —— 很多线上问题，其实是某次发布后 upstream 响应变慢，但 proxy_read_timeout 没同步调整导致的。