官方手册 · 设置参考

Shadowrocket 功能与设置

先确认 Global Routing，再核对当前 Config 与服务器。连接方式、规则策略和自动连接各有职责，修改时不要把它们当成同一个开关。

Home · 连接与服务器
Config · 配置与规则
Data · 流量记录
Settings · 通用选项

先保存可用状态，再逐项修改
本页以用户已有自己的订阅或服务器信息为前提。Shadowrocket 是 Apple 平台的闭源商业应用，唯一获取入口是 App Store。客户端一次性买断 ≠ 线路套餐；本站不提供、不销售、不推荐节点或订阅。购买与正版核验见下载说明，首次导入见使用教程。

连接模式

Global Routing：配置、代理、直连

Global Routing 决定进入 Shadowrocket 的连接采用哪一种整体处理方式。在 Home 中打开 Global Routing，可选择 Config、Proxy 或 Direct，分别对应配置、代理、直连。它与 Home 的连接开关不是同一回事：选择一种模式并不等于已经建立连接，也不说明当前服务器可用。

日常需要按域名或地址分流时，优先使用 Config。临时判断问题是否来自规则时，可用 Proxy 做对照；需要核对原有网络的访问情况时，可用 Direct。对照测试应使用同一个目标，并在测试结束后恢复原先模式，否则临时设置可能继续影响后续访问。

界面选项	处理方式	适用场景	先检查什么
Config · 配置	依据当前启用配置的规则与策略处理连接。	指定网站走 PROXY，其余流量按规则选择 DIRECT 或其他策略。	当前配置是否选中、规则顺序是否正确、策略是否指向有效服务器。
Proxy · 代理	将受客户端接管的流量主要交给所选代理路径。	临时验证服务器链路，区分规则问题与连接问题。	所选服务器参数及可用性；仍需考虑系统与应用的流量接管边界。
Direct · 直连	受接管的连接采用直接访问方式。	核对当前网络是否能直接访问同一目标。	原有网络、DNS 与目标服务是否可用。

Config 既是配置页面的名称，也可能出现在 Global Routing 的选项中。判断当前语境很重要：在 Config 页保存了一份文件，不代表该文件已经启用；选择 Config 模式，也不代表每个目标都会走 PROXY。最终路径需要结合实际命中的规则判断。

规则即稿件

Rule：匹配条件与执行策略

规则分流是在 Config 模式下，按连接的域名、地址等条件选择处理策略。通常在 Config 页选择当前配置后进入编辑或规则查看入口，核对 Rule 内容。修改前先导出备份，再一次只调整一条规则；如果配置来自远程地址，还应确认更新操作是否会覆盖本地改动。

规则的条件与结果要分开读。DOMAIN 匹配指定域名；DOMAIN-SUFFIX 匹配指定域名及其子域名；DOMAIN-KEYWORD 检查域名中是否包含关键字，范围通常更宽。IP-CIDR 与 IP-CIDR6 按地址网段匹配，GEOIP 按地址归属数据判断。USER-AGENT 依赖能够取得相应请求信息的场景，不能假定它适用于所有连接。

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

这段是规则语法示例，不包含可连接的服务器。PROXY 表示交给代理策略，DIRECT 表示直接访问，REJECT 表示拒绝符合条件的连接。若配置使用自定义策略名称，还需核对相应策略组的定义与选择结果；规则末尾写了一个名称，并不会自动生成可用的连接路径。

常规 Rule 按自上而下的顺序检查，匹配即采用对应策略，因此更具体的例外应放在更宽泛的条件之前。FINAL 是前面规则没有命中时的兜底项，应放在规则末尾。若要只让指定网站走代理，可以先列出对应的 DOMAIN 或 DOMAIN-SUFFIX，再使用 FINAL,DIRECT；还要考虑该网站是否请求其他域名上的内容。

连接成功不等于规则正确
验证时先发起新的目标请求，再检查连接记录中的目标、匹配规则与策略。已有长连接可能继续使用先前的路径。完整语法、配置结构与优先级说明见规则手册。

已有信息管理

Subscribe 与 Add Server

服务器记录保存的是单个连接所需的参数；订阅则用于集中获取和更新一组已有服务器信息。Home 主要用于查看、选择服务器与连接，Add Server 用于添加记录；Subscribe 相关入口用于管理订阅来源，Config 页则负责配置文件。订阅链接和规则配置地址承担不同职责，不能仅凭它们都是网址就互相替换。

添加时先确认格式

手动使用 Add Server 时，先按已有信息选择 Type，再填写地址、端口、认证信息以及对应的传输选项。Shadowsocks、VMess、VLESS、Trojan、WireGuard、Hysteria2 等协议所需字段并不相同，不能只复制服务器地址就认为填写完成。Scan QR Code 和剪贴板导入可以减少输入，但导入后仍应逐项核对结果。

