Shadowrocket 完整使用手册

先确认获取入口

Shadowrocket 是 Apple 平台的付费客户端，iPhone 与 iPad 是本手册的主要操作设备。获取入口是 App Store 产品页；Mac、Apple TV 与 Apple Vision 的兼容性也应在同一商店页查看。不要从设备名称推断具体系统门槛或购买适用范围：系统要求、支持设备和当前标价均以 App Store 页面标注为准。准备购买前，先确认正在使用的 App Store 店面，以及该店面产品页是否显示可购买状态。搜索结果只是查找入口，最终应在产品详情页核对信息。

识别产品时同时看三处：应用名称为 Shadowrocket，开发者为 Shadow Launch Technology Limited，产品链接中的应用 ID 为 932747118。页面所用图标应与商店产品图标一致，但不能只凭图标判断；名称或图形相近的搜索结果也可能指向不同产品。进入详情后，读完整个开发者名称，再检查地址中的 id932747118。这三个信息相互印证，比单独记一个中文别称更可靠。具体核对位置及设备说明见正版核对页。

区分应用费用与连接资料

购买支付的是 Shadowrocket 客户端本身。美区页面曾以约 2.99 美元显示一次性买断价格；实际价格、币种及购买条件以当前 App Store 页面标注为准。客户端一次性买断 ≠ 线路套餐：完成购买只表示可以取得应用，不会自动生成可连接的服务器信息。后续的导入步骤以你已经拥有自己的订阅或服务器参数为前提；如果尚未取得这些资料，可以先阅读路由和界面说明，但不能把应用内尚未出现 SERVER 条目理解成购买失败。

在 iPhone 或 iPad 上完成购买后，回到 App Store 的产品详情页执行安装，并等待系统完成。若按钮显示的是重新取得应用的状态，先核对当前登录的购买账户，再查看 App Store 已购项目；不要仅凭设备桌面是否有图标判断购买记录。换机或重新安装时，购买记录与应用内自行导入的配置是两回事：重新取得应用不意味着已有订阅、服务器备注和自定义规则必然恢复。准备迁移时，应先保留自己有权使用的原始资料，再按新设备的实际状态导入。

把“产品是否正确”“是否已取得应用”“是否已准备连接资料”分开核对，可以减少后续误判。例如打开 Home 后列表为空，先检查是否已经导入，而不是重复购买；连接后目标网站不可达，先检查服务器、路由和网络，而不是把现象归因于图标或商店账户。完成上述准备后，再进入首次启动与 VPN 配置权限阶段。

先辨认 Home 的几个位置

首次打开 Shadowrocket 后，先在 Home 观察现有状态，不必立刻更改所有选项。Home 是进入连接操作的起点：顶部连接开关与状态文字反映当前连接状态，Global Routing 决定流量采用哪一种路由姿态，SERVER 区域用于查看和选择已经加入的服务器，Connectivity Test 则用于辅助检查连接。首次进入时看见 Not Connected，只能说明当前未建立连接；如果 SERVER 还没有可选条目，应先完成导入。不同屏幕尺寸和应用内布局可能改变项目的位置，寻找时以英文界面词为准。

建议按“看状态—确认资料—选择路由—开启连接”的顺序操作。这样在系统权限弹窗出现时，能够明确它由哪一次开关动作触发，而不会把权限请求、服务器导入和规则选择混为一谈。如果先打开开关，却没有选中可用服务器，随后出现的连接失败不能单靠重复允许权限解决。记录自己操作前看到的状态文字，也便于在下一次检查时判断是否确实发生变化。

理解系统授权弹窗

在 iPhone 或 iPad 首次尝试开启连接时，系统可能要求允许 Shadowrocket 添加 VPN 配置。这是系统对网络配置变更的确认步骤，不等同于已经连上某个服务器。阅读弹窗中的应用名称及系统说明，确认它与当前操作对应后，再按系统提示完成授权；设备也可能要求通过密码或生物识别确认。授权完成后返回应用，仍须检查连接开关、所选 SERVER、Global Routing 和验证结果。系统状态栏出现 VPN 标识，只能证明相关网络配置处于启用状态，不能证明每个目标都按预期访问。

若弹窗被取消，先回到 Home 检查开关状态，再由应用中的连接操作重新触发，不要不断快速切换开关。若此前已允许配置，却在后续连接时仍看到权限相关提示，可以先确认设备当前是否允许修改 VPN 设置，以及是否有其他设备管理限制；具体可操作项目取决于设备设置。不要为了处理普通的节点参数错误而反复删除系统配置。先区分报错发生在“授权之前”“授权之后但未连接”还是“已连接但访问异常”，三种情况的检查方向不同。

