keepalive_timeout 0 并非关闭长连接，而是禁用 HTTP keep-alive，强制响应后立即关闭 TCP 连接，不发 Connection: keep-alive 头，增加握手/挥手开销及 TLS 重复成本。
在 Nginx 中，keepalive_timeout 设置为 0 并不会“关闭”长连接本身，而是**禁用 HTTP keep-alive 功能**，强制所有连接在响应结束后立即关闭。这对原本走短连接的请求影响不大，但会显著改变 Nginx 处理连接的方式和性能表现。
keepalive_timeout 0 的实际行为
当配置 keepalive_timeout 0; 时：
- Nginx 不会在响应头中添加
Connection: keep-alive（HTTP/1.1 默认是持久连接，但 Nginx 主动禁用） - 无论客户端是否请求 keep-alive，Nginx 都会在发送完响应后调用
close()关闭 TCP 连接 - 该设置作用于 server、location 或 http 块，优先级遵循 Nginx 配置继承规则
- 注意：它不影响 upstream 的 keepalive（那是
keepalive指令控制的），只影响客户端到 Nginx 这一跳
对短连接请求的影响有限，但有隐性开销
如果客户端本就是发单次请求、不复用连接（典型短连接场景），设为 0 看似“正合其意”，但仍有几点值得注意：
- 每次请求仍需经历完整的 TCP 三次握手和四次挥手，增加延迟（尤其高延迟网络）
- 内核 socket 创建/销毁、TIME_WAIT 状态增多，可能更快耗尽本地端口或连接跟踪表项
- 对 HTTPS 请求，TLS 握手开销无法复用，CPU 和延迟压力更明显
- 某些客户端（如浏览器）可能因未收到
Connection: close而等待超时才断连，反而延长感知延迟
真正需要关闭 keep-alive 的典型场景
并非所有短连接都该关 keep-alive，只有以下情况才建议设为 0：
- 明确对接不支持 keep-alive 的老旧客户端（如部分嵌入式设备、定制协议网关）
- 调试或压测时，模拟极端短连接行为，观察单请求吞吐极限
- 反向代理到上游服务时，上游明确要求每请求新建连接（此时应配
proxy_http_version 1.0;+proxy_set_header Connection '';，而非仅靠keepalive_timeout 0）
替代方案比直接设 0 更合理
多数情况下，与其粗暴设为 0，不如用更精细的控制：
- 保持默认值（如 65s），让兼容客户端自然复用连接，提升整体吞吐
- 用
keepalive_requests限制单连接最大请求数，防资源长期占用 - 对特定 location（如 /api/v1/health）用
add_header Connection close;强制关闭，不影响其他路径 - 通过
map指令按 User-Agent 或请求头动态控制 keepalive 行为
