Shadowrocket 完整手册

阶段 01 / 获取

App Store 获取与正版核验

Shadowrocket 是在 Apple 平台发行的付费闭源商业应用，唯一获取入口是 App Store。开始前先确认设备当前使用的商店账户、购买记录和可用付款方式。购买客户端与准备服务器信息是两个独立步骤：安装完成只表示设备已经具备运行客户端的条件，并不表示已有可连接的服务。本站讲解已有信息的导入与使用，不提供连接服务。

核对商店页的三项信息

打开正版下载说明，进入 App Store 产品页后，先看名称 Shadowrocket，再核对开发者 Shadow Launch Technology Limited、官方图标和应用 ID 932747118。名称只能作为初步辨认依据；开发者与应用 ID 更适合排除相近名称的搜索结果。应用 ID 对应产品链接末尾的 id932747118，不是应用当前版本的编号。

图标应与本站页头使用的官方图标一致。搜索结果、商店详情页和付款确认页之间可能存在跳转，实际确认购买前仍应重新看一次产品名称。若页面显示的开发者不同，停止当前流程，回到正版下载说明重新进入。不要因为图标色调接近就跳过开发者核对，也不要将搜索词排名当作核验结论。

理解一次性买断与设备适用范围

Shadowrocket 采用客户端一次性买断方式，实际价格、币种和税费显示以 App Store 页面为准。客户端一次性买断 ≠ 线路套餐，应用费用不包含用户已有服务的费用，也不替代服务的有效期、流量额度或账户认证。以后遇到连接失败，应分别查客户端状态与服务状态，不能仅凭“应用已购买”推断服务器应当可用。

本手册主要解释 iPhone 与 iPad 的操作。Mac、Apple TV、Apple Vision 也可在同一商店页查看兼容性；系统要求、设备支持和其他设备的通用购买适用性，以 App Store 页面标注为准。不同设备的显示布局与输入方式可能不同，不能把某一设备上的按钮位置直接当作其他设备的操作路径。

完成安装后保留购买与配置的边界

安装结束后，从设备主屏幕打开 Shadowrocket，先确认应用能够正常启动，再准备导入。App Store 购买记录用于重新获取应用，服务器与配置数据则应另外保存。两者没有自动等价关系：恢复购买记录不代表恢复全部本地设置，重新安装也不保证原有订阅分组、手动服务器和自定义规则一起回来。

换机或重新安装时，先在 App Store 检查原购买账户下的已购项目，再按已购恢复说明处理。如果商店再次显示价格，先确认账户和购买记录，避免急于重复操作。商店能否展示某项购买，还可能受当前店面与账户状态影响，这类情况应先在商店流程内排查，而不是修改客户端的连接参数。

阶段 02 / 权限

首次启动与系统 VPN 配置

第一次打开 Shadowrocket 时，先认识 Home、Config、Data、Settings 的分工。Home 主要用于查看服务器与连接状态；Config 管理分流配置；Data 提供流量相关读数；Settings 放置常用行为设置。具体布局以当前应用显示为准。熟悉这些入口后再逐项操作，比同时修改多个开关更容易判断问题来自哪里。

系统为什么请求添加 VPN 配置

在已准备服务器后首次开启连接，系统可能询问是否允许添加 VPN 配置。这是 Apple 系统管理网络扩展连接的授权步骤，用于让客户端通过系统网络机制处理流量。它与 Config 中的规则文件不是同一对象：系统 VPN 配置解决“应用能否接管对应网络流量”，Config 解决“接管后如何处理请求”。

确认弹窗来自刚刚主动开启的 Shadowrocket 操作后，按系统提示完成授权；系统可能要求设备身份验证。授权完成后返回客户端观察开关与状态。不要把允许添加配置理解成服务器认证成功，系统授权本身不会验证地址、密码、UUID 或远端服务是否正常。服务器不可达时，系统配置仍然可能已经建立。

拒绝、删除或重复出现提示时怎么处理

