负载均衡压榨tcp长连接潜力的关键在于连接建立、复用、分发、释放四环节精准匹配后端行为与网络实际，需http和stream双配置并行、参数严格分层、upstream长连接池合理设置、算法按业务选型、健康检查与超时闭环。

要让负载均衡真正“压榨”TCP长连接的高并发潜力，关键不是堆高并发数，而是让Nginx（或类似代理）在连接建立、复用、分发、释放四个环节都精准匹配后端行为和网络实际。所谓“压榨模式”，本质是**最小化无效连接、最大化连接复用、最准实时感知负载、最快隔离异常节点**——这需要HTTP和stream两套配置逻辑并行落地，不能混用。

明确连接归属，分层设参

必须严格区分两类TCP连接，参数不可交叉：

• 客户端 → Nginx 连接：由 keepalive_timeout、tcp_nodelay on、reset_timedout_connection on 控制；适用于WebSocket、API网关、MySQL直连等场景
• Nginx → 后端服务连接：由 upstream keepalive N（HTTP）或 proxy_timeout+proxy_connect_timeout（stream）控制；这是压榨性能的核心战场

错配会导致TIME_WAIT暴涨、连接被误断、复用率归零——比如把后端Redis的60秒超时设成Nginx客户端侧的120秒，连接就会在后端主动关闭后滞留于Nginx空闲池中，无法复用。

Upstream长连接池必须显式启用且合理 sizing

这是提升高并发下吞吐量最直接有效的手段，但很多人只写 keepalive 32 却忽略其真实含义：

• keepalive 32 不是“最多保持32个连接”，而是每个worker进程最多缓存32个空闲连接供复用
• 建议值 = 单worker预期并发峰值 × 0.3～0.5（例如峰值5000连接，设16–32即可；设256反而浪费内存且增加锁竞争）
• HTTP场景务必搭配：proxy_http_version 1.1; 和 proxy_set_header Connection "";，否则后端可能按HTTP/1.0处理，立即关闭连接
• stream场景（如MySQL/Redis）需加：proxy_timeout 300s; + tcp_nodelay on;，避免Nagle算法引入毫秒级延迟

按业务特征选算法，拒绝轮询一刀切

TCP是长连接协议，轮询不看状态，极易导致连接堆积。必须根据后端服务类型动态选择：

• 数据库/缓存类（MySQL、Redis、Elasticsearch）：用 least_conn; —— 它统计的是当前ESTABLISHED连接数，能真实反映节点压力，实测10万连接下各节点偏差＜5%
• 会话敏感型（IM、WebSocket、自定义信令）：禁用 ip_hash（NAT下失效），改用 hash $upstream_http_x_session_id consistent;，要求客户端透传唯一会话ID
• 异构集群（新旧机器混合）：组合使用，如 least_conn; server 10.0.1.1:6379 weight=5;，既保负载均衡又兼顾算力差异

健康检查+超时闭环，让故障响应快于业务超时

高并发下，一个慢节点会拖垮整条链路。必须让Nginx比客户端更快发现并绕过问题：

• 主动健康检查：health_check interval=3s fails=2 passes=2;，配合 match 块验证协议响应（如发送 PING 收到 PONG）
• 连接超时分级设置：proxy_connect_timeout 1s（内网）、proxy_timeout 300s（略大于后端最长耗时，如Redis批量操作240s→设300s）
• 防止单点打爆：server 10.0.1.1:3306 max_conns=2048;，超过即排队或返回503，不透传压力
• 日志可观测：log_format tcp_log "$remote_addr $upstream_addr $connection $upstream_connect_time";，用于分析连接分布与建连延迟

不复杂但容易忽略