Clash 规则模式、全局模式和直连模式怎么选：三种代理模式差异对照

三种模式区别：决定连接出口，不决定接管范围

日常同时访问本地服务与需要代理的站点，通常先用规则模式；需要暂时绕过分流规则验证节点时，用全局模式；需要比较本地网络的直连表现时，用直连模式。这三个选项解决的是“连接交给 Clash 后怎么走”，而不是“哪些应用的流量能进入 Clash”。

Clash 系列客户端的界面可能显示 Rule、Global、Direct，也可能显示对应中文。Clash Meta 后续使用 mihomo 名称，常见客户端在这一层仍沿用三种模式。具体规则能力会随内核变化，但“接管流量”和“选择出口”应当分开理解。

规则模式：按顺序匹配，再进入策略组

规则模式会按配置中的规则自上而下判断连接。普通规则命中后，就按对应目标处理；目标可以是 DIRECT、REJECT，也可以是一个真实存在的策略组。策略组再决定使用哪个节点或下级策略。因此，定位连接时要看两层：命中了哪条规则，以及这条规则指向的组最终选中了什么。

规则顺序比规则数量更重要

下面是规则段示例，不是可直接导入的完整订阅。“节点选择”必须替换成当前配置里已定义的策略组名；保留示例名称却没有对应策略组，可能导致配置加载失败。

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,节点选择

• DOMAIN-SUFFIX,example.com 匹配该域名及其子域名，不能据此推断任意包含这段字符的域名都会命中。
• 192.168.0.0/16 与 10.0.0.0/8 是常见私有地址范围；示例并未列出全部本地地址范围。
• no-resolve 表示不要仅为这条 IP 规则主动解析域名；目标已经是 IP 时仍可参与匹配。
• MATCH 是兜底规则。把它放到前面，会让后续规则失去匹配机会。

适合日常使用，但需要维护分流依据

例如，局域网存储设备应当直连，特定外部站点交给代理组，其余流量再进入兜底组。规则模式可以同时表达这些需求。不过，网站登录、图片、视频可能使用不同域名：主页面匹配正确，不代表所有子请求都会走同一条路径。

遇到“网页能打开但图片不显示”，先查看失败请求的域名与命中规则。不要直接把全部流量改成代理并长期保留，也不要只根据浏览器地址栏里的主域名补一条规则。规则来源、订阅更新和内核支持范围都需要一起确认。

全局模式：适合验证节点，不等于全设备代理

全局模式把已接管的普通业务连接交给 GLOBAL 策略处理。切换后，应再打开客户端的代理或策略组页面，确认 GLOBAL 当前选中的目标。部分界面会隐藏该组或单独显示全局选择器，以实际连接详情中的出口为准。

全局模式不保证一定经过远端节点。如果 GLOBAL 选中 DIRECT，连接仍然直连；如果 GLOBAL 指向另一个策略组，还要继续检查该组的最终选择。规则模式中常用的“节点选择”组，也不一定与 GLOBAL 同步。

用全局模式区分节点问题与规则问题

1. 记录规则模式下失败请求的域名、命中规则与出口节点。
2. 切换到全局模式，把 GLOBAL 设为同一个待测试节点。
3. 关闭对应旧连接，再重新发起请求；不要只观察仍在复用的页面连接。
4. 若全局可用、规则不可用，优先检查分流规则、目标策略组及 DNS 差异；若两者都失败，再检查节点与本地接管链路。

这个对照只是在缩小范围，不是最终结论。远端服务限流、DNS 缓存、连接复用和测试时间差都可能影响结果。应尽量保持同一网络、同一目标与同一节点，只改变模式这一项。

直连模式：适合网络对照，不等于关闭客户端

直连模式下，进入内核的业务连接通常直接访问目标，不再按普通规则选择代理节点。它适合回答一个明确问题：“这次失败是否与代理节点有关？”例如同一资源在直连下可用、指定代理节点下失败，可以继续检查该节点的连通性或目标站点对出口的限制。

但切到直连后，系统代理仍可能指向本机监听端口，TUN 虚拟网卡也可能继续工作。客户端的 DNS 监听、缓存与相关解析路径也未必停用。因此，直连模式只能作为不使用代理节点的对照，不能完全代表退出客户端后的原始网络。

