SYN Flood攻击下的连接防护与限速策略，核心不是一味拦截连接，而是尽量减少未完成握手对服务器资源的消耗，同时让正常用户仍能建立连接。处理时要先分清半连接队列、连接跟踪表和网络带宽分别承受了什么压力，再选择相应措施。
先判断瓶颈在哪里
TCP 建连需要经过 SYN、SYN-ACK、ACK 三步。攻击流量若大量停留在握手未完成阶段，半连接队列可能被占满；若设备需要记录的连接状态过多，conntrack 表也可能接近上限。若入口带宽已被流量塞满，即使主机还能处理握手，用户请求也可能到不了服务器。
在 Linux 主机和边界防火墙上查看 SYN 接收量、队列溢出记录、连接跟踪使用情况、网卡丢包及 CPU 负载，并与平时同一时段的基线比较。只看连接总数容易误判：合法的短时访问高峰也会增加连接数，不能据此直接封禁来源。
按层实施防护
主机：给握手过程留出余量
检查监听服务的 accept 队列和系统半连接队列上限，并确认应用能及时接收已完成的连接。适度调整队列容量可能有帮助，但数值受内存、内核版本、应用处理速度和并发模式影响；盲目调大只会占用更多资源，无法解决入口带宽耗尽。
启用 SYN cookie 可在半连接队列压力较大时减少对队列状态的依赖。它是缓解手段而非容量替代品：仍需观察服务器负载和应用是否能承接完成握手的连接，也不要把启用 cookie 当成攻击已解决的依据。
防火墙：限速要看流量分布
nftables 等防火墙可对新建 TCP 连接或 SYN 报文设置速率限制。按单个来源 IP 限速容易误伤共享出口后的多名正常用户；按整个服务器限速则可能在攻击期间连正常流量一起压制。较稳妥的做法是结合来源、目标端口和短时间窗口观察，并设置记录与告警，再逐步启用限制。
限值应以服务自身的合法峰值为参照，先留出业务波动余量，再在低风险时段验证。可从接近真实业务负载的测试开始，观察丢包、延迟和新连接成功率；发现合法用户受影响，就回调规则或缩小应用范围。不要把某个固定的每秒连接数当作适用于所有服务器的标准。
可执行的处置顺序
- 确认现象：核对系统日志与监控，区分半连接队列增长、conntrack 接近容量和链路拥塞。
- 保留基线：记录正常时段与异常时段的 SYN 速率、来源分布、丢包和服务可用性，避免只凭单一指标决策。
- 先做低风险调整：检查监听队列、SYN cookie 和防火墙规则是否按预期工作；对限速先告警或小范围试行。
- 验证并复盘：持续比较连接成功率、延迟及误拦截情况；恢复正常后审查规则，删除临时封禁并记录变更。
主机防护的边界
当入口链路已饱和，主机本地规则无法腾出已被占用的带宽。此时应联系网络服务提供方，确认是否能在上游过滤，或使用具备流量清洗能力的网络服务。若考虑 Linux 的 SYNPROXY 等机制，需先核实网络拓扑、规则顺序和回程路径；配置不当可能增加延迟或造成连接失败。
因此，SYN Flood攻击下的连接防护与限速策略应分为监测、主机保护、边界过滤和上游协作几层。限速负责控制资源消耗，不能代替容量规划；SYN cookie 和队列调整也不能代替链路侧的缓解能力。
常见问题
限速是否应该按来源 IP 封禁？
不宜默认永久封禁。多个用户可能共享一个公网出口，优先采用短时、可撤销的限制，并结合端口、速率及误拦截情况判断。
启用 SYN cookie 后还要扩容队列吗？
视监测结果决定。cookie 有助于应对半连接压力，但不能提升应用处理能力，也无法消除带宽瓶颈。
什么时候需要联系上游？
当链路丢包或带宽拥塞导致正常请求无法到达主机时，应尽早联系网络服务提供方；主机内的限速通常无法处理已经抵达链路的全部流量。