一、阈值是 SYN Flood 防御的"第一个参数"，也是最容易设错的

聊 SYN Flood 防御，网上能搜到两种极端答案：一种是"开 SynCookies 就行了"，另一种是"把所有阈值调到最大"。两种都错。

• 阈值设太低：正常业务高峰（促销、整点抢购、爬虫）一冲就触发拦截，误伤真实用户，运营先来找你；
• 阈值设太高：攻击都把半连接队列打满了，你的防御还在等"达标"，形同虚设；
• 阈值没有基线：连"正常情况下每秒新建多少连接"都不知道，任何数字都是猜的。

这篇把 SYN Flood 防御涉及的四层阈值——内核层、防火墙层、业务层、清洗触发层——逐一讲清楚：每个参数管什么、默认值为什么不够用、怎么基于业务基线标定。

二、60 秒回顾：SYN Flood 打的是什么资源

TCP 建立连接需要三次握手：客户端发 SYN → 服务端回 SYN-ACK 并把连接放进半连接队列等待 → 客户端回 ACK 才算建连完成。

SYN Flood 的打法：发大量 SYN 但不回 ACK（或伪造源 IP 让 SYN-ACK 发往黑洞）。结果是：

• 半连接队列（SYN backlog）被只进不出的"半开连接"占满；
• 服务端不断重传 SYN-ACK，进一步消耗 CPU 与内存；
• 队列满之后，真实用户的 SYN 也进不来了——攻击生效。

由此得出防御的两条主线：让半开连接更快被清理或"不占队列"（内核层），以及在到达主机之前拦掉异常 SYN（网络层与上游）。所有阈值都围绕这两条展开。

三、四层阈值：含义与标定方法

第一层

操作系统内核参数（Linux）

参数	作用	标定建议
net.ipv4.tcp_max_syn_backlog	半连接队列长度	按内存与业务并发适度上调（如 1024 → 4096+），但调大只是延后打满，不是防御
net.ipv4.tcp_syncookies	队列满时启用 Cookie 校验，半开连接不再占队列	生产环境应保持开启（=1）；代价是牺牲部分 TCP 选项，性能影响很小
net.ipv4.tcp_synack_retries	SYN-ACK 重传次数	从默认 5 降到 2–3：半开连接更快释放，被攻击时队列周转更快
net.ipv4.tcp_abort_on_overflow	队列溢出时直接 RST	高并发 web 服务不建议开启（放大误伤），配合上层限速更稳

两个常见误区：一是只调队列长度而不开 SynCookies——队列再大也是有限资源，Cookie 才是"队列被攻破后的底牌"；二是开了 SynCookies 就以为万事大吉——它只在队列满时触发，触发前响应已经明显变慢，阈值监控必须比 Cookie 触发更早。

第二层

防火墙/负载均衡的连接级阈值

这层防御的价值在于在半开连接到达主机之前拦掉。核心参数：

1. 新建连接速率（CPS）：全局与单源两个维度各设一条。全局防分布式洪峰，单源防单点打满；
2. 单源半开连接上限：一个源 IP 同时存在的未完成握手数超上限即拉黑/限速；
3. SYN/ACK 比例异常检测：SYN 多、成功握手少是 SYN Flood 最直接的行为指纹；
4. 会话表水位：70% 预警、90% 触发处置（与 UDP Flood 一文同理）。

标定方法（通用公式）：

阈值 = 近 30 天业务峰值新建速率 × 系数（3–5 倍）
单源阈值 = 正常单客户端最大新建速率 × 5–10 倍

系数看业务弹性：促销型业务留 5 倍，平稳型留 3 倍；必须先采集 1–2 周含高峰与节假日的真实数据再定数字。

第三层

业务/应用层的配套阈值

• 应用层连接超时：把无效连接更快断掉，减少资源占用；
• 每 IP 并发连接上限：防止单点慢速占用；
• 接入层（LB/网关）前置校验：让握手在接入层完成，后端只接收"完整连接"——攻击流量被挡在业务集群之外。

第四层

清洗触发阈值（本地扛不住之后的"开关"）

本地策略总有扛不住的量级，需要"把流量交给上游清洗"的触发条件。建议三级水位：

级别	触发条件	动作
预警（黄色）	SYN 速率达基线峰值 3 倍，或半连接队列使用率 70%	告警、值班人工确认、通知业务方
处置（橙色）	达基线 5 倍，或队列使用率 90%、防火墙开始丢新建连接	启用本地激进限速、准备切换清洗线路
清洗（红色）	本地策略已生效但丢包率/新建失败率仍持续上升	切换高防/清洗线路，DNS 快速切换（TTL 已提前调低）

