Shadowrocket 完整使用手册:从 App Store 获取到日常维护

Shadowrocket 是 App Store 上的付费应用,没有第二条获取途径。这一章讲清三件事:怎么在商店里确认自己点开的是正版、一次性买断到底买到了什么、以及在哪些设备上能装。

Shadowrocket(中文圈常称小火箭)在 App Store 里搜索时,结果中会出现若干名称相近的应用。判断方法不是看名字,而是看商店页上的三处信息:开发者一栏写的是 Shadow Launch Technology Limited;应用图标是白底、蓝紫渐变描边的火箭图形;商店页地址里带有应用 ID 932747118。三处都对,才是需要购买的那个应用。

应用 ID 为什么值得单独记

应用 ID 是 App Store 里每个应用唯一的编号。本站所有指向商店的链接都写成 https://apps.apple.com/us/app/shadowrocket/id932747118 这一条,你在地址栏里看到的 id932747118 与商店页信息里的应用 ID 是同一件事。如果某个页面给出的链接里是别的编号,它指向的就不是 Shadowrocket。

一次性买断,买的是什么

Shadowrocket 采用一次性买断的付费方式。美区定价约 2.99 美元,其他店面按当地货币显示,具体金额以你打开商店页时看到的标注为准。买断的是客户端本身,也就是运行在 iPhone、iPad 上的这个应用;购买之后不存在按月的订阅费,也不需要为解锁功能再次付费。

设备范围与系统要求

Shadowrocket 以 iPhone 与 iPad 为主,同时也出现在同一 App Store 商店页的兼容性栏里,覆盖 Mac、Apple TV 与 Apple Vision。某台设备能不能装,取决于它登录的 Apple ID 是否已经购买过这个应用,以及商店页当前标注的兼容性。系统版本要求一律以 App Store 页面标注为准——应用会随系统迭代调整最低版本,写死在教程里的数字很快就会过期。

买完之后:已购与更新

购买完成后,应用会进入该 Apple ID 的已购项目。换机或重装时,用同一个 Apple ID 在 App Store 的已购项目中重新下载即可,不需要再次付费。家人共享是否适用于这个应用,同样以商店页标注为准。

更新由 App Store 统一分发,应用内没有独立的更新通道,也不需要手动替换任何文件。保持 App Store 的自动更新开启,或者偶尔到账户页里手动点一次更新就够了。本站不会、也不能提供任何安装包——任何声称提供安装包的来源,都与正版无关。

购买前先准备好两样东西

在点下购买按钮之前,建议先备好两样东西:一是你的服务器信息或订阅链接(从你的服务商处获取),二是确认设备上登录的 Apple ID 是你常用的那一个。前者决定买完之后能不能立刻用起来,后者决定以后换机时能不能顺利找回。如果只是想先熟悉界面,应用在没有任何服务器的情况下也能打开,只是连接开关无法建立隧道。

第一次打开 Shadowrocket,系统会连续弹出几个授权窗口。它们各自管什么、该不该允许、误点了怎么补救,是这一章的内容;顺带把主界面的几个标签页认一遍。

首次启动时,最先出现的通常是 VPN 配置授权弹窗。iOS 会明确写出请求方名称,并询问是否允许添加 VPN 配置。选择允许之后,系统会为 Shadowrocket 建立一条本地隧道配置,后续的连接开关都基于这条配置工作。

为什么需要 VPN 配置权限

在 iPhone 与 iPad 上,应用要让流量经过自己的处理逻辑,必须借助系统提供的网络扩展框架。Shadowrocket 把服务器参数与规则转换成一条系统级 VPN 配置,流量从系统进入这条隧道,由应用按规则决定走代理还是直连,再交还给系统发出去。这也是为什么在系统的"设置"里能看到一条对应的 VPN 配置项——它是系统层面真实存在的条目,而不是应用内部的模拟开关。

三个弹窗分别对应什么

