Nginx 中 nginx.conf 对 TCP 连接 Keepalive 优化-Nginx-PHP中文网

nginx tcp keepalive优化需分三层：http反向代理层（upstream keepalive+proxy_http_version 1.1）、tcp四层stream层（keepalive+keepalive_timeout）、客户端连接层（keepalive_timeout/requests）；配置错位则无效。

nginx 中 nginx.conf 对 tcp 连接 keepalive 优化

Nginx 对 TCP 连接的 Keepalive 优化，核心在于区分两个独立层面：客户端到 Nginx 的连接复用（HTTP 层），以及Nginx 到后端服务器的连接复用（反向代理层或 stream 层）。配置必须精准对应场景，否则形同虚设。

一、HTTP 反向代理场景：Nginx 到后端 HTTP 服务的 Keepalive
这是最常见也最容易配错的部分。默认情况下，Nginx 每次请求都会新建后端 TCP 连接，造成大量 TIME_WAIT 和后端 CPU 压力。

在 upstream 块中声明连接池：

upstream app_backend {
  server 127.0.0.1:8000;
  keepalive 32;  # 每个 worker 进程最多缓存 32 个空闲长连接
}

在 location 块中确保协议与头部兼容：

location / {
  proxy_pass http://app_backend;
  proxy_http_version 1.1;           # 必须启用 HTTP/1.1
  proxy_set_header Connection '';   # 清除可能携带的 close 头
}

不要混淆 keepalive_timeout（客户端侧）和 upstream keepalive（后端侧）：前者管浏览器连 Nginx，后者管 Nginx 连后端，作用对象完全不同。

二、TCP 四层代理场景（stream 模块）：MySQL/Redis 等非 HTTP 流量
适用于数据库、消息队列等纯 TCP 服务，需启用 stream 模块并单独配置。

启用 stream 块，并在 upstream 中设置连接复用参数：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

stream {
  upstream redis_pool {
    server 192.168.1.100:6379;
    keepalive 64;              # 每 worker 最多 64 个空闲连接
    keepalive_timeout 60s;    # 空闲连接保留 60 秒
  }
<p>server {
listen 6380;
proxy_pass redis_pool;
proxy_buffering off;       # 必须关闭，避免粘包
proxy_responses 0;         # Redis/MySQL 类协议设为 0（非单响应场景）
}
}</p>

注意：stream 模块不支持 proxy_http_version 或 Connection 头控制，它依赖底层 TCP 行为，因此 keepalive + keepalive_timeout 是唯一复用机制。

三、客户端连接生命周期管理（通用）
无论代理哪种后端，Nginx 与客户端之间的连接也需合理管控，避免资源滞留或过早断开。

设置合理的空闲保持时间与请求数限制：

http {
  keepalive_timeout 65 60;     # 等待 65 秒后关闭，响应头写 60 秒
  keepalive_requests 100;      # 单连接最多处理 100 个请求
  tcp_nodelay on;              # 减少小包延迟，适合 API 场景
}

移动端或高并发网关可调低 keepalive_timeout（如 5–15 秒），防止文件描述符耗尽；内网长连接服务（如 SSE）可设为 300 秒。

四、验证是否真正生效
配置写完不等于优化到位，必须通过现象确认：

查看后端服务器连接状态：ss -tn | grep :port | wc -l，稳定值应接近 keepalive × worker_processes，而非随并发线性增长
检查 Nginx error log：频繁出现 connect() failed (111: Connection refused)，说明连接池太小；大量 upstream timed out，则需排查后端响应或 proxy_read_timeout 设置
使用 curl -I 观察响应头是否含 Connection: keep-alive（HTTP 场景），或用 tcpdump 抓包确认 TCP 连接是否复用

不复杂但容易忽略