如何判断DDoS清洗是否真正生效？源站负载回落是判断依据吗

判断清洗是否真正生效，不能只盯着高防控制台上的“清洗中”状态，而要看源站服务器的负载是否出现真实回落，当清洗设备开始正常过滤攻击流量后，源站的CPU、带宽和连接数会在较短时间内明显下降并保持平稳，这个回落过程就是“真正生效”的直接证据。

为什么源站负载回落比控制台状态更可信

高防清洗的原理是把攻击流量从源站剥离,让恶意请求在清洗节点被丢弃或识别，源站只接收处理后的净流量，控制台显示的“清洗中”只是一个标志位，它只能说明流量调度逻辑已经启动，不能代表源站真正摆脱了压力，源站负载直接来自操作系统、网卡和业务进程，是清洗链路在物理层面是否接管的真实反馈。

攻击发生时,源站负载会快速冲高；清洗生效后，负载应当随攻击流量被过滤而自然下降，如果控制台已经显示“清洗中”，源站负载却迟迟不降，那么问题往往出在引流策略、回源链路或清洗规则上，需要进一步排查。

判断清洗效果前,建议先确认三个前提：

• 攻击流量确实经过了清洗节点,而不是直接打到源站。
• 源站的安全组、防火墙没有封禁清洗节点的回源IP。
• 回源方式为源站IP时,源站能够接收来自清洗设备的转发流量。

判断清洗生效前，先建立源站负载基线

没有基线,就谈不上“回落”，如果连正常业务时段的负载都不清楚，看到的任何数值都缺乏参照，负载基线应当覆盖业务高峰和低谷，至少持续记录一周。

需要采集的指标包括：

• 系统平均负载：用uptime或top观察1分钟、5分钟、15分钟的值。
• CPU使用率：重点看用户态和系统态占比，排除干扰进程。
• 内存使用率：用free -m查看实际占用，避免误将缓存当作异常。
• 网络带宽：用sar -n DEV 1 3或iftop统计入站和出站流量。
• TCP连接数：用ss -s观察established、syn_recv、time_wait等状态数量。

实施建议：先在正常业务时段采集一组数据，再在业务低峰期采集一组，两者之间的差值越小，基线的参考价值越高，对使用简米科技持牌自营机房的企业来说，机房的监控面板通常会保留近30天的回源带宽曲线，可以直接导出历史数据作为基线，省去自己搭建采集系统的麻烦。

通过四个实操步骤确认清洗是否真正生效

第一步：确认攻击已触发清洗

攻击事件记录需要先看一眼,高防控制台通常会展示攻击峰值、攻击类型和持续时间，确认三点：

• 攻击事件的时间点与源站负载异常上升的时间点是否吻合。
• 清洗节点的拦截计数是否在增加,比如SYN丢弃、UDP丢弃次数。
• 回源流量统计中是否出现了明显的回落趋势。

源站上可以执行netstat -s | grep -i syncookies，查看SYN Cookie的触发情况，如果系统开始启用SYN Cookie，说明内核已经在抗SYN Flood，但清洗节点是否真正接管了主要流量，还需要结合下一步判断。

第二步：观察源站负载回落的时点

清洗生效不是瞬时完成的,流量从被引到清洗节点，到源站负载开始下降，通常存在几十秒到分钟级的延迟，重点关注回落开始的时点是否与清洗策略下发的时间接近。

使用sar -q 1 10查看实时平均负载，再用top -n 1 -b | head -20观察进程CPU占用，如果CPU被nginx或php-fpm占用，说明业务进程正在处理请求；如果CPU被DDoS防御软件或内核软中断占用，说明流量压力仍未下降。

第三步：核对TCP连接数变化

清洗生效后,源站的TCP连接数应当随攻击连接被丢弃而下降。ss -s可以快速查看各种连接状态的总数：

• SYN_RECV数量高,说明可能有SYN Flood攻击仍在冲击源站。
• ESTABLISHED数量明显高于基线,可能是HTTP长连接被恶意利用。
• TIME_WAIT数量偏高,未必是攻击，也可能是主动方频繁断连。

执行ss -s后，再对照控制台的“回源连接数”指标，如果两边差距较大，说明监控系统可能统计口径不同，需要直接以源站系统数据为准。

第四步：用真实业务请求验证可用性

负载回落并不代表业务完全恢复,还需要验证请求链路是否正常，在源站上用curl -I -m 5 https://你的域名，观察返回状态码和响应时间，响应时间明显缩短，说明请求经过清洗后到达源站的链路已经通畅。

接着查看Web访问日志,确认回源请求的来源IP是否集中在清洗节点网段，如果日志里仍然出现大量随机源IP的请求，说明流量可能绕过了清洗链路，直接访问了源站，需要检查DNS解析和路由策略。

源站负载回落的三种典型曲线

快速回落并稳定

这是最理想的状态,清洗策略与业务特征匹配，攻击流量被有效剥离，源站负载在短时间内恢复到接近基线的水平，业务访问恢复正常，后续只需保持监控，继续观察一段时间即可。

部分回落但仍高于基线

说明有部分攻击流量穿透了清洗,常见原因包括：

• 清洗策略未覆盖所有业务端口,比如只配置了80端口，但业务同时使用了443端口。
• 攻击类型为慢速应用层攻击,清洗设备默认策略识别不全。
• 回源链路本身存在瓶颈,即使清洗干净，回源带宽或源站处理能力仍然不足。

