Nginx TCP代理高并发性能瓶颈在于内核与配置协同，需调优somaxconn、tcp_max_syn_backlog等队列参数防SYN丢包，启用tcp_tw_reuse和扩大ip_local_port_range加速端口复用，放宽file-max、rmem/wmem缓冲区限制，并匹配stream模块backlog与worker_connections。
Nginx 的 TCP 代理（通过 stream 模块实现）处理高并发响应性能，关键不在“代理逻辑本身”，而在于连接建立、转发路径和系统资源调度的协同效率。它不解析应用层协议，但对底层网络行为极其敏感——稍有不慎，就会在建连、端口耗尽、缓冲区溢出或队列丢包环节卡住。真正决定性能上限的，是 Linux 内核与 Nginx 配置的精准咬合。
连接接纳能力必须匹配内核监听队列
TCP 代理每监听一个端口（如 Redis 或 MySQL 端口），都依赖内核的 `listen()` socket 接收新连接。如果内核队列太小，客户端 SYN 包直接被丢弃，现象是大量 `Connection refused` 或超时，而非 Nginx 日志报错。-
net.core.somaxconn = 65535：这是全系统级监听队列上限，必须 ≥ Nginx
listen指令中的backlog值（例如listen 6379 backlog=65535;） -
net.ipv4.tcp_max_syn_backlog = 65535：SYN 半连接队列容量，应对突发握手洪峰；低于
somaxconn会导致 SYN 包静默丢弃 - net.core.netdev_max_backlog = 262144：网卡软中断接收队列，防止网卡收包过快、内核来不及处理而丢包
短连接场景下端口回收必须加速
数据库、Redis 等 TCP 代理常面对海量短连接（一次查询即断开），极易堆积 `TIME-WAIT` 状态连接，导致： - 本地端口耗尽 → `Cannot assign requested address` - 后端连接失败 → 代理层返回 `502` 或超时解决方式不是“消灭 TIME-WAIT”，而是让它快速复用：
-
net.ipv4.tcp_tw_reuse = 1：允许将处于
TIME-WAIT的端口用于新出向连接（Nginx 主动连接后端时生效） - net.ipv4.ip_local_port_range = "1024 65535"：提供约 6.4 万个临时端口（默认仅 3.2 万）
-
net.ipv4.tcp_fin_timeout = 30：缩短
FIN_WAIT_2超时，加快连接彻底关闭 - 务必禁用 tcp_tw_recycle：该参数在 NAT/负载均衡环境下会引发连接异常，已废弃，设为 0
缓冲区与资源限制需面向吞吐而非请求量
TCP 代理不处理 HTTP 头、不解包 body，但它更依赖稳定的大吞吐通道——尤其是跨机房、高延迟链路。-
fs.file-max = 2097152：系统级最大文件描述符数，应 ≥
worker_rlimit_nofile × worker_processes - net.core.rmem_max / wmem_max = 16777216（16MB）：提升单连接收发缓冲上限，适应突发带宽或高 RTT
- net.ipv4.tcp_rmem / tcp_wmem = "4096 65536 8388608"：启用自动缩放模式，兼顾小包低延迟与大流吞吐
- vm.swappiness = 1：极低交换倾向，避免内存压力触发 swap，导致代理延迟飙升
Nginx stream 模块自身配置要轻量且确定
`stream` 块配置不复杂，但每个参数都影响连接生命周期：-
worker_processes auto;+worker_cpu_affinity auto;：绑定 CPU 核心，减少缓存失效 -
worker_rlimit_nofile 100000;：与系统ulimit -n和fs.file-max对齐 -
events { use epoll; worker_connections 65535; multi_accept on; accept_mutex off; }：关闭互斥锁、批量收连接，高并发下更高效 -
stream { upstream backend { server 10.0.1.10:6379; } server { listen 6379 backlog=65535; proxy_pass backend; } }：backlog必须 ≤somaxconn，否则无效
不复杂但容易忽略
