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

Clash 分流规则写得不漏域名，本质是让每一个目标请求都能被精准匹配到正确的代理策略，而不是在规则盲区里白白浪费流量或暴露隐私。常见情况是：你明明设置了某个域名走直连，结果它却走了代理；或者某应用的子域名突然无法访问，排查半天才发现规则里只写了主域名，漏了二级、三级甚至动态生成的子域。更隐蔽的问题在于，某些服务使用了通配符、泛解析、或通过 CDN 动态分发，导致规则根本无法覆盖所有可能的域名路径。

要解决这个问题，第一步必须明确你的目标行为——哪些域名该走代理、哪些该直连、哪些该走特定规则（如 GFWList）。但仅仅列出域名还不够，关键在于理解域名的“真实归属”和“访问链路”。例如，一个下载链接来自 PikPak，其实际请求的主机名可能是 `pikpak.com`，但具体任务中使用的地址可能是 `cdn.pikpak.com`、`api.pikpak.com`，甚至是 `*.pikpak.net` 这类泛化域名。如果规则只写了 `pikpak.com`，那这些子域名就会因为未命中而进入默认策略，最终导致下载任务一直显示“等待”——因为它们没被正确分流，既没走代理也没走直连，而是卡在了无规则匹配的兜底逻辑里。

另一个典型场景是招聘系统解析简历时踩坑。系统可能从多个第三方平台抓取简历，比如 LinkedIn、GitHub、智联、猎聘等，每个平台的域名结构不同，且部分接口使用了动态子域名（如 `api-123456.hireplatform.com`），若规则只写 `hireplatform.com`，那么这些带编号的子域名就无法被识别，导致请求被错误地路由到非预期代理，甚至触发反爬机制，造成解析失败。此时你可能误以为是程序出错，实则是分流规则遗漏了关键路径。

因此，真正有效的规则写法，必须建立在对目标服务的完整域名拓扑分析之上。操作步骤如下：

1. 用浏览器开发者工具或 Wireshark 抓包，观察目标应用发起的所有请求，重点关注 **Host 头字段** 和 **实际连接的域名**。不要只看页面标题或跳转链接，真正的请求域名往往藏在 JS、API 调用、资源加载中。

2. 提取所有出现过的域名，包括子域名、泛域名、以及带有数字/字母组合的动态域名。例如，`api-abc123.pikpak.com`、`static.v2.xxxxxx.github.io` 等。 延伸阅读：PikPak 下载任务一直显示等待的原因。 延伸阅读：招聘系统解析简历时会踩哪些坑。

3. 使用 `DOMAIN` 规则类型，而非 `DOMAIN-SUFFIX` 仅适用于简单后缀匹配。当遇到复杂层级时，优先使用 `DOMAIN` 明确指定精确域名，避免误伤其他子域。例如： ``` - DOMAIN:pikpak.com - DOMAIN:cdn.pikpak.com - DOMAIN:api.pikpak.com ``` 若需覆盖所有子域，才使用 `DOMAIN-SUFFIX`，但要警惕范围过大带来的风险。

4. 对于 CDN 或云服务（如 AWS、Cloudflare、Akamai），其域名通常具有规律性，可借助 `DOMAIN-KEYWORD` 搭配关键词过滤，如： ``` - DOMAIN-KEYWORD:cloudfront - DOMAIN-KEYWORD:cdn.jsdelivr ``` 但务必结合实际请求验证是否误拦截。

5. 在 Clash 配置中启用日志记录，查看每条请求的匹配结果。重点检查那些“未命中规则”的请求，它们往往是漏掉的根源。通过日志反推缺失的域名，逐个补充。

6. 定期更新规则库，特别是针对频繁变更的平台。像 PikPak 的接口域名可能随版本迭代更换，而招聘系统的对接服务也可能切换服务商。保持规则与实际服务部署一致，才能避免“等待”状态反复出现。

最后，判断规则是否“不漏”，不是看写了多少行，而是看是否能覆盖所有真实请求路径。一个高可用的分流规则，应具备可验证性、可追溯性和可维护性。当你发现某个任务始终无法完成，先别怀疑网络或账号，先查它的实际请求域名是否在规则中，这才是最直接的突破口。