keepalive_timeout 0 并非关闭短连接，而是禁用 HTTP keep-alive 功能，强制响应后立即关闭 TCP 连接，不发 Connection: keep-alive 头，增加握手/挥手、TLS 重复开销及 TIME_WAIT 压力。
keepalive_timeout 0 并不等于“关闭短连接”，而是主动禁用 HTTP keep-alive 功能，强制 Nginx 在每次响应后立即关闭 TCP 连接。这对本就走短连接的请求看似无感，实则引入了隐性开销和兼容风险。
它实际做了什么
- 不再发送
Connection: keep-alive响应头（HTTP/1.1 默认应复用，Nginx 主动放弃） - 无论客户端是否发起复用请求，响应一结束就调用
close()断开 TCP - 仅影响 client → Nginx 这一跳，对 upstream 的长连接（如
upstream keepalive）完全无影响
对短连接请求的真实影响
- 延迟上升：每次请求都需完整 TCP 三次握手 + 四次挥手，高延迟网络下首字节时间（TTFB）明显增加
- 内核资源压力变大：TIME_WAIT 状态激增，可能更快耗尽本地端口或 conntrack 表项
- HTTPS 开销翻倍：TLS 握手无法复用，CPU 占用升高，尤其在小包高频请求场景中尤为明显
-
客户端行为不可控：部分浏览器或 SDK 未收到
Connection: close头时，会等待自身超时才断连，反而延长感知延迟
什么情况下才真该设为 0
- 对接明确不支持 keep-alive 的老旧设备（如某些工业网关、嵌入式终端）
- 压测时模拟极端短连接模型，验证单请求吞吐极限
- 反向代理上游要求每请求新建连接（此时更推荐配
proxy_http_version 1.0;+proxy_set_header Connection '';，而非仅靠keepalive_timeout 0）
更合理的替代做法
- 对全站保持默认值（如
30s），让现代客户端自然复用，提升整体效率 - 对特定路径（如健康检查
/healthz）用add_header Connection close;精准关闭 - 用
map指令按User-Agent或请求头动态控制，例如对已知弱客户端设短 timeout，而非一刀切为 0 - 配合
keepalive_requests 100，既允许复用，又防止单连接长期滞留
不复杂但容易忽略
