Clash 怎么看一次请求命中了哪条规则

当你在使用 Clash 时，发现某个请求看似正常却未按预期走代理，或者你怀疑某条规则没生效，最直接的突破口就是确认「这条请求到底命中了哪条规则」。这并非玄学，而是可以通过日志与配置分析精确追踪的事实。问题的核心在于：Clash 的规则匹配是基于顺序和条件双重判断的，一条请求可能被多条规则覆盖，但只有第一条完全匹配的规则会真正执行。因此，若你无法确定某次请求是否命中了特定规则，就等于在黑暗中调试网络路径。

要验证这一点，第一步是启用 Clash 的详细日志功能。打开你的 Clash 客户端（无论是 Clash for Windows、Clash Verge 还是命令行版），进入设置 → 日志，将日志级别设为 `debug`。此时，所有经过代理的请求都会生成一条记录，包含源地址、目标域名、请求方法、响应状态码以及最关键的信息——「命中规则」字段。例如，日志中会出现类似：

``` [2024-04-05 14:32:17] [DEBUG] Rule: DOMAIN-SUFFIX,google.com,Proxy ```

这说明该请求命中了名为 `DOMAIN-SUFFIX,google.com,Proxy` 的规则。如果你看到的是 `DIRECT`，那说明它被直连规则拦截了，即便你本意是让它走代理。

第二步，检查规则列表的顺序。Clash 从上到下依次匹配规则，一旦命中即停止。这意味着，如果有一条更靠前的规则（比如 `DOMAIN-KEYWORD,facebook`）意外匹配了你想要走代理的 `example.com`，那么即使后面有更精准的 `DOMAIN-SUFFIX,example.com,Proxy` 规则也无效。所以，你需要逐条排查规则顺序，尤其是那些以 `DOMAIN-KEYWORD` 或 `IP-CIDR` 开头的宽泛规则。

第三步，使用工具辅助验证。你可以用浏览器或 curl 手动发起一次请求，同时观察日志输出。例如：

```bash curl -v https://example.com ```

在终端运行时，确保关闭了本地 DNS 缓存（如 `dnscache`），否则可能看不到真实请求路径。若日志显示 `DIRECT`，而你期望走代理，那就说明规则顺序或条件不匹配。

第四步，结合实际行为判断。比如你正在测试简历改版后怎么验证有没有效果——假设你把一个关键词从“资深工程师”改为“高级开发专家”，然后访问招聘平台，发现推荐结果无变化，这时就要看：是不是因为某个规则误判了你的访问来源？是不是某个 `DOMAIN-KEYWORD` 规则把“高级”这个词归类到了直连范围？通过日志确认请求是否真的走了代理，才能判断是内容策略的问题，还是代理链路出了偏差。

再比如，当你说“AI 简历生成的边界：能写什么，不能替你写什么”——如果系统提示你“简历已优化”，但你实际投递时仍被拒，不妨检查一下：这个“优化”是否真的触发了代理规则？是否因为某些敏感词（如“精通”、“掌握”）被上游规则过滤，导致生成内容被降权处理？日志中若出现 `RULE-SET,blocklist,Direct`，说明请求已被屏蔽，而非代理生效。

最后，不要忽视规则语法的细节。比如 `DOMAIN-SUFFIX,example.com,Proxy` 和 `DOMAIN,example.com,Proxy` 虽然只差一个后缀，但前者仅匹配子域名（如 `api.example.com`），后者才匹配完整域名。若你只输入 `example.com` 但规则写成 `DOMAIN-SUFFIX`，就会漏掉匹配。

总结来说，每一次请求的规则命中不是凭感觉，而是由日志中的一行记录决定。只要开启 debug，保持规则顺序合理，理解语法差异，并用实际请求验证，就能把“为什么没走代理”变成“哪条规则在起作用”的清晰答案。