要让Nginx Stream模块扛住高并发TCP流量，必须调优Linux内核参数：增大somaxconn和tcp_max_syn_backlog至65535以上、扩宽ip_local_port_range、启用tcp_tw_reuse，并配合epoll事件模型、worker_connections调高、multi_accept开启及连接生命周期精细控制。
要让 Nginx Stream 模块真正扛住高并发 TCP 流量，光靠配置远远不够。性能瓶颈往往卡在操作系统内核和网络栈层面——连接数上不去、TIME_WAIT 爆满、accept 队列溢出、缓冲区吃紧，这些问题不会因为 proxy_pass 写对了就自动消失。
调整内核网络参数
Linux 默认参数为通用场景设计，不适合高并发代理网关：
- net.core.somaxconn：设为 65536 或更高，确保 listen backlog 不被截断（否则新连接直接丢弃）
- net.ipv4.tcp_max_syn_backlog：同步提升至与 somaxconn 相当，避免 SYN 队列满导致握手失败
- net.ipv4.ip_local_port_range：扩为 1024 65535，增加可用临时端口，缓解客户端侧端口耗尽
- net.ipv4.tcp_tw_reuse：设为 1，允许 TIME_WAIT 状态 socket 在安全前提下复用于新连接（需配合 timestamps=1）
- net.ipv4.tcp_fin_timeout：可适当调低（如 30），加速 FIN_WAIT_2 状态释放，但不宜过激
优化 Nginx worker 与连接模型
stream 模块的吞吐能力直接受限于 worker 进程的事件处理效率：
- events 块中启用 use epoll;（Linux 必选），避免 select/poll 的 O(n) 性能退化
- worker_connections 设为 65536+，并确保 ulimit -n ≥ 2×worker_connections（每个连接至少占 2 个文件描述符）
- worker_rlimit_nofile 显式设置，防止启动时受限于系统默认 soft limit
- 启用 multi_accept on;，让单次事件触发尽可能多地 accept 新连接，减少系统调用开销
控制连接生命周期与资源驻留
连接不是建立完就万事大吉，空闲连接、僵死连接、缓冲区堆积都会悄悄拖垮性能：
- server 块中使用 so_keepalive=300s:15s:4，主动探测 NAT/防火墙保活阈值，避免静默断连
- proxy_timeout 应略大于后端服务最大空闲容忍时间（如 Redis 默认 300s，这里设 360s），防止 Nginx 提前关闭合法长连接
- proxy_buffer_size 根据协议响应特征设（MySQL 大查询建议 512k，Redis 小包可保持默认 8k），过大浪费内存，过小引发频繁拷贝
- 务必显式声明 proxy_buffering off;（stream 模块默认关闭，但显式写明更可靠），避免缓冲干扰流式传输或造成粘包
监控验证是否生效
调优不是一锤定音，必须用数据确认效果：
- 检查 ss -s 输出中 TCP connection 统计，重点关注 established 数是否稳定、TIME_WAIT 是否可控
- 通过 nginx -T | grep -A5 stream 确认配置已加载且语法无误
- 观察 error log 中是否有 connect() failed (111: Connection refused) 或 upstream timed out，前者指向连接池不足或后端不可达，后者提示超时设置不合理
- 若启用 vts 模块或 Prometheus exporter，重点盯 stream_upstream_connections_active 和 idle 比值，理想情况 idle 占比应高于 30%（说明复用有效）
