WAF 日志判读要点是什么
WAF 部署在应用前面，逐请求记录命中的规则、执行的动作（拦截、放行、挑战、仅记录）与请求上下文。它记录的是「尝试」而不是「结果」：被拦截说明请求没到后端，被放行的还要去后端日志确认是否成功。拦截量的高峰通常对应攻击波次，是构建时间线的现成素材。
基本信息
| 关键字段 | 规则 ID、动作、URI、来源 IP、User-Agent、时间 |
|---|---|
| 动作语义 | 拦截、放行、挑战（人机校验）、仅记录 |
| 数据位置 | WAF 控制台、日志投递（日志服务或对象存储） |
| 使用定位 | 提供线索与旁证，确证要回到应用与主机日志 |
典型使用场景
- 判断某次 Web 漏洞利用是否被拦住
- 梳理攻击波次时间线，对齐主机侧异常
- 抽查被放行的可疑请求，找出漏检
- 评估规则误报：业务被误拦时反查触发规则
- 为源 IP 封禁与后续溯源提供候选清单
分析顺序
分析顺序
1) 按规则 ID 聚合：哪些规则被高频命中
2) 按时间聚合：拦截趋势形成攻击波次时间线
3) 只看被放行或仅记录的可疑请求：漏检重点在这里
4) 查绕过迹象：编码变形、大小写混写、超大请求体、分块传输
5) 回到应用访问日志与主机痕迹确认是否真的成功
# 未做第 5 步时，结论只能写「存在尝试」动作与溯源含义
| 动作 | 含义 | 溯源关注点 |
|---|---|---|
| 拦截 | 请求被阻断，未到后端 | 确认是否真的未到达，排查日志丢失 |
| 放行 | 请求通过并转发 | 漏检重点，必须回看后端日志 |
| 挑战 | 触发人机校验 | 可挡脚本，但可能影响正常用户 |
| 仅记录 | 只记不拦（观察模式） | 观察期内完全依赖这类记录发现攻击 |
WAF 日志是旁证。判断攻击是否成功要回到 Web 访问日志（状态码与响应字节数）和后端应用日志，三者的时间要对齐后再下结论。
云 WAF 的日志投递有延迟，各厂商保留期也不同。排查较早的事件前先确认保留范围，避免把「查不到」写成「未发生」。