很多站长买了高防，却在攻击当天发现流量照旧进源站，或者正常用户被清洗节点丢掉。问题往往不在防护能力，而在 DDoS清洗阈值设错了。本文用 9 个问答讲清业务峰值怎么测、阈值分几档设、为什么必须同时配 pps 与连接数阈值、防护等级三档怎么选，以及怎么验证阈值真的生效。
Q：清洗阈值设错了会怎样？
两个方向都会出问题，而且都不好排查：
- 阈值设太低：正常的促销峰值、媒体转载带来的热点流量就会触发清洗，结果是丢包、连接重置、用户投诉网站不稳定。这类故障最容易被误判为服务器性能问题。
- 阈值设太高：攻击流量低于阈值时清洗节点不动作，等于高防形同虚设，源站被直接打满。
所以先把概念理清：清洗阈值是「清洗动作的触发线」，不是「防护能力的上限」。防护能力由套餐带宽决定，触发线由你的业务曲线决定，两者必须分开设置。
Q：设阈值前必须先拿到哪三个数？
- 业务峰值：取近 7 到 30 天的入向峰值，不是平均值。有活动排期的要单独标注。
- 套餐起调下限：服务商对防护等级有 Gbps 起调限制，阈值不能低于这个数，否则设了也不生效。
- 清洗代价：清洗会引入少量延迟，并可能影响非 HTTP 协议。要清楚自己的业务能承受什么。
# 采样服务器网卡入向速率（每秒一行，关注 rxkB/s 列）
sar -n DEV 1 60 | grep eth0 | tail -20
# 换算 Mbps：KB/s × 8 / 1000
# 历史峰值从监控系统取 7 天的 P95 与最大值
# Prometheus 示例：
# max_over_time(node_network_receive_bytes_total{device="eth0"}[7d])关键点：一定要取「入向」而不是「出向」，攻击打的是入向带宽；同时要区分 P95 与最大值，P95 用来设日常告警，最大值用来设清洗线。
Q：告警阈值和清洗阈值该分几档？
推荐两档，绑定不同动作：
- 告警阈值 = 正常峰值 × 1.5：只发通知，不做任何处置，让你有时间判断是攻击还是业务增长。
- 清洗阈值 = 正常峰值 × 3，同时不低于套餐起调下限。达到后进入清洗。
- 观察期：触发后观察 5 分钟，持续上涨才真正开启清洗，避免压测与短时热点造成的抖动误触。
要注意单位陷阱。同一个「阈值」在不同服务商后台可能是 Mbps、pps 或 新建连接数/秒，三者不能混填。用带宽阈值去防小包攻击，是导致防护失效的高频原因。
Q：为什么阈值设了却一直不触发？
三种典型原因，按出现频率排序：
- 攻击类型与阈值类型不匹配：攻击是 60 字节小包或纯 SYN，带宽只有几十 Mbps，远低于按 Gbps 设的清洗线，但 pps 已经爆表。
- 保底防护与弹性防护机制不同：保底防护通常自动生效，弹性防护需要手动开启或按阶梯升档。没升档，流量到顶后依然会漏到源站。
- CDN 挡在前面吸收了流量：域名解析到 CDN 时，高防侧看到的是回源流量，攻击被边缘节点吃掉一部分，入向曲线反而不高。
结论：带宽、pps、新建连接速率三类阈值必须全部配置，只设带宽等于只防了一半的攻击类型。
Q：pps 阈值怎么换算和设置？
核心公式只有一个：
# 平均包长 = 带宽(bps) / 包速率(pps) / 8
# 反过来：pps = Mbps × 1,000,000 / (8 × 平均包长)
# 正常业务：1 Gbps 流量、平均包长 1000 字节
# pps ≈ 1000 × 1e6 / (8 × 1000) = 125,000 pps
# 同样 1 Gbps，小包攻击平均包长 60 字节
# pps ≈ 2,080,000 pps，高出约 16 倍读法很直接：同样的带宽数字，包长越小 pps 越高。所以 pps 阈值的设定逻辑是「正常 pps 峰值 × 2 到 3 倍」，而不是照着带宽阈值等比换算。落地上还要配两条限制：
- 单源 IP pps 上限：正常用户不可能每秒发几万个包，超过阈值直接丢弃或限速。
- 异常协议过滤：只放行业务真正需要的协议与端口，减少无用包进入统计。
Q：防护等级（宽松 / 正常 / 严格）该怎么选？
三档的本质是「判定灵敏度」，不是「防护强度」。选择原则是默认用正常，仅在攻击确认后临时收紧：
- 宽松：只拦明确恶意的特征，误杀极低但漏杀偏高。适合绝对不能误伤的业务时段，如大促首日。
- 正常：默认档。常见攻击特征与频率异常都会被处理，兼顾误杀与漏杀。
- 严格：加下发行人机验证、要求完整浏览器特征、限制部分地区与老版本客户端，误杀明显上升。
关键操作纪律：严格档只在攻击确认后临时开启，攻击结束立即回退。长期开严格档的后果很具体——搜索引擎蜘蛛被拦导致收录下降、老版本浏览器用户打不开页面、海外访客无法访问，而这些故障往往几天后才被发现。
Q：清洗阈值和黑洞阈值有什么区别？
两者是不同层级的兜底，量级差很远：
- 清洗阈值：由你在防护后台设置。清洗节点过滤掉恶意流量后把干净流量转发回源站，业务继续可用。
- 黑洞阈值：由机房或运营商侧设置，通常远高于清洗阈值。触发后该 IP 的全部流量被丢弃，包括正常访问，业务彻底中断。
所以正确的链条是：告警 → 清洗 → 黑洞。黑洞通常是不可自定义的硬阈值，你能做的是让清洗尽早生效，别让流量涨到黑洞线。反复触发黑洞还会影响你在服务商处的信誉记录，后续解封更困难。
Q：阈值配置好之后怎么验证真的有效？
必须做一次受控验证，否则阈值对不对只能等攻击那天才知道：
# 1) 低峰期用压测工具模拟流量，观察是否被误洗
wrk -t4 -c200 -d120s --latency https://www.example.com/
# 2) 记录响应码与耗时，对比清洗前后的差异
curl -o /dev/null -s -w "code=%{http_code} time=%{time_total}\n" \
https://www.example.com/
# 3) 核对源站入向是否回落
sar -n DEV 1 30 | grep eth0 | tail -10三条验证标准，缺一条就说明配置还有问题：告警能在阈值附近准时发出、清洗动作在达到阈值后确实启动、清洗启动后源站入向带宽明显回落。如果源站曲线没变化，要么阈值没生效，要么流量根本没走高防。
提醒一点：压测前必须提前通知防护服务商，否则测试流量会被当成真实攻击，可能触发临时封禁，反而制造故障。
Q：还有什么补充建议？
- 阈值跟着业务走：每次大促、上新、投放前复核一次；日常曲线涨了就要同步上调清洗线，别用三个月前的数字。
- 先看源站再看后台：清洗是否发生要以源站观测为准，防护后台的「已拦截」数字可能包含正常流量。
- 把连接数阈值当成独立项：连接耗尽型攻击带宽很低，只有带宽阈值会被完全绕过。
- 记录每一次清洗事件：时间、峰值、攻击类型、处置结果。积累三次以上就能看出攻击者习惯，后续设阈值和选防护等级会精准得多。
一句话总结：清洗阈值不是越大越安全，也不是越小越灵敏；按业务峰值分两档、按攻击类型配三类阈值、防护等级只在攻击期临时收紧，这才是可用性最高的配置方式。