官方手册 · 功能参考

Shadowrocket 功能与设置

先确定 Global Routing,再检查配置与服务器;连接建立后,使用 Data 和 Diagnostics 定位具体问题。每次只修改一个设置,保留修改前的结果用于对照。

本文面向 iPhone / iPad,默认用户已有自己的订阅或服务器信息。系统要求与兼容性以 App Store 页面标注为准。

  • 模式决定路由入口
  • 规则决定匹配结果
  • 测试结果需要交叉核对

Global Routing:配置、代理与直连

Global Routing 决定当前连接采用哪一类路由方式,不是服务器协议选择器。在 Home 打开 Global Routing 后,按目的选择 Config、Proxy 或 Direct。中文说明中的“配置、代理、直连”分别对应这三个界面词;更改模式前先记下原选项,避免排查结束后忘记恢复。

界面选项 处理方式 适用场景 检查重点
Config(配置) 按当前启用配置中的规则和策略处理请求。 日常按域名、地址等条件分流。 当前配置、规则顺序、策略引用与最终兜底规则。
Proxy(代理) 以代理模式处理流量,而不是逐条采用 Config 的常规分流规则。 临时核对所选服务器是否能够承载目标连接。 所选服务器参数,以及配置中相关排除项的影响。
Direct(直连) 以直接连接方式访问目标。 对照当前网络的直接访问情况。 本地网络、解析结果和目标服务本身的状态。

怎样选择并验证模式

已有分流配置时,先在 Config 确认正在使用的文件,再把 Global Routing 设为 Config。若怀疑规则选错了策略,可临时改成 Proxy,以相同网络、相同目标做对照;若需要判断当前网络是否能直接访问,再测试 Direct。一次测试只改变模式,不同时更换服务器、DNS 和网络,否则无法判断是哪项修改产生了影响。

模式名称不能替代实际验证。Proxy 不表示服务器一定可用,Direct 也不表示系统连接开关已经关闭。观察连接状态、请求记录与实际访问结果后,再得出结论。排查完成应恢复原先需要的模式;长期停留在临时测试模式,可能使原本依赖规则的访问方式发生变化。

规则分流:匹配条件与处理策略

规则说明“哪些请求”,策略说明“怎样处理”。两者需要一起核对。

规则主要在 Config 中查看和维护;使用前确认 Global Routing 为 Config,并确认编辑的是当前启用的配置。通常按规则顺序匹配,较具体的条件应放在宽泛条件之前,FINAL 用于承接前序规则未匹配的请求。仅把一条规则加入另一个未启用的文件,不会改变当前连接行为。

规则类型匹配对象使用注意
DOMAIN完整域名。适合只处理一个确定的域名。
DOMAIN-SUFFIX域名后缀及其子域名。检查范围是否覆盖了不希望改变的子域名。
DOMAIN-KEYWORD域名中包含的关键词。匹配范围较宽,应避免过短的关键词。
IP-CIDR / IP-CIDR6IPv4 / IPv6 地址段。核对地址段和前缀长度,不要把单个地址与整个网段混淆。
GEOIP地址数据库中的地区归属。数据库判断不等同于目标服务的语言或业务地区。
FINAL其余未匹配请求。作为兜底,放在需要优先匹配的规则之后。

PROXY、DIRECT 与 REJECT 的区别

PROXY 表示交给代理策略处理,DIRECT 表示直接连接,REJECT 表示拒绝请求。配置也可能引用命名策略组;此时除了规则本身,还要检查策略组当前选择。界面模式 Proxy 与规则关键字 PROXY 属于不同层级,前者选择路由方式,后者是规则内的处理策略,不应互相替换。

[Rule]
DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.org,DIRECT
DOMAIN,blocked.example,REJECT
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY

以上只演示语法与顺序,不是可直接替代个人配置的完整文件。添加规则时先用一个目标验证,再逐步扩大匹配范围。若目标仍走了其他策略,检查前方是否有更早命中的规则,并结合请求记录核对实际域名或地址;页面中看到的域名不一定包含该服务全部请求。

订阅与服务器管理

服务器条目保存连接参数,Subscribe 用于导入和更新用户已有的服务器列表;它们不等同于 Config 中的完整分流配置。在 Home 使用 Add Server 添加单个条目,或选择 Subscribe 类型填写已有订阅。已有二维码时可使用 Scan QR Code,但应先确认二维码来自自己的配置来源。

