小火箭全局模式与直连模式:Global Routing 的 Config / Proxy / Direct 怎么选

说明 Global Routing 三种姿态各自如何处理流量,日常为何推荐 Config,以及临时切到 Proxy 或 Direct 排查问题的做法。

本文速览

Shadowrocket(小火箭)的 Global Routing 决定连接采用规则分流、统一代理还是统一直连。本文适合已经有自己的订阅或配置、但不确定模式该怎么选的用户:先辨认 Config / Proxy / Direct 的作用,再用同一目标做对照测试,最后恢复日常设置。模式切换不是更换协议,也不能代替有效的服务器配置。

Global Routing 控制什么,不控制什么

在 Home → Global Routing 中选择的姿态,决定进入 Shadowrocket 处理范围的连接怎样选择出口。Config 依据当前配置中的规则处理;Proxy 将这些连接统一交给当前代理选择;Direct 使用直连出口。这里的“全局”描述路由决策,不能理解成设备上每一种系统通信都必然经过同一条路径。

路由姿态与服务器协议是两个层面。已有服务器使用 Shadowsocks、VMess、VLESS、Trojan、Hysteria2 或 WireGuard,并不改变 Config / Proxy / Direct 的基本含义。切换到 Proxy 不会自动修复服务器地址、端口或认证字段,切回 Config 也不会自动生成适合自己的规则。

3 种
本文对照的姿态:Config / Proxy / Direct
4 类
示例规则:DOMAIN-SUFFIX / GEOIP / IP-CIDR / FINAL
2 层
姿态入口:Home → Global Routing

Config / Proxy / Direct 的选择依据

日常优先选择 Config 的前提,是已经启用了理解其作用的配置。规则分流可以让不同目标采用不同策略,而不是把所有目标强制交给同一个出口。规则可以指定 DIRECT、代理策略或其他处理方式;没有命中前面的规则时,由 FINAL 决定去向,不能一概说成“其余全部直连”。

Config

推荐

按照当前配置的规则与策略选择出口。需要同时核对规则顺序、策略指向和 FINAL;仅在 Config 出现的失败,可能来自规则或配置关联设置。

适合:已有可理解的规则配置,需要长期分流的日常使用。

Proxy

对进入处理范围的连接统一采用当前代理选择,不按普通分流规则逐项决定出口。当前服务器或策略不可用时,改成 Proxy 仍可能失败。

适合:临时验证代理出口,或对照排查 Config 的规则命中。

Direct

对进入处理范围的连接采用直连出口。它改变的是路由方式,不等同于关闭连接开关或移除系统 VPN 配置,也不能突破当前网络自身的访问限制。

适合:对照检查当前网络直连是否可用,或临时验证本地目标。

Proxy 并不天然比 Config 更快,Direct 也不保证延迟更低。速度还取决于当前网络、目标服务、所选出口、DNS 结果及连接复用等因素。如果没有具体故障,不必为了“全局”这个名称而切换姿态;先让路由符合自己的使用目的。

按固定顺序完成一次模式切换

开始前记录当前姿态、所选服务器或策略,以及 Config 中当前使用的配置。用户应已有自己的服务商与订阅;如果 Home 中尚无可用服务器,先按使用教程导入已有资料,再进行以下对照。一次只改变 Global Routing,避免把订阅更新、服务器切换和规则修改混在同一次测试里。

  1. 记录原设置

    在 Home 记录当前服务器或策略,再进入 Config 确认当前使用的配置。记下原来的 Global Routing 姿态,测试结束需要恢复。

  2. 打开模式项

    返回 Home → Global Routing。先选 Config,连接后打开一个自己有权访问的固定目标,记录能否加载及连接记录中的处理结果。

  3. 对照 Proxy

    在 Home → Global Routing 选择 Proxy,保持服务器和网络不变。重新发起到相同目标的连接,观察它是否改用代理出口,以及失败是否仍存在。

  4. 对照 Direct

    在 Home → Global Routing 选择 Direct,再测试相同目标。只记录当前网络下的直连结果,不将一次成功或失败推广为所有目标都相同。

  5. 恢复原设置

    回到 Home → Global Routing 恢复原姿态,通常是 Config。重新发起连接确认生效;如果发现配置问题,另行修改并测试,不长期保留临时排查状态。