• VPN 配置授权(Add VPN Configurations):功能必需。拒绝之后,连接开关无法生效。
• 通知权限:用于显示连接状态变化一类的提示。允许与否不影响代理功能。
• 本地网络(Local Network):只在需要让同一局域网内的其他设备访问本机代理端口时才会用到,不需要这项用法可以拒绝。

三个弹窗里只有第一个是必需的。误点了"不允许"也不必卸载重装:再次拨动连接开关时,系统会重新询问;如果始终没有弹窗,到系统"设置"的 VPN 一栏里检查是否已经存在相关配置项。

主界面的几个标签页

Shadowrocket 的主界面由底部标签页组成,后续所有操作都从这里进入:

• Home:服务器列表与连接开关。顶部显示当前 Global Routing 姿态,中间是节点列表,底部是主开关。
• Config:配置文件与规则。导入的 .conf 文件、规则列表都在这里查看与编辑。
• Data:流量统计。按服务器与按应用两组读数,第 7 章展开。
• Settings:全局设置。On Demand、DNS、订阅自动更新等选项都在这里,第 8 章展开。

界面用词保持英文原文:Home、Config、Data、Settings、Add Server、Subscribe、Global Routing、On Demand。中文说明里出现这些词时,指的就是界面上那个具体的按钮或标签;保留原文是为了让你能一一对上,而不是换成含义相近的中文词。

建议的初始化顺序

第一次配置时,按下面的顺序走一遍,比随手点开关更容易定位问题:

1. 先在 Settings 里确认 Global Routing 的姿态,默认停在 Config 即可。
2. 回到 Home,用 Add Server 或 Subscribe 把服务器信息填进去。
3. 对节点做一次延迟测试,确认参数填对了。
4. 最后再打开主开关,并用 Connectivity Test 验证一次。

顺序背后的逻辑是:开关只负责"建立隧道",隧道里能不能通,取决于服务器参数与规则是否已经就位。先填信息再开开关,失败时就能把问题缩小到参数或网络,而不是同时怀疑权限、参数与规则三件事。另外,首次打开不需要设置语言或外观——界面跟随系统语言与深色模式,没有独立的主题选项。

把服务器信息放进 Shadowrocket 有两条路径:Add Server 手动填单条,Subscribe 导入一整份订阅。两条路径可以共存,这一章分别讲清字段含义、更新方式与容易填错的地方。

Add Server:手动添加单条服务器

在 Home 页点击 Add Server 进入参数表单。第一项是 Type,它决定后面要填哪些字段:

表格只是常见组合的示意。字段会随 Type 与所选传输方式变化,服务商给你什么就填什么;多填、少填,或者照别的界面上的名字猜着填,都是连接失败最常见的来源。保存之后,节点会出现在 Home 的列表里。

Type 之外还有几处容易忽略:备注(Remark)只影响显示名称,填成便于辨认的即可;TLS 开关与 SNI、Path、Host 等字段只在服务商明确给出时才需要填;如果服务商提供的是分享链接或二维码,直接用 Scan QR Code 扫码导入,比手抄一遍更不容易出错。

Subscribe:导入订阅

订阅是服务商把一批服务器打包成一个链接,由客户端定期拉取。入口在 Home 页的 Subscribe:把订阅链接粘贴进去、写一个备注,保存后点 Update 完成第一次拉取。拉取成功后,节点会以分组的形式出现在列表里。

订阅链接从你的服务商处获取,形如 https://example.com/sub?token=xxxx 这样的地址。它通常带有身份标识,等同于账号凭据,不要贴到公开场合,也不要转发给不相关的人。本站不提供任何订阅链接,文中出现的地址都是演示用的假值。

订阅与手动添加的区别在更新方式:订阅可以整体刷新,服务商调整节点后你只需再点一次 Update;手动添加的单条节点不会自动变化,服务商换了地址就得自己改。两种方式可以同时存在,常见做法是把常用节点手动置顶,把订阅分组留在下面。

