清洗后源站请求变少，不一定代表业务流量下降，也可能是攻击流量在到达源站前已被拦截。做高防服务器防护清洗前后的业务日志对照分析，要把入口侧记录、源站日志和业务结果放在同一时间线上，并比较请求特征，而不是只盯着总量。
先统一时间和比较口径
清洗开始、策略调整、攻击缓解都可能发生在不同时间。先记下这些节点，并确认各系统使用的时区。若清洗平台按 UTC 记时、源站按本地时间记时，未换算就对照，变化可能会错位。
选择清洗前后长度相近的时间窗，按分钟或五分钟汇总；同时找一个相近时段作基线流量参考。工作日与周末、定时任务、活动通知等会带来正常波动，不能把所有增量都算作攻击。流量起伏快时用分钟粒度，业务量较小时可延长时间窗，避免少量请求造成比例误判。
三类日志各回答一个问题
| 数据来源 | 主要观察项 | 能说明什么 |
|---|---|---|
| 清洗中心日志 | 进入流量、拦截或限速量、规则命中、来源分布 | 哪些请求被处理，以及处理发生的时间 |
| 源站访问日志 | 时间、路径、状态码、响应字节、上游耗时、来源地址 | 实际到达源站并获得响应的请求 |
| 业务监控或应用日志 | 登录、下单、查询等成功数与失败数 | 用户操作是否受到影响 |
以 Nginx 为例，访问日志可配置记录请求时间、请求路径、状态码和请求处理耗时；若有链路追踪标识，也应一并保留。字段能否记录客户端真实地址，取决于代理链和可信来源配置，不能仅凭日志里的地址就认定攻击者身份。
按步骤做对照，避免把下降看成拦截成效
- 对齐时间窗。把清洗事件时间换算到同一时区，记录规则变更点。比较清洗前、清洗中、清洗后的相同长度区间。
- 分维度汇总。分别按每分钟请求数、访问路径、状态码、来源网段或 ASN、响应字节统计。还要检查失败率和响应耗时，避免总量掩盖关键接口异常。
- 关联入口与源站。若清洗中心显示拦截量上升，而源站请求下降，且业务成功数稳定，通常符合攻击被挡在入口的特征。若两端流量都下降，需继续核对访问需求、缓存行为、解析或上游链路变化。
- 抽样核验请求。检查清洗日志中的规则命中、时间和特征，再用请求ID或时间戳查应用记录。没有共同标识时，可用时间、路径和状态码做近似关联，但要注明它不是逐条请求的一一匹配。
- 检查误拦截。关注正常用户常用路径、登录或提交操作是否同步减少，是否出现集中超时、验证码异常或错误码变化。发现可疑规则后先小范围调整并观察，不要直接全局放宽防护。
看组合信号，不凭单一指标下结论
攻击拦截较可信的组合是：入口侧拦截记录与异常流量峰值同时出现；源站相应请求减少；正常业务成功率未明显恶化。若访问量下降但清洗记录没有对应变化，还应核查缓存命中、上游故障、客户端重试减少或业务需求本身变化。
需要特别留意被清洗的请求是否来自真实用户。某条规则命中量增加，只能证明规则触发，不能单独证明这些请求有害。把命中条件、来源分布、业务结果一起复核，才有助于发现误拦截。完整的高防服务器防护清洗前后的业务日志对照分析，应保留统计口径、时间窗和规则版本，便于复盘时还原判断依据。
常见问题
清洗后源站日志没有攻击请求，能说明攻击结束了吗？
不能。请求可能已在入口被拦截。应查看清洗中心的流量与拦截记录，并确认攻击是否持续、业务是否恢复。
只有总流量图，没有逐条清洗日志怎么办？
先按时间、路径和状态码对照入口与源站曲线，并向服务提供方确认统计口径及是否有规则命中摘要。结论应标注为趋势判断，避免声称逐请求已核实。
清洗后业务成功数也下降，应该先做什么？
优先检查受影响路径、错误码、耗时和规则变更时间，再抽查被拦截样本是否符合正常操作特征。这样才能判断是误拦截，还是独立的业务或链路问题。
总之，先对齐时间，再交叉核验入口、源站与业务结果；只有证据相互吻合，才能把流量变化归因于攻击拦截。按这套方法开展高防服务器防护清洗前后的业务日志对照分析，比单看请求总量更可靠。