超时设太长会导致资源被无效占用，需分层精准控制：客户端侧设client_header_timeout 10–15秒、client_body_timeout 15–30秒、keepalive_timeout 75–120秒；代理侧proxy_connect_timeout设3–8秒、proxy_send_timeout 30–60秒、proxy_read_timeout按后端P95+20%设定；并配健康检查与连接池优化。
超时设太长，表面是“多等一会儿”，实际是让连接、内存、端口、CPU全被无效占用——这不是容错，是慢性资源窒息。防御的关键不是一刀切缩短所有 timeout，而是分层控制、精准匹配、主动释放。
客户端连接：别让空闲连接赖着不走
客户端发完请求就干等，Nginx 却一直维持连接，会堆积大量 idle 连接，吃光 worker 进程的连接槽和内存：
- client_header_timeout 设为 10–15 秒：防止恶意慢速发送请求头（如 Slowloris 攻击）
- client_body_timeout 设为 15–30 秒：大文件上传可局部调高，但默认不宜超过 60 秒
- keepalive_timeout 控制在 75–120 秒：足够复用，又不会让僵尸连接长期滞留；必须比后端 keepalive 超时至少少 10 秒
- 搭配 keepalive_requests 1000–5000：避免连接刚复用几次就被强制关闭，也防单连接寿命过长导致后端提前断连后 Nginx 不感知
代理到后端：三阶段超时必须各司其职
proxy_*_timeout 不是“总耗时上限”，而是三个独立阶段的守门员。设长了，一个慢请求就能卡住整个连接池：
- proxy_connect_timeout：只管 TCP 握手，内网设 3–5 秒，跨可用区 5–8 秒，公网后端最多 15 秒；超时即换节点，不拖泥带水
- proxy_send_timeout：两次向后端写数据的间隔，普通接口 30 秒足矣；上传类场景可提至 60 秒，但需配合 client_body_timeout 同步收紧
- proxy_read_timeout：重点盯防项——它管的是“等第一个响应字节”的间隔，不是总响应时间。导出类接口设 300 秒可接受，但必须配套健康检查，确保超时前已摘除故障节点
连接池与系统层：防“假长连接”和端口枯竭
超时过长 + keepalive 配置失当，会制造大量“看似活跃实则失效”的连接，最终引发连接枯竭或 TIME_WAIT 爆满：
- upstream 块中 keepalive 值按后端承载力反推：例如后端最大连接数 200、Nginx 有 4 个 worker，建议设 120–160，而非盲目填 1024
- 必须配齐协议头：proxy_http_version 1.1 + proxy_set_header Connection ''，否则 keepalive 不生效
- Linux 内核同步加固：net.ipv4.tcp_tw_reuse = 1（启用 TIME_WAIT 复用）、net.core.somaxconn = 65535（扩全连接队列）、net.ipv4.ip_local_port_range = "1024 65535"
- Nginx stream 或 http 的 listen 指令显式加 backlog=65535，匹配内核队列容量
兜底与可观测：让问题暴露得早、死得干净
再好的配置也需要验证和熔断机制，避免“配置生效却无感知”：
- 所有超时参数统一放在 http 块顶层，特殊路径用 location 局部覆盖（如 /export/ 提高 proxy_read_timeout），避免全局污染
- 启用 upstream 健康检查（stream 模块用 nginx_upstream_check_module，http 模块用 health_check），失败阈值设 2–3 次，恢复阈值设 1–2 次
- 限制单请求资源：用 client_max_body_size、client_header_buffer_size 和 proxy_buffering off（对流式响应）防内存被单个请求撑爆
- 监控关键指标：Nginx 的
Active connections、Reading/Writing/Waiting状态分布，以及系统级ss -s | grep -i time_wait和cat /proc/net/sockstat
