nginx tcp负载均衡需针对性调优：长连接选least_conn，会话粘性用ip_hash，性能不均配weight；须设max_conns防过载、max_fails/fail_timeout快速故障隔离；stream块须与http同级，端口不可省略，权重仅影响新连接。
要让 Nginx 的 TCP 代理真正发挥负载均衡效能，不能只靠简单配置 upsteam 和 proxy_pass。关键在于匹配业务特征做针对性调优——比如连接模式（短连/长连）、协议类型（MySQL/Redis/自定义）、后端健康状态和网络延迟差异。
合理选择 upstream 调度算法
TCP 场景下默认轮询（round-robin）未必最优，需结合实际流量特征选型：
- least_conn：适合长连接、处理耗时差异大的服务（如数据库读操作），避免某台后端堆积大量空闲连接
- ip_hash：仅适用于客户端 IP 相对固定且需会话粘性的场景（如某些定制化 TCP 网关），但会削弱负载分散性
- 加权分配（weight）：当后端服务器规格不一致（如 8C16G vs 4C8G）时，按处理能力设 weight=3、weight=1，比均分更公平
- 不建议在 TCP 层用 hash $remote_addr 以外的字段（如 URI 或 header），因 TCP 协议本身无 HTTP 头部结构
精细控制连接生命周期
TCP 代理不像 HTTP 可依赖请求级超时，必须从连接级入手管理资源：
- 用 max_conns 限制单台后端最大并发连接数，防止单点过载（例如设为 500，避免压垮 MySQL 实例）
- 搭配 max_fails 和 fail_timeout 实现快速故障隔离（如 max_fails=2 fail_timeout=15s），比等待连接超时更及时
- 启用 slow_start（Nginx Plus 支持）：新上线节点逐步增加流量，避免冷启动冲击
- 注意：stream 模块中没有 keepalive 指令（那是 http 模块的），TCP 连接复用依赖客户端行为或中间件自身保活机制
提升健康检查与容灾能力
原生 stream 模块不支持主动健康探测（如 TCP 握手 + 发送探针），需组合策略弥补：
- 利用 proxy_timeout 参数间接判断：设置 proxy_timeout 5s，若连接建立或数据交互超时，自动触发重试或切换节点
- 配合 backup 服务器兜底，尤其适用于主从架构（如 MySQL 主库挂了自动切到从库读）
- 通过外部脚本+nginx -s reload 实现动态剔除（例如用 telnet 检测端口，失败则注释对应 server 行）
- 日志格式中加入 $upstream_addr 和 $session_time，便于定位连接倾斜或异常断连问题
避免常见配置陷阱
几个高频出错点直接影响均衡效果：
- stream 块必须与 http 块同级，不能嵌套在 http 内，否则配置不生效
- server 指令中的端口必须明确写全（如 192.168.1.100:3306），不能省略 :port，否则解析失败
- 权重（weight）只影响新连接分配，已建立的连接不会迁移，因此权重调整后需等待自然轮替
- 不要在 stream 中滥用 resolver —— DNS 解析在 TCP 初始化阶段完成，动态更新需配合 resolve 参数且仅限主机名
