Shadowrocket Global Routing 怎么选:Config、Proxy、Direct 三种姿态区别

Global Routing 有 Config、Proxy、Direct 三种姿态。本文说明每种姿态下流量怎么走、分别适合什么场景,以及日常使用时选哪一种。

本文速览

已有自己的服务商与订阅、希望区分分流和全局代理的用户,可以先记住:Config 按当前配置决定去向,Proxy 将受接管的普通连接交给代理策略,Direct 让这些连接直连。日常优先使用经过核对的 Config;排查时固定服务器与测试目标,只改变 Global Routing,再检查新连接的实际处理结果。

先区分 Global Routing、服务器与连接开关

Global Routing 决定的是流量处理方式,不是服务器地址,也不是连接开关。选择 Proxy 不等于已经建立可用连接,选择 Config 也不等于应用已经装入适合当前网络的规则。只有把配置、服务器和系统连接状态分开检查,才能避免把不同层的问题混在一起。

在 Shadowrocket 中,Home 用于查看服务器和连接状态,并进入 Global Routing;Config 用于管理配置文件。这里有两个同名的 Config:一个是配置文件管理位置,一个是 Global Routing 中按配置处理流量的姿态。切换姿态不会自动替用户编写规则,也不会修复失效的服务器信息。

3 项
本文比较:Config / Proxy / Direct
2 处
Home 查看路由姿态,Config 管理配置文件
1 次
每轮排查只改变一个变量,再发起新连接

如果 Global Routing 列表中还显示 Scene,应将其视为按场景组织路由选择的入口,不要把它当作另一种协议。使用场景设置时,需要核对实际生效的场景与路由选择。本文先比较手动选择 Config、Proxy、Direct 的基本行为,不展开 Scene 的条件配置。

Config、Proxy、Direct 分别适合什么情况

Config:按当前配置处理

推荐

连接按当前配置的规则与策略决定去向。规则既可以指定 DIRECT,也可以指定 PROXY 或配置中定义的策略;未命中前序规则时,由 FINAL 决定后续处理。

适合:配置已核对、需要按目标分流的日常使用

Proxy:使用代理路径

受 Shadowrocket 接管的普通连接不再按常规分流规则逐项选择出口,而交给代理路径。实际使用的服务器仍需核对;系统流量、排除项与特殊网络行为不能简单概括为“整台设备所有数据”。

适合:临时验证代理路径,或对照排查规则影响

Direct:使用直连路径

受接管的普通连接采用直连,不使用代理服务器作为这些连接的出口。应用的连接状态与 DNS 等设置仍要独立检查,不能把 Direct 等同于关闭应用连接。

适合:建立直连对照,检查当前本地网络能否访问目标

选择 Config 的前提是理解当前配置。不能把 Config 简化成“部分网站代理,其余一定直连”:如果配置末尾是 FINAL,PROXY,未命中前序规则的连接仍会交给代理。反过来,Proxy 也不是速度更快的档位;速度取决于本地网络、服务器路径、目标服务与连接负载。

Config 如何读取规则:顺序与 FINAL

规则通常按顺序匹配,前面的明确规则先参与判断,FINAL 负责前序规则未命中时的处理。排查某个域名时,应先找它实际命中的规则,而不是只查看配置最后一行。宽泛规则排在前面,可能使后面的具体规则没有机会生效。

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

以上是规则段落示意,不是可直接替代现有配置的完整文件。example.com 仅用于说明域名匹配。示例中的 PROXY 表示代理策略;若实际配置使用自定义策略名称,应核对该名称的定义与当前选择,避免把示意文本直接覆盖到正在使用的配置中。

域名规则与 IP 规则依赖的输入不同。目标已经是 IP 地址时,不应期待域名后缀规则凭空得到域名;按 IP 匹配时,解析结果也会影响判断。遇到“同一网站偶尔走不同路径”,需要结合当次请求记录、目标地址和命中规则分析,不能只看规则文本推断。

在 iPhone 上切换并验证路由姿态