• 只想暂时不走节点：使用直连模式，然后确认连接详情中的出口为 DIRECT。
• 要测试完全不经过客户端：先关闭系统代理与 TUN，再按需退出客户端，确认系统没有残留手动代理。
• 退出后所有网页都打不开：检查系统是否仍指向 127.0.0.1 的代理端口，而对应监听已经停止。

直连也不意味着所有目标都能访问。目标服务是否可达，仍受本地网络、路由、DNS 和服务端策略影响。某个站点直连失败，不能单独证明客户端设置有误。

系统代理与 TUN：决定哪些连接进入内核

系统代理通常通过操作系统的代理设置，让遵循该设置的应用把请求交给本机 HTTP 或 SOCKS 入口。浏览器往往支持系统代理，但命令行工具、游戏和部分独立应用可能使用自己的网络配置。TUN 则通过虚拟网卡和路由接管匹配流量，范围仍取决于路由、排除项、权限和内核配置。

先核对监听端口，再测试接管链路

以下命令假定客户端的 HTTP 或混合监听端口为 7890。这只是具体演示值，不是所有客户端的默认值；请先在客户端端口设置中核对，再执行。Windows 可用 curl.exe，macOS 与 Linux 通常使用 curl。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com
curl --noproxy "*" --connect-timeout 10 --max-time 20 -I https://example.com

第一条显式经过本机代理入口，第二条让 curl 不使用应用层代理。若 TUN 仍开启，第二条流量依然可能被虚拟网卡接管，因此不能把它当作完全绕过客户端的测试。应结合连接面板检查这两次请求是否进入内核，以及最终出口是什么。

命令返回 HTTP 响应只能说明这次请求得到响应，不能证明视频、游戏 UDP 或整个系统都已正常代理。HTTP 代理测试与 UDP 接管是两件事，后者还取决于入口方式、节点协议和服务端支持。

切换模式后连接异常：按五项顺序排查

1. 核对当前配置与最终出口

先确认启用的是哪份订阅或本地配置，再查看模式与策略组。订阅更新可能改变规则和组名；界面上曾经选中的节点，也不一定仍是当前连接使用的节点。规则模式看命中规则，全局模式看 GLOBAL，直连模式看 DIRECT。

2. 关闭旧连接后再复测

切换模式通常影响新建立的连接，既有 TCP 连接和部分 UDP 会话可能继续沿用原路径。浏览器的 HTTP/2、HTTP/3 连接复用会让这种现象更明显。可在客户端连接面板结束目标连接，再重新打开页面；结束全部连接会中断下载、会议等任务，应提前保存工作。

3. 分开检查 DNS 与业务出口

解析失败时，切换到全局不一定能解决问题。查看日志是否出现 DNS 超时、目标解析错误，或 fake-ip 相关异常。对于 mihomo，DNS 上游、解析策略与是否遵循规则取决于实际配置；不能简单认为“全局模式下所有 DNS 都经节点”。修改前先备份，不要同时更换 DNS、节点和模式。

4. 检查系统代理、TUN 与其他网络工具

若显式代理测试正常，浏览器却没有对应连接记录，优先检查浏览器是否使用独立代理配置。若 TUN 开启后失败，则查看运行权限、路由排除和其他 VPN 是否冲突。一次只保留一条待测试的接管链路，避免系统代理与多个虚拟网卡交叉影响判断。

5. 用同条件记录代替只看延迟

节点延迟测试通常只是对特定地址的一次探测，不代表目标网站吞吐量。可以在同一网络下记录三次请求的模式、节点、目标域名、结果与错误信息。例如记录“规则模式命中 DIRECT，连接超时；全局模式选节点 A，返回 HTTP 200”，比单独写“节点显示 80 ms”更有定位价值。这里的数值是记录格式示例，不是本站实测结果。

日常选择建议：规则常用，全局与直连用于对照

• 办公、浏览与局域网设备并用：优先规则模式，验证私有地址与常用服务的实际命中结果。
• 怀疑分流错误：临时切全局，显式选择待测节点，关闭旧连接后比较同一个目标。
• 怀疑节点或远端线路异常：用直连作对照；需要原始网络基线时，再关闭系统代理和 TUN。
• 只有某一个应用异常：先确认它是否进入内核，不要反复切换三种模式代替检查接管方式。

可靠的判断顺序是：流量有没有进入内核、当前模式如何处理它、最终出口是否符合预期。把这三件事确认清楚，再调整规则或节点。需要核对安装与导入步骤，可以查看Clash 使用教程；需要理解规则字段，可继续查阅协议手册。