Nginx TCP代理连接复用核心机制是upstream keepalive连接池，需同时配置keepalive N、keepalive_timeout和proxy_buffering off三项；连接池大小应根据后端单实例最大连接数与worker数量反推，建议设为后端处理能力的1/2～1/3，并通过ss命令或监控指标验证idle连接占比是否健康。
TCP 代理连接复用的核心机制
Nginx 的 TCP 代理（通过 stream 模块实现）本身不依赖 HTTP 协议头，因此无法像 HTTP 场景那样靠 Connection: keep-alive 控制复用。它的连接复用完全由 upstream keepalive 指令驱动——即每个 worker 进程在内存中维护一个到后端的空闲连接池，新请求优先从池中取已建立的连接，而非新建 TCP 握手。
必须启用的三项基础配置
缺一不可，否则复用不会生效：
-
启用 stream keepalive 连接池：在 upstream 块中写
keepalive 32;（建议值 16–64），表示每个 worker 最多缓存该后端的 32 个空闲连接；8 个 worker 就是最多 256 条可复用连接。 -
设置空闲连接保活时长：搭配
keepalive_timeout 60s;，超时后自动关闭空闲连接，避免僵死连接堆积；该值应略小于后端服务的连接空闲超时（如 Redis 的timeout或 MySQL 的wait_timeout）。 -
禁用缓冲以保障协议原语：显式添加
proxy_buffering off;，防止 stream 模块因缓冲导致粘包、延迟或连接状态错乱——这对 Redis、MySQL、自定义 TCP 协议尤为关键。
连接池大小如何合理设定
不能拍脑袋填数字，需结合后端承载力反推：
- 若后端单实例最大连接数为 2000，Nginx 配置了 4 个 worker，按 70% 安全水位计算：2000 × 0.7 ÷ 4 ≈ 35，设
keepalive 32或48更稳妥。 - 对短会话协议（如 Redis 查询、MySQL 简单查询），建议设为后端单机处理能力的 1/2～1/3；对长连接协议（如 MQTT Broker、gRPC over TCP），可适当提高并配合更长的
keepalive_timeout。 - 避免设得过大：超出后端承受能力会导致连接被拒绝，或触发内核
TIME_WAIT资源耗尽（可通过调高net.ipv4.ip_local_port_range和开启tcp_tw_reuse缓解）。
验证复用是否真正生效
仅看配置不等于有效，要用数据确认：
- 在 Nginx 机器上执行：
ss -tan | grep :<em>backend_port</em> | grep ESTAB | wc -l，压测中连接数应稳定在worker_processes × keepalive附近，而非随并发线性上涨。 - 在后端服务器运行：
ss -s | grep "TCP:"，观察established数量是否显著低于客户端并发数；同时检查TIME_WAIT是否明显下降。 - 启用
nginx-vts-exporter或 Prometheus 监控stream_upstream_connections_active和stream_upstream_connections_idle指标，idle 连接占比持续高于 30% 说明复用健康。
