99吧机场

站长推荐

IPLC专线+BGP中转，不限使用设备数量，价格亲民，性价比拉满！

→

FlyBit机场

折扣优惠

IPLC专线+中转,所有线路都是1倍率，用多少算多少，很实在！

→

很多人开始自定义 Clash 分流后，都会遇到类似情况：明明添加了某个域名规则，它却没有进入指定代理组；写了 DIRECT，应用仍然经由代理连接；订阅更新后看起来规则还在，实际行为却变了。

这类问题通常不意味着节点坏了，也不一定是客户端故障。更常见的原因是：Clash 会按顺序匹配规则，先匹配到的规则通常就会立刻生效。你以为自己写的规则很明确，但它可能排在一条更宽泛的规则后面，因而根本没有获得匹配机会。

本文不讨论某个服务商的专用订阅，也不要求你一次性读懂完整配置文件。只要掌握“看连接记录、确认命中规则、检查顺序、再修改”的流程，就能处理大多数规则不生效的问题。不同 Clash 客户端的界面名称可能略有差异，但底层判断逻辑基本一致。

先记住核心原则：规则通常从上到下匹配

在 Clash 的规则模式中，一条连接会依次与规则列表比对。满足某条规则的条件后，客户端会把流量交给该规则指定的策略组或出口，后面的规则一般不再继续判断。

可以把它理解成排队过闸：

1. 连接先来到规则列表顶部；
2. 从第一条开始逐项核对；
3. 找到第一条符合条件的规则；
4. 使用该规则指定的策略；
5. 后续规则即使更具体，也没有机会再参与。

例如，下面两条规则的排列会产生完全不同的结果：

- DOMAIN-SUFFIX,example.com,PROXY
- DOMAIN,api.example.com,DIRECT

访问 api.example.com 时，第二条看起来更精确，但实际会先命中第一条 DOMAIN-SUFFIX,example.com，因此走 PROXY。

如果你的目标是让 api.example.com 直连，应当调整为：

- DOMAIN,api.example.com,DIRECT
- DOMAIN-SUFFIX,example.com,PROXY

这就是排查的第一原则：越具体、优先级越高的例外规则，应放在更宽泛规则之前。

不要靠猜：先在连接记录中确认“实际命中了什么”

当规则行为与预期不符时，最容易犯的错误是直接反复改配置。更可靠的方法是先看连接记录，也就是 Connections、连接、活动连接或网络日志页面。

找到出问题的网站或应用连接后，重点确认以下信息：

• 请求的域名是什么；
• 实际连接的 IP 地址是什么；
• 使用了 TCP 还是 UDP；
• 最终选中了哪个策略组；
• 客户端显示的 Rule、规则、Match 或 Process 信息是什么。

假设你在浏览器中打开的是 www.example.com，连接记录中却显示请求发往 cdn.example.net。这并不罕见。网页本身、图片、脚本、登录接口、视频资源和统计服务，可能来自完全不同的域名。此时只给 www.example.com 写规则，无法控制其他资源的流向。

对于桌面应用也一样。应用显示的名称不一定等于它实际访问的域名。应以连接记录为准，而不是按软件名称或网页地址凭感觉添加规则。

如果客户端的连接记录里没有规则名称，也可以先观察“最终策略组”。例如你期望直连，但记录中显示进入某个代理组，说明至少已经确认：当前连接没有按你的预期走 DIRECT。下一步再回到配置中寻找可能抢先匹配的规则。

常见规则类型：域名、关键词、IP 不要混为一谈

Clash 规则看上去都是逗号分隔的文本，但匹配对象并不相同。理解这一点，能避免大量“规则写了却没反应”的情况。

DOMAIN：只匹配一个完整域名

- DOMAIN,login.example.com,PROXY

它只针对 login.example.com 本身，不会自动匹配 api.login.example.com，也不会覆盖 example.com 下的其他子域名。适合处理非常明确的单个接口或例外站点。

DOMAIN-SUFFIX：匹配域名及其子域名

- DOMAIN-SUFFIX,example.com,PROXY

它可以匹配 example.com、www.example.com、api.example.com 等。对于一个服务使用多个子域名的场景，这通常比逐条写 DOMAIN 更实用。

不过它的范围较大，务必留意不要误伤相似但不属于目标服务的域名。规则值应是纯域名后缀，不要带 https://、路径、端口或通配符形式的网址。

DOMAIN-KEYWORD：范围很宽，使用要谨慎

- DOMAIN-KEYWORD,example,PROXY

只要域名中包含 example，就可能匹配。它适合临时定位或名称高度明确的场景，但不适合随意放在规则列表顶部。因为关键词可能意外命中无关域名，造成难以解释的分流结果。

IP-CIDR：按目标 IP 判断，不认识域名

- IP-CIDR,203.0.113.0/24,DIRECT,no-resolve

这类规则根据目标 IP 或网段决定去向。它常被用于局域网、内网网段或某些固定地址服务。要注意，许多互联网服务使用动态调度、内容分发网络或多地区地址，IP 可能变化；只依赖 IP 规则，长期维护成本通常较高。

另一个容易忽略的点是：域名规则能否命中，与 Clash 是否获得域名信息有关。如果连接记录只看到 IP，或者应用直接访问 IP 地址，那么你写的 DOMAIN、DOMAIN-SUFFIX 规则自然无法生效。这时要先确认该流量究竟有没有域名可供匹配。

GEOIP、GEOSITE 与 MATCH：范围最大的“兜底规则”

GEOIP 和 GEOSITE 往往引用地区或分类数据库，便于批量分流；MATCH 则可理解为最后的默认处理规则。它们本身并非有问题，关键在于位置。