若刚才拒绝授权，先回到应用确认服务器信息已保存，再重新尝试开启连接，观察系统是否再次给出授权流程。若没有出现预期提示，可到设备系统设置中的 VPN 管理位置查看对应配置是否存在。不同系统布局可能调整，按 VPN 项目名称查找，不必照搬某一固定层级。不要在尚未确认归属时删除其他用途的配置。

如果曾从系统设置删除 Shadowrocket 对应的 VPN 配置，后续连接可能需要重新授权。处理前先断开连接，再回到应用发起一次新的连接请求。反复授权仍失败时，记录系统提示原文、是否存在设备管理限制，以及当前是否还有其他 VPN 连接正在运行。权限问题应先解决权限，不要同时更换协议、DNS 和规则。

区分相机、照片与网络授权的用途

使用 Scan QR Code 时，扫描相机需要对应的相机权限；若通过图片识别二维码，可能涉及系统照片选择流程。这些权限只与导入路径有关，手动填写 Add Server 并不要求先完成扫码。二维码中可能包含完整认证信息，扫描前确认来源属于自己的已有服务，扫描后仍要核对协议、地址与端口。

出现本地网络访问相关提示时，应结合当时功能判断用途，例如访问局域网内目标；它不能替代 VPN 配置授权。通知等辅助权限也不等于连接权限。遇到多个弹窗，按顺序阅读每一项请求，不要将“已经点过允许”作为所有权限均已满足的依据。记录哪一项被拒绝，后续才有明确的恢复目标。

建立可重复的首次连接条件

初次设置建议停留在一个稳定的网络环境，暂时不要来回切换 Wi-Fi 与 Cellular。先确认断开客户端时普通网络可用，再保存一组正确参数、完成系统授权，并观察客户端与系统状态是否一致。若设备受组织管理，某些网络扩展操作可能被策略限制，应遵守设备管理要求，不要把限制误判为服务器故障。

完成这一阶段，只能确认应用启动和系统授权流程正常。连接后还需检查目标请求是否成功、Global Routing 是否符合预期，具体见第五章。有关权限提示与系统配置之间的对应关系，可继续阅读首次连接的 VPN 配置提示说明，排查时保留提示原文比仅描述“开不了”更有帮助。

阶段 03 / 导入

添加服务器与 Subscribe 管理

导入前先判断拿到的是什么：单个服务器参数、包含服务器信息的二维码，还是订阅链接。三种输入对应不同操作，不能把普通网页地址当作订阅，也不能把订阅链接填入单个服务器的地址字段。所有内容都应来自用户已有的服务；本章只说明如何准确录入与核对，不对任何服务作选择建议。

Add Server 的字段应逐项对应

进入 Add Server 后，先选择与已有信息一致的协议，再填写地址与端口。地址通常是域名或 IP，不应自行附加路径；端口应与远端监听端口一致。接着填写该协议要求的认证字段。不要看到字段为空就任意补值，也不要把说明文本中的标签一起复制进去。输入完成后保存，再重新打开检查一次。

认证通过仍不代表传输设置正确。TLS 的服务器名称、WebSocket 的路径与 Host 等字段属于不同层次，应逐项按已有参数填写，不能因为服务器地址看起来相似就相互替代。证书验证失败时先检查名称、设备时间和远端证书，不要把关闭验证当作日常解决办法。VMess 与 VLESS 的字段差异可查阅协议参数区别说明。

Subscribe：导入与更新不是同一动作

订阅导入会读取链接返回的内容，并生成对应服务器分组；订阅更新则再次获取内容，以同步地址、端口和其他参数变化。选择导入入口时，将链接按应用提供的订阅方式录入，保存后等待请求完成，再确认分组中确实出现服务器。只有分组名称而没有可用条目时，应检查响应内容，不能据此认为导入已成功。

订阅链接通常带有个人认证信息，不要发到公开对话、截图或故障反馈中。复制时注意链接末尾是否缺失、是否带入空格，以及是否从富文本中复制成了展示文字。更新失败时先记录具体错误，再检查普通网络是否能到达订阅地址、服务是否仍有效、返回内容是否为登录页或错误页；不要用连续点击更新代替定位。

二维码导入后仍需检查结果

