keepalive_timeout仅控制nginx与客户端连接，不影响后端；后端连接复用需配置upstream keepalive、proxy_http_version 1.1及后端自身超时。

keepalive_timeout 不能优化后端长连接的闲置释放周期——它只管 Nginx 与客户端之间的连接，对后端（如 PHP-FPM、Node.js、Java 应用等）完全无效。

真正控制后端连接闲置释放的，是另一套独立配置：

• Nginx 到后端的连接池：靠 upstream 块中的 keepalive N 指令（例如 keepalive 32;），它定义了每个 worker 进程可复用的空闲后端连接数；
• 后端服务自身的超时设置：比如：
  • Spring Boot：server.tomcat.connection-timeout=60000
  • Node.js HTTP Server：server.timeout = 60000
  • PHP-FPM：request_terminate_timeout 或 pm.max_requests 配合连接生命周期管理

---

✅ 正确做法：前后端连接要“分段管理”

Nginx 前端连接和后端连接是两层独立链路，必须分别调优：

• keepalive_timeout（前端）
  控制浏览器/App 发起请求后，Nginx 空闲等待多久关闭该 TCP 连接。
  → 影响的是客户端重连频率、TLS 复用效率、文件描述符占用。

• upstream keepalive（后端）
  控制 Nginx 主动维护多少个到后端的空闲连接，避免每次请求都重建 TCP+应用层握手。
  → 必须配合 proxy_http_version 1.1; 和 proxy_set_header Connection ""; 才生效。

---

⚙️ 后端连接闲置释放的关键配置示例

upstream backend {
    server 127.0.0.1:8000;
    keepalive 64;  # 每个 worker 最多缓存 64 个空闲连接到后端
}

server {
    location /api/ {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        # 其他必要头...
    }
}

同时确保后端服务明确设置了连接空闲超时，且不大于 Nginx 的 upstream keepalive 超时逻辑（Nginx 不主动 kill 后端连接，但会拒绝复用已失效的连接）。

---

? 常见误区

• 把 keepalive_timeout 60; 当成“整个请求链路都保持 60 秒” → 错，它只作用于第一跳（客户端 ↔ Nginx）；
• 修改了 keepalive_timeout 却没配 upstream keepalive → 前端复用了，后端仍在频繁建连；
• 后端设了 timeout=5s，Nginx 却设 keepalive 100 → Nginx 缓存的连接可能已被后端关闭，导致 upstream prematurely closed connection 错误。

---

? 验证是否生效

• 查看 Nginx 日志中 $upstream_addr 字段，若出现 127.0.0.1:8000, 127.0.0.1:8000 连续复用，说明后端连接池起效；
• 用 ss -tan | grep :8000 | wc -l 观察稳定连接数是否在 keepalive N × worker_processes 量级浮动；
• 抓包确认后端 TCP 连接是否复用（相同源端口 + 目标端口多次交互）。

不复杂但容易忽略。