例如：

- GEOSITE,CN,DIRECT
- MATCH,PROXY

表示先让分类为 CN 的域名直连，其余未命中的流量走代理。若你要给某个站点设置例外规则，应放在这些宽泛分类规则之前，否则依然可能被提前截获。

RULE-SET 为什么“看起来加载了，实际却没命中”

RULE-SET 是将大量规则保存在独立文件或远程规则集中的方式。它让主配置更整洁，但也增加了几个需要检查的环节。

第一，确认规则集已经成功下载或读取。如果远程规则集更新失败、链接返回的并非规则内容，或者本地文件路径不正确，客户端可能提示加载异常，也可能继续使用旧缓存。不要只看界面中是否存在规则集名称，还应查看更新时间、报错提示和日志。

第二，确认规则集的格式与当前内核兼容。不同客户端、不同内核以及不同规则集格式之间，可能存在差异。某些规则集适用于特定内核或特定行为模式，不能想当然地直接替换。遇到不明错误时，优先回到客户端或规则集维护方提供的格式说明，不要把 YAML、文本规则集和二进制规则集混用。

第三，确认 RULE-SET 在总规则中的位置。例如：

- RULE-SET,work,DIRECT
- RULE-SET,streaming,PROXY
- MATCH,PROXY

如果 work 与 streaming 中存在重叠域名，排在前面的 work 通常优先。规则集并不是“自动智能合并”，其先后顺序仍然重要。

第四，检查策略组名称是否完全一致。规则最后一项写的是策略组名称，而不是某个节点名称。若配置中没有对应策略组，或名称因订阅更新、覆写修改而发生变化，规则即使匹配也无法按预期转发。中文名称、空格、大小写和符号都应仔细核对。

覆写与订阅规则冲突：你改的位置可能根本不参与最终配置

使用订阅配置时，许多人会在客户端导入后的配置页面直接修改规则。问题在于，下一次更新订阅后，修改可能被替换；有些客户端还会通过覆写、合并模板或脚本，在订阅内容生成最终运行配置前再次调整规则。

因此要分清三个概念：

• 订阅原始内容：服务端提供、更新时可能整体替换；
• 本地覆写内容：用于长期保留自己的策略组、规则或 DNS 设置；
• 当前运行配置：客户端最终实际加载并用于分流的结果。

排查时，不要只看自己编辑过的某一处。应尽量找到客户端展示的“当前配置”“生效配置”或配置预览，确认目标规则最终是否存在、位于什么位置、引用的策略组是否正确。

如果客户端支持“在规则前插入”与“在规则后追加”，处理例外规则时通常应选择前插入。因为追加到末尾很可能已经晚于 GEOIP、GEOSITE 或 MATCH 等兜底规则。

修改后建议执行完整刷新流程：保存覆写、重新载入配置、必要时重启核心，再重新发起一次全新的连接观察记录。浏览器和应用可能复用已有连接；只刷新网页不一定会触发新的路由判断。可以关闭对应网页标签、退出并重新打开应用，或等待旧连接自然结束后再验证。

一套可重复使用的排查清单

当某个规则“不生效”时，可以按下面顺序操作。这样比凭感觉删除重写更节省时间。

1. 确认当前处于规则模式。 如果使用全局模式，分流规则通常不会按预期决定出口；如果处于直连模式，也会绕开大部分代理选择逻辑。
2. 打开连接记录并复现问题。 记录实际域名、IP、协议、命中的策略组和规则提示。
3. 检查规则对象是否写对。 访问的是子域名就考虑 DOMAIN-SUFFIX；连接只有 IP 就不要期待纯域名规则命中。
4. 搜索同类规则。 在最终生效配置中查找该域名、关键词、所属规则集和更宽泛的后缀规则。
5. 比较排列顺序。 将单域名例外、业务必需规则放在通用分类、关键词规则和 MATCH 前面。
6. 确认策略组存在且可用。 规则指向的策略组应与当前配置名称一致，策略组内部也要有可选出口。
7. 检查 RULE-SET 状态。 看它是否正常下载、格式是否兼容、更新是否成功，以及它与其他规则集是否重叠。
8. 重新载入并建立新连接。 保存后重新加载配置，避免用旧连接判断新规则。
9. 一次只改一个变量。 改完一处立即验证并记录结果，避免多项改动叠加后无法判断真正原因。

两个容易忽略的边界情况

第一是应用绕过系统代理。部分应用不会使用系统代理设置，或者自行建立网络连接。此时即使规则正确，流量也未必进入 Clash 核心，自然不会出现在相应连接记录里。是否能接管这类流量，取决于客户端工作模式、系统权限和应用自身网络机制。不要把“没有连接记录”直接等同于“规则失效”。

第二是 DNS 缓存与连接复用。规则调整后，系统、浏览器、应用以及客户端本身可能暂时保留旧的解析或连接状态。先确认当前是否出现了新的连接记录，再判断规则是否生效；必要时在不影响工作任务的前提下重新打开应用或清理相关缓存。

结语：规则排障的关键是证据链，而不是堆规则

Clash 分流的难点不在于规则语法多复杂，而在于你需要知道一条连接实际访问了什么、先被哪条规则匹配、最后进入了哪个策略组。只要建立这条证据链，很多看似玄学的问题都能变成明确的顺序和匹配问题。

日常配置中，建议保持规则结构简单：把少量明确的例外规则放在顶部；把可维护的大类交给可靠的规则集；将 MATCH 这类兜底规则放在最后；每次修改都通过连接记录验证。规则越少但越清楚，后续更新订阅、迁移客户端和排查异常时就越轻松。