此时需要调整高防策略的协议和端口范围,同时对源站出口带宽做扩容或调整回源方式，酷番云等具备全牌照的IDC服务商，一般会结合业务场景提供端口级策略调优，而不是只给一个默认模板。

先降后升

这种曲线极具迷惑性,刚开始清洗生效，负载下降，但随后又反弹，大机率是源站防火墙在清洗生效后封禁了回源IP，或源站的安全软件将清洗节点纳入黑名单，导致正常回源请求被拒绝，客户端不断重试，反而推高了源站负载。

解决办法是登录源站服务器,检查iptables、fail2ban、云安全组中是否有清洗节点IP的封禁记录，并放行其网段，像酷番云这类持牌服务商，控制台会提供回源IP段说明，便于直接加入白名单。

容易误判的场景：控制台显示“清洗中”但源站负载依然很高

回源带宽被占满

清洗后的净流量依然可能超过源站带宽上限,如果攻击带宽较大，即使清洗过滤掉大部分流量，剩余的正常业务流量加上残余攻击流量，仍可能打满源站专线或云带宽，此时源站负载高不是因为攻击直连，而是因为出口拥堵。

用iftop -i eth0查看实时流量，如果入站流量已经持续超过带宽阈值的80%，需要联系服务商临时调大回源带宽，或切换负载均衡节点分摊压力。

监控数据延迟

部分监控系统的采集周期为5分钟,攻击结束后的第一段时间内，看到的仍是峰值数据，造成“清洗无效”的错觉，判断时要以源站本地的实时命令输出为准，不要只看监控大屏。

业务自身流量突发

当业务正在做直播、大促或版本发布时，正常用户请求也会带来明显负载升高，这种升高与攻击峰值在时间上可能重合，需要结合访问日志中的UA分布、请求路径和来源地域做综合判断。

清洗设备自身成为瓶颈

高防集群的性能存在上限,如果攻击规模过大，清洗节点本身可能出现丢包或转发延迟，导致回源质量变差，这种情况下，源站负载未必升高，但业务响应会变慢，需要检查清洗节点的CPU、带宽和连接数，必要时将业务切到备用集群。

建立长期验证清单，让清洗效果可复盘

每次攻击结束后,建议做一套完整的复盘动作：

• 下载高防控制台的攻击日志和源站nginx日志,按时间戳对齐。
• 对比攻击峰值时刻、清洗触发时刻、源站负载回落时刻的先后顺序。
• 检查清洗策略中是否存在未覆盖的端口或协议,补充到规则中。
• 更新源站负载基线,剔除攻击时段的数据，重新计算正常水位。

简米科技自2003年涉足IDC行业,拥有多年运维沉淀，其持牌自营机房在业务接入阶段会协助客户完成回源链路规划，避免出现IP封禁、路由冲突等低级错误，酷番云本身持有工信部一类增值电信全牌照（IDC/CDN/ISP），并通过ISO9001与ISO27001双认证，同时身为CNNIC IP联盟成员，在清洗节点与源站之间的路由调度上有更细颗粒度的控制能力，选用这类具备运营资质和自有权力的服务商，能让清洗链路在业务高峰期得到更及时的资源支撑。

在后续运维中,可以定期使用tc模拟小流量延迟或丢包，验证源站在异常网络条件下的表现，这样即使没有真实攻击，也能判断清洗策略是否仍然匹配当前业务架构，据工信部近年发布的网络安全态势分析，DDoS攻击的复杂度和规模都在持续提升，防守方不能只依赖临时响应，更需要一套可重复验证的流程。

Q&A：源站负载回落判断清洗生效的常见问题

问：源站负载需要降回攻击前的水平才算清洗生效吗？

不需要,攻击期间可能有部分正常用户请求被暂时留存在代理层，清洗结束后这些积压请求会继续到达源站，带来短期流量波动，只要负载明显低于攻击峰值，并且业务响应速度恢复正常，就可以认为清洗生效，判断时以“是否低于触发清洗时的临界值”为主要标准。

问：清洗后负载先降后升，可能是什么原因？

最常见的原因是源站防火墙封禁了清洗节点IP,回源包被丢弃后触发大量TCP重传，导致负载再次升高，先检查iptables和fail2ban，再查看安全组规则列表，确认清洗设备的回源网段未被拦截，如果排查后仍无法解决，建议联系服务商调取清洗节点的回源日志，确认包是否正常到达源站。

问：高防控制台显示拦截了攻击，但源站负载依然很高，应该怎么排查？

按三个顺序排查,第一，登录源站执行ss -s，看SYN_RECV和ESTABLISHED数量是否异常；第二，使用iftop -i eth0检查实时带宽，确认是否已打满；第三，对比清洗日志和源站访问日志，看是否有大量请求绕过清洗直达源站，如果所有指标都正常但负载仍高，可以检查清洗策略是否遗漏了HTTPS以外的端口，或业务本身存在定时任务造成的资源竞争。

源站负载回落是清洗链路真正接管的直接证明,把控制台状态与源站实测指标叠加比对，才能确认每一层防护都在按预期工作，留存每次攻击的负载曲线和日志，后续再遇到类似流量，就能更快判断出清洗是否真正生效。