订阅的更新时机

更新订阅有两个时机:手动更新,以及在 Settings 里开启的自动更新。手动更新的入口在订阅分组上,点开分组详情即可看到 Update;自动更新适合订阅内容经常变动的用户,代价是每次启动应用会多一次网络请求。

更新失败时,先分清是"拉不到"还是"拉到了但用不了":前者通常是链接失效、token 变更,或当前网络访问不到订阅域名;后者说明订阅内容本身有变化,需要看服务商的通知。完整的排查顺序在第 9 章。

从文件导入配置

除了逐条填写,Shadowrocket 也支持导入配置文件:拿到 .conf 文件后,通过系统分享菜单选择 Shadowrocket,即可导入到 Config 页。配置文件里可以同时包含服务器列表、规则与通用参数,适合已经有一份完整配置的用户。导入后注意检查 Config 页顶部的选中状态——同时存在多份配置时,只有被选中的那一份生效。

另有一个 Import from Cloud JSON 入口,用于从云端 JSON 恢复配置。它读取的是你自己保存的配置内容,与节点订阅是两件不同的事。

延迟测试与节点选择

节点列表里每个条目会显示延迟读数,点一下即可重新测。这个数字是一次探测往返的耗时,只能用来横向比较同一时刻的节点,不能代表实际速度——它不测带宽,也不测长时间稳定性。Connectivity Test 会做更完整的一轮检查,结果会区分解析、连接等环节。

列表支持排序与置顶。日常使用建议把两三个稳定节点放在最上面,避免每次都在长列表里翻找。

Global Routing 决定隧道里的流量"默认往哪走",是 Shadowrocket 里最容易设错、也最值得先弄懂的一项。它只有三种姿态:Config、Proxy、Direct。

三者的关系可以这样理解:主开关决定"隧道开不开",Global Routing 决定"隧道里怎么走"。切到 Direct 不会断网,只是不再有流量经过代理服务器;切到 Proxy 也不会影响系统本身,Bypass 名单里的局域网地址仍然直连。

Config 姿态:规则说了算

Config 是日常使用唯一需要长期保持的姿态。在这个姿态下,Shadowrocket 从上到下读 Config 页里的规则,第一条命中的规则决定这条连接走 PROXY、DIRECT 还是 REJECT,后续规则不再参与。规则的写法与顺序在第 5 章展开。

切到 Config 姿态之前,先确认 Config 页里有一份被选中的配置。没有配置文件、或配置文件里没有规则时,Config 姿态下的行为会完全交给兜底规则,结果往往与预期不符——这也是"明明开了代理,某个网站却打不开"的常见原因之一。

Proxy 与 Direct:两个临时姿态

Proxy 姿态适合"今天就是要全部走代理"的场景:所有未被 Bypass 的流量都从当前选中的服务器出去,规则不参与判断。它的副作用也很直接——本该直连的局域网访问、本该省流量的近端请求,都会绕一圈,速度与流量开销都会变。

Direct 姿态可以理解为一个"带配置的关闭状态":隧道仍然建立,但没有任何流量进入代理。它适合在需要临时停用代理、又不希望丢掉当前节点选择的场合。用完记得切回 Config,否则下一次连接会继续沿用 Direct。

与 On Demand 的分工

On Demand(按需连接)管的是"什么时候自动开、什么时候自动关",Global Routing 管的是"开了以后怎么走"。两者是正交的:你可以让 On Demand 在蜂窝网络下自动连接,同时让 Global Routing 停在 Config 姿态按规则分流。把这两项混在一起调,是配置越调越乱的常见起点。

怎么确认当前姿态

Home 页顶部会显示当前的 Global Routing 姿态。打开主开关后,状态栏出现 VPN 图标只说明隧道建立了,不代表流量一定走了代理——是否真的走了代理,要在 Data 页的读数里看(第 7 章)。

