最有效手段是调大 /proc/sys/net/core/somaxconn 值并同步匹配 Nginx backlog、worker_connections 和文件描述符限制；若 ss -lnt 显示 Recv-Q 持续满载，且 error log 出现 accept() failed (99)，即表明内核连接队列已成瓶颈。
直接看 /proc/sys/net/core/somaxconn 的当前值，再结合 Nginx 实际并发连接压力来放大，是应对“Connection refused”最有效、最底层的手段之一。它不是玄学调优，而是对操作系统连接队列瓶颈的精准干预。
确认当前 somaxconn 值是否成为瓶颈
执行以下命令查看实时值：
cat /proc/sys/net/core/somaxconn
如果输出是 128、511 或 1024，基本可以判定已成瓶颈——尤其当 Nginx error log 中频繁出现 accept() failed (24: Too many open files) 或 accept() failed (99: Cannot assign requested address) 时，往往不是文件描述符不够，而是连接请求在内核队列里就被丢弃了。
更进一步验证：用 ss -lnt 查看各监听端口的 Recv-Q 列，若长期接近或等于当前 somaxconn 值（比如显示为 511/511），说明队列持续满载，新连接正在被内核静默丢弃。
安全放大的推荐取值与写法
不建议盲目设到 65535，应按实际负载阶梯式调整：
- 中小流量（峰值连接 ≤ 5k）：设为 4096 —— 兼容大多数云主机默认限制，且足够覆盖 Nginx 默认
backlog=511场景 - 中高流量（峰值连接 5k–20k）：设为 16384 —— 需同步在
nginx.conf的listen行显式声明backlog=16384，否则 Nginx 不会使用该上限 - 超大流量或 Ingress 场景：设为 65535 —— Nginx Ingress Controller 会自动读取该值作为 backlog，无需手动配；但需确保
fs.file-max≥ 2×该值，避免文件描述符耗尽
临时生效命令（测试用）：
sysctl -w net.core.somaxconn=16384
永久生效：写入 /etc/sysctl.conf 并运行 sysctl -p
必须同步检查的关联项
单独调大 somaxconn 可能无效，还需确认三项：
-
Nginx listen 配置是否匹配：例如
listen 80 backlog=16384;，否则 Nginx 仍按默认 511 接收，内核队列再大也无用 -
worker_connections 是否足够：若
worker_connections 1024，单 worker 最多处理 1024 连接，即使队列拉到 65535，也无法消费，需同步放大（如设为 8192） -
系统文件描述符上限：用
ulimit -n查 Nginx 进程限制，用cat /proc/sys/fs/file-max查全局上限；二者均应 ≥somaxconn × worker_processes × 2
避免踩坑的关键细节
以下操作看似“加强”，实则可能引发故障：
-
不要开启
tcp_tw_recycle：该参数在 NAT 环境（包括所有云厂商 VPC、K8s Service）下会导致连接异常，Linux 4.12+ 已彻底移除，务必设为 0 -
慎用
tcp_syncookies=0：关闭 SYN cookies 会削弱抗 SYN Flood 能力，除非你有硬件防火墙兜底，否则保持默认 1 更稳妥 -
别只调单个参数：
somaxconn必须和tcp_max_syn_backlog（建议同值或略高）、net.core.netdev_max_backlog（建议 ≥ somaxconn）协同调整，否则半连接队列或网卡软中断队列会先堵住
