三种运行模式的流量走向差异
Clash 及其衍生内核 Clash Meta（mihomo）在客户端设置里通常提供三种运行模式：规则模式（Rule）、全局模式（Global）与直连模式（Direct）。这三种模式决定的不是节点本身，而是“一条网络请求发出后，先经过什么判断，再走向哪里”。理解这一层判断逻辑，比记住每个模式的名字更重要。
- 规则模式：每一条请求先与配置文件中的
rules列表逐条匹配，根据域名、IP 段、GEOIP 归属地等条件，把流量分配给对应的代理组或直连；未命中任何规则的请求，最终交给规则列表末尾的默认策略（通常是MATCH或FINAL）处理。 - 全局模式：跳过规则匹配，所有流量（无论域名或 IP）统一发往当前选中的代理组或节点，出站行为高度一致但缺乏区分度。
- 直连模式：跳过代理，所有流量都走本机网络直接出站，等同于临时关闭代理功能。
三者的关键区别在于“判断环节是否存在”以及“存在时判断的粒度”。规则模式保留了精细判断，全局模式和直连模式都放弃了判断，只是放弃后流量的终点不同——一个终点是代理节点，一个终点是本机网络。
| 模式 | 是否匹配规则 | 流量终点 | 典型耗时特征 |
|---|---|---|---|
| 规则模式 | 是 | 按规则分配到直连或不同代理节点 | 命中直连规则的请求延迟低，命中代理规则的请求延迟取决于节点 |
| 全局模式 | 否 | 统一发往当前选中节点 | 所有请求延迟一致，取决于该节点线路质量 |
| 直连模式 | 否 | 本机网络直接出站 | 不经过代理，延迟等同于未使用 Clash 时的原始网络 |
说明：直连模式不等于“规则模式里全部走直连”。直连模式是在客户端层面整体关闭代理判断逻辑，即便配置文件里写了大量代理规则，也不会生效；而规则模式下即使某条规则明确写了直连，其余规则仍会正常把流量导向代理节点。
规则模式的典型适用场景
规则模式是绝大多数日常使用场景下的推荐设置，原因在于它能同时满足“境内服务保持低延迟直连”和“境外或特定服务走代理”两种需求，不需要用户手动切换。常见的规则维度包括：
- 域名后缀与关键词匹配：例如把常见的国内视频、支付、政务类域名归入直连策略，避免不必要的绕行。
- GEOIP 地理位置匹配：把解析结果落在特定国家或地区的 IP 归入对应策略，常用于区分境内 CDN 与境外服务器。
- 局域网与私有地址段直连：确保访问路由器管理页面、局域网内的打印机或 NAS 设备时不经过代理，这类规则通常写在规则列表靠前的位置。
- 进程与端口维度的规则（部分 Clash Meta 内核支持）：按发起请求的应用程序名称匹配，实现“只让某个应用走代理，其余应用直连”的精细控制。
一份典型的规则片段大致如下：
rules:
- DOMAIN-SUFFIX,cn,DIRECT
- GEOIP,CN,DIRECT
- DOMAIN-KEYWORD,examplecdn,Proxy
- IP-CIDR,192.168.0.0/16,DIRECT
- MATCH,Proxy这类配置的核心思路是：先把明确应该直连的流量拦截下来，再把不确定的流量统一交给最后一条 MATCH 规则处理。规则模式适合长期挂载使用、需要兼顾访问速度与稳定性的场景，例如日常办公、浏览网页、使用即时通讯工具等。规则文件通常由订阅提供方维护，用户也可以在客户端的“配置”页面里查看当前生效的规则集，或使用“覆写”功能追加自定义规则而不必修改原始订阅内容。
全局模式的典型适用场景与风险
全局模式的价值在于“可预测性”：所有流量走同一条线路，不存在因规则误判导致某个网站访问异常的问题。这在以下几种场景下比规则模式更合适：
- 排查规则是否生效异常：当怀疑某个网站访问缓慢或连接失败是规则匹配错误导致时，切到全局模式并强制所有流量走代理节点，如果问题依然存在，说明故障点在节点本身或网络环境，而不是规则配置。
- 需要统一境内境外访问口径：部分企业内网测试、跨境数据比对等场景，要求所有请求都从同一出口地址发出，全局模式能保证这一点，而规则模式下境内流量直连会导致出口地址不一致。
- 临时验证某个节点的整体表现：想集中测试某个新增节点在各类网站上的连通性和速度，全局模式可以避免规则分流带来的干扰变量。
注意：全局模式下，境内网站的访问也会经过代理节点，这通常意味着额外的延迟增加，以及部分依赖本机真实 IP 归属地的服务（如地图定位、部分支付验证）可能出现异常。长期使用全局模式并非节省流量或提升速度的做法，建议只在排查问题或有明确出口一致性需求时短暂启用。
另外需要留意，全局模式下选择的“当前节点”是单一节点或单一代理组，如果该节点本身不稳定，所有流量会同时受到影响，风险相比规则模式下的分散分流更集中。
切换模式后需要注意的缓存与连接状态问题
模式切换看似只是客户端界面上的一个开关，但底层涉及连接表、DNS 缓存与内核状态的重建，处理不当会出现“切换后网页打不开”“提示已连接但实际不通”等现象。以下是几个需要留意的细节：
- 已建立的长连接不会自动重新分流：模式切换前已经打开的 TCP 连接（例如正在播放的视频流、正在下载的文件）通常会沿用原来的出站路径，直到该连接自然结束。如果需要立即生效，建议手动断开对应应用的连接或重启应用。
- DNS 缓存可能导致域名仍解析到旧结果：规则模式下大量分流依赖 GEOIP 判断，而 GEOIP 判断的前提是先完成域名解析。如果客户端或系统层面的 DNS 缓存里保留了模式切换前的解析结果，短时间内规则匹配可能仍按旧的 IP 归属地判断。此时可以在客户端里手动清除 DNS 缓存，或等待缓存自然过期。
- 代理组的健康检测状态不会因模式切换而重置：如果某个代理组在规则模式下因为延迟测试失败被标记为不可用，切到全局模式后如果仍选中该代理组，同样会连接失败，这与模式本身无关，需要先确认节点连通性。
- 浏览器与部分应用有自己的连接池：浏览器为了性能会复用已建立的 HTTP/2 或 HTTPS 连接，模式切换后浏览器不一定会立即感知变化，遇到页面加载异常时，先尝试强制刷新或重启浏览器进程，而不是直接判断代理配置出了问题。
建议：切换模式后，优先用一个新开的浏览器标签页访问一个明确的测试地址，观察连接状态卡片里的当前协议与节点信息是否已经更新为预期值，确认无误后再继续其他操作，避免被残留连接的旧状态误导判断。
如何在客户端中快速切换与验证
不同客户端（如 Clash Verge、Mihomo Party、FlClash）在界面呈现上略有差异，但操作路径基本一致：
- 打开客户端主界面，找到“模式”或“运行模式”相关的分段控件，通常直接以“规则 / 全局 / 直连”三个选项呈现。
- 点击对应模式完成切换，多数客户端会在状态栏或连接状态卡片里同步显示当前生效的模式名称，例如连接状态卡片顶部的协议信息中标注
rule或global。 - 切换后打开日志面板，观察最近几条请求命中的具体规则或策略，确认流量走向与预期一致。这一步对排查规则配置是否生效尤其有用。
- 如果只是临时验证节点连通性，验证结束后记得切回规则模式，避免长期处于全局模式带来的延迟增加和出口异常风险。
对于日常使用者，规则模式配合一份维护良好的订阅规则集，基本可以覆盖绝大部分场景，无需频繁手动切换模式；全局模式更多是排查工具和特殊场景下的临时选择；直连模式则适合完全不需要代理时，作为快速关闭代理功能的开关使用。