tcp_abort_on_overflow=1仅将全连接队列满时的静默丢包改为立即发RST，使客户端快速感知失败；真正有效的是扩大somaxconn与应用backlog并加快accept处理。
tcp_abort_on_overflow 本身不是防御手段，也不能缓解连接溢出压力。它只是改变内核在全连接队列满时的丢包行为：设为 1 时，立即发 RST 终止新连接；设为 0（默认）时，静默丢弃第三次握手的 ACK，客户端会超时重试。
先确认是不是真溢出了
别急着改参数。先看现象和指标：
- 运行 ss -lnt | grep :端口，关注 Recv-Q 值：若接近 Send-Q（即 backlog 大小），说明全连接队列已打满，应用 accept() 太慢或线程阻塞
- 执行 netstat -s | grep "listen.*overflows"，如果数字持续增长，就是明确的溢出证据
- 配合 ss -s 查看 orphan、synrecv 等计数，区分是半连接队列（SYN Flood）还是全连接队列（accept 瓶颈）的问题
真正有效的调优动作是扩容和加速
溢出的根本原因是“进得快、取得慢”。关键在两点：扩大容量 + 加快处理。
-
调大系统级全连接队列上限：
临时生效：sysctl -w net.core.somaxconn=65535
永久生效：在 /etc/sysctl.conf 中添加 net.core.somaxconn = 65535，再运行 sysctl -p -
同步调大应用层 backlog（否则无效）：
Tomcat/Spring Boot：server.tomcat.accept-count=65535
Netty/Golang：SO_BACKLOG 设为 65535
Java 原生：new ServerSocket(port, 65535)（默认仅 50） - Docker 注意事项：容器默认继承宿主机低值（常为 128），启动时需加 --sysctl net.core.somaxconn=65535
tcp_abort_on_overflow 的合理定位
它只是配套策略，不是主因解决方案。设为 1 的真实价值是：
- 让客户端在第三次握手失败后立刻收到 RST，避免长时间等待超时（默认最多 127 秒）
- 便于 NIO 客户端捕获连接关闭事件，快速重试或降级
- 减少服务端堆积无效状态，降低后续误判干扰
但它不提升吞吐、不减少丢包、也不抵御攻击——只让失败更透明、更可控。
