先分清“触发清洗”和“业务故障”

流量清洗告警出现，不等于服务器已经宕机，也不代表所有异常请求都能在服务器本机日志里看到。清洗通常发生在流量到达源站之前：防护平台识别异常流量并进行过滤或处置，因此源站日志可能只记录处置后的请求，甚至在攻击期间几乎没有新增记录。

排查时应先查看防护平台的事件记录和流量曲线，再与服务器网络、防火墙、Web 服务及应用日志按时间对齐。重点字段包括事件编号、检测与处置时间、目标地址和端口、协议、攻击或规则类型、处置动作、流量与包速率、源站入方向流量，以及访问日志中的状态码、请求路径和请求标识。美国高防服务器结合流量清洗时，最关键的不是孤立看某一条告警，而是确认“何时检测、何时开始处置、处置后流量如何变化、业务何时恢复”。

哪些日志需要查看

建议按从防护边缘到源站应用的顺序取证。不同服务商对字段名称的定义可能不同，先确认日志的采样方式、统计口径和时区，不要仅凭字段名直接下结论。

防护平台事件日志

优先记录事件编号或告警编号。它是关联同一事件不同页面、导出文件和工单记录的稳定线索。若平台未提供统一编号，可组合使用目标地址、端口、协议、事件类型和时间窗口，但要注意不同事件可能在同一时间发生。

还应区分以下时间：

• 检测时间：平台首次识别到异常的时间。
• 处置开始时间：清洗或其他缓解动作开始生效的时间。
• 处置结束时间：平台结束该次动作的时间；不一定等于业务恢复时间。
• 记录生成或告警推送时间：日志生成、邮件或通知到达的时间，可能晚于实际事件。

查看处置动作时，应确认字段含义是“已启用”“已观察”还是“已拦截”，不要把检测到异常误读为已经成功清洗。若日志提供放行、丢弃或缓解结果，也要核对其统计范围和计量单位。

源站网络、系统与防火墙日志

查看网卡收发量、连接数、系统负载及防火墙记录，可以帮助判断异常流量是否穿过防护层到达服务器。但本机看到的源地址不一定等于攻击源：经过清洗、转发或上游封装后，源站日志可能显示转发节点地址；也可能因连接复用而不能按单条请求还原真实来源。

若本机流量在告警时明显升高，且防护平台显示处置未生效、处置范围不包含该目标，或源站仍承受大量异常连接，需要进一步核对防护配置和目标地址映射。反过来，如果平台记录流量峰值和丢弃量上升，而源站入方向流量保持平稳，可能说明异常流量被挡在源站之外；仍需结合业务指标确认，而不能只凭单一曲线认定恢复。

Web 与应用日志

访问日志要看字段实际配置。常见信息包括请求时间、客户端地址、请求方法、路径、响应状态、响应字节和处理耗时。若配置了请求标识，可用它将入口日志与应用日志关联。错误日志则关注连接失败、超时、上游响应异常和资源不足等信息。

清洗期间访问日志减少，不一定是业务流量下降，也可能是异常请求被提前过滤；访问日志中的客户端地址异常集中，也不能单独证明攻击来源，因为地址可能经过转发或记录规则转换。判断业务影响应优先结合真实用户请求成功率、关键接口错误率和应用处理耗时。

如何把告警与日志关联成时间线

先统一时区与时间精度

平台可能使用协调世界时，也可能按账户或控制台时区显示；服务器则通常使用系统配置的时区。导出日志前，记录每份数据的时区、时间格式和统计粒度，并统一换算到同一时区。没有时区标记的时间戳，不应直接与其他日志逐秒对照。

服务器可用以下命令检查时间与同步状态。命令适用于使用 systemd 的 Linux 系统，仅查看信息，不会修改配置：

date -Is
timedatectl status

如果系统不是 systemd 环境，应使用该发行版提供的时间状态工具。若服务器时钟未同步或存在明显偏差，先记录偏差范围；不要直接改动系统时间来“对齐”日志，否则可能影响运行中的服务和后续审计记录。

还要留意时间精度：防护平台可能按分钟汇总，而访问日志精确到秒。分钟级曲线无法证明某一秒内的先后关系，应将结论限定为对应统计区间。

建立统一事件表

