Nginx Stream模块高性能TCP转发的关键在于系统资源对齐与参数精准匹配：需同步调大文件描述符上限、内核连接队列、启用epoll多连接接受、合理配置keepalive与超时、按业务调整缓冲及读写超时。
Nginx Stream 模块提升 TCP 转发处理水平，关键不在“加功能”，而在让每个连接真正稳住、快速流转、不被系统卡住。它本质是复用 Nginx 已有的高效事件循环，做纯字节流透传，但效果好不好，取决于底层资源是否对齐、参数是否咬合。
必须匹配系统级文件描述符上限
Stream 处理的是原生 TCP 连接，每个连接至少占 1 个文件描述符（fd）。若 worker_connections 设为 65536，但 nginx 进程的 ulimit -n 仍是默认 1024，那实际能建立的连接数就是 1024 —— 多余请求会被内核静默丢弃，日志里甚至没有记录。
- 在
/etc/security/limits.conf中为 nginx 用户（如www-data或nginx）添加：www-data soft nofile 2097152 www-data hard nofile 2097152
- 同时在
nginx.conf的 main 块中写明：worker_rlimit_nofile 2097152; - 验证方式：
cat /proc/$(pgrep nginx)/limits | grep "Max open files"，确认 soft/hard 值均 ≥worker_connections × worker_processes
同步调大内核连接队列长度net.core.somaxconn 控制每个监听 socket 的「已完成三次握手、等待 accept()」队列长度。默认值常为 128，瞬时建连高峰会直接丢 SYN ACK 包，客户端表现为“连接超时”，Nginx 却无日志。
- 计算建议值：
somaxconn ≥ worker_connections / worker_processes × 2（留余量）
例如worker_processes 4、worker_connections 1048576，则somaxconn至少设为524288 - 同步调整
net.ipv4.tcp_max_syn_backlog（未完成连接队列），建议设为somaxconn的 1.5–2 倍 - 生效命令：
sysctl -w net.core.somaxconn=524288sysctl -w net.ipv4.tcp_max_syn_backlog=1048576
并写入/etc/sysctl.conf永久保存
启用 epoll + multi_accept 提升事件处理效率
Stream 不走 HTTP 流程，对 I/O 模型更敏感。若未显式指定，Nginx 可能回退到 select，触发 1024 连接硬限制。
- 在
events块中必须配置：use epoll;multi_accept on;accept_mutex on;（默认开启，保持即可） -
multi_accept on表示单次 epoll_wait 尽可能 accept 多个就绪连接，减少系统调用次数，显著降低高并发下的调度抖动
合理设置连接保活与超时参数
长连接场景下，空闲连接易被中间设备（NAT、防火墙）静默断开，需靠内核 keepalive 与 proxy_timeout 协同兜底。
-
listen 3306 so_keepalive=300s:15s:4;
表示空闲 300 秒后开始探测，每 15 秒发一次，连续 4 次失败才断连 -
proxy_timeout 1h;
必须 ≥ keepalive 总探测耗时（300 + 15×4 = 360 秒），否则 Nginx 会先于探测结束就关闭连接 -
proxy_responses 1;
等待上游返回第一个响应包再确认连接可用，比仅靠三次握手更可靠，防后端服务监听了端口但尚未就绪
缓冲与转发行为按业务节奏适配
大流量或大数据包场景（如 mysqldump、Redis bigkey 扫描），小缓冲会导致频繁 syscall 或截断。
-
proxy_buffer_size 512k;
建议设为 256K～1M，注意这是 per-connection 缓冲，高并发下需权衡内存占用 -
proxy_read_timeout 300s;和proxy_send_timeout 60s;
按实际业务响应时间设定，避免慢查询拖垮整个连接池 - 若后端支持 PROXY 协议（如 HAProxy + MySQL），可加
proxy_protocol on;透传客户端真实 IP
不复杂但容易忽略