在 iPad 上沿用同一判断顺序

iPad 的宽屏布局可能让 Home 上的列表和控件呈现方式与 iPhone 不同，但权限的性质没有变化：系统确认的是设备上的 VPN 配置，SERVER 资料仍需用户自行导入。首次使用两种设备时，分别确认各自的系统授权和应用内选中项，不要假设一台设备上的允许操作会自动替另一台完成。对于同一 Apple ID 的购买记录，应从 App Store 已购状态核对；对于连接资料，应从每台设备的实际列表核对。

完成权限确认后，保持连接关闭，先把已有资料导入并检查字段。遇到找不到开关、列表或测试入口的情况，可参考首次打开与 Home 区块说明。在这个阶段，最有用的记录不是“能否打开网页”，而是应用是否正常启动、Home 是否显示、系统权限是否已确认，以及 SERVER 是否仍为空。这些事实将为下一阶段的导入排错提供边界。

先判定资料类型

Shadowrocket 的服务器条目可以来自手动填写、单条分享链接或订阅。开始前先看清自己已经拥有的是哪一种资料：服务器地址、端口、协议和认证字段适合逐项填写；以协议前缀开头的分享链接通常表示单个条目；由服务商提供、用于定期取得一组条目的 URL 则应按 Subscribe 处理。订阅 URL 与某个服务器地址不能互相代替，把前者填进服务器地址字段，或把单条分享链接当成订阅更新地址，都会造成难以解释的错误。

对手动添加，在 Home 找到添加入口并进入 Add Server，先选择与已有资料一致的协议类型，再逐项填写。地址写主机名或 IP，端口应与资料一致，认证信息应按该协议要求填写；备注可以帮助自己识别条目，但备注不是连接参数。输入时注意复制内容两端的空格、数字端口、大小写敏感字段和容易混淆的字符。保存后先回到 SERVER 确认出现了新条目，并检查实际选中的是哪一条，再启动连接。应用支持的字段以 Add Server 当前显示为准。

按协议检查必要参数

表格只用于定位检查方向，不是通用填写模板。同名协议下也可能有不同的传输、安全和域名参数；不要凭记忆替换服务商给定的值。WireGuard 的 PrivateKey 属于本地身份资料，PublicKey 与 Endpoint 各有不同作用，详细解释可见WireGuard 参数说明。对任何认证资料，都避免在公开页面、截图或求助消息中完整展示。要排查字段，优先自己逐项对照原始资料。

导入与更新已有订阅

如果已有 Subscribe URL，使用应用内对应的订阅添加方式，粘贴完整地址并保存，然后执行应用提供的更新操作。订阅示例地址如 https://example.com/sub?token=xxxx 仅用于说明 URL 形态，不能用于连接。更新成功后还应返回 SERVER 检查是否生成条目，以及正在选中的条目是否仍符合需要。导入成功与节点可用是两件事：前者说明应用取得并解析了资料，后者还要经过连接与目标访问验证。关于 ss://、vmess://、vless://、trojan:// 单条链接与订阅 URL 的差别，见分享链接与订阅链接说明。

更新失败时先检查设备能否访问订阅地址、URL 是否被截断，以及原始资料是否仍有效；如果显示更新完成但列表为空，再确认订阅实际内容与应用识别的格式。不要为了试错把私密 URL 粘到公开检测网页。Scan QR Code 可以用于导入自己持有的有效资料，但扫描后仍需复核字段和来源。资料已进入 SERVER 后，下一步是选择 Global Routing，而不是仅凭列表里出现条目就认定分流已经正确。

先选姿态，再讨论命中规则

Global Routing 决定流量采用何种路由判断方式。界面里的 Config、Proxy、Direct 可分别理解为按配置判断、统一走所选代理路径、统一采用直连路径。中文解释只是为了说明行为，实际查找设置时仍以英文词为准。切换姿态通常不需要重新输入服务器资料，但会改变对连接结果的解释：同一个目标在 Config 下可能命中 DIRECT，在 Proxy 下则走所选服务器。因此排查时必须先记下当前姿态，否则“开关已开却没有经过服务器”可能只是路由选择的正常结果。

Config 最需要理解的是规则顺序与兜底策略。规则通常从具体匹配走向更一般的匹配：DOMAIN 指定完整域名，DOMAIN-SUFFIX 匹配域名后缀，DOMAIN-KEYWORD 按关键词匹配；GEOIP、IP-CIDR 与 IP-CIDR6 则涉及地址范围判断。规则右侧的 PROXY、DIRECT、REJECT 是处理策略，不是协议名称。PROXY 仍依赖已选的可用服务器，DIRECT 使用设备当前网络直接访问，REJECT 用于拒绝匹配请求。USER-AGENT 也属于可见的规则关键字；具体能否适用于某条请求，应以应用内的匹配表现为准。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,ads,REJECT
GEOIP,CN,DIRECT
FINAL,PROXY