一个实用的自检习惯:每次调整 Global Routing 或规则之后,打开一个明确写在规则里的域名,回到 Data 页看它的流量落在哪一组读数上,再决定要不要继续改。

三个常见的误配

• 把 Direct 当成"关闭应用"长期挂着,结果订阅更新与节点测速都出现异常。
• 把 Proxy 当成"更彻底的分流",实际上它绕过了全部规则。
• 在 Config 姿态下没有兜底规则,未命中任何规则的流量走向变得难以预测。

规则写在 Config 页的配置文件里,格式统一为"类型,参数,策略"三段。这一章讲清每种类型匹配什么、顺序为什么重要,并给出可以直接照抄的最小片段。

一条规则由什么组成

规则的基本结构是 类型,参数,策略。类型决定拿什么去比对,参数是比对的依据,策略决定命中之后怎么走。策略有三种:PROXY 走代理,DIRECT 直接连接,REJECT 拦截。举例来说,DOMAIN-SUFFIX,example.com,PROXY 的意思是:凡是 example.com 及其子域的请求,都走代理。

常用规则类型对照

DOMAIN 与 DOMAIN-SUFFIX 的差别值得单独记:前者只匹配写出来的那一个域名,后者连同它的所有子域一起匹配。example.com 与 www.example.com 在 DOMAIN-SUFFIX 下由一条规则覆盖,在 DOMAIN 下则需要写两行。

顺序:自上而下,先命中先生效

规则列表是有序的。Shadowrocket 从第一行开始逐条比对,第一条命中的规则决定这条连接的走向,之后的规则不再参与。由此得出两条实践原则:一是把具体的规则放在宽泛的规则前面,例如 DOMAIN 放在 DOMAIN-KEYWORD 之前;二是兜底规则 FINAL 必须放在最后一行,否则它会把后面所有规则都挡掉。

GEOIP 规则需要先得到目标 IP 才能判断归属,所以它通常排在域名类规则之后——域名能判断的先判断,判断不了的再交给 IP 层。这是规则顺序里最常被问到的一点。

一份可以照抄的最小片段

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,example,DIRECT
IP-CIDR,203.0.113.0/24,DIRECT
IP-CIDR6,2001:db8::/32,DIRECT
USER-AGENT,Example*,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

这段配置表达的策略是:example.com 及其子域走代理,其中 api.example.com 与带 example 关键词的请求例外直连;两个示例网段直连;国内 IP 直连;其余全部走代理。把域名与网段换成你自己的目标即可,格式不用改。

如果只想代理少数目标、其余全部直连,把兜底改成 FINAL,DIRECT,并在前面列出需要代理的域名:

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

两种思路没有优劣,取决于使用习惯:前者是"默认走代理、例外直连",后者是"默认直连、例外走代理"。选定一种之后,规则列表会清晰很多。

REJECT 与拦截的边界

REJECT 策略会让命中的连接被拦下,常用于屏蔽特定域名。需要明确它的边界:它只对能匹配到的域名或 IP 生效;HTTPS 连接被拦下之后,表现为连接失败或加载超时,而不是"内容被过滤";应用内自行发起的请求、使用了域名前置或自建解析的请求,可能完全绕过规则。因此不要把 REJECT 当作通用的屏蔽方案,它只是一个规则层面的开关。更细的说明在本站博客《Shadowrocket REJECT 策略:屏蔽原理与拦截边界》里。

修改规则之后

规则改动保存后,需要让配置重新加载:切一次 Global Routing,或者断开再打开主开关即可。改动量大时,建议先在小范围内验证一条新规则,确认命中之后再批量添加——一次性写几十行再回头排查,成本会高很多。

信息填完、规则就位之后,连接与验证是最后一步。这一章讲开关与状态怎么看、Connectivity Test 检查什么,以及连不上时按什么顺序排查。

