同一个网站，规则模式打不开，切成全局却正常；明明选了新节点，连接记录里还是另一个名字。遇到这类问题，先看这条连接实际走了哪条规则、哪个代理组，再决定要改什么。
本文以 Clash Verge Rev 和 Mihomo 为例，讲清规则、全局、直连三个模式，并完成一次“只让指定网站走指定出口”的配置。还没有完成导入和首次连接，可以先看 Windows 入门教程；Mac 用户可以从对应操作步骤开始。
01 三个模式，改变的是出口选择
先确定前提：请求已经进入了客户端。系统代理、应用自身代理设置和 TUN 负责把流量送进来，下面三个模式负责决定进去以后怎样处理。未被接管的应用，不会因为切到全局就自动经过客户端；接管方式见系统代理与 TUN 的区别。
| 模式 | 进入客户端后的普通业务连接 | 适合什么时候用 |
|---|---|---|
| 规则（Rule） | 按当前配置匹配规则，选择直连、代理组或其他策略 | 日常分流：不同网站使用不同出口 |
| 全局（Global） | 使用 GLOBAL 组当前选择的节点或策略 | 临时对比：判断问题是否与分流结果有关 |
| 直连（Direct） | 由本地网络直接连接目标 | 临时检查本地网络，或不需要代理出口时 |
这三个模式是路由选择，不是速度档位。全局也要检查 GLOBAL 组究竟选了什么：如果选的是 DIRECT，结果仍然是直连；如果选的是另一个代理组，还要继续看那个组的选择。Mihomo 运行模式说明
直连模式也不等于退出客户端：系统代理、TUN 等入口可能仍开启。要停用接管，需要处理对应开关，不能只把模式改成“直连”。Clash Verge Rev 名词解释
02 换了节点没效果，可能换错了组
代理页里有“节点选择”“流媒体”“自动选择”等分组时，不要把它们当成一排作用相同的开关。规则通常先指向一个组，组再选节点，也可能继续选另一个组。
例如，一份配置把视频网站分给“影音”，普通网页交给“节点选择”。你在“节点选择”里换成节点乙，但“影音”仍直接选着节点甲，视频连接就可能继续走甲。只有“影音”选择了“节点选择”这个组，它才会沿着这条选择关系继续向下找出口。
手动选择组（select）由你决定使用哪个选项；如果它选择的是自动选择组（url-test），后者仍会按自己的测速配置选择节点。想固定到具体节点，就检查整条选择路径，而不是只看最外层的组名。手动选择组与自动选择组
实际排查时，可以在连接详情里找策略、代理链或类似字段。不同界面展示顺序可能不同，重点是认出“命中了哪个组”和“最终使用哪个节点”。
03 先看顺序，再看规则写得对不对
Mihomo 的路由规则从上往下匹配。通常前面命中的规则就决定了后续策略，因此“更精确”不会自动获得更高优先级；精确规则如果排在已经覆盖它的规则之后，仍可能用不上。涉及 UDP 等条件时，还要注意目标策略是否具备相应支持。路由规则与优先级
下面是用来理解顺序的片段，不是可以替换整个订阅的完整配置。example.com 是示例域名，“节点选择”必须换成你配置中真实存在的组名：
rules:
- DOMAIN,video.example.com,节点选择
- DOMAIN-SUFFIX,example.com,DIRECT
- MATCH,节点选择
在这个例子里，访问 video.example.com 先命中第一条，交给“节点选择”；访问 docs.example.com 则命中第二条，使用直连。如果把前两条交换，video.example.com 也会先被域名后缀规则接住。
DOMAIN 对应完整域名；DOMAIN-SUFFIX 对应该域名及其子域名。末尾的 MATCH 用于接住前面没有匹配到的连接。不要为了让某个网站使用节点，就在前面塞一条覆盖所有连接的 MATCH：那会让后面的分流规则失去机会。
04 在 Verge Rev 里给一个网站添加规则
先选一个你确实需要调整的网站。例如，某个域名在当前网络下直连不通，而你已有能访问它的节点。只改这一项，验证后再扩展范围。
- 在“订阅”页面找到正在使用的配置，右键选择“编辑规则”。这里维护的是该订阅的自定义规则，可以保留在后续订阅更新中。
- 新增规则，类型先选
DOMAIN，内容填写连接记录里的完整主机名，例如video.example.com。不要填https://、路径或整个网页地址。 - 代理策略选择当前配置中实际存在的代理组；需要直连时选 DIRECT，需要使用节点时选相应的组，并确认组内选择。
- 需要覆盖订阅中已有的分流结果时，放入前置规则，同时检查前面是否还有会先命中的自定义项。不要把它追加在已兜底的 MATCH 后面。
- 保存并确认没有配置错误，保持规则模式，然后让目标应用重新发起连接。
界面入口与前置/后置规则的含义可参考 Verge Rev 自定义规则。这与直接改下载下来的订阅正文不同；后者可能被下一次更新覆盖。
一个网页可能同时访问登录、图片、视频和接口等多个域名。添加主站域名后页面只恢复了一部分，先查看失败连接，再补真正需要的域名。不要因为一个资源加载失败，就直接扩大成整类域名、全部应用或全部流量。
05 改完以后，检查一条新连接
验证时保持订阅、模式和接管方式稳定，只调整刚才那条规则或对应组的选择。打开“连接”页面，清除筛选，重新访问目标内容，找到刚建立的连接，逐项检查：
- 目标是否相同： 看实际域名或 IP，而不是只认浏览器标签页上的网站名。
- 规则是否符合预期： 有没有命中新加的规则，还是先被另一条规则或规则集处理。
- 策略是否正确： 命中的组是否是你刚才修改的组，组内有没有继续指向其他组或 DIRECT。
- 应用是否恢复： 出口符合预期以后，再验证原先失败的操作，例如播放、登录或下载。
已有长连接不适合作为换规则、换节点后的唯一观察对象。可优先重连目标应用，或只关闭相关连接后重新测试；直接清空所有连接会影响其他正在使用的程序。
如果仍无法区分，可以做一次有控制的对比：记录当前设置，在全局模式中选择同一个明确的节点，重新建立目标连接。全局可用、规则模式不可用，提示你继续查分流和代理组；它并不能单独证明某一条规则错误，因为模式变化也可能影响其他配置行为。对比后切回规则模式，修正具体目标。
06 几种常见现象，对应查哪里
| 现象 | 下一步检查 |
|---|---|
| 换了节点，目标连接仍走旧节点 | 是否改错代理组、组里还有嵌套选择，以及观察的是否为旧连接 |
| 明明加了代理规则，却显示 DIRECT | 当前模式、规则顺序、实际域名，以及命中组是否选了 DIRECT |
| 全局能用，规则不能用 | 对比同一目标的新连接，确认规则模式的最终出口是否与全局相同 |
| 网页文字出现了，图片或视频失败 | 找失败资源的域名与连接，逐项判断，不只给主站加规则 |
| 完全找不到应用的连接记录 | 清除筛选、查看日志，再检查应用代理或 TUN 接管；规则还没到发挥作用的阶段 |
| 订阅更新后又不对了 | 是否改了会被覆盖的订阅正文、当前配置是否切换、原代理组是否还存在 |
如果连接已经走了预期节点，但仍出现域名解析异常，继续检查 DNS 接管、加密和出口。如果客户端根本看不到目标流量，则回到系统代理与 TUN 的排查步骤。先根据连接记录确定问题发生在哪一步，再动对应设置，通常比不断切换三个模式更有效。