popup 只回答「哪些规则在本页生效过」，请求日志回答「哪条规则命中了哪个请求」：逐条列出时间、方法、请求 URL、命中的规则、执行的动作与执行结果。规则没按预期生效时，这里是排查的第一站。
规则管理页顶部统计区的**「命中记录」卡片**就是入口：卡片上的数字是各标签页合计的命中条数，会随页面的新请求实时增长，点整张卡片进入日志。日志视图左上角有「返回规则管理」，随时可以退回。
统计区在还没有任何分组时不显示——此时也不可能有命中。
日志里的每一行都是一次规则动作的记录，没有命中任何规则的请求不会出现在这里。换句话说，它是规则命中统计的原始数据，popup 上的规则标记只是它按规则去重后的投影。
因此「请求没出现在日志里」通常意味着规则没匹配上，而不是日志漏了：先检查匹配方式与模式，再确认该请求是否落在通道能力范围内。
命中日志按标签页归档，因此要先选一个标签页。下拉里只列出当前仍有命中记录的标签页，后面的数字是该标签页的记录条数，按最近活跃排序。
工具栏下方按命中次数倒序列出本页命中过的规则。点击某条规则即可只看它的记录，再点一次取消。命中量大的时候，先在这里定位是哪条规则在反复触发，比逐行扫更快。
| 筛选项 | 说明 |
|---|---|
| 关键词 | 同时匹配请求 URL、请求方法与规则名称，大小写不敏感 |
| 动作 | 只看某一类动作（拦截 / 重定向 / Mock / 限速…）的记录 |
| 执行结果 | 只看「已生效」或「未应用」的记录 |
| 列 | 说明 |
|---|---|
| 时间 | 记录按本地自然日分组，组内使用固定 24 小时制 时:分:秒，毫秒压暗跟在后面；同一请求的多个动作会挨在一起，毫秒能看出先后。悬停可看完整日期时间 |
| 方法 | 请求方法 |
| 请求 URL | 完整 URL，悬停可看全 |
| 命中规则 | 点击即跳回规则视图并定位、高亮该规则；规则已被删除时显示「已删除的规则」 |
| 动作 | 实际执行的动作，配色与规则列表一致 |
| 执行结果 | 「已生效」表示动作真的执行了；「未应用」表示规则匹配上却没能应用，悬停可看原因 |
如果日志所属的标签页仍然打开，点击任意记录行会激活该标签页；点击「命中规则」仍然优先跳回规则视图，不会切换标签页。
「未应用」目前只有两种原因，都属于页面补丁通道刻意的 fail-open：不透明响应（no-cors）读不到响应体、同步 XHR 容不下异步处理。这两种情况下扩展一律原样放行，宁可规则不生效也不破坏页面。
storage.session），随浏览器会话有效，不会持久化到磁盘。