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

Clash 分流规则写得不漏域名，本质是让每一个你可能访问的网络请求都能被正确识别并路由到对应的代理策略，而不是在规则盲区中走默认直连或误入错误代理链。常见问题不是规则写错了，而是你根本没意识到某些域名早已进入你的流量路径——比如一个看似无关的子域名、某个第三方脚本加载的CDN地址、或是某应用内嵌的API接口。一旦这些被遗漏，哪怕只是偶尔触发一次，就可能导致页面加载失败、登录失效、功能异常，甚至隐私泄露。

要确保不漏域名，核心逻辑是：**先覆盖已知高频目标，再通过流量监控反推未知项，最后用规则结构化归类避免冲突**。第一步，明确你要分流的三类域名：国内服务（如百度、腾讯）、国际服务（如Google、GitHub）、以及混合型服务（如微信、阿里云）。国内服务通常走直连，国际服务走代理，混合型则需根据具体子域名判断。例如 `*.baidu.com` 应直连，但 `api.github.com` 必须走代理。

第二步，建立规则模板。使用 Clash 的 **DOMAIN-SUFFIX** 和 **DOMAIN-KEYWORD** 两种匹配方式组合，避免单靠精确匹配。例如：

```yaml - DOMAIN-SUFFIX,google.com,Proxy - DOMAIN-SUFFIX,baidu.com,DIRECT - DOMAIN-KEYWORD,cdn,Proxy ```

这里 `DOMAIN-KEYWORD,cdn,Proxy` 能捕获所有包含“cdn”字样的域名，包括 `static.example.com` 或 `cdn.jsdelivr.net`，这是最易被忽略的入口。若只写 `DOMAIN-SUFFIX,jsdelivr.net,Proxy`，那 `cdn.jsdelivr.net` 就会漏掉，因为域名层级不一致。

第三步，启用 Clash 的日志功能，观察实际连接行为。在规则生效后，打开浏览器访问常用网站，查看 Clash 日志中的“出站”记录。重点留意以下几类情况： - 出现 `DIRECT` 但你期望走代理的域名； - 出现 `Proxy` 但该域名应直连的（如 `login.weixin.qq.com`）； - 域名以 `api.` `static.` `img.` 开头，且未被规则覆盖。

例如，当你访问微博时发现 `weibo.com` 走了直连，但图片资源来自 `sinaimg.cn` 却走了代理，说明 `sinaimg.cn` 没被纳入规则。此时应立即添加 `DOMAIN-SUFFIX,sinaimg.cn,DIRECT`，否则后续加载缓慢或失败。

第四步，对复杂服务做细分处理。以 GitHub 为例，不仅需要 `github.com` 走代理，还要覆盖其镜像源和静态资源： ```yaml - DOMAIN-SUFFIX,github.com,Proxy - DOMAIN-SUFFIX,githubassets.com,Proxy - DOMAIN-SUFFIX,githubusercontent.com,Proxy - DOMAIN-SUFFIX,raw.githubusercontent.com,Proxy ```

同理，阿里云的文档站点 `help.aliyun.com` 有时走代理会导致加载失败，而 `aliyuncs.com` 又必须走代理才能调用服务，这就要求你根据实际表现手动补充规则。不能依赖“官方推荐列表”，因为它们往往过时或覆盖不全。

第五步，定期更新规则库。很多用户以为规则写完就一劳永逸，但域名结构随时变化。例如某平台将旧版 `api.oldsite.com` 替换为 `api.newsite.com`，若未及时更新，新域名就会走直连，导致功能异常。建议每月检查一次常用服务的域名变更，尤其是涉及登录、支付、文件下载等关键流程的接口。

关于「Notes on jianli bf 1」，这并非独立议题，而是提醒你在配置过程中保持系统性思维：每一行规则都应有对应场景支撑，而非随意堆叠。同样，求职信和简历怎么搭配投，本质上也是精准匹配——你投递的每一份材料都应与岗位需求形成闭环，如同规则与域名的对应关系，缺一不可。

最终，真正不漏域名的规则，不是写得越多越好，而是写得越准越少。每一条规则都要能回答：“为什么这个域名必须走这个策略？” 如果无法解释，就删掉。规则的本质是过滤器，不是万能网。