更新时保留来源边界

管理已有订阅时，为每个来源使用能够辨认的名称，更新后检查服务器数量变化、分组及当前选中项。订阅更新可能替换该来源下的记录，直接修改其中某个服务器未必能长期保留。如果必须保存个人调整，先确认应用提供的复制或本地保存方式，并与订阅管理的记录区分。

删除前分清操作对象是单个服务器、整个订阅，还是 Config 文件。它们之间有关联，但不是同一份数据。订阅更新失败时，先核对地址是否完整、访问凭据是否有效以及当前网络能否取得内容；不要把包含凭据的完整地址贴到公开反馈中，也不要反复导入同一地址来代替排查。

连接触发

On Demand：按条件建立连接

On Demand 用于根据预设网络条件触发连接行为，解决的是“何时连接”，而不是“某个网站采用哪条规则”。在应用的 On Demand 入口查看和编辑条件；具体入口位置及可选条件以当前应用界面为准。启用前，先确认手动连接、当前服务器和 Config 已经可以正常工作。

设置时先明确一个具体场景，例如是否希望在特定 Wi-Fi 环境下自动连接，然后只添加完成该场景所需的条件。若界面按网络类型或 Wi-Fi 名称提供选项，应核对名称是否准确，并检查条件之间的先后关系。不要一次加入大量重叠条件，否则切换网络后很难判断是哪一项触发了行为。

保存后，在实际使用的网络环境下测试，再切换到另一种网络复查。连接是否自动恢复可能受系统调度、设备状态和网络变化影响；On Demand 不能让不可用的服务器变得可用，也不能修正规则中的策略名称。需要持续诊断时，可先暂停自动触发，改为手动连接，避免测试过程中状态反复改变。

VPN 授权与自动连接是两件事
首次连接时，系统可能要求允许添加 VPN 配置；这是系统授权流程。On Demand 则是在已有配置基础上的连接条件设置。系统显示 VPN 状态，只说明相关连接处于活动状态，不表示所有目标都采用同一种策略。

访问核对

Data：流量统计与记录阅读

Data 用来查看客户端记录的流量与连接信息。进入 Data 后，先识别当前统计的范围、时间或重置状态，再阅读上传、下载等项目。它反映的是客户端在相应统计范围内观察到的数据，不应直接当作设备全部网络用量，也不等同于已有订阅账户的计费账单。

验证某条规则时，可以先记下当前数据或使用界面提供的清理入口，再只访问一个目标，随后查看新增连接。重点核对目标域名或地址、实际采用的策略以及可能显示的匹配信息。不同页面加载的图片、接口和其他资源可能来自多个域名，因此一页内容出现多条连接是正常现象。

统计数值增加，只能说明有流量经过相应路径，不能单独证明页面内容已经完整返回。后台任务也可能产生数据；比较设置前后的结果时，应尽量使用相同网络、同一目标和相近的操作范围。清理记录前先保留必要的故障线索，反馈时隐藏私人域名、地址和认证内容。

名称解析

DNS：先区分解析与连接

DNS 负责把域名解析为连接所需的地址。它与代理协议和规则策略相关，但并不是同一层设置：服务器能够建立连接，仍可能遇到目标域名解析失败；域名能够解析，也不代表对应服务端口可以访问。排查时应将这两个阶段分别核对，而不是看到页面失败就立即更换所有参数。

在哪里检查与修改

先查看 Settings 中当前可用的 DNS 相关选项，再核对启用的 Config 是否包含解析设置。配置文件中的 General、Host 等内容可能影响结果；只改一个通用选项，未必等于当前配置的全部解析行为已经改变。配置层与通用层的具体生效关系，应结合当前选项说明及诊断结果确认。

调整前记录原值，确认要解决的是解析超时、返回地址异常，还是特定网络下的可达性问题。使用已有且适合当前网络的解析设置，每次只改变一项，然后针对同一域名重新测试。不要同时改 DNS、规则和服务器，否则即使恢复访问，也无法判断是哪一项生效。

注意缓存与域名规则

修改解析设置后，已有缓存与长连接可能让结果暂时保持不变，应按应用可用的清理或重连方式重新发起请求。DOMAIN-SUFFIX 这类规则依赖域名信息，IP-CIDR 则检查地址范围；一次请求中观察到的域名与地址应结合阅读。不要仅凭一个返回地址就断言全部请求的策略一致。

Settings 常用项

测试方法、组件与同步

Settings 集中管理测试、展示、同步和诊断等通用选项。选项是否出现，以及其具体位置，可能随设备和当前应用界面不同。以下按用途说明，修改时仍应阅读选项旁的解释；不确定的高级项先保留原值，避免把一次局部排查变成整套配置重建。

