官方手册 · 功能与设置
Shadowrocket 功能与常用设置
先确定流量如何处理，再检查服务器、连接条件与诊断结果。各项设置分别负责不同环节，不必一次修改全部选项。
本页以 iPhone 与 iPad 上的操作为主。界面布局与可用选项以当前应用内显示为准；系统要求以 App Store 页面标注为准。
决定按规则、代理或直连处理。
按规则顺序选择流量策略。
结合实际访问定位失败环节。
Home → Global Routing
Global Routing 三种模式
日常按规则使用时选 Config；Proxy 与 Direct 适合明确目标后的临时检查。
Global Routing 决定客户端接管范围内的流量采用哪种处理方式。在 Home 打开 Global Routing，选择 Config、Proxy 或 Direct，再返回核对当前选择。中文所说的配置、代理、直连，分别对应这三个英文界面词；它们不是三份服务器信息，也不会替你补齐连接参数。
| 模式 | 处理方式 | 何时使用 | 检查重点 |
|---|---|---|---|
| Config · 配置 | 按当前启用配置中的规则选择策略。 | 需要让不同目标分别使用 PROXY、DIRECT 或 REJECT。 | 启用的配置、规则顺序与最终匹配策略。 |
| Proxy · 代理 | 在该模式的处理范围内使用代理路径。 | 临时对照服务器是否能完成目标访问。 | 当前服务器、认证参数与实际访问结果。 |
| Direct · 直连 | 在该模式的处理范围内直接连接目标。 | 判断问题是否也发生在当前本地网络。 | 本地网络、域名解析和目标本身的可达性。 |
切换模式后的验证方法
先记录原来的模式与当前服务器，再用同一个目标做对照测试。若 Proxy 可以访问而 Config 不行，应继续检查配置与规则；若两者都失败，则优先核对服务器信息与基础网络。Direct 下能访问也不代表代理参数正确，它只说明该目标在此次直连条件下可达。
Global Routing 不是对所有系统流量都作出同样结果的承诺。系统网络行为、配置中的相关选项与已有连接都会影响观察结果。切换后重新发起目标请求，避免把旧连接的表现当成新模式的效果；测试结束后恢复原先的日常模式。
Config → 规则
规则类型与策略动作
规则负责匹配请求，策略负责决定动作。先看顺序，再看单条语法。
规则分流在 Global Routing 选择 Config 时发挥作用。进入 Config，确认当前启用的是哪一份配置，再查看或编辑其中的规则。规则按配置中的实际顺序自上而下检查，首条匹配后执行对应策略；FINAL 应放在最后，为此前未命中的请求提供处理方式。
用目标特征选择规则类型
DOMAIN 用于精确域名匹配；DOMAIN-SUFFIX 用于匹配指定域名后缀及相关子域；DOMAIN-KEYWORD 根据域名中的关键字匹配，范围通常更宽。IP-CIDR 与 IP-CIDR6 分别描述 IPv4、IPv6 地址网段；GEOIP 依据地址归属数据判断。不同类型依赖的信息不同，域名规则与地址规则不能简单互换。
USER-AGENT 针对请求中的相应信息进行匹配，但并非所有连接都能提供可用于判断的这一信息。不要把它当成通用的应用识别方法。编辑前应确认当前应用支持的规则语法，以及该规则类型在目标流量上的适用条件。
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
DOMAIN-KEYWORD,ad,REJECT
FINAL,PROXY以上仅为规则顺序教学示例，不是建议直接替换现有配置。example.com 为示例域名。
区分 PROXY、DIRECT 与 REJECT
PROXY 表示使用代理策略，DIRECT 表示直接连接，REJECT 表示拒绝匹配请求。策略写成可用的策略组名称时，还需要继续核对该组的选择结果。注意界面模式 Proxy 与规则动作 PROXY 的大小写不同，也不要把 Config 模式误认为所有请求都必须使用代理。
远程配置更新可能替换本地修改。需要长期保留的调整，应先明确当前文件的来源与更新方式，并保留可恢复副本。进一步的分步操作可参阅使用说明。
Home · Subscribe · Add Server
订阅与服务器管理
以已有的订阅或服务器信息为前提；导入成功之后仍需核对选择与参数。
订阅用于集中更新服务器条目，手动添加则适合管理一组明确的连接参数。订阅链接从你的服务商处获取，在对应的 Subscribe 入口填写；需要单独添加时，从 Home 进入 Add Server，按已有资料选择协议类型并填写参数。具体入口位置以当前应用界面为准。
先选协议，再填写连接字段
Shadowrocket 支持 Shadowsocks、VMess、VLESS、Trojan、HTTP、SOCKS5、WireGuard、Hysteria2 等协议。不同协议需要的认证和传输字段并不相同，不能只复制地址与端口就认定配置完整。逐项核对服务器地址、端口、密码或其他认证信息，并按资料填写 TLS、传输方式等相关选项。
需要扫码时使用 Scan QR Code；使用剪贴板导入时，先核对剪贴板确实是预期的分享内容。二维码和分享链接都可能包含认证资料，不宜上传到公开页面。订阅 URL 同样应按凭据保管，示例 https://example.com/sub?token=xxxx 仅用于说明字段形式，不能作为实际连接信息。
更新、选择与删除分别处理
Subscribe 更新会按来源返回的内容刷新条目，它不等于更新客户端，也不保证当前选中的服务器仍然有效。更新后检查条目名称、数量变化和当前选择，再执行 Connectivity Test，并用实际网页或服务验证。手动修改订阅内的条目可能在后续更新时被覆盖，重要参数应另行妥善记录。
管理多份订阅时，可用清晰的备注区分用途与来源，删除前确认操作针对单条服务器还是整份订阅。删除列表内容不代表已经取消你与服务商之间的服务关系，也不应被当作远端凭据撤销。
Settings → On Demand
On Demand 按需连接
它决定何时触发连接，不代替 Global Routing 决定请求走哪条路径。
On Demand 根据设置的网络条件触发连接行为，适合需要在网络变化时减少重复手动操作的场景。进入 Settings 中的 On Demand，先查看可用条件，再按实际需求配置。涉及 SSID 时，应填写所用 Wi-Fi 的准确名称，并理解该条件对应的是连接、忽略还是其他可选动作。
先验证手动连接，再加入条件
先关闭按需触发的干扰，确认当前服务器能够手动连接、Global Routing 符合预期，再配置一条明确条件。保存后分别在命中与未命中条件的网络下测试，观察连接状态与实际访问。若同时修改服务器、规则和网络条件，出现问题时很难判断是哪一项造成变化。
On Demand 不是固定时刻启动的计划任务，也不意味着网络切换时所有现有连接都能保持。系统调度、网络可用性以及 VPN 配置状态都会影响触发。无法触发时先检查条件和系统授权；连接反复恢复时，也应检查是否仍有按需条件在起作用，而不是不断重复操作主开关。
连接何时建立与请求如何分流属于两层设置：即便 On Demand 已触发连接，Config 下的 DIRECT 规则仍会让匹配流量直连。出行或更换网络前，建议保留一份简短的条件说明，避免遗忘旧 SSID 条件。
Data
Data 流量统计
用于观察客户端记录的流量变化，不替代服务商的计费记录。
Data 提供客户端侧的流量统计视角。打开 Data，先查看当前界面展示的统计范围、时间范围与分类，再判断上传、下载或累计值的含义。不同范围的数字不能直接相减对照，重置前也应先确认重置会影响哪一部分记录。
用统计辅助定位，不单凭总量下结论
排查时先记录当前值，完成一次明确的访问操作，再返回观察变化。若有上传而几乎没有下载，可能是请求发出后没有获得预期响应，但仍需结合诊断与目标状态判断。后台活动、其他正在进行的请求和连接重试都可能影响统计，因此应尽量保持测试条件简单。
客户端统计与服务商账单可能因统计周期、协议开销、计量口径等产生差异。Data 中看到的总量不等于剩余服务额度，也不能据此推断订阅是否到期。涉及服务有效期或额度时，以你已有服务的实际记录为准。
流量变多并不必然代表分流错误。先确认哪类请求产生变化，再检查 Global Routing 和规则命中情况。若需要保留排查证据，记录测试时间与操作即可；分享记录前遮盖服务器、域名或其他敏感内容。
Settings
DNS、测试、同步与诊断
一次只改一个变量，保存原设置，再验证同一个目标。
DNS：先确认当前配置由谁管理
DNS 负责把域名解析为地址。排查入口包括 Settings 中可用的 DNS 相关设置，以及 Config 当前启用文件中的 DNS 部分；应先确认当前解析行为由哪一层控制，再修改对应项目。不要看到网页打不开就同时改动多处 DNS，也不要把服务器地址解析与目标网站解析混为一谈。
延迟测试通过但网页打不开时，依次确认域名能否解析、规则最终采用什么策略、实际请求是否成功。配置中的解析路径可能与代理请求路径不同，单独一个测试结果不足以证明整条访问链路正常。保留原配置，修改后重新发起请求，并对照恢复原设置后的表现。
Test Method 与 Connectivity Test：测量条件要一致
Test Method 用于选择可用的测试方式，通常在 Settings 的测试相关设置中调整；Connectivity Test 用于触发连接测试。不同方法关注的环节不同，排序结果应在同一网络、同一方法和接近的时间条件下比较。不要把一次数值较小直接解释成所有网站都更快。
测试失败时先核对所选方法的要求，再检查服务器参数与网络环境。测试通过后仍要访问实际目标，确认解析、连接与内容加载完整完成。若更换 Test Method 后结果明显变化，应记录方法名称，避免拿两种不同条件下的结果进行比较。
Today Widget：作为快捷入口使用
Today Widget 提供系统允许范围内的快捷查看或操作入口。先在 Settings 中核对相关选项，再到系统的小组件管理界面查看是否可添加对应项目。可用形式取决于设备系统与当前应用实际提供的能力，不应把某一种旧布局当成所有设备都必须出现的样式。
小组件显示可能存在刷新间隔。操作后若状态与预期不同，应返回 Home 确认实际连接状态，再检查系统是否允许相应功能。小组件不是独立的服务器配置，也不会替代应用内的 VPN 授权。
iCloud 同步：分清同步与备份
在 Settings 中查看 iCloud 相关选项，并同时核对系统是否允许 Shadowrocket 使用 iCloud。开启前先确认当前选项说明覆盖哪些内容；服务器条目、配置文件、选择状态与其他设置不应未经核实就视为全部同步。首次使用建议先保留本地副本，再在另一台设备逐项核对。
同步用于让受支持的数据在设备间保持一致，并不保证保留每次历史修改。删除或错误编辑也可能传播，所以同步不能替代独立备份。同步内容可能含有订阅 URL 或认证信息，应保护设备与 iCloud 账户；不要为排查问题公开整份同步数据。
Diagnostics：围绕一次失败请求收集信息
从 Settings 中的 Diagnostics 或当前界面提供的诊断入口开始，先记录网络类型、Global Routing、当前配置与服务器，再复现一次失败请求。按基础网络、服务器地址解析、连接建立、规则处理、目标访问的顺序检查，比反复切换全部设置更容易缩小范围。
诊断记录中可能包含目标域名、服务器地址及请求细节。分享前移除订阅 URL、认证字段和其他私人信息，优先保留能说明现象的最小片段。完成排查后恢复临时修改的选项，停止不再需要的详细记录，避免后续操作与旧测试混在一起。