上面的 example.com 是示例域名，片段只展示规则关系，不应直接视为完整配置。第一行让该域名及其子域名采用 PROXY；第二行展示关键词匹配后的 REJECT；第三行展示 GEOIP 与 DIRECT 的组合；没有被前面规则处理的请求再由 FINAL 决定去向。若把 FINAL,DIRECT 写在末尾，未命中的请求便采用直连策略。修改之前先保存现有 Config，并记录具体目标及预期行为，避免同时改动多条规则后无法判断哪一处改变了结果。

用三姿态缩小故障范围

当 Config 下某目标访问异常，可在明确测试范围后对照 Proxy 与 Direct 的表现。如果 Proxy 可访问而 Config 不行，优先检查规则命中和 FINAL；如果 Proxy 也失败，应回到所选服务器参数、认证、网络连通性和目标本身。如果 Direct 可访问而 Config 异常，不等于必须永久改成 Direct，应继续找出匹配该请求的规则。三姿态对照是一种诊断方法，不是对所有网络环境的固定推荐；测试结束应恢复自己需要的姿态，并重新验证常用目标。

配置文件可能同时包含规则以外的设置，例如 DNS 相关项目。对一条请求的最终观察结果，既可能受域名解析影响，也可能受 IP 规则、路由姿态和目标服务影响。不要把某个测试网页给出的单一结果当成整份 Config 的正确性证明。需要进一步了解术语，可查术语表；需要处理 DNS 的具体设置，可读DNS 设置说明。

把连接拆成几个可观察的阶段

开始连接前，先在 SERVER 选中一条自己已有的服务器，确认 Global Routing 是刚才决定使用的姿态，再操作 Home 上的开关。随后依次观察：系统权限是否已经通过、应用状态是否从 Not Connected 改变、设备是否显示相应网络状态、Connectivity Test 是否给出结果，以及实际目标是否按预期访问。这些观察项不能互相替代。开关处于开启状态，并不保证服务器认证成功；测试某个地址成功，也不能保证所有域名都命中相同规则。

Connectivity Test 适合做快速比较，但测试对象、当前网络和路由设置都会影响结果。一次测试失败时，先确认设备本身联网正常，再检查所选服务器是否仍是想测试的条目；如果刚更新过 Subscribe，尤其要重新核对选中项。接着确认当前是 Config、Proxy 还是 Direct，再用同一目标重复测试，避免每次都更换网络与目标。记录“姿态、所选条目、测试目标、出现的现象”这四项，比只写“连接不上”更容易定位原因。

按现象分支排查

如果无法启动连接，先回看系统 VPN 配置权限及 Home 状态，不要急着改规则。如果显示已连接但目标无法访问，先判断该目标是否被 Config 中的 REJECT 或 DIRECT 规则处理，再检查 PROXY 所依赖的服务器。如果只有少数域名异常，重点核对对应 DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD 和 DNS；如果所有目标都异常，则优先检查设备基础联网、服务器字段、认证和所选条目。目标网站本身暂时不可用，也可能产生相似现象，因此需要选择不止一个自己熟悉的目标交叉验证。

当一条已有服务器的参数需要确认时，先对照最初取得的资料，不要随机更换协议、端口和安全设置。地址解析正常但连接仍失败，可能与认证或传输参数有关；订阅能够更新但服务器不可用，也只说明资料获取这一步成功，不能跳过服务器验证。反过来，单条服务器可用而某份订阅更新失败，应集中检查订阅 URL 的完整性和可访问性。把“取得配置”“建立连接”“目标访问”分成不同层次，排查才不会循环。

连接稳定之后再检查长期行为

第一次成功访问目标后，继续测试几次常用场景：设备从一个已知网络切到另一个网络、锁屏再解锁、订阅更新后重新选中条目。网络切换可能改变 DNS、可用路径或连接保持状态；一次成功不代表后续所有环境都无需检查。若平时使用 On Demand，先理解触发条件，再把它加入测试；否则自动连接动作会干扰手动开关的结果。关于 On Demand 与后台使用的取舍，可参见按需连接与耗电排查。

