Shadowrocket
功能与常用设置
先确认流量由哪种模式处理，再调整配置与连接条件。本页按“是什么、在哪里、怎么设、注意什么”说明 iPhone 与 iPad 上的常用功能；具体入口和可用选项以应用内显示为准，系统要求以 App Store 页面标注为准。
Global Routing：Config / Proxy / Direct
Global Routing 决定当前连接采用哪种整体处理方式。在 Home 找到 Global Routing，打开后选择 Config、Proxy 或 Direct。它不是服务器协议，也不等于连接开关：选好模式之后，仍需确认服务器、配置与主连接开关的状态。日常需要按域名或地址分别处理流量时使用 Config；排查时可以临时切换另两种模式，完成后恢复原设置。
| 界面选项 | 处理方式 | 适用情形 | 先核对什么 |
|---|---|---|---|
Config 配置 |
依据当前启用配置中的规则与策略处理流量。 | 日常分流；区分需要代理与直接连接的请求。 | 活动配置、规则顺序、策略指向与最终规则。 |
Proxy 代理 |
对客户端接管的连接采用代理处理，而非日常规则分流。 | 临时验证所选服务器能否处理目标请求。 | 当前服务器是否可用，以及认证和传输设置。 |
Direct 直连 |
对客户端接管的连接采用直接连接处理。 | 核对本地网络能否直接访问同一目标。 | 本地网络、域名解析与目标服务的可达性。 |
操作时先记录原模式，在同一网络上用同一目标分别测试，避免切换网络和更改多个设置。若 Proxy 可以访问而 Config 不行，重点检查规则是否命中、策略是否指向正确服务器；若 Direct 正常但 Proxy 失败，重点检查服务器信息与连接日志。这些现象只是缩小排查范围，不能单凭一个结果断定原因。
Direct 不等于关闭系统中的 VPN 配置，Proxy 也不是对所有设备通信的绝对保证。模式测试应结合实际请求记录判断。切回 Config 后再次检查活动配置，防止把临时排查模式留作日常设置。
Rules：匹配条件与执行结果
规则分流把“匹配哪个请求”和“如何处理该请求”分开描述。进入 Config，确认当前启用的配置，再打开对应配置的编辑入口查看规则。规则通常按顺序匹配，较具体的条件应放在较宽泛的条件之前；Global Routing 选择 Config 时，当前配置中的规则才是日常分流检查的重点。
先选规则类型，再核对策略
DOMAIN 用于精确域名匹配，DOMAIN-SUFFIX 用于域名及其子域名范围，DOMAIN-KEYWORD 按域名中的关键字匹配。IP-CIDR 与 IP-CIDR6 表示地址网段，GEOIP 使用地址地理分类。按域名和按地址判断的前提不同，解析结果也会影响地址类规则的判断，不应只凭规则名称猜测命中结果。
规则末尾的策略指定处理方式。DIRECT 表示直接连接，REJECT 表示拒绝；PROXY 应对应当前配置中可用的代理策略或策略组。策略组若另有选择项，还要检查其当前选择。只写出 PROXY 这个名字，并不能替代一条可用的服务器连接。
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT这段示例表示 example.com 及其子域名使用 PROXY，前面未匹配的请求由 FINAL 交给 DIRECT。example.com 是教学域名，示例不是适合所有网络的完整配置。FINAL 应作为最终处理规则，不能放在需要继续匹配的规则前面。
修改后用实际请求验证
编辑前保留可恢复的配置副本，每次只修改一个条件或策略。保存后确认修改的是当前活动配置，发起一个新的目标请求，再从可用的连接记录中检查命中规则和策略。已有连接可能继续使用此前的处理结果，需要重新发起连接才能比较。遇到 USER-AGENT 等规则类型时，还需核对它对实际请求的适用条件，不能将其当作通用的按应用识别规则。
- 具体规则在前
- 策略名称有效
- FINAL 放在末尾
Subscribe 与 Add Server
服务器条目保存连接所需的地址、端口、认证和协议参数；Subscribe 则通过用户已有的订阅 URL 获取一组服务器信息。两者可以并存，但来源与维护方式不同。在 Home 使用 Add Server 添加条目，按资料提供的类型选择协议；导入订阅时选择 Subscribe，并填写已有订阅的 URL。不要把订阅 URL 填进单个服务器的地址栏。
手动添加：字段逐项对应
Shadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard 与 Hysteria2 的认证和传输字段不同。应按用户已有资料填写，不根据协议名称自行猜测。尤其要核对服务器地址与端口、密码或 UUID，以及资料要求的 TLS、传输类型、Host、SNI 等字段；只填写界面实际提供且连接资料要求的选项。
使用 Scan QR Code 或导入链接后，也要打开条目检查解析结果。二维码能成功读取只表示内容被识别，不表示服务器可连接。备注用于辨认条目，不参与认证；可以按用途命名，但不要在备注中写入密码或完整订阅凭据。
订阅更新：来源与本地修改分开管理
添加 Subscribe 后执行更新，检查是否出现服务器条目，再选中需要使用的服务器。若更新失败，先核对 URL 是否完整、凭据是否有效、当前网络能否取得订阅内容。订阅更新成功只说明内容获取和解析成功，仍要进行连接验证。
订阅内条目可能随更新变化，本地修改也可能被新内容覆盖。删除订阅前先确认关联条目及备用配置，更新后重新核对所选服务器和策略组。订阅 URL 中的 token 属于访问凭据，提交排查信息时应遮盖；手册中的示例不能作为实际连接资料。
On Demand：按条件建立连接
On Demand 使用系统支持的按需机制，在符合已设置条件时触发连接。它与 Global Routing 分工不同：On Demand 关注何时连接，Global Routing 关注连接中的流量如何处理。在 Settings 查找 On Demand 相关入口，以应用内列出的条件和开关为准。调整前应先完成一次手动连接，确认服务器和配置本身可用。
设置时先确定需要触发的网络条件，再启用对应选项。若界面提供网络类型或 Wi-Fi 条件，逐项核对其包含、排除或断开行为，不要仅根据名称理解为所有网络都自动连接。保存后分别在符合条件与不符合条件的环境下检查连接状态，并发起实际请求验证。
按需连接不是持续可用的保证。系统状态、网络切换与服务器可达性都会影响结果，触发机制不能修复错误的密码或失效服务器。遇到刚断开又重新连接的情况，先检查 On Demand 条件是否仍成立，再处理主连接开关，避免反复操作却保留原触发条件。
排查连接问题时，可以暂时关闭 On Demand，用手动方式完成同一网络下的对照测试。确认原因后再恢复所需条件。日常使用中还应留意其他已启用的 VPN 配置，核对系统当前显示的连接与 Shadowrocket 中的状态是否一致。
Data：上传、下载与分组流量
Data 用来观察客户端记录的流量。打开 Data，先看当前统计范围与分组，再读取上传和下载数值：上传是从设备发出的数据，下载是设备接收的数据。界面中显示的累计量与当前速率不是同一个指标，比较读数前应核对单位、时间范围，以及此前是否执行过清零。
若当前界面提供按服务器与按应用的分组，前者适合核对流量经过哪个服务器，后者适合观察来源分布。应用识别和统计范围有条件限制，分组名称不能单独证明某条规则已命中；判断分流行为仍应结合请求记录、活动配置和策略选择。
用可重复的操作比较读数
先记录当前数值，再执行一个明确的操作，例如重新加载同一页面，随后查看上传与下载的增量。后台同步、媒体预加载和系统通信也可能产生流量；重复打开已缓存内容时，增量可能较小。测试期间尽量保持网络和服务器不变，避免把网络切换与正常后台流量混入比较。
客户端读数不应直接视作服务方账单或设备全部流量。连接覆盖范围、计数周期、协议开销和服务方计费口径可能不同。若需要比较，应先对齐时间区间与单位，再向已有服务方核对其统计规则，而不是要求两个面板的数字逐字相同。
需要清零时，先保存排查所需的读数，再使用当前界面提供的重置入口。清零统计不会替代订阅更新、服务器切换或配置修复。记录问题时写明“清零前后”和“测试动作”，比单独提供一张累计流量图更便于复现。
Settings：DNS、测试、组件与同步
Settings 集中提供连接相关选项与辅助工具；部分参数也可能由活动 Config 指定。调整前先记录原值，并确认设置属于全局选项还是当前配置，避免在两个位置反复覆盖。以下入口以应用实际显示为准，组件与同步的可用性还取决于设备及系统支持情况。
DNS：域名解析与配置协同
DNS 将域名转换为连接所需的地址。查看 Settings 与活动 Config 中的 DNS 相关项，先确定当前由哪处配置控制解析，再修改对应设置。已有配置若包含解析服务器或域名专用规则，应先理解其作用；不要仅因某个域名访问失败就同时更换所有解析选项。
设置后分别测试域名解析与目标连接。解析成功只表示取得了地址，不表示连接一定成功；地址类规则还可能受解析结果影响。若修改后出现异常，恢复原值做对照，并检查请求记录中的地址与策略。提交诊断资料时只保留必要的域名和错误信息，隐去涉及个人访问记录的内容。
Test Method 与 Connectivity Test
Test Method 用来选择连接测试的方法。在 Settings 找到相关选项，按当前界面提供的方式设置，再回到服务器列表执行 Connectivity Test。不同方法测量的阶段不同，某个数值可能反映连接建立或对指定目标的请求耗时，而不是实际下载速度。
比较服务器时应保持测试方法、测试目标与网络一致。一次测试失败也可能来自测试目标不可达或短时网络波动，不能直接等同于所有请求都会失败。选择条目后，还要用实际需要访问的目标验证认证、传输和路由是否共同正常。
Today Widget：系统组件入口
Today Widget 提供系统组件中的快捷查看或操作入口。在 Settings 检查相关选项，再按设备系统支持的组件添加流程，将应用提供的组件加入可用区域。组件形式和支持范围以当前系统及应用显示为准，不把名称相近的系统组件当作同一功能。
组件适合减少重复打开应用的操作，但不能替代首次配置与授权。修改服务器或配置后，应回到应用确认当前选择；组件读数或状态未及时刷新时，以应用内实际状态和连接验证为依据。
iCloud：跨设备同步条件
iCloud 相关设置用于同步应用支持的内容。在 Settings 查看同步入口，并核对系统中是否允许 Shadowrocket 使用 iCloud。先确认当前设备的数据正确，再启用同步；另一台设备也需要满足相应账号、系统权限与网络条件。
同步范围以应用列出的项目为准，不应假定所有密码、统计、日志和系统 VPN 授权都会一起迁移。操作前保留重要配置的可恢复副本，操作后逐项核对服务器、配置和当前选择。iCloud 同步与 App Store 已购恢复是不同流程，同步数据并不代替应用购买记录。
Diagnostics：定位连接失败阶段
Diagnostics 用于收集或查看诊断信息。在 Settings 查找对应入口，按界面提示执行需要的诊断。先写下发生问题的网络、Global Routing 模式、所选服务器和具体操作，再复现一次问题；这样才能把日志中的时间与实际动作对应起来。
阅读结果时先区分订阅获取、域名解析、服务器连接、认证与目标请求等阶段。单个错误不一定代表最终原因，应结合前后记录判断。分享诊断结果前，检查并遮盖订阅 token、密码、UUID、个人地址和不必要的访问记录，仅保留复现问题所需的信息。
从连接资料到实际请求的核对顺序
功能彼此关联，但排查时应分层检查。先确认资料，再确认连接，最后验证规则与辅助设置；一次只改变一项，才能知道哪次修改影响了结果。以下顺序适用于已有订阅或服务器信息的用户，不要求先开启全部功能。
- 检查来源。确认 Subscribe 更新结果，或检查 Add Server 的协议、地址、端口与认证字段，记录当前选中的服务器。
- 检查配置。在 Config 确认活动配置；使用 Config 模式时，核对 Rules 顺序、策略组选择与 FINAL。
- 完成手动连接。核对系统授权，开启连接并发起实际请求。必要时临时用 Proxy 与 Direct 对照，测试后恢复原模式。
- 检查解析与日志。只有出现相应现象时才调整 DNS 或测试设置，结合 Diagnostics 区分失败阶段。
- 再启用便利功能。连接稳定后设置 On Demand、Today Widget 与 iCloud，并在 Data 记录相同操作的流量变化。
若需要从购买与首次授权开始，请阅读下载指南；已有资料但尚未完成第一次连接，请阅读使用教程。遇到规则关键字不熟悉的情况，可以先查看名词解释，再回到当前配置核对具体条件。