打开连接与状态指示

Home 页底部的开关就是主开关。打开之后,系统状态栏会出现 VPN 标识,应用内开关会变为开启状态。这两个指示只说明隧道建立了,不说明流量是否走了代理——后者要看 Data 页的读数与当前姿态。

节点选择在列表里完成:点选节点行或它前面的圆点,当前节点会有明显标记。切换节点不需要重新开关,隧道会按新节点重建。

Connectivity Test 检查什么

Connectivity Test 会依次检查几件事:域名解析是否正常、能否连接到所选服务器、以及经由服务器访问外部地址是否成功。结果里会分别列出各环节的状态,失败时会停在第一个出问题的环节。

看结果的方法是从上往下读:解析失败说明 DNS 环节有问题;连接失败说明服务器地址、端口或协议参数对不上;解析与连接都成功但外部访问失败,则更可能是服务器侧的状态问题,以服务商提供的信息为准。

怎么验证分流真的生效

验证分流不需要额外工具,用 Data 页就能完成:

1. 打开一个明确写了 PROXY 的域名,回到 Data 页,看流量是否落在当前服务器的读数上。
2. 打开一个明确写了 DIRECT 的域名,确认它没有增加服务器的读数。
3. 如果第 2 步的读数也在涨,回到 Config 页检查规则顺序,确认没有更靠前的规则抢先命中。

这个三步自检能覆盖绝大多数"规则看起来写了却不生效"的情况。

连接失败时的排查顺序

连不上时,按下面的顺序逐项排除,比反复重装应用有效得多:

1. 权限:确认 VPN 配置授权没有被拒绝,系统"设置"的 VPN 一栏里存在对应配置。
2. 参数:逐字核对 Address、Port、Password 或 UUID 与服务商给的信息是否一致,注意大小写与多余空格。
3. 协议细节:检查 Type 是否选对,TLS、SNI、Path、Host 等字段是否按服务商说明填写。
4. 时间:设备时间明显偏差会影响 TLS 握手,把时间设置改为自动。
5. 姿态:确认 Global Routing 没有停在 Direct。
6. 订阅状态:如果节点来自订阅,先更新一次订阅再判断。
7. 网络环境:换一个网络(例如从 Wi-Fi 切到蜂窝)再试,排除当前网络对 VPN 的限制。

七步里前四步覆盖了大部分失败案例。如果全部走完仍不通,把 Connectivity Test 的结果与服务商核对,问题多半在服务器侧或账号状态,已经超出客户端能处理的范围。

间歇性断流

能连上但时不时断流,通常与网络切换、节点负载或规则冲突有关。可以先观察断流出现的时机:切换 Wi-Fi 与蜂窝时断,多半是网络切换导致隧道重建;固定时段断,可能是节点侧的问题;只在访问特定应用时断,则回到规则里找那条应用的域名是否被 REJECT,或者被错误地指向了直连。

Data 页把经过隧道的流量按两个维度统计:按服务器、按应用。这一章讲清两组读数各自统计什么、为什么与系统统计对不上,以及用它定位异常流量的顺序。

两组读数分别是什么

按服务器一组,统计每个节点承载的上行与下行流量,用途是判断"流量从哪条线路出去",在多个节点之间做取舍时最直观。按应用一组,统计每个应用产生的流量,用途是判断"是谁在用流量"。

两组读数的单位是 B、KB、MB、GB,按 1024 进制换算,界面上通常把上行与下行分列显示。需要留意的是,这里统计的是经过 Shadowrocket 隧道的流量,而不是设备网卡上的全部收发。

为什么与系统统计对不上

系统"设置"里的蜂窝网络统计与 Data 页的读数经常不相等,原因有三个:

• 口径不同:系统统计的是网卡层的收发,包含所有直连流量与系统自身请求;Data 页只统计进入隧道的部分。
• 时间窗口不同:系统统计按计费周期或手动重置的区间累计,Data 页的计数从你上次重置或安装时开始。
• 处理方式不同:部分协议会对流量做额外封装,隧道内的计数与实际网卡计数之间存在正常差异。

三者叠加,两组数字不一致是常态,不需要据此判断"统计坏了"。要判断套餐用量,以服务商面板上的读数为准——Data 页更适合用来做相对比较。

用它定位异常流量的顺序

发现流量消耗异常时,按"总量 → 服务器 → 应用 → 规则"的顺序看:

1. 先看总量增速,确认异常是持续出现的,还是集中在某一段时间。
2. 再看按服务器读数,找出承载流量最多的那个节点。
3. 接着看按应用读数,定位到具体应用。
4. 最后回到 Config 页,检查这个应用的域名是否本该走 DIRECT,却被前面的规则带到了代理。

第 4 步是最容易被跳过、也最容易出结果的一步:很多"流量莫名增加"的情况,根源是某条宽泛的规则把本该直连的请求引到了代理上。相关读数的更多解释在本站博客《Shadowrocket Data 页流量统计怎么看》里。

重置与记录

Data 页提供重置入口,重置后计数从零开始。建议在调整规则前后各重置一次,用两段读数做对照,比盯着累计数字更容易看出改动是否生效。

最后提醒一点:Data 页的流量统计与你的线路套餐用量是两件事。套餐余量、计费周期、超量策略都由服务商决定,以服务商面板为准;客户端这边只能看到经过自己的那部分。

Settings 页集中了不随节点变化的全局选项。这一章挑出日常真正会动的几项,讲清它们各自解决什么问题、什么时候才需要改。

On Demand:按需连接

On Demand 决定应用在什么网络条件下自动连接与断开,触发条件分三类:

• Wi-Fi:按当前连接的 Wi-Fi 名称匹配,可以指定某些网络自动连接、某些网络自动断开。
• 蜂窝网络:在蜂窝数据下自动连接,常用于"出门自动开"的用法。
• 域名:访问特定域名时触发连接,适合按目标而不是按网络判断的场景。

三类条件可以组合,组合之后是"或"的关系:任意一条满足即触发。常见的误配是把条件写成互相矛盾的两条,例如 Wi-Fi 下要求断开、同时又按域名要求连接,结果表现为连接状态反复切换。设置完成后,建议在真实的网络切换场景里验证一次。更细的参数说明见本站博客《Shadowrocket On Demand 按需连接:Wi-Fi、蜂窝与域名触发怎么设》。

DNS

DNS 设置决定域名解析走哪条路径。默认跟随系统即可满足大多数场景;需要指定解析服务器时,可以在这一项里填入地址。改动 DNS 会直接影响域名类规则的判断结果,改完之后按第 6 章的三步自检确认一次。

要提醒的是,DNS 与分流是两层逻辑:先解析出域名对应的地址,再按规则决定这条连接怎么走。解析环节出问题,规则写得再对也不会生效。

Bypass 与局域网

Bypass 名单里的地址永远不进入隧道,常见的例子是局域网网段与本机地址。默认值已经覆盖了常用的私有网段,除非有明确的局域网服务需要访问,否则不需要改动。把公网地址误加进 Bypass,会让本该走代理的流量直接出去。

订阅自动更新

这一项控制订阅的刷新时机:打开时自动更新、按周期自动更新。订阅内容经常变化的用户建议开启;订阅稳定的用户可以关掉,减少每次启动的网络请求。无论开关如何,手动 Update 始终可用。

代理端口与局域网共享

Shadowrocket 可以在本机监听一个代理端口,供同一局域网内的其他设备使用。开启后需要允许本地网络权限(第 2 章提到的第三个弹窗)。这是一项有明确使用场景的功能:只在确实需要给别的设备提供代理时开启,用完关闭。

日志与诊断

