连接数告急时，先别急着调大队列：如果大量连接停在握手阶段，扩大应用连接池未必有用；如果已建立连接长期不释放，单靠 SYN 代理也解决不了。处理 TCP连接耗尽攻击的识别与缓解措施，应先确定资源耗尽发生在哪一层，再决定拦截还是调参。
先判断耗尽的是哪种连接资源
TCP 建连要经过 SYN、SYN-ACK、ACK。服务器收到 SYN、尚未完成握手的连接属于半连接；完成握手后等待应用 accept 的连接，以及应用已接管的连接，则占用不同资源。SYN flood 常使半连接队列承压，但慢速客户端、应用处理变慢或连接未及时关闭，也可能让已建立连接持续堆积。
- 在 Linux 服务器运行 ss -s，观察连接状态概况；再用 ss -ant 查看 SYN-RECV、ESTAB 等状态是否异常集中。短时快照不能单独证明攻击，建议按相同间隔连续观察变化。
- 查看 nstat -az 中与 TCP 重传、连接失败相关的计数，并对照系统日志、负载均衡器和应用连接数。若请求量不高而 SYN-RECV 激增，更像握手阶段压力；若 ESTAB 很多且业务处理延迟上升，应进一步查连接持有时间与应用线程。
- 若启用了 conntrack，检查 conntrack -S 及当前跟踪表占用。跟踪表满与 TCP 队列满不是一回事，扩大 TCP 队列不会自动释放跟踪表资源。
这套 TCP连接耗尽攻击的识别与缓解措施，关键是将连接状态、系统计数和业务负载放在一起看，而不是只凭某个告警下结论。
SYN 代理：把握手压力挡在后端之前
SYN 代理（也称 SYN proxy）由防火墙、负载均衡器或具备相应能力的网络设备代替后端应答握手；客户端完成握手后，代理再与后端建立连接。对来源分散、半连接队列反复接近上限，且入口设备有足够处理能力的场景，它能减少不完整握手直接占用后端队列的风险。
代价是增加设备配置与连接状态管理，可能带来额外时延；代理容量或规则配置不当，也会成为新的瓶颈。启用前确认设备支持该功能，评估回源链路、超时、合法长连接及故障切换，并先在可回退的入口范围验证。SYN 代理主要针对握手阶段，不会替代应用层的连接生命周期管理。
系统调优：修正容量边界，不是消除攻击
Linux 可启用 SYN cookies，缓解半连接队列压力：检查 net.ipv4.tcp_syncookies 的当前值，并按发行版文档设置为启用。它在队列压力下减少保留半连接状态的需求，但不增加应用处理能力，也不能解决已建立连接占满、带宽打满或 conntrack 表耗尽。
还要核对 net.ipv4.tcp_max_syn_backlog、net.core.somaxconn 和应用 listen backlog。前者影响半连接队列上限，后两者涉及已完成握手后等待 accept 的队列边界，实际生效值受内核版本、应用配置和负载影响。调整前记录当前值，单项小幅变更后观察队列、延迟、丢包和应用错误；不要照搬网上的固定大数值。增加队列只能争取处理时间，无法补足 CPU、内存或应用吞吐。
| 方案 | 更适合 | 主要限制 |
|---|---|---|
| SYN 代理 | 握手阶段压力突出，入口设备可承接过滤 | 增加网络设备依赖与状态处理成本 |
| 系统调优 | 正常流量出现短时突发，队列配置明显偏小 | 扩大缓冲不等于提升持续处理能力 |
按顺序处置，避免把故障调得更隐蔽
- 采集连接状态、队列溢出或丢弃计数、CPU、内存和跟踪表占用，先区分半连接、accept 队列与已建立连接问题。
- 如果确认握手洪泛且入口支持，优先评估 SYN 代理或上游过滤；同时检查允许的客户端路径，避免误伤正常连接。
- 若问题是合理流量突发，核对监听队列和应用 accept 能力，再逐项调整相关内核参数，并在相同流量条件下比较变化。
- 如果 ESTAB 持续攀升，检查应用超时、连接复用和资源释放；若 conntrack 接近容量，则单独处理跟踪表及网络路径问题。
因此，TCP连接耗尽攻击的识别与缓解措施没有一个参数包打天下：半连接洪泛优先考虑入口防护与 SYN cookies，队列配置不足再谨慎调优，已建立连接堆积则回到应用和会话管理。每次只改变一类因素，并保留回退方案。
常见问题
开启 SYN cookies 后还需要 SYN 代理吗？
不一定。若 cookies 已缓解半连接压力且入口仍有余量，未必需要代理；若后端队列或上游链路持续承压，可评估入口防护。
只调大 tcp_max_syn_backlog 可以吗？
只有半连接队列容量确实不足时才可能有帮助。若瓶颈在 accept 队列、应用处理或网络跟踪表，单独调大它不能解决问题。
怎样判断调优是否有效？
在相近流量下对比 SYN-RECV、队列溢出、建立连接成功率、业务延迟和错误率；确认改善没有转化为其他资源耗尽。
连接数高就一定遭到攻击吗？
不是。流量突增、客户端行为变化、应用变慢或连接释放异常都可能造成连接堆积，应结合来源、连接状态和业务负载判断。
