keepalive_timeout设得过大易致空闲连接堆积成僵死连接，占用socket和内存；其仅控制客户端到Nginx的HTTP/1.1空闲等待时长，不作用于后端连接；合理值需按场景设定：静态资源10–30秒、移动端API略大于轮询周期（如45秒）、内网SSE可60–120秒、高并发网关≤10秒，并须配合keepalive_requests协同调优。
keepalive_timeout 设得过大，容易积累大量空闲连接却不被复用，变成“僵死连接”——它们占着 worker 进程的 socket 和内存，却不再收发请求，最终拖慢响应、触发 worker_connections 耗尽或 OOM。
明确 keepalive_timeout 的作用边界
它只控制客户端到 Nginx 之间 HTTP/1.1 空闲连接的等待时长，不是 TCP 层保活，也不影响 Nginx 到后端（如 PHP-FPM、API 服务）的连接。设为 0 表示禁用长连接；设为 300 秒不代表连接真能活 5 分钟，而是“最多等 300 秒新请求”，实际是否复用，取决于客户端行为和上游链路是否配合。
按场景选合理值，别盲目拉长
- 纯静态资源或 CDN 回源：10–30 秒。移动端弱网可能重试，但过长易堆积
- App 后端 API（轮询间隔 10–60 秒）：设为略大于轮询周期，比如 45 秒
- 内网服务或 SSE 长轮询：可设 60–120 秒，但必须确认客户端持续发起请求
- 高并发低延迟网关（QPS > 500）：建议 ≤ 10 秒，并开启
reset_timedout_connection on;
必须搭配 keepalive_requests 一起调
只改 timeout 不够。Nginx 默认 keepalive_requests 100，意味着即使连接没超时，只要处理完 100 个请求就断开。在高 QPS 场景下（如每秒 200 请求），单连接平均撑不过半秒，导致频繁重建连接、TIME_WAIT 暴涨。
建议同步设置：
keepalive_timeout 30s; keepalive_requests 1000;
值参考：QPS × 平均响应时间（秒）≈ 理论并发连接数，keepalive_requests 可设为该值的 2–5 倍，但不超过后端能稳定支撑的连接上限。
验证是否真有僵死连接
- 查当前 ESTABLISHED 连接数：
ss -tnpo | grep :80 | grep ESTAB | wc -l，对比worker_connections × worker_processes是否接近阈值 - 看 nginx stub_status：
Waiting高而Writing低，说明大量连接空闲挂起 - 抓包观察：用
tcpdump -i lo port 80看同一 IP:port 是否反复新建连接，而非复用 - 日志加字段：
$connection_requests和$request_time，分析单连接承载请求数与间隔分布
