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

Clash 分流规则写得不漏域名，核心在于对流量路径的精确掌控和对规则优先级的合理设计。很多用户在配置时误以为只要把常用域名加进规则就行，但实际运行中仍会遇到某些应用突然走代理、部分网页加载失败、或本该直连的却走了代理——根本原因往往是规则覆盖不全、匹配逻辑错误，或是未考虑子域名、泛解析、动态跳转等复杂场景。尤其当使用如 PikPak 这类依赖第三方服务器分发资源的服务时，若规则只写了主域名 `pikpak.com`，而忽略了其子域名 `api.pikpak.com`、`cdn.pikpak.com`，甚至后续可能接入的 `login.pikpak.com`，就会导致登录失败或文件无法下载。更隐蔽的问题是，某些服务在首次访问时会通过短链跳转，比如从 `https://pikpak.link/abc123` 跳到 `https://api.pikpak.com/v1/share/download?token=...`，若规则未涵盖跳转目标，即便原始链接被放行，后续请求依然会被代理拦截。

要确保不漏域名，必须从三个层面入手：第一，明确每个应用的完整请求链路。打开浏览器开发者工具，开启 Network 面板，模拟典型操作（如打开 PikPak 分享链接），观察所有发起的请求，记录下所有出现的域名与路径。特别注意那些带有 `www.`、`api.`、`cdn.`、`static.` 等前缀的子域名，以及任何包含 `s3.amazonaws.com`、`cloudfront.net` 等 CDN 服务的地址。第二，使用通配符与正则表达式增强覆盖能力。例如，将 `*.pikpak.com` 加入直连规则，比单独写多个子域名更可靠；对于动态生成的路径，可用 `^https://api\.pikpak\.com/.+` 这类正则匹配，避免因路径变化导致规则失效。第三，建立规则优先级体系。Clash 规则按顺序执行，越靠前的规则越优先。应将最具体、最明确的规则放在前面，例如先写 `DOMAIN-SUFFIX,google.com,Direct`，再写 `DOMAIN-SUFFIX,*.google.com,Direct`，避免模糊规则“吃掉”精准规则。

常见误判点包括：认为“只写主域名就够了”“用了白名单就万无一失”“DNS 解析成功就代表直连”。事实上，即使 DNS 返回正确 IP，若规则仍指向代理组，流量仍会走代理。因此必须结合 `IP-CIDR` 和 `DOMAIN` 双重判断，尤其对国内服务，可加入 `IP-CIDR,1.0.0.0/8,DIRECT` 这类大段直连规则，防止误触代理。同时注意，某些应用如求职信和简历投递平台（如拉勾、BOSS 直聘）常使用多级域名和 CDN，且其提交表单的接口往往为 `https://api.lagou.com/v1/resume/upload`，若仅写 `lagou.com`，很可能遗漏关键请求。此时应以真实抓包结果为准，确认所有涉及数据上传、身份验证、通知推送的域名是否全部覆盖。 延伸阅读：PikPak 怎么保护分享出去的链接。 延伸阅读：求职信和简历怎么搭配投要注意什么。

最终的验证方式是：在规则生效后，用一个已知的测试用例（如打开一个 PikPak 分享链接并下载文件，或在某招聘平台提交一份简历）全程监控网络请求。检查每一个请求是否都落在预期的直连或代理组中。若有异常，回溯抓包日志，逐条对比规则列表，找出第一个匹配但错误的规则，调整其位置或细化条件。不要依赖“感觉”或“经验”，规则的本质是精确的指令集合，而不是模糊的建议。

真正可靠的分流规则，不是堆砌域名，而是基于真实流量行为构建的结构化判断逻辑。每一个被遗漏的域名背后，都是一次无效连接、一次延迟卡顿、一次用户体验断裂。当你在配置时看到某个应用“偶尔出问题”，那不是运气差，而是规则尚未完成闭环。