通过 Scan QR Code 识别后，检查新条目的协议、备注与地址是否符合预期。二维码可能只代表一个服务器，也可能表示订阅入口，导入结果要以应用生成的对象为准。若识别成功但没有出现预期内容，先判断输入类型，不要立即手动拼接链接。来源不清或内容无法核对时，停止使用并重新取得自己的正确信息。

手动修改与订阅覆盖的边界

订阅中的条目由订阅内容维护，手动改过某项参数后，下一次更新可能重新覆盖该字段。需要临时验证时，先记录原值，并尽量保留独立的测试条目，避免把整个分组改成难以追踪的状态。服务器显示名称只是备注，同名并不意味着同一地址，整理时应按实际协议、地址和端口判断重复。

导入结束后，先选择一条服务器做单次验证，不必立即测试全部条目。若旧条目可用、新条目不可用，优先对比新旧参数与服务状态；若全部条目都失败，再检查系统权限、本地网络和导入方式。删除旧分组前确认新分组已完成实际访问测试，避免把仍可回退的数据提前清除。

阶段 04 / 分流

Global Routing 三姿态与规则顺序

Global Routing 决定进入客户端的请求采用哪种处理姿态。Config 按当前配置中的规则处理，Proxy 将相关请求交给所选代理处理，Direct 按直连方式处理。这里说的是客户端接管范围内的请求，不应将任一姿态理解成设备上一切网络行为都必然遵循同一条路径；系统机制、应用行为与具体连接类型仍会影响观察结果。

先选姿态，再解释访问结果

日常需要规则分流时，使用 Config 并确认当前启用的配置。排查时可短暂对比 Proxy 与 Config：如果同一目标在 Proxy 下可访问、在 Config 下失败，规则、策略引用与 DNS 处理值得优先检查。这个对比不是绝对结论，因为两次请求也可能遇到缓存、连接复用或网络变化，应在相近条件下重复确认。

规则通常按顺序匹配

规则文件中，具体匹配应放在宽泛匹配之前，最后用 FINAL 处理未命中前序规则的请求。DOMAIN 匹配具体域名，DOMAIN-SUFFIX 匹配域名后缀，IP-CIDR 匹配地址段，GEOIP 按地址归属数据库判断。规则关键字与策略名要分别理解：前者决定匹配什么，后者决定匹配后交给哪种处理方式。

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

这是用于解释规则顺序的 Shadowrocket .conf 片段，不是适合所有网络的完整配置。第一条将示例域名后缀交给 PROXY，第二条让指定私有地址段使用 DIRECT，第三条根据 GEOIP 数据处理，最后一条承接剩余请求。实际使用时应结合自己的局域网地址、目标需求与配置中可用策略核对，不能只复制片段就假定分流完整。

域名规则与 IP 规则为什么可能表现不同

域名匹配依赖请求中可识别的域名信息，IP 规则则针对目标地址。某些应用直接连接 IP，或者连接已由缓存解析，这时只添加域名规则未必覆盖全部相关请求。一个页面还可能请求多个域名，主页面成功而图片失败，通常应继续检查对应资源请求，不能只给主域名补一条规则就结束。

GEOIP 的判断依赖数据库与解析结果，不等同于网站使用的语言、品牌所在地或用户看到的内容。目标使用多个地址、地址发生变化时，匹配结果也可能改变。遇到边界情况，先查看实际请求目标，再判断应使用明确域名、地址段还是其他规则。不要为了单次访问问题随意扩大整个地址段的处理范围。

修改 Config 后必须重新验证

先保存原配置副本，再修改一条有明确目标的规则，确认保存且当前使用的是修改后的配置。配置列表中存在文件，并不代表它正在生效；文件名称相似时尤其要核对。若策略名称引用不存在、规则格式不正确或远程资源更新失败，应先处理配置错误，再进行网络访问测试。

阶段 05 / 验证

连接开关、Connectivity Test 与实际访问

连接验证需要同时观察三个层次：系统是否允许启动、服务器链路能否建立、目标请求是否按预期完成。开关保持开启只能说明某一层状态，不能单独证明网页访问正常；同样，某次测试超时也不一定代表全部网络路径都不可用。按层次记录结果，才能避免“有时能用”的描述掩盖真正差异。

