Nginx TCP Keepalive优化需分三层：HTTP反向代理层（upstream keepalive+proxy_http_version 1.1）、TCP四层stream层（keepalive+keepalive_timeout）、客户端连接层（keepalive_timeout/requests）；配置错位则无效。
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 中设置连接复用参数：
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（非单响应场景） } } 注意：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 连接是否复用
不复杂但容易忽略