Config 为什么走错出口:从规则顺序检查

Config 的核心是规则匹配。通常按配置中的顺序检查,命中相应规则后采用其指定策略,因此更具体的例外需要放在可能覆盖它的宽泛规则之前。下面只是用于阅读语法的规则片段,不是完整配置,也不是建议直接覆盖当前文件的成品方案。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

如果 Proxy 可以访问而 Config 失败,先查新连接命中了哪条规则,再核对该规则的策略。目标网页可能同时请求多个域名,首页域名走代理不代表图片、登录接口和其他资源也走同一出口。应根据实际连接记录检查相关域名,而不是只添加一条网页地址后就认定分流已经完整。

订阅更新与配置更新也不是一回事:更新已有订阅主要改变服务器列表及其参数,不应据此推断 Config 中的规则已经同步改变。在 Config 检查当前配置是否确实被选用,且规则引用的策略仍能找到可用服务器。更多规则说明可查阅Rules 功能说明。

用对照结果定位问题,不直接下结论

下面的现象是判读测试结果的方法,不是对某个网络的实测报告。比较时必须使用同一目标、同一网络和同一个代理选择,并查看新连接;如果期间从 Wi-Fi 切到蜂窝网络,或换了服务器,结果就不再是单纯的模式对照。

观察结果优先检查下一步
Proxy 成功,Config 失败 规则命中、策略指向、当前配置及配置关联的 DNS 设置 查看失败连接的实际处理结果,修正对应配置后重新测试。
Direct 成功,Proxy 失败 代理出口连通性、服务器字段、认证及当前策略选择 核对已有服务资料,保持网络不变测试该服务器。
Proxy 成功,Direct 失败 当前网络到目标的直连路径及 DNS 结果 确认是否只影响特定目标,不把结果理解为全网必须使用 Proxy。
三种姿态均失败 基础网络、目标服务状态、DNS、连接授权与测试方式 先验证其他目标是否正常,再逐项排查,避免反复切换模式。

服务器测试的延迟读数不能代替真实请求。显示一个延迟值,只能说明相应测试方式取得了响应,不代表目标网页的 DNS、认证、数据传输或所有资源都已正常。反过来,某次测试超时也不必然说明所有应用流量都无法通过,应结合实际连接记录判断。

On Demand 与路由姿态分别检查

Settings → On Demand 管理按条件触发连接的行为,Global Routing 管理连接建立后怎样选择出口。二者不能互相替代:打开 On Demand 不会自动把所有目标设为代理,选择 Direct 也不等于取消按需连接。排查“为什么又连上了”时,应检查触发条件,而不是只反复修改路由姿态。

区分连接触发与出口选择

连接是否触发
  • 入口:Settings → On Demand。
  • 检查已启用的触发条件及当前网络是否满足条件。
  • 手动对照测试期间,记录 On Demand 原设置,避免自动重连影响判断。
连接走哪条路
  • 入口:Home → Global Routing。
  • 用 Config / Proxy / Direct 对照出口行为。
  • Config 还需核对规则与策略;使用 Scene 时另查场景条件。

先确认连接为什么建立,再确认新连接采用什么出口;测试结束后恢复路由姿态与按需连接设置。

如果需要验证完全未通过 Shadowrocket 的网络状态,应关闭连接并确认系统连接状态;若启用了 On Demand,还需确认它没有再次触发连接。这与选择 Direct 的测试目的不同:前者验证未连接时的环境,后者验证 Shadowrocket 连接状态下的直连处理。

日常使用与恢复检查

完成排查后,保留能够解释其行为的配置。对多数需要规则分流的日常场景,使用 Config 并维护规则,比长期停留在用于对照的 Proxy 或 Direct 更便于定位问题。但如果自己的需求本来就是统一代理或统一直连,也可以选择对应姿态,关键是理解出口变化及其影响。

Shadowrocket 是在 App Store 获取的闭源商业应用,以 iPhone 与 iPad 使用为主。正版核对应检查开发者 Shadow Launch Technology Limited 与应用 ID 932747118;应用一次性买断不等于线路套餐,连接所需的已有订阅或配置需要用户自行准备。系统要求与通用购买适用性以 App Store 页面标注为准。

App Store 正版核对购买与恢复说明