建立一组可比较的基线

先断开连接，确认当前 Wi-Fi 或 Cellular 能完成普通网络访问。如果普通网络本身需要登录或存在断连，先处理基础网络。然后固定一条已核对的服务器与一个 Global Routing 姿态，开启连接并等待状态稳定。验证期间尽量使用同一目标，不要一边换网络、一边换服务器又一边更改规则。

实际访问应观察目标页面是否完整加载、资源是否持续返回，以及新请求是否可重复成功。已经打开的页面可能来自缓存，不能仅靠刷新图标停止旋转判断。必要时关闭目标应用中的原连接后重新发起请求，或使用另一个明确的新请求交叉检查；注意不必为了验证清除全部设备数据。

Connectivity Test 的读数能说明什么

Connectivity Test 用于辅助观察测试目标的连通情况，结果受测试方法、目标和当时网络条件影响。读数较低不等于下载速度一定高，也不保证所有网站都可访问。某条服务器可以完成测试，但实际目标依赖的 DNS、TLS、应用协议或资源域名仍可能失败，因此测试结果应与真实访问一起看。

比较两条服务器时，应尽量固定测试方式和网络环境，避免把不同条件的读数直接排序。单次超时可以重试确认，但不必持续密集测试全部条目；过多测试会增加额外请求，也可能干扰观察。保存有代表性的成功与失败结果，比记住一个瞬间数值更有利于分析。

按失败发生的位置缩小范围

如果开关立即回落，先看系统 VPN 配置、权限与应用提示；如果开关稳定但所有实际请求失败，检查服务器地址、端口、认证、传输与基础网络；如果仅某个目标失败，再检查该目标的域名解析、规则匹配和远端状态。认证错误、证书错误与超时的含义不同，应保留原文，不要统一写成“连不上”。

如果测试正常但网页打不开，先确认 DNS 是否能给出有效结果，并比较 Config 与 Proxy 下的同一请求。解析成功也可能返回在当前路径上无法到达的地址，因此还要结合后续连接错误判断。详细流程见DNS 解析失败排查，不要同时替换所有 DNS 选项来碰运气。

速度问题与连接问题分开处理

能够连接但速度不稳定时，先区分首次建立连接慢、单个请求慢和持续传输慢。前两者可能涉及解析与握手，持续传输则还与远端负载、本地信号、网络拥塞和目标限制有关。延迟只是一个观察维度，并不是吞吐能力的直接换算公式。切换网络后表现变化，也只能提示本地路径值得检查。

可按速度慢的分层检查固定条件对比。完成临时测试后，恢复原先的日常姿态，尤其要避免将排错时使用的 Proxy 或 Direct 长期留在不符合需求的状态。若仍不能定位，将网络类型、协议、姿态、错误原文与复现步骤整理后，再查看常见问题中的对应分类。

阶段 06 / 观察

Data 流量读数与统计边界

Data 用于观察客户端能够统计到的流量活动，适合辅助判断连接期间是否有请求和数据传输。它不是服务账单，也不是判断所有请求路径的唯一依据。读取任何数字前，先确认当前统计范围、页面分组、单位与起止时间；不同范围的两个数字即使看起来相近，也不适合直接相减得出结论。

上传、下载与速率分别怎么读

上传与下载是相对于设备的数据方向。上传通常包括请求、提交内容以及连接过程中的交互；下载包括返回数据与响应内容。打开一个页面也会产生上传，因此上传不为零并不意味着设备正在主动发送大型文件。连接建立、重试和后台活动同样可能增加读数，应结合当时操作理解。

速率描述某个时间窗口内的数据变化，累计流量描述某个统计区间内的总量。瞬时速率下降可能只是当前没有新数据，不能据此断言连接断开；累计数字仍在增加，也不证明目标页面已经成功完成。注意界面显示的是字节类单位还是比特类单位，单位不同会造成表面上很大的数值差异。

按服务器与按应用查看时的限制

