keepalive_timeout本身不直接提升稳定性，而是通过合理控制空闲连接生命周期，避免资源耗尽或连接异常中断，从而间接支撑高并发下的稳定运行；关键在于设得准、配得全、收得快，并需协同keepalive_requests、upstream keepalive及reset_timedout_connection等参数，配合系统级调优与实时指标验证。
keepalive_timeout 本身不直接“提升稳定性”，而是通过合理控制空闲连接生命周期，避免资源耗尽或连接异常中断，从而间接支撑高并发下的稳定运行。关键不在设大，而在设得准、配得全、收得快。
按业务类型设定合理超时值
不同请求模式对连接复用需求差异很大，统一设 65 秒容易失衡：
- API 网关或 App 后端：建议 15–30 秒。移动端请求节奏紧凑但网络易中断，过长会积压大量无效连接；
- 静态资源服务（CDN 边缘、图床）：可设 60–300 秒。JS/CSS/图片常被并行加载，复用率高，延长超时能显著减少握手开销；
- WebSocket 或长轮询升级前：需配合 proxy_read_timeout 和后端心跳，设 300–600 秒，但必须确保 upstream 也启用 keepalive 并同步超时；
- 内网微服务调用：若链路可控、延迟稳定，可设 60–90 秒，略小于后端 keep-alive timeout（如后端设 60s，Nginx 设 55s），避免单方面断连引发 502。
必须协同配置的三项关键参数
单独调 keepalive_timeout 效果有限，以下三者缺一不可：
- keepalive_requests：限制单连接最大请求数，默认 100。API 场景建议设 500–1000，防止单连接长期霸占资源；恶意慢速连接场景可降至 50，强制轮转；
- upstream keepalive：在 upstream 块中设置，如 keepalive 32;，表示每个 worker 缓存最多 32 个空闲到后端的连接。值建议为峰值并发的 1/4～1/2；
- reset_timedout_connection on：超时后发 RST 而非 FIN，跳过四次挥手，内核立刻回收 socket，对 Slowloris 类攻击和 TIME_WAIT 激增有明显抑制作用。
配套系统与 Nginx 内部调优
连接稳定性最终受限于底层能力，参数需与系统级配置对齐：
- worker 进程数设为 CPU 核心数（如 16 核设 worker_processes 16;），并启用 worker_cpu_affinity 绑核；
- worker_connections 设 8192–65535，同时配置 worker_rlimit_nofile 65535，并在 /etc/security/limits.conf 中同步调整 nofile 上限；
- 内核层面调大监听队列：sysctl -w net.core.somaxconn=65535，防止新连接被 listen 队列截断；
- 启用高效事件模型：use epoll; + multi_accept on;，提升 accept 效率，减少惊群。
验证是否真正生效
不能只看配置是否写上，要靠实时指标判断：
- 用 ss -tnpo | grep :443 | grep ESTAB | wc -l 观察 ESTABLISHED 连接数趋势，调优后应更平稳、无突增；
- 检查 nginx stub_status 中 Waiting 状态占比，过高说明空闲连接滞留严重；
- 抓包确认响应头含 Connection: keep-alive，且多个请求复用同一 TCP 流；
- 监控 error log 是否仍有 upstream prematurely closed connection 或 client closed connection while waiting for request，这些是上下游 keepalive 不匹配的典型信号。