日志开关用于记录连接过程。排查疑难问题时打开、复现一次、再关闭,把日志内容与服务商核对。日常保持关闭即可,长期开启只会占用空间。

iCloud 同步与备份

配置可以通过 iCloud 在设备之间同步。开启后,换机时不需要重新整理规则;不开也不影响使用,只是需要手动导出导入。两种方式都可以,关键是选定一种并保持一致,避免两台设备上的规则版本互相覆盖。

不需要动的项

Settings 里还有一批与外观、提示、实验性功能相关的开关。它们大多有合理的默认值,在没有明确需求时保持默认,是让配置保持可预测的最简单方法。每改一项之前,先想一下"它解决什么问题";想不出答案的改动,通常会在几周后变成新的困惑。

最后一章讲日常维护:订阅更新失败怎么查、节点失效怎么处理、换机怎么迁移,以及哪些操作其实不需要做。

订阅更新失败的排查顺序

1. 链接本身:确认订阅链接没有缺字符、没有过期,与服务商当前提供的一致。
2. 网络可达:订阅域名本身可能需要经过代理才能访问,先连接一个可用节点再更新。
3. 返回格式:更新成功但节点列表为空,说明返回内容不是客户端能识别的格式,与服务商核对。
4. 账号状态:以服务商面板上的状态为准,客户端看不到账号侧的信息。

四步之后仍失败,把更新时看到的提示原样发给服务商,比描述"用不了"有效得多。相关的常见原因在本站博客《Shadowrocket 订阅更新:手动更新、打开时自动更新与失败原因》里有更细的展开。

节点失效与切换

单个节点连不上时,先测一次延迟,再换一个节点对照。如果同一订阅下的多个节点同时失效,优先怀疑订阅需要更新或账号状态变化,而不是逐个排查节点参数。频繁在多个节点之间来回切换并不能改善稳定性,固定两三个可用节点、其余留作备用,是更省事的状态。

规则与配置的维护

规则是配置里最容易积累冗余的部分。建议每隔一段时间做一次清理:删掉已经不再访问的域名规则,把重复的条目合并,确认兜底规则仍在最后一行。改动前先导出当前配置留一份副本——配置文件本身很小,备份成本几乎为零。

如果规则引用了远程列表,留意列表本身的更新频率;远程内容不可访问时,本地已有的规则会继续工作,不会导致连接中断。规则写法的系统讲解见本站博客《Shadowrocket 规则写法:DOMAIN、GEOIP、IP-CIDR 与 FINAL 各匹配什么》。

换机与重装

换到新设备时,先在新设备上用同一个 Apple ID 从 App Store 的已购项目里重新下载 Shadowrocket,再从 iCloud 同步或导入之前备份的配置,最后重新填一遍订阅链接(订阅链接属于账号凭据,同步范围以你自己的备份方式为准)。

重装应用之前,先确认配置已经导出。卸载会连同本地配置一起清掉,这一步没有后悔的余地。

应用更新与系统升级

应用更新走 App Store,与普通应用没有区别。系统大版本升级之后,如果连接行为出现变化,先检查 VPN 配置授权是否仍然有效,再按第 6 章的七步顺序排查一次——升级后权限重置是常见的现象,不是应用出了问题。

三个常见误区

• 把客户端当成线路:买断应用不等于获得任何流量,节点与订阅始终来自你的服务商。
• 把"连接成功"当成"线路可用":状态栏图标只说明隧道建立了,实际能不能通要看验证结果。
• 把规则当成万能开关:规则只能决定流量怎么走,不能改变服务器侧的状态,也不能替代服务商提供的服务。

接下来看什么

本页覆盖的是完整流程。如果只想快速跑通,回到使用教程的五步主线;遇到具体问题,常见问题页按"正版核验与购买 / 安装与首次打开 / 订阅与节点导入 / 规则分流与故障排查"四类整理了问答;想深入某一块,可以到日志里找专题文章。