添加与更新时核对什么

手动添加时,协议类型必须与已有服务器信息一致,然后逐项核对服务器地址、端口、认证信息和协议相关选项。Shadowsocks、VMess、VLESS、Trojan、WireGuard 等协议的参数不能机械互换。保存成功只说明条目已创建,不说明远端服务可用;应选中该条目,再执行 Connectivity Test,并做一次实际访问。

导入 Subscribe 时,保持链接完整,尤其注意查询参数、复制时带入的空格与换行。订阅更新是重新读取其内容,可能新增、修改或移除服务器条目。手动修改订阅生成条目之前,先考虑下一次更新是否会覆盖这些修改;需要保留的个人设置应单独记录,避免把临时编辑当成长期保存方式。

多份列表与敏感信息

同时管理多份订阅时,用备注区分来源和用途,清理前先核对条目属于哪一份列表。相同备注不代表参数相同,重复地址也未必意味着完全重复,因为端口、协议和认证方式可能不同。删除后还应检查 Config 中是否存在对原条目或策略名称的引用,防止规则仍指向已经移除的对象。

订阅链接可能包含访问凭据,二维码、导出内容和诊断记录也可能携带服务器信息。不要把这些内容直接放入公开截图。本站不提供、不销售、不推荐节点或订阅;需要核对远端参数时,应使用用户已有信息,向对应服务方确认,而不是通过反复切换无关设置猜测正确值。

On Demand:按条件触发连接

先让手动连接正常,再设置自动触发;自动连接不能修复错误的服务器参数。

On Demand 用于按网络等条件决定是否触发连接。进入应用内的 On Demand 设置入口,查看当前规则与动作,再按实际需求设置 Wi-Fi、蜂窝网络或域名相关条件。入口位置和可用选项以设备上应用内显示为准,不应根据另一台设备的界面位置直接推断。

按一个条件逐步启用

先确定一个可重复验证的场景,例如进入某个已知 Wi-Fi 后需要连接。填写网络名称时核对拼写与空格,然后检查动作是否符合预期。保存后切换到对应网络,观察系统连接状态和实际访问结果。第一条规则验证通过后,再加入其他网络条件;不要一次加入多条相互重叠的规则。

域名相关条件还涉及系统何时发起解析或访问,不能把填写域名理解为对所有关联请求立即执行同一动作。多条条件存在交集时,应检查规则排列、各自动作以及实际命中结果。网络切换后表现不同,也可能是当前网络本身无法访问服务器,需要与规则触发失败区分。

与 Global Routing 的边界

On Demand 负责连接触发,Global Routing 与 Config 负责连接后的流量处理。自动连接成功不代表分流一定符合预期;仍需检查当前模式与配置。若手动断开后又出现连接,先检查 On Demand 是否仍处于启用状态,而不是立即删除服务器。需要暂停自动行为时,在对应设置中关闭并再次观察状态。

Data:读取流量统计

Data 用于查看应用记录的流量信息。打开 Data 后,先确认当前视图的统计范围、时间范围和计量单位,再读取上传与下载数据。如果页面提供重置操作,重置前保留需要对照的记录;归零后的数值与此前累计值不能直接比较。

怎样用统计辅助判断

排查时可以先记录数值,再只打开一个目标页面,随后返回 Data 观察变化。若有数据增长而页面仍失败,说明“发生了流量”与“目标业务请求成功”并不是同一件事;还需核对 DNS、目标响应以及规则策略。后台应用也可能产生流量,因此不应把同一时段的全部增长都归因于刚打开的页面。

Data 不是服务方的剩余额度页面,也不等同于设备系统中的蜂窝用量。统计起点、网络范围、协议开销与计费口径可能不同,不能用应用内累计值直接推算远端账户余额。同样,看到流量不能证明请求一定使用了代理策略,判断具体路径应结合 Global Routing、命中规则和请求记录。

需要复现问题时,采用固定观察区间并记录当前网络,比单独截取一个累计数字更有意义。不要为了得到看似整齐的结果而连续清空记录;有价值的是修改前后的可比变化,而不是某个孤立的数值。

Settings:常用项与诊断入口

先读当前配置,再调整应用设置。配置文件内的相关选项也可能影响最终行为。

DNS:先确认问题发生在哪一步