两条关键提醒：① 清洗触发阈值必须低于"业务彻底不可用"的阈值——等业务瘫了才触发清洗，切换窗口里业务还在损失，很多预案失效就失效在这一条；② DNS TTL 必须提前调低（见本站《DNS 解析为什么会超量》的 TTL 策略），否则切换生效以小时计，预案等于没做。

四、常见标定错误：五个真实高发的坑

1. 拍脑袋定数字：没有业务基线，阈值全靠"感觉"，要么天天误报、要么真攻击时无感；
2. 只看带宽不看握手速率：SYN Flood 的瓶颈是半开连接与 CPS，不是 Mbps——监控必须覆盖"新建连接速率、半开连接数、SYN/ACK 比例"；
3. 阈值一设就不管：业务增长后基线漂移，去年合理的阈值今年可能天天误报。至少每季度复核一次；
4. 白名单缺失：监控探测源、合作方、爬虫引擎被阈值拦截，"防御上线、业务报障"；
5. 各层阈值互相矛盾：流量在"更弱的一层"先被打穿。各层容量应从外到内递减，让压力逐层卸载。

五、可直接执行的标定清单

• 确认 tcp_syncookies = 1（所有对外提供 TCP 服务的机器）
• 按 30 天峰值 × 3–5 倍标定全局与单源 CPS 阈值，写入防火墙/LB 配置
• 设置单源半开连接上限与 SYN/ACK 比例告警
• 半连接队列使用率 70%/90% 两级告警接入值班流程
• 监控补齐"新建连接速率、半开连接数、SYN/ACK 比例"三条曲线（不止看带宽）
• 建立白名单：监控探测源、CDN 回源、合作方 IP
• 三级水位（预警/处置/清洗）写入应急预案，明确每级的责任人与动作
• 每季度复核一次阈值，业务大促前专项上调
• 做一次授权压测：模拟 SYN Flood，验证各级阈值与切换流程真实生效

六、常见问题（FAQ）

Q1：SynCookies 开了是不是就不需要其他防御了？

不是。SynCookies 只在半连接队列满之后才触发，触发前服务响应已经明显劣化；且它对"已建立连接的资源消耗型攻击"无效。它是"最后的底牌"，不是完整防御——阈值监控、限速、上游清洗仍然需要。

Q2：半连接队列（tcp_max_syn_backlog）调多大合适？

在内存允许范围内适度上调（如 1024 → 4096），但注意：调大只是延长被攻满的时间；队列过大反而拖慢溢出后的恢复速度。重点应放在防火墙层的 SYN 过滤与限速上。

Q3：阈值具体设多少？有没有通用数字？

没有通用数字，只有通用公式：近 30 天业务峰值新建速率 × 3–5 倍（全局），正常单客户端峰值 × 5–10 倍（单源）。先采集 1–2 周含高峰的数据再定数。任何不基于基线的数字都是赌博。

Q4：单源限速和全局限速，优先配哪个？

都配，但作用不同：单源限速对单点/小规模攻击直接有效，成本低误伤小；全局限速防分布式洪峰，是最后的本地防线。精力有限时，先配单源 + 告警，再逐步加全局。

Q5：促销日业务峰值本来就高，怎么避免误伤？

两条路：大促前按预期峰值临时上调阈值（写进变更流程）；或使用"动态基线"类智能阈值（部分云防火墙支持自动学习）。关键是把"大促调阈值"变成运维日历上的固定动作。

Q6：误伤了正常用户，怎么快速回滚？

所有阈值类策略都应支持"一键停用/调整"并保留变更记录。误伤时先降阈值或临时放行受影响来源，同时核对是基线漂移（业务涨了）还是攻击误判（攻击者伪装正常流量），再决定长期修正方向。

Q7：上了 CDN/高防之后，本地阈值还有意义吗？

有，而且更重要了。CDN 回源流量同样可能携带攻击（回源打穿），且源站一旦暴露会被直连绕过。本地阈值是最后一道防线，不是被 CDN 替代的旧设施。

Q8：SYN Flood 和 UDP Flood 防御有什么本质区别？

SYN Flood 耗的是"半开连接/会话"这类状态资源，防御核心是握手行为识别与队列管理；UDP Flood 耗的是带宽与会话表，防御核心是端口策略与限速。监控指标也不同：SYN 看 CPS 与半开连接数，UDP 看 PPS 与带宽。可参考本站《UDP Flood 攻击怎么防御》对照阅读。

 

关于墨者安全
墨者安全致力于安全防护、服务器高防、网络高防、ddos防护、cc防护、dns防护、防劫持、高防服务器、高防dns、网站防护等方面的服务，全网第一款指纹识别技术防火墙，自研的WAF指纹识别架构，提供任意CC和DDoS攻击防御