Test Method：统一 Connectivity Test 的条件

Test Method 用于选择连接测试的方法，通常在 Settings 中与测试相关的选项一起查看。先明确要测的是基础连通性，还是通过代理访问测试目标的能力，再按界面提供的方式选择。随后回到 Home 对已有服务器执行 Connectivity Test，比较时保持方法与测试目标一致。

测试结果只代表当时、该方法下的反馈，不是长期速度保证。某种测试失败而实际网页可用，可能是测试方式或目标不适用；测试成功而某个网站失败，也可能涉及该网站的规则、解析或服务状态。不要只按一次测试的数字重排所有服务器。

Today Widget：快捷入口不是策略配置

Today Widget 相关设置用于配合系统组件展示或快捷操作；可在 Settings 中查看应用提供的选项，并在系统允许的位置添加对应组件。组件的展示形式与刷新行为取决于设备及系统支持，不能假定每种设备都有完全相同的入口。

使用组件操作后，必要时返回 Home 确认连接状态和选中服务器。组件不会替代 Config 中的规则，也不会自动补齐服务器参数。若组件显示与主界面暂时不一致，先核对主界面，再检查系统组件是否已经刷新。

iCloud 同步：先辨认覆盖范围

iCloud 同步用于在符合条件的设备间同步应用支持的数据。在 Settings 查看相关开关之前，先确认系统已登录自己的 Apple 账户，iCloud 相关权限可用，并理解选项说明中的同步范围。不要假定连接记录、全部凭据和所有本地文件都会一起同步。

换机前，除检查同步状态外，还应为重要配置做独立导出备份。新设备恢复后依次核对订阅、服务器、Config、Global Routing 与 On Demand，先手动验证连接，再恢复自动连接条件。应用购买记录与配置同步属于不同机制；恢复购买并不会自动替代配置恢复。

按现象排查

Diagnostics：一次验证一个环节

Diagnostics 用于收集和检查连接问题的线索，可从 Settings 的诊断相关入口进入，具体工具以当前应用显示为准。开始前先描述可复现的现象：是所有目标都失败、只有一个域名异常，还是仅在切换网络后出现问题。现象越具体，越容易决定下一步检查什么。

记录当前状态。保存 Global Routing、选中服务器、启用配置和网络类型。先保留原始配置，测试期间暂停可能改变状态的自动连接条件。
检查基础网络。确认设备当前网络可以完成正常访问；若原有网络本身异常，先处理这一层，避免把它误判为规则问题。
检查服务器参数。对照已有信息核对 Type、地址、端口及认证字段，再执行适当的 Connectivity Test。手动填写时尤其要留意多余空格与字段遗漏。
检查域名解析。针对同一个失败域名观察解析结果。域名无法解析与地址无法连接是不同现象，分别处理。
检查匹配路径。在 Config 模式下发起新请求，结合记录核对命中规则与策略；必要时短暂切换 Proxy 做对照，随后恢复原模式。
整理结果并还原。记录哪一项变更影响了结果，撤销无效调整，确认日常配置和 On Demand 已恢复到预期状态。

日志可能包含订阅地址、服务器信息、访问域名或认证内容。导出或分享前先检查并遮去敏感字段，只保留定位问题所必需的部分。诊断工具提供的是证据，不是自动修复结论；一次测试未复现，也不能直接认定问题已经消失。

常见设置判断

切换到 Config 后，为什么仍有连接采用 DIRECT？

Config 表示按配置判断，不表示所有连接都采用 PROXY。先看目标命中了哪条规则，再检查是否由 FINAL,DIRECT 兜底，同时确认正在使用的配置确实是刚才编辑的那一份。

开启 On Demand 后，还需要设置规则吗？

需要分别考虑。On Demand 决定连接触发条件，Global Routing 与 Config 决定连接建立后的处理方式。先把手动连接与分流验证清楚，再启用自动触发。

订阅更新后，本地调整为什么发生变化？

由订阅管理的服务器记录可能在更新时按来源内容重新生成。先区分本地记录、订阅记录与规则配置，重要调整独立保存，并在更新后检查当前选中项。

功能设置完成后，在哪里核对系统兼容性？

Shadowrocket 以 iPhone 与 iPad 为主要使用设备；Mac、Apple TV、Apple Vision 的兼容性与所有系统要求以 App Store 页面标注为准。获取入口与正版三要素核对见App Store 正版核验说明。

需要从首次导入开始操作，可继续阅读使用教程；需要检查完整规则结构与关键字，转到规则手册。两类操作都建议沿用同一原则：先备份、只改一处、用新请求验证，再决定是否保留修改。