核心是启用upstream keepalive连接池并合理配置keepalive_requests与超时策略：需设keepalive 32、proxy_http_version 1.1、proxy_set_header connection ''，避免仅调大keepalive_requests而忽略连接复用机制。
要解决微服务网关间因高QPS导致的TCP频繁握手与挥手开销，核心不是单纯调大 keepalive_requests，而是配合连接复用机制（keepalive）、上游健康状态、请求特征和超时策略做系统性调优。
理解 keepalive_requests 的真实作用
keepalive_requests 控制的是单个长连接上最多能承载多少个 HTTP 请求后主动关闭该连接。它不控制连接是否复用，也不影响 TCP 握手频率——真正决定是否复用连接的是 keepalive 指令（启用 upstream 连接池）和客户端/上游服务的 Connection: keep-alive 行为。
若只调高 keepalive_requests 但未开启或配好 keepalive，Nginx 仍会为每个请求新建 TCP 连接，该参数完全无效。
必须配套启用 upstream keepalive 连接池
在 upstream 块中启用长连接复用，才是降低挥手开销的关键：
- 添加
keepalive 32;（数字建议设为单个 worker 进程预期并发连接数的 1–2 倍） - 必须去掉
proxy_http_version 1.0;，改用proxy_http_version 1.1; - 显式设置
proxy_set_header Connection '';，避免透传close头干扰复用 - 确保上游微服务支持 HTTP/1.1 并正确处理
Connection: keep-alive
合理设置 keepalive_requests 与超时组合
该值过小（如默认 100）会导致连接过早回收；过大（如 10000+）可能让空闲连接滞留太久，占用 fd 资源，还可能拖慢故障节点的剔除速度。
推荐按以下方式设定：
- 观察典型请求耗时（P95 keepalive_requests 2000 可支撑约 10 秒活跃期
- 搭配
keepalive_timeout 60s;，形成“请求数 + 时间”双重退出条件 - 若上游存在偶发卡顿，可适当降低该值（如 500–1000），加速异常连接释放
验证与观测要点
调优后需确认是否真正生效：
- 用
ss -tnp | grep :80 | wc -l对比调优前后 ESTAB 连接数变化趋势 - 开启 Nginx stub_status，关注
Active connections和Reading/Writing/Waiting分布 - 在 upstream 日志中打开
$upstream_addr和$upstream_connect_time，统计复用率与建连耗时下降比例 - 抓包验证：连续多个请求是否复用同一 source port → dest port 组合
不复杂但容易忽略。
