先分清代理模式与流量接管
Clash 的三种代理模式，决定的是进入内核的连接如何选择出口。规则模式按规则分流，全局模式交给全局策略，直连模式直接连接目标。它们不是三种接管设备流量的方法，也不是三档速度设置。
系统代理、应用内代理与 TUN 则负责把连接送进内核。例如，浏览器使用 127.0.0.1:7890 作为 HTTP 代理时，浏览器的相应请求会进入这个监听端口。没有使用系统代理的应用，可能仍然自行联网；开启全局模式不会自动改变这一点。
三种模式的流量走向对照
| 模式与字段值 | 出口选择方式 | 适合的操作 |
|---|---|---|
规则模式 rule |
按 rules 顺序匹配，采用首个命中规则的目标 |
日常浏览、国内外分流、按域名选择策略 |
全局模式 global |
交给内置 GLOBAL 策略组所选的出口 |
短时排除规则影响、对比节点连通性 |
直连模式 direct |
由内核直接连接目标，不经代理节点转发 | 比较本地网络、排查代理出口与局域网访问 |
这里的“直连”仍然发生在内核处理流程中，不等于退出客户端。DNS、监听端口以及已经启用的流量接管机制仍可能参与连接。三种模式也不会替你补齐节点信息、修复订阅或修改服务器端配置。
规则模式：按顺序匹配，再进入策略组
规则模式适合长期使用。内核从上向下检查 rules，遇到第一条匹配项就使用该规则指定的目标。目标可以是 DIRECT、REJECT、某个代理节点，也可以是配置里已经存在的策略组。
规则目标与策略组选择是两个步骤
假设某条域名规则指向“节点选择”，内核先确定这条连接属于“节点选择”，再根据该组的类型与当前状态决定实际出口。手动选择组使用当前选项，自动测速组则按自身配置选择。规则命中某个组，不代表该组一定转发到远端节点；如果组内选中 DIRECT，最终仍然直连。
下面是用于理解顺序的配置片段，不是完整订阅。“节点选择”必须与现有 proxy-groups 中的名称完全一致，且应检查其他规则是否需要排在它们前面。
mode: rule
rules:
- DOMAIN-SUFFIX,home.arpa,DIRECT
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
- IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
- MATCH,节点选择DOMAIN-SUFFIX根据域名后缀匹配。内核需要获得相应域名信息，不能假定所有纯 IP 连接都能命中域名规则。IP-CIDR匹配目标 IP 网段。这里的三个网段覆盖常见私有 IPv4 地址。no-resolve表示不为了这条 IP 规则额外触发域名解析；已经具有目标 IP 的连接仍可以匹配。MATCH是兜底项，应放在需要优先执行的规则之后。放到最前面会让后面的普通规则失去匹配机会。
网站走错出口时检查什么
打开连接详情，依次核对目标域名或 IP、命中规则、策略链和最终节点。若连接命中 MATCH，说明前面的规则没有接住它；若命中正确的策略组却走了错误节点，应调整组内选择，而不是继续新增同类规则。需要进一步配置时，可查看进阶手册的策略组说明。
全局模式：通过 GLOBAL 暂时绕过分流判断
全局模式把进入内核的连接交给 GLOBAL 策略组，不再使用普通 rules 列表进行出口分流。客户端界面通常会提供全局策略的选择入口，具体名称与位置取决于客户端版本。
切到 global 后，还要确认 GLOBAL 当前选中了什么。它可能选中一个节点、一个策略组，也可能选中 DIRECT。只看“全局模式”四个字，无法判断实际出口；平时规则模式里的“节点选择”也不一定就是此时使用的全局选项。
用全局模式区分规则问题与节点问题
- 记录当前规则模式下打不开的同一个网址，以及连接详情中的命中规则。
- 切换到全局模式，在
GLOBAL中明确选择要测试的节点。 - 关闭该网址对应的旧连接，再重新发起请求，观察新的连接记录。
- 若全局可用、规则不可用，优先检查规则命中结果和策略组选择；若两者都不可用，再检查节点、DNS 与接管链路。
- 测试结束后恢复规则模式，并重新确认日常使用的策略组。
直连模式：排查本地网络，不等于关闭 Clash
直连模式下，内核直接连接目标，而不是通过代理节点中转。它适合回答一个具体问题：同一条请求不经过远端代理出口时，是否能够成功？例如路由器管理页打不开，可以先切换直连模式，重新建立连接，再观察是否恢复。
但直连模式不是“原生网络”的完整还原。开启 TUN 时，相关连接仍可能经过虚拟网卡；启用 mihomo DNS 或 Fake-IP 时，解析与地址映射仍可能由内核处理。只有退出相关接管路径，才是在测试应用完全绕过内核的情况。
分两轮比较，避免混淆原因
- 第一轮：保持系统代理或 TUN 不变，只切换为直连。主要比较是否与代理节点、出口选择有关。
- 第二轮：按客户端提供的开关关闭系统代理与 TUN，并检查浏览器是否另设代理。主要比较是否与内核接管、DNS 或应用代理有关。
如果第一轮仍然失败，第二轮却正常，就不能直接得出“本地网络坏了”的结论。应继续检查 DNS 配置、虚拟网卡路由、代理监听端口和防火墙。反过来，直连失败但代理成功，也可能是本地网络到目标服务的路径差异，不代表规则模式必然有误。
模式在哪里切换，配置字段怎么写
桌面客户端常见入口是主界面的“代理模式”或托盘菜单中的“规则／全局／直连”。手机端可能放在首页模式选项或侧边菜单中。各客户端布局不同，不宜把某一个客户端的菜单路径当成所有 Clash 客户端的通用路径。
核对时以实际选中的模式和内核运行状态为准。若直接维护 YAML，模式字段位于顶层，不放进 dns、tun 或 proxy-groups 内：
# 顶层字段；可选值为 rule、global、direct
mode: rule修改文件后通常需要重新加载配置。部分客户端会把界面设置、覆写配置或运行时状态合并到最终配置中，所以“文件里写着 rule”和“内核正在使用 rule”未必始终一致。订阅更新后也应确认本地修改是否仍被保留。
端口与模式是独立设置
mixed-port: 7890 表示在 7890 端口提供混合 HTTP 与 SOCKS 代理监听，与 mode 不是同一个字段。若浏览器仍连接旧的 7890，而实际监听已经改成 7891，切换任何模式都无法解决端口不一致。应同步修改应用代理或系统代理中的地址与端口。
按使用场景选择，避免反复试开关
日常浏览：规则模式
国内服务、局域网设备与需要代理的站点同时使用时，优先采用规则模式。先把规则顺序与策略组对应关系理顺，再根据实际连接记录补充规则。无需为了一个站点长期把所有进入内核的流量交给同一远端出口。
临时验证节点：全局模式
需要排除规则影响时，使用全局模式并明确选择节点。尽量固定目标网址、接管方式和 DNS 条件，只改变一个变量。节点延迟测试成功只代表测试目标在当时可达，不能证明浏览器访问的另一个域名也一定成功。
路由器、NAS 与本地服务调试：直连对比后回到规则
访问 192.168.1.1 或本地开发服务时，可用直连模式做短时对比。若确认是全局代理出口导致失败，长期方案通常是恢复规则模式，并为实际局域网网段设置直连规则。TUN 的路由排除属于另一层配置，不应与规则中的 DIRECT 混为一谈。
不要直接把所有私有地址都视为可访问资源：公司 VPN、远程办公网络和本地网络可能使用重叠网段。遇到这类情况，需要结合路由表与公司网络要求确定出口，而不是机械套用通用片段。
切换后没有变化：检查旧连接、DNS 与接管范围
- 先找连接记录。如果没有对应的新连接，确认应用是否使用系统代理，或者它的流量是否被 TUN 接管。系统代理通常不能覆盖所有应用及所有 UDP 流量。
- 再看实际出口。确认当前模式、命中规则和策略链。全局模式检查
GLOBAL，规则模式检查命中的目标组。 - 重建测试连接。已有下载、长连接或浏览器连接池不一定随模式切换迁移。可在客户端关闭对应连接，再重新访问；必要时完全退出并重新打开浏览器。
- 单独处理 DNS。域名解析失败不等于规则错误。检查 DNS 查询是否正常、解析结果是否符合预期；切换模式并不必然清除应用缓存或替换 DNS 上游。
- 最后确认运行配置。检查订阅是否成功加载、覆写是否生效，以及界面模式是否覆盖了 YAML 中的设置。
选择模式的核心是控制变量：日常使用让规则决定去向；排查时用全局固定代理出口，再用直连做对照。每次切换后检查一条新连接的实际路径，比反复切换多个开关更容易定位问题。首次配置系统代理或 TUN，可继续阅读使用指南中的代理模式说明。