Nginx对上游服务器使用keepalive

m0_61787196

474人浏览 · 2026-06-12 01:24:58

m0_61787196 · 2026-06-12 01:24:58 发布

一、引言：别让 Nginx 成为“短连接制造机”

当 Nginx 作为反向代理时，它位于客户端和后端应用服务器（如 Tomcat, Node.js, PHP-FPM）之间。一个常见的性能陷阱是：Nginx 与后端服务器之间的连接默认是短连接！

这意味着，对于每一个来自客户端的请求，Nginx 都会：

与后端服务器进行一次完整的 TCP 三次握手。
转发请求并接收响应。
立即进行 TCP 四次挥手 关闭连接。

而后端服务器处理 TCP 连接的开销通常远大于 Nginx。在高并发场景下，这种“用完即弃”的模式会导致：

后端服务器 CPU 飙升：大量时间花在处理连接建立/关闭上。
Nginx 本地端口耗尽：产生海量 TIME_WAIT 连接。
整体吞吐量急剧下降。

upstream keepalive 机制正是为解决此问题而生。它允许 Nginx 与后端服务器之间复用 TCP 连接，将 Nginx 从“短连接制造机”转变为高效的“连接管理者”。

💡 核心价值：
正确配置 upstream keepalive，是释放 Nginx 反向代理全部性能潜力的关键一步，能带来数倍的 QPS 提升！

二、工作原理：Nginx 的上游连接池

upstream keepalive 并非简单地开启一个开关，而是建立了一个智能的连接池。

1. 核心流程

请求到来：Nginx 收到一个需要转发给后端的请求。
池中寻觅：Nginx 检查其 upstream 连接池，看是否有空闲的、指向目标后端的 KeepAlive 连接。
复用 or 新建：
- 如果有空闲连接，则直接复用，发送请求。
- 如果没有，则新建一个 TCP 连接。
归还连接：请求处理完毕后，如果后端响应支持 KeepAlive，Nginx 不会关闭这个连接，而是将其放回连接池，供后续请求使用。
池满或超时：当连接池已满，或者连接空闲时间过长，Nginx 会清理掉这些连接以释放资源。

2. 关键特性

每个 Worker 独立：连接池是按 Nginx 的 worker 进程隔离的。总的最大空闲连接数 = keepalive * worker_processes。
仅缓存空闲连接：keepalive 指令定义的是空闲连接的数量上限，而不是总连接数。活跃的连接不受此限制。

三、核心配置：三步开启上游 KeepAlive

要让 upstream keepalive 生效，必须同时配置以下三个部分，缺一不可。

第一步：在 `upstream` 块中定义连接池大小

upstream backend {
    # 为每个 worker 进程缓存 32 个空闲的 keepalive 连接
    keepalive 32;

    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
}

keepalive 32: 这是最核心的指令。数字 32 表示每个 worker 进程最多可以缓存 32 个空闲的、与后端服务器的 HTTP/1.1 KeepAlive 连接。

第二步：在 `location` 块中强制使用 HTTP/1.1

server {
    location / {
        proxy_pass http://backend;
        
        # 必须设置！强制 Nginx 使用 HTTP/1.1 与后端通信
        proxy_http_version 1.1;
    }
}

proxy_http_version 1.1: KeepAlive 是 HTTP/1.1 的默认行为。如果不显式指定，Nginx 默认使用 HTTP/1.0 与后端通信，而 HTTP/1.0 默认是短连接。

第三步：清除干扰性的 `Connection` 头

server {
    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        
        # 必须设置！清除从客户端带来的 Connection 头
        proxy_set_header Connection "";
    }
}

proxy_set_header Connection "": 客户端可能会发送 Connection: close 或 Connection: keep-alive。如果不清理，这个头部会被透传给后端，可能干扰 Nginx 与后端之间 KeepAlive 连接的建立。将其设为空字符串，可以确保 Nginx 完全掌控与后端的连接行为。

四、深度调优：如何确定 `keepalive` 的最佳值？

keepalive 的值并非越大越好，需要根据业务场景精确计算。

1. 计算公式

一个经验公式是：
每个后端所需连接数 ≈ (QPS / 后端数量) * 平均响应时间(秒)

2. 实战案例

假设你的系统指标如下：

总 QPS: 2000
后端服务器数量: 4 台
平均响应时间 (RT): 50ms (0.05秒)

计算过程：

每台后端承受的 QPS = 2000 / 4 = 500
每台后端所需的连接数 = 500 * 0.05 = 25

因此，keepalive 的值应略大于 25，比如设置为 32。

3. 监控与验证

监控 TIME_WAIT: 使用 ss -tan state time-wait | wc -l 命令。配置生效后，TIME_WAIT 连接数应大幅下降。
观察后端负载: 后端服务器的 CPU 使用率（特别是 system CPU）应该显著降低。
压测对比: 使用 wrk 或 ab 工具进行压测，对比开启前后的 QPS 和延迟。