把每个来源的关键时间整理到一张表中，保留原始时间和换算后的统一时间。建议至少记录：

比较时间时，给告警推送延迟留出余量。通知到达时间晚于检测时间很常见，不能把通知时间当作攻击开始时间。若不同系统的时钟偏差不明，先按较粗的时间窗口关联，再通过事件编号、目标地址、端口和请求标识缩小范围。

使用“时间窗口＋事件特征”交叉核对

单纯按时间接近匹配容易误关联。更可靠的做法是同时核对：

1. 目标是否一致：目标地址、业务域名、端口是否属于同一服务。
2. 协议和事件类型是否一致：防护平台记录的协议、类型是否与受影响服务相符。
3. 时间是否连续：流量异常、处置开始、源站指标变化和业务恢复是否构成合理先后关系。
4. 指标是否相互印证：平台丢弃量增加时，源站是否减少异常连接；应用错误率是否同步变化。
5. 是否有共同标识：事件编号、请求标识或平台提供的关联编号能否贯穿多份记录。

例如，平台记录某目标在一段时间内进入处置状态，丢弃统计上升；同一窗口中源站入方向流量没有同步激增，业务错误率先升后降。这些现象共同支持“异常流量受到处理，业务影响随后缓解”的判断。若只有告警而没有处置状态或源站、业务侧指标，就只能确认平台检测到异常，不能据此断言清洗有效或业务已经恢复。

服务器侧日志的快速核对

如果使用 Nginx，可在确认实际日志路径后查看对应时间段的访问日志。路径、日志格式和时区由具体配置决定，以下命令只是示例，不要未经核验直接假定文件位置：

grep '目标时间片段' /var/log/nginx/access.log

查看错误日志时同样应先确认路径：

grep '目标时间片段' /var/log/nginx/error.log

如果日志按日期轮转、压缩，或时间格式与搜索内容不同，命令可能没有输出；这不代表该时间段没有请求。应先检查 Nginx 的日志配置、轮转规则及文件时间范围，再选择对应日志文件。对大文件进行筛选前，优先限制到目标文件和时间范围，避免无必要地遍历大量历史日志。

筛选后不要只统计总请求数。至少比较异常前、处置期间、处置后的请求量、状态码分布、响应耗时和关键业务接口表现。若日志格式没有记录某个字段，不能从现有日志中补推该字段；可以在后续变更中评估是否增加记录，但应先考虑隐私、存储量和日志轮转策略。

结果如何判断

• 平台显示检测，但没有处置记录：确认事件是否仅为告警、是否需要人工启用动作，以及目标是否处于保护范围。此时不应表述为“已经清洗”。
• 处置已开始，平台丢弃量上升，源站流量平稳：符合异常流量被边缘处理的表现；还要检查业务成功率和延迟，确认真实用户请求是否恢复。
• 处置已开始，但源站流量和错误率仍高：核对目标映射、端口范围、协议范围、策略状态和统计口径；同时检查源站是否存在应用瓶颈或其他故障。
• 平台流量回落，业务仍报错：清洗结束不等于应用恢复。继续看应用错误、数据库或其他依赖服务状态，并确认是否存在缓存、队列或连接积压。
• 源站日志缺少攻击请求：可能是流量在到达源站前已被处理，也可能是日志未覆盖该服务、采样或轮转导致缺失。应结合平台记录和监控判断，不能把“没有日志”直接当作“没有流量”。

适用边界与证据留存

各平台对带宽、包速率、丢弃量、攻击类型和处置状态的命名及统计口径可能不同；抽样日志也无法代表全部流量。跨系统的时间线可以建立相关性，但仅凭时间先后不能证明因果。若要判断某项策略是否有效，应同时检查策略作用对象、处置状态、源站指标和业务结果，必要时向防护服务提供方核实字段定义与原始事件记录。

排查过程中保留原始日志、导出时间、时区说明、事件编号和字段说明，并记录筛选条件。不要只保存截图或经过汇总的数字；后续复核需要能回到原始记录。最终判断应明确区分“平台检测到异常”“平台执行了处置”“源站流量受到控制”和“业务恢复正常”，只有这些证据链彼此吻合，才能完整说明清洗事件对服务器和业务的实际影响。