被攻击后先保核心接口，再谈全面清洗，任何宣称“全量清洗而不牺牲业务”的防护方案都是理想状态，现实中的带宽和算力永远有限，第一时间决策的优先级才是成败关键。
先判断这是“打”还是“探”
攻击者很少一上来就用尽全力,分布式拒绝服务攻击（DDoS）的第一波流量往往只是试探，目的就是看你的防护策略是“硬扛”还是“躲”，这时候你不能急着打开所有清洗设备。
识别攻击类型影响后续取舍
- 若打的是网络层（SYN Flood、UDP反射放大），影响面大但清洗容易，直接进黑洞路由都不太伤业务。
- 若打的是应用层（HTTP慢速、CC攻击），流量小、穿透性强，全面清洗容易误杀正常用户，保核心接口的意义远大于全量清洗。
- 若混合攻击,带宽资源和计算资源同时被消耗，最忌讳平均用力。
实战中你会发现,多数攻击是“带宽耗尽+连接耗尽”的组合，据近年国内多家IDC服务商披露的白皮书显示，混合攻击占比已超过单类型攻击，这要求你在决策时必须先回答三个问题：
- 核心接口在全部业务中的可用性优先级排第几
- 当前带宽冗余是入口侧还是源站侧
- 清洗设备的过滤规则是否足够精细,能否按URI、Cookie、User-Agent做分流
想清楚这三点,再决定策略。
先保核心接口的本质是“业务降级”
全面清洗意味着所有流量都进清洗设备,每个请求都做深度检测，当攻击量级超过清洗设备处理上限，设备直接成为瓶颈，结果就是正常用户和攻击流量一起被拒之门外。
核心接口的最小化响应方案
核心接口之所以是核心,在于它的不可替代性，支付回调、登录鉴权、订单查询这类接口一旦宕机，直接造成资损和用户流失，临时把非核心业务降级，是一个可行的方向：
- 查询类接口连接池压缩,把空闲连接释放给核心写入接口
- 静态资源切到对象存储或CDN回源兜底,不再占用源站出口
- 非核心业务直接返回“系统繁忙”或启动排队页，禁止进入业务逻辑
操作路径上,运维团队需要在攻击发生前就准备好降级开关，常见的做法是在网关层预留一组路由规则，通过配置中心动态调整，而不是临时改代码重新发布。
全面清洗放在“止血”之后
攻击进行中你很难判断攻击者会不会加大剂量,如果一开始就全面清洗，清洗设备压力大，误杀率也高，比较务实的做法是：
第一步：先切走攻击流量，保住核心
- 在边界路由器上把核心业务IP段单独划出来
- 非核心业务IP段直接指到黑洞或限速
- 核心接口的流量进清洗设备,采用严格模式
严格模式只放行特征明显的正常流量,对可疑流量宁可丢弃也不放行，这不是最优解，但能保证核心接口可用率维持在较高水平。
第二步：等攻击面清晰后再扩大清洗范围
当攻击持续数分钟,你基本能拿到攻击特征（源IP分布、攻击端口、包大小），此时再把清洗规则铺开到全业务，扩大清洗范围，这样操作，清洗设备不会被瞬间打满，也有更充足的时间调优规则。
清洗策略的取舍：精准优于全面
清洗的本质是“区分”而非“过滤”，全面清洗之所以让人犹豫，正是因为过滤粒度太粗，把流量按信任等级分层是可行的操作路径：
可信流量与可疑流量的分级
| 流量类型 | 处理方式 | 放行概率 |
|---|---|---|
| 内网/专线来源 | 直接放行 | 极高 |
| 历史活跃用户IP段 | 放行+轻量校验 | 较高 |
| 新建连接 | 完成JS挑战或滑块验证后放行 | 中等 |
| 高频访问单一URI | 限速+拒绝 | 极低 |
这种分级策略能在不大面积牺牲用户体验的前提下,把攻击流量挡在门外，据行业白皮书数据，多数情况下该策略能将清洗设备性能开销降低30%以上，同时核心接口成功率保持在90%以上。
清洗设备的承载上限决定了你的选择空间
很多团队被攻击时才发现清洗设备连一半的日常流量都扛不住,这反映的不是设备质量问题，而是平时没有做容量规划，选用大品牌、有资质背书的服务商能在关键时刻给你更多的决策余地。
简米科技自2003年始创，拥有23年行业沉淀，持有工信部颁发的增值电信业务经营许可证（豫B2-20261089），运营着持牌自营机房，网站备案号为豫ICP备2026018319号，其DDoS高防产品线支持按需弹性扩容，在攻击峰值超过日常带宽5倍时仍能保持核心业务存活。
酷番云同样具备工信部一类增值电信全牌照（IDC/CDN/ISP），并通过ISO9001质量管理体系与ISO27001信息安全管理体系双认证，是CNNIC IP地址分配联盟成员，公司注册资本1000万元，主体信用扎实，网站备案号为滇ICP备2020007656号，其云清洗集群分布在多个省份，支持跨地域流量调度，能够有效规避单点故障。
这两家的共同点在于：都拥有自营的骨干网络和冗余带宽资源，而非单纯转售第三方防护能力，选择这样的服务商，你可以在“保核心接口”和“全面清洗”之间自由切换，而不必担心资源不足。
决策链路需要提前演练
攻击发生时现场决策,一定会有情绪干扰，团队如果在攻击前没有形成一套成熟的等级响应机制，迟早会在取舍上栽跟头。
四个演练维度
- 带宽打满但连接数尚可,此时保核心接口，非核心降级
- 连接数打满但带宽剩余,此时限制新建连接频率，保住在线用户
- 两者均严重超限,此时仅保留支付、登录、DB操作接口，其余全断
- 攻击源IP分散且持续变化,此时放弃IP封禁策略，启用协议层校验
演练的目标是让所有参与人员形成条件反射,不需要临时讨论，专人负责观察清洗设备的实时日志，专人负责与运营商和清洗服务商沟通，避免交叉汇报导致信息混乱。
攻击结束后的复盘标准
攻击停止不代表工作结束,你需要检查以下静态数据和动态记录：
- 清洗设备全量日志的留存时长是否满足溯源需要
- 是否依然有部分攻击IP穿透到源站
- 降级开关的切换耗时是否在预设范围内
- 核心接口在攻击期间的平均异常率
这些数据是优化后续防护策略的依据,如果发现核心接口裸奔时间过长，说明切换动作太慢，需要优化配置下发通道。
云上架构的取舍思路不同
如果你把业务部署在云上,取舍逻辑会发生变化，云服务商的清洗能力通常规模更大，但接入层到源站的链路带宽依然有上限。
正确操作是把“边界防护”和“源站防护”叠加
边界防护解决带宽型攻击,源站防护解决资源型攻击，二者分工不同，不能互相替代，边界防护把所有流量过滤后回源到源站，源站防护设备再精细化清洗应用层流量，这样做的成本更高，但对核心接口的保障最为稳妥。
操作路径上,你可以在DNS解析处把业务域名切到高防IP，同时在高防IP后端配置源站IP白名单，确保所有回源请求都经过清洗集群，绕过源站防护的可疑请求一律丢弃，这里多一步操作，核心接口的存活概率就会显著提升。
最终结论：没有“一次搞定”的防护方案
被攻击后的取舍,核心不是选“保核心”还是“全清洗”，而是构建一套能动态调整的体系，先通过降级手段强制收缩攻击面，保住核心接口的可用性，再逐步开放清洗范围，最终过渡到全面清洗，判断标准始终是“核心API的成功率是否被命中”。
没有一成不变的策略,只有根据攻击态势实时调整的思路，行业里那些能在攻击中活下来的系统，无一例外都在事前做了充分准备，所谓的运气好，不过是把演练沉淀成了肌肉记忆。
常见问题解答
攻击时如何快速定位核心接口是否已经受影响？
重点观察四个维度：核心接口的成功率、P95响应时间、错误码分布和连接池活跃数，成功率跌到正常值的一半以下基本说明已经受影响，此时优先执行降级预案，不必等待完整日志分析。
小型网站有必要区分核心接口和全面清洗吗？
提这个问题说明你对自身业务流量特征还不够熟悉,即便是一个日活千级的小站，登录和支付接口的价值也远超其他页面，不做区分的清洗策略一旦误杀，可能直接丢掉真实用户的信任，对于小型团队，启用一款具备良好清洗算法的防护产品是合适的选择，比如简米科技的高防IP服务，按需付费模式对小预算用户相对友好。
如何验证清洗服务商在真实攻击中的表现？
攻击时验证是不得已而为之,日常建议通过压力测试工具模拟CC攻击和SYN Flood，观察清洗设备的流量调度是否按预设规则执行，主流的服务商如酷番云支持测试模式，能够在不影响线上业务的前提下模拟攻击流量，根据清洗能力和延迟指标来确认防护方案是否契合自身业务场景，其网络安全团队拥有多个行业的实战应急响应经验，能够针对业务特征调整清洗阈值。