清洗平台显示攻击流量回落，只能说明进入源站的异常请求减少了，不能直接证明服务已恢复。判断恶意流量清洗后源站性能恢复检查是否通过，要同时看用户请求、服务器资源和后端依赖，并与攻击前的正常基线比较。
如果只盯着平均响应时间，慢请求可能被掩盖；如果只看服务器负载，数据库排队或应用错误也可能漏掉。以下步骤适用于网站、接口及其他对外服务，具体指标要按自身业务和架构调整。
先建立可比较的基线
优先选取攻击前服务正常、业务量相近的时段作为参照。按分钟记录请求量、响应时间分位数、错误率，以及应用进程、数据库和网络资源情况。若没有完整监控，可从应用访问日志、主机监控和数据库监控中取同一时间窗口的数据。
比较时要考虑日夜流量差异、定时任务和发布变更。攻击期间若刚好发生版本更新，就不能把前后差异全部归因于清洗。建议同时对照攻击前基线和近期相似业务时段，避免拿低峰数据作为唯一标准。
按顺序检查五类信号
- 确认入口流量：查看清洗侧的异常流量变化，并核对源站实际收到的请求量。若入口显示攻击减弱、源站请求仍明显高于正常范围，应检查清洗策略、回源路径或残留的高频请求。
- 看响应时间和错误率：观察中位数及较慢请求的延迟，例如 p95；同时检查超时、失败请求和 5xx 错误。恢复后的数值应回到自身正常区间，而不是套用一个适用于所有服务的固定毫秒数。
- 检查资源是否退压：查看 CPU、内存、磁盘 I/O、网络带宽和文件描述符等指标。流量下降后资源仍长期接近容量上限，可能表示请求堆积、进程未释放资源，或后台任务仍在追赶积压。
- 核对后端依赖：检查数据库连接池、慢查询、队列长度，以及缓存命中情况。入口恢复而数据库连接耗尽时，用户仍会遇到延迟或失败；不要为追求短期缓解而未经评估地提高连接上限。
- 验证真实业务路径：从外部发起少量正常请求，覆盖首页或健康检查、登录、查询、提交等关键操作。确认状态码、返回内容和写入结果符合预期，避免只用一个静态页面判断服务可用。
用分阶段观察避免误判
先小范围验证，再观察稳定性
先进行低频探测，并让业务人员核对关键功能；随后持续观察监控面板和日志。可先按 5 至 15 分钟的窗口检查变化，再延长到 30 分钟或更久。这个范围只是排查节奏示例，突发流量、业务周期和恢复机制不同，所需观察时间也会不同。
如果延迟和错误率接近基线、资源不再持续攀升，且多个观察窗口内没有反弹，可认为性能趋于稳定。恢复判定最好连续满足一段时间，而不是取某一分钟的峰值或低谷。这个恶意流量清洗后源站性能恢复检查结论，也应记录对应时间、指标和异常项，便于之后复盘。
异常时定位是哪一层未恢复
请求量正常但延迟偏高，优先查应用执行时间、数据库等待和队列；延迟正常但错误率高，检查依赖故障、限流规则及应用日志；资源仍高且请求量不高，则排查未结束的后台任务、连接泄漏或清洗后的配置变化。每次只调整一项并记录结果，避免多个改动叠加后无法判断原因。
常见问题
清洗结束后，是否可以立即关闭防护？
不宜仅凭平台状态决定。先确认源站流量、错误率和关键业务稳定，再根据防护策略及风险评估调整；不要在攻击是否结束尚不明确时贸然撤掉保护。
没有攻击前监控数据怎么办？
先用近期相似时段、业务日志和主机记录建立临时参照，并标明不确定性。后续补齐请求量、延迟分位数、错误率及依赖指标，形成可复用基线。
恢复后延迟偶尔升高，算不算未恢复？
单次尖峰不一定代表故障。检查它是否伴随错误增加、资源持续高位或用户操作失败；若多个窗口反复出现，再按应用、数据库和网络路径逐层定位。