验证完成的标准不是某个状态点亮，而是你预期采用 PROXY 的目标能够按预期访问、预期 DIRECT 的目标仍可正常使用，并且切换回日常 Config 后结果保持一致。只有在这个基础上，Data 中的数字才有明确的解释前提。若现象无法归入上述分支，可返回教程主线逐步复核输入、选择与开关顺序，避免在未知状态下继续叠加设置变更。

先界定统计范围

Data 用于观察应用内呈现的流量信息。进入该页面前，先记下当前连接状态、所选服务器和 Global Routing，再查看计数。数字是否变化，应放在这组前提下理解：某些请求可能按 DIRECT 处理，某些请求可能被 REJECT；设备上的其他活动、后台刷新与先前连接也可能使观察窗口里的数字不只对应眼前刚打开的一个页面。不要把 Data 中某个总量直接写成“某网站用了多少”，也不要把应用内统计与运营商账单视为完全相同的计量口径。

比较前后数据时，先确定观察的起点和终点。可以在明确当前值后，访问一个自己熟悉的目标，再返回 Data 查看变化；如果期间切换了网络、服务器或路由姿态，就把这项变化写入记录。不同视图可能按连接、条目或时间范围呈现信息，应先读清页面标签再比较。界面实际提供哪些筛选与重置入口，以当前应用内显示为准；不要根据别人的截图推断自己的页面一定有相同按钮。

用统计辅助判断，不用它替代连通测试

流量出现增长，说明观察范围内有相关数据活动，却不能单独证明目标内容正确加载，也不能证明每条请求都走 PROXY。若 Data 没有立即变化，先确认连接是否保持、请求是否真正发起、当前筛选范围是否覆盖测试时段，然后回到 Home 和 Connectivity Test 核对。尤其在 Config 姿态下，同一个应用发出的不同请求可能匹配不同规则，只根据一项累计值很难还原各请求的路径。需要判断单个目标时，应结合路由规则、连接状态和目标实际表现。

排查“流量看起来偏多”时，先做可重复的小范围观察，而不是一次关闭所有功能。记录开始时的数值，暂停自己正在进行的大流量任务，再按平时网络使用方式观察一段时间。若仅在后台出现持续增长，可对照系统电池与网络使用信息，并检查是否启用了 On Demand 等会影响连接时机的设置。两处统计可能基于不同范围和计算方式，出现差值不必立即归因于应用异常。先弄清单位、时间窗口和是否计入后台活动，再决定要不要调整设置。

保留可复查的记录

需要向自己的服务商询问连接资料问题时，描述网络类型、所选协议、连接时段和可复现现象即可；不要附上完整订阅 URL、密码或密钥。Data 截图也应先检查是否含有账户、服务器备注或其他个人信息。如果怀疑某条规则导致流量走向与预期不同，回到 Config 逐条检查处理策略，而不是仅重置统计。重置只能改变观察起点，不能修正路由逻辑。

Data 最适合回答“在这段已知条件下，流量有没有变化、变化是否与操作大体一致”。它不适合独自回答“服务器为何认证失败”“某个域名命中了哪一条规则”或“商店购买是否成功”。前两者应回到连接与 Global Routing 章节，购买问题则回到已购恢复说明。明确工具的用途后，统计数值才能成为排查线索，而不是新的误判来源。

先保留可用基线

Settings 集中了会影响使用习惯和连接行为的选项，但首次成功连接后，不需要逐项改动。建议先记录一组已经验证可用的基线：所选 SERVER、Global Routing、当前 Config，以及是否使用 On Demand。之后只针对明确的问题调整相关设置，每次改一项并重新访问同一个测试目标。这样一旦表现变差，就能知道应恢复哪一项，而不是在多个开关变化后猜测原因。不同设备和应用内页面可能显示不同项目，名称与可用范围以实际界面为准。

On Demand 的作用是按设定条件决定何时建立连接，不是提高某条服务器速度的按钮。若日常需要在特定网络环境下自动连接，先明确触发条件与例外情况，再开启对应配置；测试时观察进入网络、离开网络及重新解锁设备后的状态。若只是在排查手动连接问题，先暂时保持测试条件简单，避免自动动作覆盖自己刚完成的开关操作。对后台活动或耗电有疑问，也应先查系统给出的电池使用情况，再结合连接频率判断，不能仅凭应用保持连接这一事实推定原因。

区分 DNS 与路由规则

DNS 负责把域名解析为后续连接需要的信息；Global Routing 和 Config 规则决定请求如何处理。两者相互关联，但并不是同一个设置。系统 DNS、自定义 DNS 与 DNS over HTTPS 各有适用场景，改变解析方式后，应重新测试此前出现问题的域名，同时保留一个不受该问题影响的对照目标。如果此前的问题来自错误的服务器认证，修改 DNS 通常不能直接修复；如果表现仅在个别域名上出现，解析结果与规则命中则值得一起检查。

