外观
规则模式、全局模式与直连模式：何时用哪一种
Clash 系客户端的三种出站模式分别回答三个不同的问题：规则模式回答“每条连接该走哪里”，全局模式回答“先让所有流量走同一个出口看看”，直连模式回答“暂时让代理完全不介入”。
日常使用以规则模式为主，全局模式用于排错和临时对照，直连模式用于确认问题是否出在代理链路之外。这三种模式只决定出站选择，不决定接管方式，后者由系统代理或 TUN 负责。
核心结论与适用条件
- 如果你已经导入订阅、策略组指向有效节点，并且希望国内站点走直连、境外站点走代理，那么日常应停留在规则模式。规则模式依赖规则列表的质量，规则列表来自订阅或你自己维护的规则集，质量不由模式本身决定。
- 如果你怀疑某个网站打不开是规则没有命中正确分组，那么临时切到全局模式可以排除规则的影响：全局模式下所有连接都被送往同一个策略组，规则列表不再参与决策。若切换后正常，问题在规则；若依旧不通，问题在节点、DNS 或接管层。
- 如果你想确认“是不是代理软件导致了网络异常”，那么切到直连模式。直连模式下客户端仍在运行、端口仍在监听，但所有连接都不经过代理节点，其效果接近于不使用代理。
- 如果某些应用根本没有出现在连接面板里，那么问题通常不是出站模式，而是接管层没有覆盖该应用，需要先阅读TUN 模式与系统代理的区别再决定是否切换接管方式。
- 如果你使用的内核较旧，部分规则类型或策略组类型可能不被识别，这与协议覆盖一样取决于内核家族，详见mihomo 内核与原版 Clash 内核的差异。
以上结论成立的前提是：客户端从官方发布渠道获取、订阅格式与客户端匹配、本机同一时间只有一个接管者。本文不针对任何软件的具体版本、不写菜单路径细节，只讲三种模式的机制、使用时机与排错顺序；各界面上的开关位置请在客户端设置中找到出站模式相关选项。想先回顾桌面端整体选择逻辑，可以回到桌面客户端专题总览。
先分清三个层次：接管、出站、节点
很多使用上的困惑来自把三件事混为一谈。可以把一条连接从应用发出到到达目标，拆成三个层次。
第一层是接管：应用发出的数据包有没有被代理客户端截获。系统代理方式下，只有遵守系统代理设置的应用才会把请求交给客户端本地端口；TUN 方式下，客户端创建虚拟网卡并调整路由，几乎所有流量都会先经过它。接管层决定的是“客户端能不能看到这条连接”。
第二层是出站：客户端看到连接之后，决定它交给谁。这正是规则、全局、直连三种模式的职责范围。规则模式逐条匹配规则，全局模式直接指定一个出口，直连模式直接放行。
第三层是节点：被选中的策略组里，最终使用哪一个具体节点，以及这个节点与机场服务器的连接是否可用。节点选择可能由手动选择、延迟测试自动选择或故障转移组决定。
把这三层分开后，排错顺序就清楚了：连接面板里没有记录，先查第一层；记录里显示命中了某个规则但目标站点仍不可用，查第二层的规则与第三层的节点；记录里显示直连但你希望走代理，查规则命中结果。出站模式只在第二层起作用，切换模式不会修复接管层的问题，也不会让一个失效的节点恢复可用。
三种模式的技术参数对照
下表概括三种模式的行为差异。表中不包含任何速度或延迟数值，“统计口径”列说明该行属于机制描述还是经验归纳。无法用通用资料确定的内容写“待核实”或 Not Tested。
| 指标 | 规则模式 | 全局模式 | 直连模式 | 单位 | 统计口径 | 数据来源 | 更新时间 |
|---|---|---|---|---|---|---|---|
| 出站决策依据 | 自上而下匹配规则列表 | 固定指向全局策略组 | 不经过任何代理节点 | — | 机制描述 | 通用技术资料 | 2026-10-18 |
| 规则列表是否参与 | 参与 | 不参与 | 不参与 | — | 机制描述 | 通用技术资料 | 2026-10-18 |
| 是否使用代理节点 | 部分连接使用 | 全部连接使用 | 不使用 | — | 机制描述 | 通用技术资料 | 2026-10-18 |
| 国内站点路径 | 通常命中直连规则 | 也会绕经代理节点 | 直连 | — | 常见默认行为 | 通用技术资料 | 2026-10-18 |
| 对节点流量消耗 | 取决于规则命中比例 | 所有流量都消耗 | 无 | — | 机制推导 | 通用技术资料 | 2026-10-18 |
| 典型用途 | 日常使用 | 排错、临时对照 | 排除代理影响 | — | 经验归纳 | 通用技术资料 | 2026-10-18 |
| 常见误用 | 规则过期、分组指向失效节点 | 长期开启导致国内访问变慢 | 忘记切回导致代理失效 | — | 经验归纳 | 通用技术资料 | 2026-10-18 |
| 对机场计费流量的影响 | 待核实（取决于套餐口径） | 待核实 | 无节点流量 | — | 品牌资料 | Vendor Data，待核实 | 2026-10-18 |
| 实测稳定性 | Not Tested | Not Tested | Not Tested | — | 本站测试状态 | 本站 | 2026-10-18 |
表中“对节点流量消耗”一行是机制层面的推导：全局模式让所有连接都走节点，因此即使访问国内站点也会消耗机场套餐流量。这一点对小流量套餐的用户尤其重要，后文会在风险部分展开。
规则模式：日常使用的主模式
规则列表是如何被匹配的
规则模式下，客户端维护一份有序的规则列表，每条规则由类型、匹配内容和目标策略组三部分构成。常见的类型包括按域名完整匹配、按域名后缀匹配、按域名关键字匹配、按 IP 段匹配、按地理位置库匹配、按进程名匹配，以及引用一个远程规则集合。匹配过程自上而下，第一条命中的规则决定这条连接的去向，后面的规则不再检查。列表末尾通常有一条兜底规则，把未命中的连接指向某个默认策略组。
这个顺序带来的后果是：规则的先后位置本身就是配置的一部分，范围很宽的规则放在前面会遮蔽后面更具体的规则；同时，兜底规则决定了“未知流量”的命运：兜底指向代理，则未知流量默认走代理；兜底指向直连，则未知流量默认直连。两种选择没有对错，取决于你更担心“该走代理的没走”还是“不必走代理的走了”。
域名规则与 IP 规则的差别
域名类规则在请求发起时就能判断，因为客户端可以从系统代理请求或 TUN 嗅探到的信息中取得域名。IP 类规则则需要知道目标 IP，这往往意味着先做一次 DNS 解析。如果规则列表里 IP 规则很多且放在较前位置，客户端可能为了匹配规则而提前解析域名，解析结果又会受 DNS 配置影响。因此许多配置会给 IP 规则加上“不解析”的修饰，让它们只在目标已经是 IP 时才生效，从而避免不必要的 DNS 查询。具体的修饰写法属于配置文件的语法细节，可以在Clash 配置文件的三段结构一文中对照阅读。
规则集与订阅内置规则
多数机场的 Clash 格式订阅会在配置中附带一份规则列表，也有用户习惯把规则集拆成独立的远程文件，由客户端定期拉取。两种方式的区别在于更新责任：订阅内置规则随订阅更新而变化，远程规则集由你自己配置的更新周期决定。如果订阅更新失败，内置规则就停留在旧版本，这是订阅更新失败排查需要关注的另一面。
规则质量问题常见于三类情形：规则过时，新出现的服务域名没有被收录，会落到兜底规则；规则过宽，把本应直连的内网或本地服务也送进了代理；规则冲突，同一域名被前后两条规则指向不同分组，实际只有靠前的生效。排查时看连接面板中每条连接显示的命中规则，比猜测更可靠。
策略组如何影响规则模式的结果
规则的目标不是节点，而是策略组。策略组可以是手动选择型、按延迟自动选择型、故障转移型、负载均衡型，也可以是引用其他策略组的嵌套结构。规则模式下“某类流量该走哪里”因此被拆成两步：规则把流量分给一个策略组，策略组再决定使用哪个节点。所以出现“规则命中正确但仍然不通”时，应该检查对应策略组当前选中的节点是否有效，而不是反复修改规则。关于用故障转移组保证备用订阅可用，可参考故障转移策略组的搭建思路。
为 AI 工具与开发工具单独分流
规则模式的价值在于可以给不同场景指定不同出口。例如可以为某些 AI 工具的域名单独建一个策略组，使其固定使用某类线路；也可以为开发工具的域名设置独立规则，避免它们被兜底规则带到不合适的出口。品牌资料显示覆盖相关使用场景，具体可用性、解锁状态及节点表现可能随 IP、地区和平台策略变化，建议以最新实际测试结果为准。关于把这类分流写成规则的思路，可以阅读AI 场景的分流规则思路。
全局模式：排错与对照，不适合长期开启
全局模式到底做了什么
全局模式下，客户端忽略规则列表，把所有连接交给一个被称为全局的策略组，这个策略组里列出了所有可选节点或策略组，你选中哪个，全部流量就去哪个。它的优点是行为简单、可预测：既然规则不再参与，也就没有“规则命中错了”这种变量。它的代价同样明确：国内站点、局域网服务、软件更新服务都会绕道代理节点。
适合开启全局模式的三种时机
第一种时机是怀疑规则问题。某个站点打不开，先切到全局模式再访问：能打开，说明规则没有把它分到正确的出口；仍打不开，说明规则之外的某个环节有问题。这一步把排错范围缩小了一半。
第二种时机是对比不同节点。想判断某个节点是否可用，全局模式下选中该节点、访问目标站点，路径最短，没有规则和策略组的干扰。需要说明的是，本站未提供任何节点的速度测试数据，任何节点表现都应以你自己的实际测试为准。
第三种时机是首次导入订阅后的快速验证。刚导入订阅时，规则可能尚未完整拉取，用全局模式先确认“订阅里至少有一个节点能连通”，再回到规则模式处理分流细节，可以把“订阅是否有效”和“分流是否合理”分开验证。
长期使用全局模式的问题
长期使用全局模式会出现几类副作用。国内站点的访问路径变长，且部分国内服务会因为访问来源地区变化触发额外验证；套餐流量被不必要地消耗；局域网设备、打印机、NAS 等内网服务可能因被送往代理而无法访问，除非客户端对私有地址段另有直连处理；一些依赖地理位置判断的应用可能出现异常。这些现象并不意味着节点故障，只是全局模式的预期行为。
全局模式与 DNS 的关系
全局模式并不自动解决 DNS 问题。如果 DNS 解析仍由本机直接完成，解析结果可能与代理出口所在地区不一致；如果客户端启用了自身的 DNS 处理，则解析行为取决于其 DNS 配置。关于 DNS 泄露的风险与加密 DNS 的原理，背景知识见协议与安全机制专题。排错时应记住：全局模式只统一出站选择，不统一 DNS 行为。
直连模式：把代理从问题里剔除
直连模式的用途常被低估。它的核心价值是提供一个对照组：当网络异常时，切到直连模式，如果异常依旧，说明问题在本地网络、运营商线路、路由器或目标站点本身；如果异常消失，说明问题和代理链路有关，再往下追查接管层、规则、节点。
直连模式还有几个实际用途。其一，临时访问只允许本地网络来源的服务，比如某些内部系统或需要本地 IP 验证的网站，不必退出客户端。其二，在需要确认某个国内服务是否被代理影响时，直连模式提供干净的基线。其三，当机场订阅暂时失效而你又需要正常上网时，可以先切到直连模式保证基本网络，再慢慢排查订阅问题。
需要提醒的是，直连模式下客户端的系统代理或 TUN 通常仍保持开启，只是出站不走节点。这意味着连接仍经过客户端，客户端崩溃或端口被占用仍会影响网络。如果要彻底排除客户端的影响，应关闭系统代理开关或退出客户端，再测试网络。
决策树：该用哪一种模式
Decision Path
Clash 出站模式的选择路径
text
当前遇到的是什么情况？
├─ 日常上网，一切按预期
│ └─ 规则模式
├─ 某个站点打不开
│ ├─ 先看连接面板：该连接是否出现？
│ │ ├─ 没有出现 → 接管层问题，检查系统代理或 TUN
│ │ └─ 出现了 → 记录命中的规则与策略组
│ ├─ 临时切到全局模式再试
│ │ ├─ 能打开 → 规则或分组问题，回规则模式修正规则
│ │ └─ 仍打不开 → 节点、DNS 或目标站点问题
│ └─ 换一个节点再试，仍不通 → 切直连模式验证本地网络
├─ 怀疑代理软件影响了整体网络
│ └─ 直连模式；异常仍在 → 与代理无关
├─ 刚导入订阅，想先确认订阅有效
│ └─ 全局模式选一个节点验证，再回规则模式
└─ 需要访问局域网设备
└─ 规则模式 + 私有地址段直连规则，不使用全局模式这棵决策树的核心是顺序：先接管，再出站，最后节点。
知识图谱：Clash 出站模式的概念关系
实体定义
出站模式是 Clash 系内核提供的全局开关，决定内核处理每条已被接管的连接时采用何种决策方式。它不是节点，也不是协议，而是策略层面的入口。规则模式、全局模式、直连模式是其三个取值。
相关概念
上位概念是桌面代理客户端的整体工作流程，同级概念包括系统代理与 TUN 两种接管方式；下位概念包括规则、规则集、策略组、节点；依赖概念包括 DNS 处理、订阅更新和内核对规则类型的支持。当客户端从 Clash 系换成 sing-box 系时，出站决策的概念依然存在，只是术语和配置结构不同，对照阅读见sing-box 桌面端的配置结构。
技术参数
可观察的参数包括：当前出站模式、当前被选中的全局或策略组节点、连接面板中每条连接的命中规则、规则列表的更新时间、订阅最近一次更新时间。这些参数都来自客户端界面，不需要额外工具。需要在文章中强调的是，本站没有任何节点的实测速度，“Not Tested”是所有品牌当前的统一状态。
适用场景
规则模式适用于长期日常使用；全局模式适用于排错、临时对照与新订阅验证；直连模式适用于排除代理影响与临时访问本地网络限定的服务。三种模式都不适用于“解决接管层缺失”这一类问题。
对比依据
比较三种模式时，依据应是机制而不是体感：规则列表是否参与、是否使用代理节点、是否消耗套餐流量、对局域网访问的影响。体感速度受节点、时段、本地网络共同影响，无法用来判断模式本身的优劣。
常见问题指向
关于“为什么我切了模式没效果”，指向接管层与 TUN；关于“为什么订阅更新后规则变了”，指向订阅更新机制；关于“为什么全局模式下国内网站变慢”，指向路径与流量消耗。后文常见问题部分对这些点逐一回应。
与机场品牌的方案关联
出站模式本身与具体机场无关，但机场资料会影响你如何使用它。第一，订阅格式：品牌若提供 Clash 格式订阅，通常已经附带规则与策略组，导入后即可在规则模式下使用；若仅提供节点链接，则需要自行建立规则。第二，协议：brands.json 中大多数品牌标注 VLESS，要使用这类节点，客户端内核必须具备对应协议能力，这是选择内核的前置条件。第三，流量口径：套餐流量的计算方式在资料中为待核实，因此在全局模式下是否会多消耗流量，应以官网说明为准。
下面的快照是一个“自研客户端+第三方订阅导入”且标注 VLESS 的样本，用来说明品牌资料中与客户端选择直接相关的字段。字段状态为 Vendor Data，本页字段对照不构成推荐。
Infrastructure Service Snapshot
U1S1 /u1s1
- 入门价格
- 20 元/月
- 价格类型
- 月付 月付价
- 入门流量
- 120GB
- 线路
- IEPL专线
- 协议
- VLESS
- 运营年份
- 2023
- 客户端
- 自研客户端+第三方订阅导入
- 支付方式
- 支付宝 / 微信 / USDT
如果想按客户端方式或协议筛选品牌，可以进入品牌库逐项核对；如果还没有决定选哪个品牌，先回到选型清单按步骤判断。
| 方案关联项 | 对出站模式的影响 | 资料来源 | 状态 |
|---|---|---|---|
| Clash 格式订阅 | 通常自带规则与策略组，可直接用规则模式 | 品牌资料与通用技术资料 | Vendor Data |
| 仅提供节点链接 | 需自行创建规则，或先用全局模式验证 | 通用技术资料 | Vendor Data |
| 标注 VLESS | 需要 mihomo 等新内核，旧内核无法识别节点 | 通用技术资料 | Vendor Data |
| 套餐流量口径 | 全局模式是否更耗流量，以官网说明为准 | 品牌资料 | 待核实 |
| 实测节点表现 | 暂无统一结果 | 本站 | Not Tested |
常见误区与排错顺序
误区一：把全局模式当成更强的模式
有人认为全局模式“更彻底”，所以遇到问题就切全局并一直留着。实际上，全局模式只是放弃了分流。它在排错时有价值，长期使用则放大了国内站点绕路和流量消耗的副作用。
误区二：以为直连模式等于关闭代理
直连模式只是出站不走节点，接管层仍在。如果问题来自系统代理残留或虚拟网卡路由，直连模式下依然会出现。彻底关闭要关闭接管层。
误区三：规则模式下改了规则却没有生效
可能的原因有：编辑的是订阅生成的临时配置而非自己的覆写文件，下一次订阅更新后被覆盖；规则放在了被更靠前的宽泛规则遮蔽的位置；客户端没有重新加载配置。排查时应先确认修改是否保存在受保护的位置，再确认配置已被重新载入。
误区四：认为模式切换后现有连接立即改道
已建立的长连接不一定会立刻改变出口，许多客户端提供“关闭现有连接”的功能，切换模式后手动关闭旧连接，新连接才会按新模式决策。表现为切换后某个下载仍沿用旧路径，并非模式未生效。
建议遵循的排错顺序
先看接管：连接面板是否出现该连接。再看模式：当前是否在规则模式。再看规则：该连接命中了哪条规则、指向哪个分组。再看分组：当前选中的节点是否有效。再看 DNS：解析结果是否合理。最后才考虑目标站点自身的问题或本地网络。这个顺序与前文三层结构一致，每一步只回答一个问题。
优点、限制与风险提示
优点
- 三种模式语义清晰，切换成本低，适合作为排错时的“二分法”工具。
- 规则模式可以把不同场景的流量分到不同出口，兼顾访问效率与套餐流量消耗。
- 直连模式提供无代理基线，帮助区分代理问题与网络问题。
- 全局模式在验证新订阅或对比节点时路径最短，变量最少。
限制
- 出站模式不能解决接管层缺失的问题，部分应用不走系统代理时需要借助 TUN。
- 规则质量由订阅或规则集决定，模式本身无法弥补过期或错误的规则。
- 不同客户端对模式的呈现方式略有差异，界面术语可能不同，本文不针对任何版本的界面作断言。
- 本站没有任何节点的实测数据，三种模式下的实际访问表现需要自行测试。
风险提示
- 全局模式长期开启会消耗不必要的套餐流量，小流量套餐用户尤其要注意，套餐计量口径以官网为准。
- 全局或规则不当可能把内网或本地服务送到代理，造成隐私或访问问题。
- 切换到直连模式后忘记切回，会让需要代理的应用失去代理，并可能误以为是节点故障。
- 修改规则时务必保留原配置备份，避免误改后无法还原。
- 使用代理服务须遵守所在地区适用的法律法规与目标平台的服务条款，本文仅讨论技术原理与选型。
常见问题
Clash 的三种出站模式分别适合什么情况？
规则模式适合日常使用，由规则列表决定每条连接走代理还是直连；全局模式适合排错和临时对照，所有连接统一走同一个出口；直连模式适合排除代理影响，所有连接都不经过节点。三种模式只决定出站选择，接管方式由系统代理或 TUN 决定。
为什么切换到全局模式后国内网站变慢了？
因为全局模式忽略规则列表，国内站点也会绕经代理节点，路径变长，并且可能因访问来源变化触发额外验证。这是该模式的预期行为而不一定是节点故障，日常使用应回到规则模式并确认国内站点命中直连规则。
直连模式是不是等于关闭了代理软件？
不等于。直连模式只是让出站不经过代理节点，系统代理或 TUN 通常仍保持开启，连接仍然经过客户端。如果要彻底排除客户端影响，应关闭系统代理开关或退出客户端后再测试。
规则模式下某个网站打不开，应该怎么判断是规则问题还是节点问题？
先在连接面板确认该连接是否出现以及命中了哪条规则，再临时切换到全局模式访问。能打开说明规则分流有问题，仍打不开则应检查当前节点、DNS 和接管层。每次只改变一个变量，才能把结论归因到某一层。
切换出站模式后，已经建立的连接会立刻改道吗？
不一定。已建立的长连接可能沿用原来的出口，新连接才会按新模式决策。许多客户端提供关闭现有连接的功能，切换模式后手动关闭旧连接，可以让后续请求按新模式重新选择路径。
全局模式会不会多消耗机场的套餐流量？
从机制上看会，因为全局模式下所有连接都经过代理节点，访问国内站点也会产生节点流量。但套餐的具体计量口径在品牌资料中为待核实，应以官网说明为准，小流量套餐用户更应避免长期开启全局模式。
修改了规则却没有生效是什么原因？
常见原因有三个：修改的是订阅生成的临时配置，下一次订阅更新后被覆盖；新规则被位置更靠前的宽泛规则遮蔽；客户端没有重新加载配置。应先确认修改保存在不会被覆盖的位置，再重新载入配置并在连接面板核对命中规则。
访问局域网设备时应该使用哪种模式？
应使用规则模式并保证私有地址段有直连规则，不建议使用全局模式。全局模式会把局域网请求也送往代理节点，导致无法访问路由器、NAS 或打印机等本地设备。
使用 VLESS 节点时出站模式有什么特别要求吗？
出站模式本身没有特别要求，但客户端内核必须支持该协议，否则节点在导入阶段就会被忽略或报错，三种模式下都无法使用。内核的选择见 mihomo 内核相关文章，协议原理见协议专题。
订阅更新失败会影响规则模式吗？
会。订阅内置的规则列表随订阅更新，更新失败时规则会停留在旧版本，新出现的服务域名可能落入兜底规则。节点列表也不会同步，品牌调整节点后可能突然失效，应尽快排查订阅更新问题。
下一步与同集群文章
读完本文，可以按需求继续阅读：想了解接管方式的差别，去看TUN 模式与系统代理；想了解内核选择与协议支持，去看mihomo 内核说明；想读懂配置文件里的规则段，去看配置文件三段结构；想对照图形前端的导入流程，去看Clash Verge Rev 的安装与订阅导入；手机端的类似概念，可从移动端客户端专题进入。关于机场线路层面的路由知识，可参考线路与路由专题，而对不同品牌与方案的整体对照，请进入对比中心，涉及使用风险的部分则可查阅风险专题。
Cluster · clash
Clash 系客户端
- Clash Verge Rev 安装与订阅导入完整步骤如何安装 Clash Verge Rev 并导入订阅？
- mihomo（Clash Meta）内核：与原版 Clash 的差异mihomo 内核和原版 Clash 有什么区别？
- 规则模式、全局模式与直连模式：何时用哪一种Clash 的三种出站模式分别适合什么情况？
- TUN 模式与系统代理：区别、开启方法与常见问题TUN 模式和系统代理有什么区别，什么时候需要开 TUN？
- 读懂 Clash 配置文件：proxies、proxy-groups 与 rulesClash 配置文件的主要结构是什么？
- 订阅更新失败排查：网络、格式与证书问题订阅更新失败时应该怎么排查？
- macOS 上使用 Clash 类客户端：权限与系统设置在 macOS 上使用 Clash 类客户端需要授予哪些权限？
下方卡片指向品牌库，品牌详情页中的注册链接为各品牌官方注册或推广链接；本页资料部分只整理公开资料，不构成推荐，也不承诺任何平台的可用性；星岛梦第一、光速云第二为本站推荐排名，非测试结果。