DNS 负责域名解析;相关选项可在 Settings 的 DNS 入口及当前 Config 的配置内容中核对。先记录原来的解析设置,再根据已有配置要求修改。应区分域名无法解析、解析后无法建立连接,以及已连接但目标响应异常,三者不能用同一种处理方式解决。

设置后使用同一域名复测,并考虑缓存可能使修改前后的结果暂时一致。只有部分域名异常时,检查对应规则、解析路径与 IPv4 / IPv6 结果,不要直接把所有请求改到同一策略。更换 DNS 不会自动修正错误的端口、认证信息或不可用的远端服务器;排查应围绕已观察到的错误,而不是频繁替换解析地址。

Test Method:理解 Connectivity Test 的测试范围

在 Settings 中检查 Test Method,再运行 Home 的 Connectivity Test。测试方式决定测量对象与成功条件,不同方式得到的耗时不宜直接比较。若选项要求测试目标,也要确认目标本身可访问;测试目标异常时,结果可能反映目标问题,而非服务器的全部能力。

一次测试通过,不代表所有网站、传输方式或业务都正常;一次 timeout 也不足以证明整份配置失效。先连续复测,再核对地址、端口、协议参数、系统时间和当前网络,最后用实际需要访问的目标交叉验证。记录结果时同时写明测试方式,避免只比较一个数字。

Today Widget:快捷访问与状态核对

Today Widget 用于相关快捷操作与信息展示。在 Settings 查看 Today Widget 选项,再根据设备系统提供的组件添加入口操作。是否可添加、具体呈现方式及可用操作,以当前系统与应用内显示为准;不同设备的布局不必完全一致。

执行快捷操作后,仍应回到 Home 核对所选服务器、Global Routing 和连接状态。组件显示的是操作入口或状态信息,不负责检查服务器参数。若快捷操作后的状态与预期不同,先确认应用内状态和 On Demand 条件,不要仅凭组件外观判断连接已经建立。

iCloud:同步不等于购买恢复

使用 iCloud 同步前,先在 Settings 核对同步开关与涉及的内容,并确认系统允许应用使用 iCloud。新设备上先检查同步结果,再继续修改;没有立即出现内容时,应先核对账户、网络和系统权限,避免通过重复创建条目造成混乱。

不要把同步理解为全部设置和敏感字段必然完整迁移。以实际同步到的内容为准,重要配置仍应保留可恢复记录;导出内容需妥善保管。iCloud 同步与 App Store 已购恢复处理的是不同问题,重新获取客户端应查看已购恢复说明,不能用同步开关代替购买记录核对。

Diagnostics:为一次具体故障收集证据

在 Settings 查找 Diagnostics,按当前应用提供的工具检查连接或记录。操作前先写清症状:是所有请求失败、某个域名失败,还是仅在切换网络后失败。随后记录当前 Global Routing、所用配置、服务器条目和错误发生条件,再复现一次,避免用大量无关记录掩盖关键错误。

诊断工具给出的是观察结果,不是自动修复保证。处理日志时重点找时间一致的错误与对应请求,不要只凭某一条警告推断全部原因。对外提供记录前,移除订阅链接中的凭据、认证字段及个人网络信息;保留错误类型、复现步骤和必要的脱敏参数,通常更便于定位问题。

设置核对顺序

从“能否建立基础连接”开始,再检查“请求是否走对策略”,最后才处理自动化和同步。按以下顺序操作,可以减少多项设置相互影响造成的误判。

  1. 确认已有信息完整。核对服务器协议、地址、端口及认证字段;订阅导入后先确认列表中确实有可选择的条目。
  2. 确认当前路由方式。检查 Home 的 Global Routing。使用 Config 时,确认当前启用文件和策略引用,而不是只检查某个已保存文件。
  3. 先手动建立连接。完成必要的系统 VPN 配置授权,再使用 Connectivity Test 和实际目标验证;测试期间暂不叠加新的自动连接条件。
  4. 逐项核对规则与 DNS。针对一个失败目标检查命中情况,每次只修改一处,并保留修改前后记录;无改善时恢复原值。
  5. 最后设置 On Demand 与同步。基础连接稳定后再启用按需条件、组件操作及 iCloud,分别验证各自结果。

首次配置可接着阅读使用说明;需要核对购买与设备兼容性时,前往App Store 正版下载说明。本页是 Shadowrocket 官方手册的功能参考,具体可用选项以应用内显示为准。