SYN Flood攻击的识别指标与防护配置，不能简化为“连接数变多就拦截”。TCP 服务遭遇正常访问高峰时，连接数也会增加；反过来，攻击流量可能在握手完成前耗尽资源，已建立连接数未必明显上升。判断时要看握手过程和系统丢弃情况，配置时则要确认防护发生在哪一层。
为什么连接数不足以定性
TCP 建连需要客户端发送 SYN、服务端返回 SYN-ACK，再由客户端发送 ACK。SYN Flood会让大量连接停留在握手未完成状态，占用服务端的半开连接队列；来源地址还可能被伪造。因此，统计已建立连接或总连接数，都可能漏掉关键变化。
更有用的观察对象包括单位时间内的 SYN 到达量、SYN-ACK 与最终 ACK 的比例、SYN-RECV 状态数量、握手重传，以及监听队列溢出或丢弃计数。Linux 可通过 ss 查看连接状态，并结合内核 TCP 统计、主机监控和防火墙日志核对。单个指标突然变化仍不能独立证明攻击：网络丢包、客户端质量差、服务发布或流量突增，也可能造成握手重试。
把指标组合起来判断
先看速率，再看握手结果
按 1 分钟观察突发变化，再用 5 分钟窗口确认趋势；这只是排查起点，实际窗口应按业务流量和监控采样间隔调整。将 SYN 到达速率与成功建连速率对照。如果前者显著上升，而完成握手的比例持续走低，同时半开连接和重传增加，就比单看连接总量更值得警惕。
核实服务是否真的受影响
检查监听队列溢出、丢包、CPU 与网络接口负载，并从外部探测 TCP 服务是否能正常建立连接。假设一台 Linux 主机的 SYN-RECV 数量升高，但探测成功率、队列状态和资源使用都稳定，先排查短时访问高峰或监控口径变化；若队列丢弃增加、建连失败同步出现，才需要优先处置。不同内核版本、网卡卸载和采集方式会影响计数含义，应记录基线，不套用通用固定阈值。
指标判断与防护配置不是一回事
SYN Flood攻击的识别指标与防护配置解决的是两个问题：前者判断是否出现异常及影响范围，后者改变流量处理方式。先留存攻击前后指标，再逐层启用防护，才能看出配置是否有效，也能减少误伤合法连接。
- 定位队列和流量入口。确认受影响的是哪台主机、哪个 TCP 监听端口；对照主机、边界防火墙和上游网络的计数，避免只在应用日志里找原因。
- 核对 Linux 队列设置。检查
net.ipv4.tcp_syncookies。启用 SYN cookies 可在 SYN 队列压力升高时减少半开连接占用，但它不是带宽清洗，也不能解决所有连接队列或应用处理瓶颈。 - 谨慎调整队列容量。
tcp_max_syn_backlog关系到未完成握手队列，somaxconn影响监听队列上限，应用自身传入的 backlog 也会参与限制。扩容前核对内存、并发和内核版本；盲目加大队列只会延后资源耗尽，不会过滤攻击流量。 - 评估入口侧防护。防火墙或负载均衡器支持时，可评估 SYN Proxy，由入口设备代答握手；流量已压满接入链路时，应联系网络上游或云平台评估清洗。按来源限速有误伤共享出口用户的可能，不宜仅凭单个 IP 的连接数设严苛规则。
- 验证并回退。配置后持续检查握手成功率、队列丢弃、合法用户连通性和设备负载；每次只改一类参数，记录原值与生效范围，发现正常访问受影响时及时回退。
常见问题
连接数很高就一定是 SYN Flood 吗？
不是。已建立连接增加可能来自正常业务；应结合 SYN 速率、未完成握手、重传和丢弃计数判断。
开启 SYN cookies 后还要扩队列吗？
不一定。先确认瓶颈是 SYN 队列还是应用接受连接的队列，再按主机资源和业务并发评估；cookies 也不能替代上游带宽防护。
如何减少误封正常用户？
用历史基线与多项指标确认异常，优先在入口设备做可观测、可回退的策略，并持续验证合法连接是否恢复。
归根结底，SYN Flood攻击的识别指标与防护配置应分开处理：多指标确认异常，按队列、主机和网络入口选择措施，再用握手成功率与丢弃计数验证效果。
