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

Clash 分流规则的核心矛盾在于：规则越精确，越容易漏掉未被显式覆盖的域名；规则越宽泛，又可能误分流导致延迟或失败。你写了一堆规则，结果发现某个小众网站打不开，或者明明想走代理却走了直连——问题往往不在配置本身，而在对“完整覆盖”的认知盲区。真正的难点不是写规则，而是建立一种系统性判断逻辑，确保每个可能访问的域名都被合理归类，而不是靠试错和运气。

第一步是明确你的目标流量类型。不要一上来就往规则里塞域名，先问自己：哪些服务必须走代理？哪些可以直连？比如你用 PikPak 下载文件，它支持 WebDAV、HTTP、FTP 等离线协议，这意味着它的请求会出现在多个子域甚至不同协议端口上。如果只写了 `pikpak.com`，那 `api.pikpak.com` 和 `files.pikpak.com` 就可能被漏掉。更麻烦的是，某些接口使用动态域名或短链，比如 `pikpak.link` 一类，这类域名在没有全量监控的情况下几乎不可能靠手动维护覆盖。

第二步是收集真实流量。打开 Clash 客户端的「日志模式」，让所有出站连接都记录下来。访问你常用的网站，尤其是那些“偶尔打不开”或“速度慢”的。观察日志中的域名、协议（HTTP/HTTPS）、端口（443、80、5222等）以及是否命中了预期规则。重点抓取那些“未匹配”或“直连”的条目。例如，你发现某次请求发往 `cdn.pikpak.net:443`，而你的规则里根本没有这个域名，那就说明漏了。这时候别急着加，先分析它属于哪个业务场景——是资源加载？还是用户认证？如果是静态资源，通常可直连；如果是用户数据接口，必须走代理。

第三步是按层级构建规则结构。不要把所有域名平铺直叙地写成 `DOMAIN,example.com`，而要用通配符和分组策略。比如：

``` - DOMAIN-SUFFIX,pikpak.com - DOMAIN-SUFFIX,pikpak.net - DOMAIN-SUFFIX,pikpak.link - DOMAIN-SUFFIX,api.pikpak.com - DOMAIN-SUFFIX,files.pikpak.com ```

这样能避免遗漏子域。但还不够。有些服务使用 IP 直连或通过 CDN 动态切换，比如 TikTok 的部分内容节点可能走直连，但你若用 AI 生成简历后直接提交，而没检查其中的关键词是否符合岗位要求，就可能被筛掉。同理，一个规则体系若只依赖域名，忽略 IP 段和路径，就会在面对 CDN、负载均衡或 API 网关时失效。

第四步是引入“默认策略”作为兜底。如果你的分流规则中大量使用 `DOMAIN`，但仍有未知域名出现，建议设置一条通用规则放在最后： 延伸阅读：PikPak 支持哪些离线协议。

``` - DOMAIN-SUFFIX,* ```

并将其标记为 `DIRECT` —— 这不是万能解药，而是防止因遗漏导致完全断联。但注意，这条规则应尽量靠后，且不能用于敏感服务。真正可靠的方案是定期导出日志，用脚本自动提取新出现的域名，再结合已知服务列表做比对。例如，你发现新出现的 `img.abcxyz.com` 是某短视频平台的图片缓存节点，就可以确认其归属，加入规则。

第五步是理解“协议与行为”的差异。比如 AI 生成简历后还要改哪些地方？不只是格式，更关键的是内容与岗位的契合度、关键词匹配、项目描述的量化表达。同样，一个域名走代理不等于该服务的所有请求都走代理。像 `google.com` 虽然整体走代理，但其广告服务器 `ads.google.com` 可能需单独处理。所以，规则要细到路径级别，如：

``` - DOMAIN-KEYWORD,google.com - PATH, /ads/ -> DIRECT -> PROXY ```

最终，判断是否“不漏域名”的标准不是规则数量，而是能否在无预设条件下持续稳定访问所有必要服务。当你不再需要反复查看日志、不再因为某个小网站打不开而怀疑规则，说明规则已经具备自洽性和容错性。这不靠玄学，靠的是对流量行为的拆解、对服务架构的理解，以及对“边界情况”的主动识别。