Clash 分流规则怎么写才不漏域名

Clash 分流规则写得不漏域名，核心在于精准覆盖所有目标流量，同时避免因规则模糊或优先级错乱导致的遗漏。常见问题不是规则写错了，而是规则没覆盖全——比如只写了 `example.com`，却漏了 `www.example.com`、`api.example.com`、`cdn.example.com`，或是未考虑子域名通配和协议差异（如 `http://` 与 `https://`）。更隐蔽的问题是：某些域名在实际请求中通过 CDN 跳转，真实访问的是 `cloudfront.net`、`fastly.net` 等后端节点，若仅按原始域名设置规则，就会彻底失效。

要确保不漏，必须从流量路径反推规则逻辑。第一步，打开 Clash 客户端的「日志」功能，用浏览器访问你关心的网站（如 AI 辅助求职信平台），观察日志中实际发起的请求域名。例如，当你提交一份求职信时，前端可能调用 `api.resumeai.com`，而该接口又通过 `s3.amazonaws.com` 传输文件，此时如果只配置 `resumeai.com`，那 `s3.amazonaws.com` 的请求就会走默认代理或直连，造成流程中断。真正有效的规则必须包含这些中间跳转点。

第二步，使用通配符时务必谨慎。`*.example.com` 可以覆盖所有子域名，但不能用于匹配 `example.com` 本身；反之，`example.com` 不会匹配 `sub.example.com`。正确做法是：主域名写一条精确规则，子域名统一用通配符补充。例如： ``` DOMAIN,example.com DOMAIN-SUFFIX,*.example.com ``` 这样既明确又全面。注意，`DOMAIN-KEYWORD` 虽然灵活，但容易误匹配，比如 `keyword:login` 会命中所有含 login 的域名，包括 `login.google.com`，导致大量误判。除非你确定关键词唯一，否则应避免使用。

第三步，检查规则优先级。Clash 按规则列表顺序执行，一旦匹配即停止。因此，**最具体规则必须放在最前面**。比如你有两条规则： ``` DOMAIN,www.google.com DOMAIN-SUFFIX,google.com ``` 如果前者在后者之后，那么访问 `www.google.com` 时，规则会先匹配到 `google.com`，从而走错误线路。正确的顺序是把精确匹配放前，通配放后。

第四步，利用本地 DNS 解析验证。在命令行运行 `dig example.com`，查看返回的权威服务器地址，再用 `nslookup` 检查是否解析到预期的 IP。如果发现域名解析到了 `1.1.1.1` 或 `8.8.8.8`，说明你的 DNS 配置可能被绕过，需要检查 Clash 是否启用了“DNS 重定向”或“Bypass DNS”。此外，部分服务（如 PikPak）分享链接时会生成临时跳转页，其域名可能是 `pikpak.com`，但实际资源由 `cdn.pikpak.com` 托管，若规则只写 `pikpak.com`，就无法拦截其静态资源请求，导致下载失败。这类情况必须手动抓包分析，确认完整链路。 延伸阅读：AI 辅助求职信：结构固定，三处必须人工核对。 延伸阅读：PikPak 怎么保护分享出去的链接。

第五步，定期更新规则库。很多开源规则集（如 Anti-AD、Chinalist）会定期调整，建议每周手动拉取一次最新版本，并对比自己添加的自定义规则是否冲突。工具推荐使用 `clash-rules` 或 `rule-china` 这类维护良好的集合，它们已对常见服务做了分层处理，可直接引用。

最后，测试必须真实场景模拟。不要只靠 ping 域名，而要用浏览器访问完整页面，触发所有请求。可通过开发者工具的 Network 标签页，逐项检查每个请求的域名、状态码和代理状态。若某条请求显示“Direct”，而你本意是走代理，那就说明规则漏了。

真正的不漏，不是规则写得多，而是每一步都基于真实流量行为，而不是主观猜测。规则写得越细，越可能出错；写得越准，越能兜底。AI 辅助求职信的三处必须人工核对，正是这个道理——系统可以生成结构，但语义和上下文必须人来判断。同样，分流规则也必须让机器跑，让人来验。