判断 SYN 洪水，不能只看“连接数变多”。先弄清哪些连接停在握手中、哪些已经完成握手却等待应用处理，才能让SYN洪水攻击的识别与连接队列防护落到可观察、可执行的检查上。
先分清两种队列
TCP 建连通常从客户端发送 SYN 开始。服务端回复 SYN-ACK 后，会等待客户端最后的 ACK；这段未完成握手的状态常显示为 SYN-RECV，也就是半连接。它占用的资源与 SYN 队列有关。
握手完成后，连接进入等待应用调用 accept 接收的队列，常称 accept 队列或已完成连接队列。应用处理变慢时，这个队列也可能积压。两者都可能造成新连接受影响，但原因不同：半连接猛增更值得检查 SYN 攻击或路径异常；已完成队列持续满，则还要检查应用是否及时接收连接。
读数时看趋势，不看单个快照
观察半连接与监听队列
Linux 上可用 ss -ant state syn-recv 查看当前 SYN-RECV 连接，用 ss -lnt 查看监听套接字。对监听项而言，常见 Linux 环境下 Recv-Q 表示当前等待应用接收的连接数，Send-Q 表示队列上限；它们不等同于半连接队列的占用量。不同系统和工具版本的显示可能有差异，需结合本机文档确认。
在同一服务、相近负载下重复采样，并记下时间、目标端口和连接来源。若 SYN-RECV 突然增加、持续不退，而成功建连或应用请求没有相应增长，应进一步检查。正常的突发访问、客户端重传、负载均衡器或 NAT 后的大量用户，也会改变连接分布，单凭某个地址或一次计数不能定性。
核对内核计数器与应用表现
可用 nstat -az 查看系统 TCP 扩展计数器，重点关注 ListenOverflows、ListenDrops，以及 SyncookiesSent、SyncookiesRecv、SyncookiesFailed 等名称；具体是否提供取决于内核版本。计数器应比较一段时间内的增量，不要把机器启动以来的累计值误当成当前故障。
同时查看应用日志、连接建立成功率、响应延迟和 CPU、网络情况。如果 SYN-RECV 高但监听队列未满，问题未必在 accept 队列；如果监听队列 Recv-Q 接近 Send-Q 且 ListenOverflows 增长，则应用接收不及时或队列容量不足的可能性更高。
按顺序排查与缓解
- 确认影响范围：记录受影响的主机、端口和起止时间，并分别查看 SYN-RECV、监听队列及应用请求，避免把单一指标当作结论。
- 检查近期变化：核对发布、监听配置、负载均衡和网络策略是否刚有调整。若条件允许，采集短时网络包或防火墙日志，观察 SYN 到达与握手完成的比例，并保护好日志中的地址信息。
- 核查队列设置：Linux 可检查 sysctl net.ipv4.tcp_max_syn_backlog net.core.somaxconn net.ipv4.tcp_syncookies，并查看应用传给 listen 的 backlog。内核上限、应用参数和实际处理能力共同影响结果；只调大其中一个参数，不能代替应用及时 accept。
- 选择缓解措施：确认启用 SYN cookies 是否符合当前系统配置。SYN cookies 可在 SYN 队列压力下减少保存半连接状态的需求，但不是无限容量方案，也不能解决带宽耗尽或应用队列堵塞。具备条件时，可由边界防火墙或负载均衡器启用 SYN proxy；规则应针对明确的服务和异常流量制定，避免误伤合法客户端。
- 验证恢复：观察半连接数量、队列占用、计数器增量和真实业务请求是否同步改善。保留调整前后的配置与观测结果，若只有队列数字下降而建连失败仍在，应继续查网络路径及应用处理。
避免把“调大队列”当成万能解
扩大 backlog 适用于应用短时接收不及时、并且主机资源仍有余量的情形；它能提供缓冲，却不会提升应用处理速度，过度扩大还会增加资源占用并延后暴露拥塞。SYN cookies 更偏向应对半连接压力；SYN proxy 则在网络边界代为处理握手，部署和策略管理更复杂。选择前应先确认拥塞发生在哪一段。
实用的SYN洪水攻击的识别与连接队列防护，核心是把半连接状态、accept 队列、内核计数器和应用表现放在同一时间线上判断，而不是看到连接变多就盲目封禁或修改参数。
常见问题
SYN-RECV 数量高就能确认是攻击吗？
不能。短时访问高峰、丢包导致的重传或网络设备变化也可能推高数量；应结合持续时间、握手完成情况和服务影响判断。
ss 的 Recv-Q 是半连接数吗？
通常不是。Linux 监听套接字的 Recv-Q 表示等待应用接收的已完成连接，半连接需另看 SYN-RECV 状态及相关计数器。
把 tcp_max_syn_backlog 调大就能解决吗？
不一定。它涉及半连接队列容量，但应用 backlog、系统上限、处理速度和网络带宽同样重要，应先定位实际瓶颈。
启用 SYN cookies 后还需要监控吗？
需要。它不能替代带宽防护、应用排队检查和攻击流量分析，仍要观察连接成功率、队列与相关计数器。