按服务器观察时，重点是同一统计区间内对应服务器处理的数据变化，而不是只看当前所选服务器名称。切换服务器后，先前连接的生命周期与读数归属需要结合实际界面解释，不能假定选择项变化会立即重写全部历史统计。若界面提供不同视图，应先确认当前视图的标题和分类口径。

若当前界面提供按应用或进程归类的信息，应将其作为客户端可识别范围内的观察结果，而不是设备所有应用流量的完整审计。系统能提供的信息、共享连接及后台请求会影响归类，无法识别的请求也不应被强行归因。具体展示范围以当前应用显示为准，不能根据某项未列出就认定它完全没有联网。

为什么与服务记录不完全一致

客户端统计与已有服务后台记录可能使用不同起止时间、结算周期、单位换算和协议开销口径。服务端还可能汇总同一账户的其他设备或连接，而客户端只展示本设备可统计的活动。先对齐时间与设备，再检查是否包含上下行、重传及额外连接开销，通常比直接比较总数更有意义。

如果刚开始观察时已经存在后台请求，初始读数就不是零基线。测试过程中自动订阅更新、连通性检测和其他应用同步也可能产生额外活动。要做小范围对照，可以记下开始读数和结束读数，控制测试时长与目标，但不要为了“清零”贸然删除统计历史或重置全部配置。

把 Data 用于有边界的诊断

开启连接后，若发起新请求却看不到预期数据变化，先检查请求是否走了当前观察范围，以及是否命中缓存。出现上传增长而下载长期没有明显变化时，可把它视为需要进一步检查远端响应的线索，但不能仅凭这一现象断定某种认证错误。应同时查看连接提示、解析结果和规则处理情况。

记录一次测试的开始时间、目标、姿态与服务器，再观察相应读数变化；随后只改一个条件重复测试。这样可以把统计与实际操作关联起来。更多读数口径见Data 流量统计说明。如果需要反馈问题，仅保留必要的统计摘要，遮盖服务器地址、个人标识与认证内容，不必公开整页记录。

阶段 07 / 设置

Settings、DNS 与 On Demand

Settings 中的项目影响客户端行为，Config 中的项目则可能影响当前配置下的请求处理。某项功能具体出现在哪个位置，以当前应用显示为准。调整前先明确要解决的现象，以及该项目作用于全局行为还是单个配置。若不清楚作用范围，先保留默认值并查阅含义，不要把所有看起来相关的开关一起打开。

On Demand：触发条件与手动连接

On Demand 用于按系统条件请求建立或维持连接，常见条件涉及 Wi-Fi 与 Cellular。它不是服务器可用性保证，也不代表连接失败后一定自动更换服务器。启用前先确保手动连接已经能稳定工作，再决定哪些网络条件需要触发，避免把基础连接故障与自动触发行为混在一起。

先在固定网络中确认规则，再切换到另一种网络观察。手动关闭后是否重新触发，需要结合当前条件和系统状态理解；如果连接反复出现，先检查 On Demand 条件是否仍满足，而不是只反复拨动主开关。需要临时停用时，应同时理解自动触发的设置，确认系统状态确实保持在预期结果。

Wi-Fi 名称条件应准确核对，名称相近并不等于同一网络。连接需要网页登录的 Wi-Fi 时，先完成基础网络认证，再验证自动连接。系统可能因休眠、网络重建或切换状态重新评估条件，因此短暂变化应结合时间线观察，不能把一次切换当作所有场景都已测试通过。

DNS 设置先看职责，再看地址

DNS 将域名解析为地址，但解析路径与后续连接路径不是同一个问题。更改 DNS 前，先判断失败发生在解析阶段还是连接阶段：域名没有结果、返回错误，与已有地址但连接超时，应采用不同排查方向。只要网页打不开就修改 DNS，容易让原本简单的问题增加新的变量。

使用自定义解析方式时，应确认该方式在当前网络可达，并理解其请求将如何处理。局域网名称、内网域名与公开域名可能有不同需求，一套配置不一定适用于所有环境。更改后重新发起请求，注意缓存与已有连接可能使旧结果短时保留；不要因一次结果未变化就继续叠加更多选项。

