net.core.somaxconn与应用层backlog不匹配导致全连接队列溢出，引发connection refused或超时；实际生效值为二者最小值，需同步调大并检查fd限制三层配置。
net.core.somaxconn 和应用层 backlog 不匹配导致连接拒绝
客户端频繁报 Connection refused 或超时，但服务端 CPU、内存正常，大概率是全连接队列溢出。内核用 net.core.somaxconn 限制每个监听 socket 的已完成三次握手的连接数上限，而应用调用 listen() 时传入的 backlog 参数若小于该值，实际生效的仍是较小者。
常见陷阱：
- Java（如 Tomcat）默认
acceptCount=100，远低于net.core.somaxconn=65535，队列实际卡在 100 - Go
net.Listen()默认 backlog 是系统SOMAXCONN值，但旧版 Go（ - Nginx 的
listen ... backlog=必须显式设置，否则用内核默认（常为 128）
实操建议：
- 统一设
net.core.somaxconn = 65535（临时：sysctl -w net.core.somaxconn=65535；永久：写入/etc/sysctl.conf后sysctl -p） - 同步检查并调高应用配置：Tomcat 改
server.xml中acceptCount；Nginx 加backlog=65535；Node.js 用server.listen(port, host, backlog) - 验证是否生效：
ss -ltn看Send-Q列是否为 65535
tcp_max_syn_backlog 过小引发 SYN_RECV 堆积
当大量客户端并发发 SYN 包，而服务端处理不过来时，未完成三次握手的连接会堆积在半连接队列。此时 netstat -s | grep -i 'listen drops' 可能显示 Listen overflows 或 SYN cookies sent，ss -ntp state syn-recv 能看到大量 SYN_RECV 状态连接。
该参数和 net.ipv4.tcp_syncookies 强相关：
-
tcp_max_syn_backlog控制队列长度，默认常为 128 或 8192，万级并发下极易打满 - 若
tcp_syncookies=1（默认开启），队列满后内核会启用 cookie 机制，但带来额外计算开销且部分客户端不兼容 - 单纯开
syncookies不解决根本问题，应优先扩大队列
实操建议：
- 设
net.ipv4.tcp_max_syn_backlog = 65535，与somaxconn对齐 - 确认
net.ipv4.tcp_syncookies = 1作为兜底（防 SYN Flood），但不依赖它扛流量 - 观察
/proc/net/snmp中TcpExt: ListenOverflows计数是否归零
ip_local_port_range 和 tcp_tw_reuse 不配合导致 Cannot assign requested address
对 API 网关、微服务调用方等高频主动建连的服务，Cannot assign requested address 错误本质是本地端口耗尽。默认 ip_local_port_range = 32768 65535 仅提供约 3.2 万个临时端口，而每个 TIME_WAIT 连接会占用端口约 60 秒（tcp_fin_timeout 默认值）。
关键点在于：即使扩宽端口范围，若不启用复用，TIME_WAIT 端口仍不可用于新连接。
-
net.ipv4.ip_local_port_range = 1024 65535提供超 6.4 万个可用端口（避开 1–1023 即可） -
net.ipv4.tcp_tw_reuse = 1允许内核将处于 TIME_WAIT 的端口快速复用于新 outbound 连接（需确保net.ipv4.tcp_timestamps = 1，现代内核默认开启） -
net.ipv4.tcp_tw_recycle已被移除（Linux 4.12+），切勿配置
实操建议：
- 直接写入：
echo "net.ipv4.ip_local_port_range = 1024 65535" >> /etc/sysctl.conf - 必须配对启用：
echo "net.ipv4.tcp_tw_reuse = 1" >> /etc/sysctl.conf - 缩短回收时间可选：
net.ipv4.tcp_fin_timeout = 30，但效果不如tw_reuse直接
文件描述符限制未同步提升导致 accept 失败
每个 TCP 连接至少消耗 1 个文件描述符（fd）。即使内核参数全调到 65535，若进程或系统级 fd 限制太低，accept() 仍会返回 EMFILE 错误。
三层限制必须全部检查：
- 系统级最大 fd 数：
cat /proc/sys/fs/file-max，建议 ≥ 131072 - 用户级硬限制：
ulimit -Hn，需在/etc/security/limits.conf中设* hard nofile 65536 - 进程启动时软限制：
ulimit -Sn，对应* soft nofile 65536，且需确保 PAM 模块加载（/etc/pam.d/common-session含pam_limits.so）
容易被忽略的点：
- systemd 服务需单独配置：
LimitNOFILE=65536写入 service 文件的[Service]段 - Docker 容器需加
--ulimit nofile=65536:65536或改 daemon.json - Java 应用启动前执行
ulimit -n 65536无效，必须由 shell 启动环境继承