在 Config 中看到 dns-server 等项目时，应先确认自己正在编辑的是哪份配置，以及改动后是否真正启用了它。不要把教学示例的解析地址直接当作适用于所有网络的默认值。记录旧值、改一项、保存、重新测试，并确认是否需要刷新相关连接，构成一次完整的设置实验。详细的三种解析方式与验证步骤见DNS 设置说明。如果某个 Config 来自你已有的资料，编辑前也应考虑后续更新是否会覆盖本地修改。

处理配置与设备之间的差异

同一份连接资料放在 iPhone 和 iPad 上，也不保证每台设备的 Settings 完全相同：系统网络、权限状态、所选 Config 和本地偏好都要分别核对。Import from Cloud JSON 等导入项只有在你确实拥有相应格式的资料时才有用途，不能拿普通订阅 URL 随意替代。导入后先确认具体内容，再决定是否启用；对来历不明的配置，不宜直接覆盖当前可用设置。

维护设置时优先回答三个问题：想改变的现象是什么、哪一个选项可能直接影响它、怎样验证改动确实有效。若无法回答，就先保持已验证的基线。Settings 的价值在于按需要细化行为，而不是让所有选项都处于某个统一状态。查找界面英文词和规则关键字时，可以配合术语表；完成设置后，再按连接章节的方法做一次实际目标验证。

把更新分成两条线

日常维护首先要区分应用更新与连接资料更新。Shadowrocket 本身的更新通过 App Store 处理；商店页面是查看应用信息、兼容性和更新记录的入口。Subscribe 更新则是应用从你已有的订阅 URL 重新取得配置内容，两者不会因为名称里都含“更新”就自动同步。发现新条目没有出现时，先检查订阅更新及 SERVER；发现应用功能或界面描述与手册不同，则先核对 App Store 页面和应用内现有文案。不要用服务器列表的变化推断应用版本，也不要用应用更新推断订阅内容已经刷新。

准备换机时，先确认 App Store 已购记录及当前设备能够访问的购买账户，再整理自己有权使用的订阅 URL、手动填写所需字段、个人 Config 修改和必要备注。将私密资料存放在自己控制的安全位置，不把完整 URL 或密钥发到公开讨论区。新设备取得应用后，按“权限—导入—选中服务器—Global Routing—验证”的顺序重新核对。即使两台设备使用同一购买账户，也应分别确认应用内实际有哪些条目及当前选中了哪份配置；已购状态不能替代应用数据检查。

发生故障时保留最少而充分的信息

一个便于复盘的记录应包含：故障开始的大致时段、iPhone 或 iPad、当前网络类型、连接前后的 Home 状态、所选协议和服务器备注、Global Routing 姿态、测试目标及结果。如果是在改动后出现问题，还要记录刚改过的设置。备注用于辨识即可，不要记入密码、密钥或完整订阅地址。先复现一次，随后只改变一个条件重新测试；如果结果发生变化，就继续沿该分支核查。多项同时变更会让下一次同类问题更难处理。

可以用一条固定的判断路径整理问题：应用能否正常打开；SERVER 是否有预期条目；是否能确认系统 VPN 配置权限；连接状态是否变化；Proxy 下所选服务器是否可用；Config 下目标命中什么规则；Data 是否在已知测试中变化。每一问都对应本页前面的阶段。若订阅无法更新，不必先改 DNS 和全部规则；若只有某个域名失败，也不必先重装应用。把故障定位到阶段之后，再查该阶段的参数和边界情况。

定期核对，而非频繁重置

日常可定期检查 App Store 产品页、已保存的原始资料是否仍可使用，以及常用目标在当前 Config 下是否符合预期。遇到网络环境变化，先重复简短验证，再决定是否调整 On Demand 或 DNS。规则中使用的域名、地址范围和个人需求会变化，过去有效的匹配不代表永远适用；每次调整都应保留可恢复的旧配置。清空列表、重置统计或重新导入全部资料，应当是在明确目的和备份范围后执行的操作，而非遇到一次测试失败时的默认第一步。

本手册的结束点不是某个“完成”按钮，而是一套可重复的检查顺序：从 App Store 核对产品，确认权限与已有资料，在 Global Routing 中确定路径，实际验证连接，用 Data 辅助观察，并在 Settings 中只改动有明确目的的选项。需要重新走一遍简短流程时，返回快速上手教程；需要核对购买与设备条件时，查看App Store 正版说明。始终以 App Store 页面和应用内当前文案校准本手册中的操作位置。