以下操作以用户已导入自己的服务器或订阅为前提。先保持一个可识别的服务器选择,避免订阅更新、服务器切换和路由修改同时发生。需要完整的导入步骤时,可查看入门指南;服务器与订阅的管理说明见服务器管理。

  1. 进入 Home,确认当前服务器。进入 Config,核对当前启用的配置文件,记录其名称和 FINAL 的策略。
  2. 返回 Home → Global Routing,选择 Config,再回到 Home 检查连接状态;首次连接时按系统提示完成授权。
  3. 访问一个明确由域名规则匹配的目标,再访问一个预计落到 FINAL 的目标。在 Data 的连接记录中核对请求去向;具体记录入口以当前界面为准。
  4. 保持服务器不变,将 Home → Global Routing 改为 Proxy,对同一目标重新发起连接。不要仅刷新已有长连接页面后就下结论。
  5. 改为 Direct 再测一次,记录是否能解析域名、能否建立连接、页面资源是否完整加载。完成后恢复原本计划使用的 Config。

例如,若 Proxy 下新请求成功,Config 下同一请求失败,并且记录显示 Config 命中了 DIRECT,就应优先检查该条规则及直连路径。这只是一个判读示例,不是对具体网站的实测结果。反之,若三种姿态都失败,优先核对本地网络、DNS 和目标服务,而不是反复更换规则文件。

两种使用场景:日常分流与临时诊断

选择方案:把日常设置与排查对照分开

日常使用 Config
  • 核对 Config 中启用的文件,确认 FINAL 的去向。
  • 对需要直连和需要代理的目标分别验证一次。
  • 订阅更新后,重新确认服务器选择与策略引用。
临时使用 Proxy / Direct
  • 固定服务器、测试目标和本地网络。
  • 每次只改 Global Routing,再发起新连接。
  • 记录结果后恢复原姿态,不把诊断设置长期遗忘。

结论:Config 负责可核对的日常分流,Proxy 与 Direct 负责提供两条明确的排查对照路径。

若设备配置了自动连接行为,还应检查 Settings → On Demand。On Demand 控制在相应条件下建立连接的行为,不负责替代 DOMAIN-SUFFIX 或 FINAL 等规则。排查时若连接状态自行变化,应先核对这一层,再判断 Global Routing 是否按预期工作。

订阅与配置也要分开理解:更新订阅主要用于获取已有服务中的服务器信息,并不意味着当前规则已经被修正。协议名称同样不是路由姿态;服务器使用 Shadowsocks、VMess、VLESS、Trojan、Hysteria2 或 WireGuard,不改变 Config、Proxy、Direct 在这里所承担的基本职责。

常见问题:切换后为什么结果不一样

选了 Config,为什么看起来仍然都走代理?

先在 Config 查看当前文件的 FINAL,再找是否有较早出现的宽泛代理规则。若使用策略组,还要检查组内选择。用两个不同目标发起新请求,在 Data 中核对实际记录,不能凭单个网页的结果推断所有连接。

Proxy 能打开,Config 打不开,是不是订阅有问题?

先保持同一服务器,对照 Config 下该目标命中的规则与策略。如果 Config 实际走 DIRECT,应检查直连可达性;若它选择了不同服务器,应检查对应策略。只有代理服务器本身连接失败时,才继续核对服务器参数或已有订阅的更新结果。

Direct 能打开,但 Proxy 不行,应该改哪里?

这说明该目标在当前直连路径下可达,不能据此确认代理路径可用。返回 Home 核对服务器选择与连接状态,再检查服务器地址、端口和认证信息是否与用户已有资料一致。不要通过修改 FINAL 掩盖服务器连接错误。

延迟有数值,为什么三种姿态都打不开网页?

延迟结果只覆盖对应测试过程,不等于域名解析、网页连接与资源加载全部成功。先验证本地网络,再检查 DNS 是否获得有效结果,同时区分“解析失败”和“连接超时”。切换 Proxy 不会自动修复错误的 DNS 地址或目标服务故障。

选了 Direct,系统为什么仍显示连接状态?

Direct 是流量处理姿态,不是停止连接的按钮。需要停止连接时,应返回 Home 操作连接开关;若连接随后重新建立,再检查 Settings → On Demand 的条件设置。不要把系统连接标识当作代理出口已经生效的证据。

完成排查后的复核清单

最终应保存的是一组可解释的设置,而不是一个“能打开就不再检查”的临时状态。对日常使用来说,明确当前配置、代理策略与 FINAL 的去向,比长期停在某个姿态却不清楚流量路径更重要。切换 Wi-Fi 与蜂窝网络后,可以按同样方法再做一轮简短验证。

Shadowrocket 是 Apple 平台的付费客户端,主要在 iPhone、iPad 上使用,唯一获取入口是 App Store。系统要求、兼容性和购买适用范围以 App Store 页面标注为准。客户端买断 ≠ 线路套餐;使用服务器与订阅功能时,应准备用户自己已有的服务信息。

前往 App Store