日志、测试与隐私信息

日志适合在复现问题时按需查看，重点记录错误原文、时间、目标与重复条件。长期保留详细日志可能增加本地存储占用，并积累访问相关信息。需要分享时，先移除完整订阅链接、认证字段和个人标识；即使是域名列表，也可能反映使用习惯，应按最小必要范围提供。

连接测试相关选项会影响测试所采用的目标或方式，修改后不要继续与旧条件下的读数直接比较。若目标本身不稳定，测试结果可能随之变化。排查中应固定测试条件，并将真实目标访问作为补充验证，而不是为了得到更小的数值不断更换设置。

调整后保留回退路径

每次修改 Settings 前，记录原值、修改原因与预期结果；对 Config 的修改另存文件副本。若应用提示需要重新建立连接，在停止当前重要传输后再操作。修改没有改善问题时先恢复原值，再进入下一项检查，不要留下多项无法解释的实验设置。

阶段 08 / 维护

更新、备份与故障记录

稳定使用后的维护重点不是频繁改动，而是保留可恢复状态，并在变化发生时知道变化来自哪里。客户端更新、订阅更新、Config 更新和系统更新是不同事件，各自可能改变不同层次。一次只安排一类重要调整，完成验证再继续，能够显著降低出现问题时的定位成本。

客户端更新走 App Store

在 App Store 查看 Shadowrocket 的更新记录与当前设备适用条件，并按商店提供的方式更新。更新前确保已有参数和本地配置具备备份；更新后先按原来的服务器与姿态验证，不要立即顺便替换全部配置。若行为变化，记录变化前后操作与应用提示，不需要猜测某个版本是否一定导致问题。

系统更新也可能改变权限提示、网络切换行为或界面路径。更新后若首次连接请求重新确认，先阅读提示并检查对应系统配置，不要直接删除所有数据。系统要求仍以 App Store 页面标注为准。客户端可以正常打开但连接异常时，应继续按权限、服务器、规则、DNS 的层次检查。

备份哪些内容才有实际意义

至少分别保存手动服务器所需参数、订阅来源、当前 Config 文件和关键 Settings 的原值。订阅链接本身并不等于一份长期有效的服务器快照，服务内容变化后，重新导入可能得到不同结果。备份应说明保存时间与用途，但不要把认证信息写进公开文件名、截图标题或共享文档。

使用应用当前提供的导出或保存功能时，确认导出的对象是什么，并检查文件是否包含预期内容。导出成功的提示不等于已验证可以恢复，重要配置应在保留原数据的前提下确认可读取。备份存放在自己控制、访问受限的位置；准备分享规则示例时，应先移除个人服务器与订阅信息。

订阅和 Config 分开维护

订阅更新后先检查条目数量与关键参数是否符合预期，再做实际连接验证。若条目减少，先确认返回内容与服务状态，不要马上删掉全部旧信息。Config 更新则重点检查规则顺序、策略引用与远程资源是否正常。两种更新同时进行，会让失败原因更难区分，尤其不适合在已经连不上的时候一起尝试。

清理重复条目时，按实际协议、地址和端口辨认，不只看备注名称。保留一个已验证的回退配置，确认新状态稳定后再整理旧文件。没有说明来源或用途的配置不要随意叠加；文件越多并不代表功能越完整，当前启用对象清晰、引用关系有效才是维护目标。

整理能复现的故障记录

有效记录应包含：问题发生的网络类型、是否刚切换网络、所用协议、Global Routing 姿态、具体错误原文、失败目标范围，以及最近一次已知正常状态。再写清已经尝试的单项调整和结果。这样才能区分“所有请求失败”“仅一个目标失败”与“测试失败但实际访问正常”等不同情形。

记录中不需要出现密码、UUID、完整订阅链接或可识别个人身份的内容。必要时用描述替代真实地址，保留协议、错误类别和时间顺序即可。查询FAQ或回到入门指南复核基础步骤时，按记录逐项对照，不要为了获得不同结果不断重复整套导入流程。