Shadowrocket 故障排查大全

连接开关打不开：先检查系统授权

本章适用于 Home 中的连接开关无法保持开启、刚开启就回到关闭状态，或者首次连接时卡在系统授权。先区分“隧道没有建立”和“隧道建立后不能访问”：前者优先检查系统权限与配置能否加载，后者再检查路由及服务器。仅凭顶部是否出现 VPN 标识，不能判断所有请求已经成功。

确认系统弹窗与当前操作

首次建立连接时，系统可能要求允许添加 VPN 配置，并通过设备密码或生物识别确认。这是系统保存网络配置的授权过程，不是订阅验证。应在理解弹窗用途后完成确认；如果之前取消，回到 Shadowrocket 重新发起连接并观察。不要在弹窗尚未处理时反复点击开关，否则难以判断哪一次操作生效。

如果没有弹窗且开关立即退回，进入系统 Settings，查找 VPN 与设备管理相关入口，核对是否存在 Shadowrocket 对应记录。系统入口名称可能随系统语言与布局变化，以设备实际显示为准。先记录现有条目，不要直接批量删除；受管理设备的网络限制应由设备管理员确认，而不是通过反复重建配置尝试绕过。

排除配置加载与连接竞争

返回 Home，确认 SERVER 中确实存在可选择的服务器，并核对当前选择不是已经删除的订阅项目。导入成功只代表信息被保存，不代表参数一定完整。尤其在替换订阅、删除分组或重新导入 Config 后，需要重新确认所选项目仍然有效。若问题恰好发生在某次编辑之后，先恢复编辑前的备份再测试。

接着检查是否同时存在其他活动的 VPN 配置，或者某个系统管理策略正在重新建立连接。多个接管网络的配置可能相互替换，表现为开关闪回或连接状态不断变化。对自己有权限管理的配置，先停止其他连接，再单独测试 Shadowrocket。不要把系统中所有网络相关设置一并关闭，否则会引入新的变量。

On Demand 也应纳入检查。它可能依据网络条件自动触发连接，造成“手动关闭后又打开”的观感。排错期间先记录原有条件，暂时停用自动触发，使用手动开关重复一次。若手动连接稳定、恢复自动条件后才异常，应集中检查条件匹配，而不是继续修改服务器密码或协议字段。

用最小变更验证恢复路径

确认当前基础网络能够访问普通网页后，完全关闭连接，退出到系统主屏，再重新打开应用测试。仍不正常时可重启设备，用于排除短暂的系统网络状态异常。每次测试都应等待界面完成状态变化；连续快速开关不仅不能缩短握手过程，还可能让日志只留下多次人为中断，掩盖真正的失败原因。

如果最近编辑过 Config，先保留副本，再切换到自己先前确认可用的配置。配置解析错误和远端连接错误并不是同一层问题：前者可能在建立隧道前就终止，后者通常发生在隧道启动之后。查看应用提供的相关提示，优先处理具体报错；不要只依据“连不上”这一描述就同时重写规则与 DNS。

只有在备份完成、确认并非受管理策略限制后，才考虑移除属于 Shadowrocket 的旧 VPN 配置，再由应用重新请求系统授权。此操作处理的是系统配置记录，不会修复过期的订阅或错误的服务器参数。订阅地址、证书和手动条目是否另有备份，应在操作前逐项确认，不能把重新授权当作完整的数据恢复。

本章的完成标准是：开关能够保持开启，系统不再反复要求授权，且手动关闭能够正常结束连接。若满足这些条件但网页仍打不开，转到下一章。若系统始终拒绝保存配置，应记录完整提示、设备是否受管理以及重启后的结果，再按常见问题中的权限说明继续核对。

已连接但无法上网：区分路由与远端失败

连接开关保持开启，只能说明本地隧道处于工作状态；具体请求还需要经过规则匹配、名称解析和远端连接。先关闭 Shadowrocket，使用当前网络访问两个平时可正常访问的网站。如果关闭后也失败，应优先处理 Wi-Fi 认证、蜂窝数据权限或基础网络，而不是更换 Config。完成基础对照后，再开启连接复测同一目标。

先用 Global Routing 建立对照

记录原来的 Global Routing，再按需要使用 Config、Proxy、Direct 做短暂对照。中文说明分别对应配置、代理、直连，但实际界面词仍以英文为准。这些姿态用于改变请求的路径选择，不是改善所有网络问题的通用开关。测试结束后应恢复原本需要的姿态，避免把临时验证设置长期保留。

如果 Proxy 可访问而 Config 失败，重点检查失败请求命中的规则、策略指向以及配置是否真正启用。如果 Direct 可访问而 Proxy 失败，重点检查当前服务器与远端链路。如果只有关闭隧道才恢复，不能立即认定是节点故障，还要检查隧道内的 DNS、系统权限和其他网络配置是否存在交互影响。

检查规则顺序，不用整份替换

规则一般按配置中的顺序判断，较宽泛的条件放得过早，可能先匹配到原本需要另一策略的请求。核对时先找具体域名对应的规则，再检查后面的兜底策略。下面片段只用于理解匹配顺序，不是适用于所有环境的完整配置；实际使用前，还需要确认已有配置中的策略名称与运行环境相符。

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

示例中，第一条处理指定域名及其子域，第二条按地理地址判断，最后一条接收此前未匹配的请求。若把范围很大的规则放在前面，后面更具体的条件就可能没有机会参与判断。修改时先复制当前 Config，仅在副本中调整一条相关规则，再用同一请求验证，避免一次替换整份配置导致无法回溯。

如果某个网站首页能开、图片或登录失败，应把这些请求视为不同目标。页面可能同时访问主域名、静态资源域名和身份验证域名；只给首页域名写规则，不能保证关联资源走相同路径。观察相关请求的域名与实际策略，再补足确有需要的条件。不要为了修复单个资源，直接把全部流量都改到另一条路径。

把规则判断与业务响应分开

当应用提供连接记录时，可在复现一次问题后核对目标域名、匹配规则、选择策略及错误类型。应先确认记录对应的是本次操作，而不是后台刷新产生的其他请求。HTTP 状态、认证失败或网站拒绝访问，与底层无法连接不同；能够收到远端业务响应，通常已经比单纯超时更接近应用层，应按响应内容继续判断。

规则为 REJECT 时，请求被主动拒绝可能正是配置的预期结果。遇到网页元素缺失，先确认对应资源是否被这类规则匹配，而不是直接判定服务器失效。若确需放行，应只调整相关条件并记录原因。与此同时，名称解析失败可能使基于地址的后续判断受到影响，涉及此类现象时还应参阅 DNS 章节。

本章的完成标准是能够说明“哪个目标、在哪种姿态、经哪条策略失败”。保存这个结论比保存一张笼统的连接状态图更有用。若 Proxy 下所有目标都超时，转到节点超时章节；若只在 Config 中异常，继续细查规则；若所有路径都出现名称解析错误，优先进入 DNS 检查，不要重复调整已经验证正确的服务器信息。

节点超时：分层核对服务器与协议参数

Connectivity Test 的超时是测试没有在规定条件内得到预期结果，不等于所有业务请求都必然失败。不同测试方法可能涉及不同目标与协议，因此应同时观察实际网页访问。先记录是单个项目超时、同一订阅中的多个项目超时，还是所有已有项目都失败；范围不同，后续检查方向也不同，不能仅凭一个数字比较可用性。

从网络范围确定检查方向

先在当前网络测试一个自己此前确认可用的目标，再在允许使用的另一种网络下重复。若相同服务器在蜂窝数据正常、在某个 Wi-Fi 失败，应检查该网络的认证状态、访问限制与出口条件。若所有网络都失败，则更应核对服务器是否仍在运行、端口是否正确、账户是否有效，以及服务端配置是否已经发生变化。

不要用连续批量测试代替定位。先选择一个项目，确认测试完成后再观察实际访问，避免大量并发请求影响结果或触发远端限制。记录时间与网络类型，有助于区分持续故障和偶发波动。若只有某个时段失败，应保留该时段的重复结果，而不是依据一次成功就认定配置已经完全恢复。

按服务端原始信息逐字段核对

服务器地址和端口应与自己的服务端信息一致。地址中的前后空格、复制时混入的换行、错误的端口，都会导致无法建立连接。端口并非可以随意尝试的选项：必须是服务端实际监听的端口。使用域名时还需要确认解析结果正确；使用地址临时对照时，则要保留原本需要的 TLS 主机名语义。

带有传输层设置的项目，还应对照服务端检查传输类型、路径及相关主机字段。地址用于找到服务器，TLS 主机名用于验证对端身份，某些传输的主机字段则服务于请求路由，它们并不总是相同概念。只有在服务端明确要求一致时才填写同样内容，不应看到多个域名输入框就机械复制同一个值。

证书错误通常有比“超时”更具体的提示，应核对设备日期时间、证书有效性及名称匹配。不要把关闭证书验证作为常规解决办法，那会改变安全边界，却不能解决服务端证书配置本身的问题。如果自己管理服务器，应修复对应证书与服务配置；如果使用已有服务信息，应按其有效参数核对，而不是猜测组合。

识别传输限制与服务端问题

部分协议或功能依赖 UDP，网络允许普通网页访问并不意味着相关流量也一定可达。若某种传输只在特定网络失败，应将网络差异与服务端要求一起检查。不要盲目调整 MTU、保活或超时参数；这些设置需要有分片、路径或空闲连接方面的证据，否则容易把原本单一的故障变成多个配置变量叠加。

对于自己管理的服务器，可以核对服务是否运行、监听端口、防火墙及同时段的服务端记录。客户端显示连接被关闭，可能来自远端主动结束，也可能来自中间网络中断，单一提示不能确认原因。应把客户端与服务端的时间对应起来，再判断请求是否到达以及停在哪个阶段；不需要把完整的认证信息复制进排查记录。

若更新订阅后旧项目消失或地址改变，应以当前有效信息重新选择项目，不要继续测试已经不再维护的本地条目。订阅中的显示名称只是标识，名称相同不代表底层参数相同。恢复后保存必要的核对结论：失败网络、错误阶段、修正字段与实际访问结果；订阅仍无法刷新时，再按下一章检查获取与解析链路。

Subscribe 失败：区分获取、解析与项目变化

订阅更新包含几个独立环节：请求地址、取得响应、解析内容、写入项目。失败可能发生在其中任意一步。先保留原来的有效条目，不要先删除再尝试更新；否则一次临时请求失败就可能把可用的本地信息一起清空。排错时应记录具体提示，区分连接超时、状态异常、格式不支持以及更新成功但项目数量变化。

先保护地址，再核对完整性

订阅地址可能包含访问凭据，应按敏感信息保存。复制时核对是否缺少后半段参数，是否混入空格、标点或聊天软件附加的换行。不要把完整地址放到公开讨论区，也不要用不明页面替自己转换内容。需要向他人说明结构时，应只保留域名类型和参数名称，并将能够识别账户的值遮盖。

浏览器能打开一个地址，并不代表返回的就是可导入内容。浏览器可能已有登录状态，或者展示的是网页、验证页面、访问错误说明。应依据应用提示及自己的订阅说明判断响应类型。若查看原始响应，只需核对内容是不是预期格式，不要把整段可能包含认证信息的文本复制到公共位置。

把网络失败与内容失败分开

请求超时或域名解析失败，先进入网络与 DNS 检查；明确的认证失败则应检查地址是否失效、账户状态以及凭据是否变更。遇到请求过于频繁的提示，应停止重复刷新，按响应要求等待后再试。不断删除重加通常不会恢复访问权限，反而可能让服务端看到更多重复请求，增加判断难度。

若订阅获取依赖当前代理，而当前代理恰好又来自失效的订阅，就可能形成更新依赖。应先判断该地址在当前网络是否能够直接访问，以及应用当前配置如何处理更新请求。已有其他确认可用的路径时，可用它作一次对照；没有时，应先恢复基础连通条件，不能指望一次更新自动修复所有网络层问题。

格式错误应核对服务端给出的内容是否为 Shadowrocket 当前支持的导入形式。网页链接、配置文件地址和服务器分享信息并非完全相同的对象，不能只因它们都能复制就放进相同入口。按自己的原始信息选择 Subscribe 或对应导入操作；首次使用不确定入口时，可返回快速上手核对操作主线。

确认“更新成功”后的项目状态

更新成功但列表变空，需要检查返回内容是否确实包含有效项目，或者是否经过了筛选。项目减少也可能源于服务端正常移除条目，不宜直接判断为客户端丢失。先保存当前结果，与自己持有的订阅说明对照，再确认是否存在名称过滤、分组差异或临时响应异常。不要在未查清原因前多次覆盖唯一的本地备份。

手动编辑订阅生成的条目后，下一次更新可能重新写入服务端信息。因此，用于试验的参数最好另存为明确标记的手动项目，并保留原订阅作为对照。两者名称应能区分，避免以为修改没有生效，实际测试的却是另一个条目。排查结束后整理临时副本，防止日后继续选择过期的测试信息。

导入项目和启用 Config 也应分别确认。Subscribe 解决服务器信息的更新，不会自动保证所有规则、DNS 与策略都适合当前网络。即使新项目已经出现在 Home，仍需要选择有效服务器，核对 Global Routing，并完成实际访问测试。如果列表更新成功但无法连接，应转到节点超时章节，而不是继续反复导入同一地址。

建立可恢复的更新习惯

在进行较大调整前，备份自己需要保留的手动信息与 Config，并确认备份中包含哪些内容。不同导出方式覆盖的数据范围可能不同，不能把“已有一个文件”等同于所有信息都已保存。将敏感备份存放在自己控制的安全位置；展示问题时，只提供错误类别、发生时间和去除凭据的必要结构。

本章的完成标准不是列表出现一次，而是能够重复更新、项目内容符合预期、选中项目可以实际使用。若地址本身已失效，应按自己已有服务的管理方式更新信息；应用购买与订阅有效性是两条独立关系。有关购买或已购恢复的问题，应到已购项目恢复说明处理，不要通过重复购买客户端尝试修复订阅。

速度慢：分开测量响应、吞吐与稳定性

“慢”至少包括首次打开等待长、开始传输后吞吐低、播放时反复停顿，以及网络切换后短暂中断。先把现象写具体，再决定测什么。Connectivity Test 的响应结果只覆盖特定测试条件，不能直接代表大文件传输速度，更不能代表所有网站的表现。一次较低的测试时间，也无法排除后续丢包或远端拥塞。

建立可比较的测试条件

选择一个平时可访问的固定目标，在相同设备、相同网络和相近时段下比较。先测关闭连接时的基础访问，再测当前配置，最后才更换自己已有的其他有效项目。每轮只调整一个条件，保持其他应用的下载与同步状态尽量一致。若同时换网络、换节点、换规则，任何改善都无法归因，也就难以稳定复现。

观察慢发生在哪个阶段。输入地址后长时间没有开始，可能与名称解析、连接建立或握手有关；已经持续传输但速度偏低，更应检查链路容量、丢包及服务端负载；单个页面某些资源迟迟不出，则可能是相关域名走了不同策略。阶段判断比只记录“打开用了很久”更能缩小排查范围。

排除本地网络与目标差异

Wi-Fi 信号格数不能完整反映网络质量。距离、干扰、接入点负载和宽带出口都可能影响传输。先靠近接入点测试，并确认同一网络没有大规模后台传输；再与蜂窝数据作对照。若只有一处 Wi-Fi 表现差，优先检查该网络。如果蜂窝数据同样异常，再核对设备是否处于低数据模式或应用网络权限受限。

同一个代理项目访问不同目标，速度可能差异明显，因为远端出口到目标网站的路径并不相同。目标自身负载、资源分发节点以及账户侧限制，也可能影响结果。应使用不止一个目标确认范围，但不必进行大量并发测速。一次面向特定网站的缓慢，不足以证明客户端整体性能异常，也不适合作为修改全部配置的依据。

核对规则、重试与后台负载

Config 中某些资源被 REJECT 或被送到不可用策略时，网页可能等待重试后才继续，表现像网速慢。先查看失败请求是否集中于同一域名或同一策略，再检查规则顺序。若 Proxy 下页面完整而 Config 下明显拖延，可以围绕相关规则做局部对照，不必为了排错长期改变所有请求的路径。

同时检查是否有频繁的订阅刷新、批量连接测试或大量诊断记录。它们未必是根本原因，但会占用网络与处理资源，干扰测试。排错时先停止不必要的重复操作，只保留当前需要的观察项目。不要为获得更多信息无限延长详细记录；找到可复现条件后，保存必要片段即可，随后恢复正常使用设置。

传输参数应以已有服务器要求为基础。随意提高并发、不断缩短超时或修改 MTU，并不能保证改善速度，反而可能导致更多连接重建与重传。只有当证据指向特定问题时才测试相关参数，例如某种网络下大包传输异常而小请求正常；测试前保存原值，并明确什么结果才算改善，什么情况下需要回退。

用实际任务验证改善

如果更换已有有效项目后恢复，应再次确认原项目在相同条件下是否仍然慢，避免把时间变化误当作节点差异。若所有项目都在同一网络慢，而另一网络正常，继续追查本地出口。如果所有网络都只对某个目标慢，应检查目标服务与访问路径。每个结论都应至少有一次重复对照，而不是只依赖偶然成功。

测试还应考虑设备温度与后台任务。刚完成系统更新、照片同步或大量内容索引时，设备可能同时处理多项工作，网页渲染慢也会被误认为传输慢。将“内容下载完成”和“页面显示完成”分开观察；设备明显发热时，暂停高负载任务后再测，不要边持续充电高负载运行边比较细小差异。

最终用原来出问题的任务验收：连续浏览是否稳定、播放是否仍停顿、切换网络后能否恢复，而不是只追求某次测试数字更小。保留两三条有解释力的记录即可。若等待主要发生在域名首次解析阶段，进入下一章；若速度问题伴随明显耗电，再结合耗电章节检查后台重连与诊断活动。

DNS 问题：核对解析路径与缓存

DNS 负责把域名转换为后续连接需要的地址。名称解析成功不代表服务一定可达，解析失败也不等于服务器认证出错。常见现象包括某些域名打不开、首次访问等待明显、切换网络后短时异常，以及同一域名在不同路径上结果不同。先记录目标域名和具体错误，再确认问题是否确实发生在解析阶段。

区分系统 DNS、自定义 DNS 与加密解析

系统 DNS 通常随当前网络获得，自定义 DNS 则改变解析请求使用的服务。DNS over HTTPS 通过 HTTPS 传输解析请求，但它仍依赖底层网络可达、正确的证书验证与可用的服务地址，并非填写后就能修复全部连接问题。选择方式时应考虑当前网络条件，而不是只根据形式判断可靠程度。

若某个加密解析服务使用域名作为入口，还需要考虑初始连接如何得到它的地址，以及请求本身经过哪条路径。已有代理完全不可用时，依赖该代理才能到达的解析服务也可能失败。先把这一依赖关系画清楚，再决定用哪种可达方式作对照，不要同时替换 DNS、服务器和全部规则，使错误链条变得更长。

用单个域名做可重复检查

挑选一个反复失败的域名，在同一网络下分别观察关闭连接与开启连接后的结果。若只有开启后失败，核对当前 Config 中的 DNS 设置和解析请求路径；若两种状态都失败，应检查网络侧解析和目标自身状态。测试时使用完全相同的域名，不能把主页域名与图片资源域名的不同结果当作同一次对照。

不要把“直接访问某个地址成功”当成域名问题的唯一证明。HTTPS 服务可能依赖 TLS 主机名与虚拟主机路由，直接输入地址会改变请求语义，结果不能简单比较。更稳妥的方法是结合解析记录、错误阶段与实际连接记录判断；需要指定地址测试时，也应保留服务要求的主机名，而不是关闭验证。

理解规则与解析的相互影响

DOMAIN、DOMAIN-SUFFIX 与 DOMAIN-KEYWORD 根据域名条件进行判断；IP-CIDR、IP-CIDR6 以及 GEOIP 则涉及地址条件。是否需要先解析、解析得到哪些地址以及后续如何匹配，都与实际规则和配置有关。排错时不应把所有请求都视为只匹配一次域名规则，应查看失败请求的实际处理结果。

[Rule]
DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.org,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,PROXY

上面的地址段是文档示例，不能据此配置自己的实际网络。no-resolve 用于表达该地址规则不主动为匹配而触发域名解析，并不表示全局停止 DNS。理解这一区别，才能避免为了减少一次解析而改变整份配置的行为。将示例用于学习后，应回到已有配置中检查相关规则，而不是直接覆盖正在使用的内容。

同时留意 IPv4 与 IPv6。某个网络能够返回 IPv6 地址，却未必具备稳定可用的对应路径，可能出现部分请求等待后才改用其他地址的现象。先对比不同网络的结果，再核对地址族与连接记录。不要在没有证据时直接关闭所有 IPv6 相关设置；改变地址选择会影响其他请求，必须保留恢复路径。

处理缓存与配置覆盖

修改解析设置后，已有连接、应用缓存或系统缓存可能让短时间内的结果与预期不同。先停止当前连接，重新建立后测试新请求；必要时结束目标应用的旧会话再访问。只有确实需要时才重启设备，不应把每次重启后的偶然恢复当成最终修复。记录变化是否持续，才能判断是缓存影响还是问题本来就间歇发生。

还应检查设备是否启用了其他 DNS 配置描述文件，以及当前 Config 是否覆盖应用中另一个入口的设置。看到设置页填有某个值，并不能证明本次请求实际采用它。以生效配置和记录为准，逐项排除覆盖关系；对于受管理设备，不要擅自移除组织下发的网络设置，应先确认管理要求与自己的操作权限。

本章的完成标准是：目标域名能得到合理结果、后续连接能继续，且切换网络后仍可复现正常行为。更完整的选型说明见Shadowrocket DNS 设置详解。若解析正常而握手失败，应回到服务器参数检查；若只有个别资源被拒绝，则返回规则章节，不要继续更换已经验证可用的 DNS。

耗电与更新后异常：检查后台活动和配置变化

耗电增加与更新后异常经常被放在一起描述，但需要分别取证。前者要看观察时段内的实际活动，后者要确认究竟发生了什么变化。连接保持开启不代表一直在大量传输，系统电池统计中的应用占比也不是该应用独立造成全部耗电的证明。先确定可比较的使用条件，再判断是否存在持续异常。

让电池观察具备可比性

在系统 Settings 的电池统计中查看相近时长的使用区间，同时记录屏幕开启时间、信号状况、充电与否及主要任务。弱信号、视频播放、热点共享和后台同步都可能增加整机耗电。若一段时间主要在待机、另一段时间持续传输，两个百分比不能直接比较；应尽量在相似任务下观察趋势。

网络扩展承担其他应用经过隧道的通信，系统统计的归属需要结合总流量理解。可以对照 Data 中的活动情况，判断是否存在自己未预期的大量传输；但不要凭统计归属就直接认定某个进程空转。先找出当时是否有照片同步、内容下载或其他后台请求，再决定是否需要调整 Shadowrocket 设置。

检查反复重连与诊断负载

持续失败后重试，可能比稳定保持连接带来更多握手和网络唤醒。检查是否在信号不稳时频繁重建、是否存在过密的测试，以及 On Demand 条件是否反复触发。先保存原设置，暂时停止不必要的自动测试和诊断，再观察相同时长。不要仅为省电盲目改变服务端要求的保活设置，否则可能引入空闲后断线。

详细日志适合短时间复现问题，不适合没有目标地长期收集。记录中还可能包含域名、地址及其他使用信息，因此排查完成后应恢复日常设置，并按需要清理敏感记录。若设备明显发热，先停止高负载任务，待状态稳定后继续对照；温度异常持续存在时，还应检查设备与系统层面的其他原因。

确定更新改变的是哪一层

应用更新、系统更新、订阅刷新和远端 Config 更新属于不同变化。回忆最后一次正常使用后发生的操作，并分别记录。应用更新应通过 App Store 核对；系统要求以 App Store 页面标注为准。订阅或远端配置可能独立于应用更新发生变化，不能因为时间接近，就认定所有异常都由应用更新造成。

先做最小复测：保留当前数据，使用先前确认有效的服务器和配置，手动建立连接，再访问固定目标。如果服务器未变而 Config 变更，应优先比较规则、DNS 与策略引用；如果只有订阅项目变更，则重新核对字段。若所有信息都没变，但系统权限状态改变，再回到连接开关章节检查授权与系统记录。

比较配置时，应围绕实际字段差异，而不是只看文件名称。相同名称的远端文件可能已经被更新；不同名称的本地副本也可能内容一致。恢复先前副本可以帮助定位，但不意味着应该长期忽略必要调整。确认某项差异导致故障后，应理解其用途，再选择修正或恢复，避免把所有新设置一概删除。

重装不是第一步

重新安装前应确认备份范围、订阅地址与手动项目的保存位置，并核对 App Store 的购买账户。应用能够重新获取，不代表本地配置会自动完整回来。有关购买恢复请参阅已购恢复；该流程处理应用获取权，不负责恢复自己的服务信息，也不会改变远端服务器的可用性。

如果确实需要重新建立环境，应一次只恢复一部分：先验证授权与基础连接，再恢复自己已有的有效服务器，最后恢复完整规则和额外设置。这样能找到异常随哪一步重新出现。把所有备份一并导入后直接测试，只能知道问题还在，无法判断是旧配置、网络条件还是某项后台行为造成。

本章的完成标准是异常活动减少、常用任务正常，并能在相近使用条件下重复观察。对外描述问题时，可提供系统类型、网络类型、变化类别和去除敏感信息的错误片段，不必公开全部备份。若只有 iPad 出现异常，而同样信息在其他自有设备正常，继续阅读下一章，从设备网络与配置差异入手。

iPad 专项：检查网络权限与配置一致性

iPad 与 iPhone 可以使用同类服务器信息，但设备网络条件并不一定相同。常见差异包括只有 Wi-Fi、具备蜂窝数据、通过热点联网，以及使用受管理的网络配置。不要因为同一个订阅在一台设备正常，就认定另一台一定是应用损坏；先把设备实际使用的网络、所选项目和生效 Config 对齐，再做比较。

先确认基础网络是否真正可用

连接公共 Wi-Fi 后，可能还需要完成网络自己的认证页面。此时状态栏显示已接入，并不意味着已经能够访问外部目标。先关闭连接，完成网络要求的正常认证，并访问普通网页验证；基础网络恢复后再开启 Shadowrocket。若认证会话过期，应先处理网络登录，反复更新订阅通常不能解决这类问题。

使用蜂窝数据的设备，应在系统 Settings 中核对应用是否获准使用蜂窝数据，以及是否启用了影响后台活动的限制。仅具备 Wi-Fi 的设备不需要寻找不存在的蜂窝选项。系统要求与适用设备以 App Store 页面标注为准；首次获取和授权步骤可在iPad 获取说明中对照，不必凭另一台设备的菜单位置推断。

同名不等于同配置

对照两台设备时，逐项确认服务器地址、端口、协议、TLS 与传输字段，而不是只比较显示名称。订阅可能在不同时间更新，列表中的同名项目也可能已经变更。随后确认 Global Routing 与 Config 的实际选择；一台处于 Proxy、另一台处于 Config 时，访问结果不同本来就可能来自规则，而非设备性能。

大屏界面可能以不同方式呈现列表与详情。进入某个配置的详情，不一定表示已经将它选为当前使用项；编辑一个服务器，也不一定会改变正在使用的另一个项目。完成编辑后返回实际选择界面，再确认生效对象。对界面词不熟悉时，可阅读Home、Config 与 Settings 界面词对照。

备份导入之后，也要核对它到底恢复了哪些内容。服务器、订阅地址、规则文件与系统 VPN 授权是不同层的信息，不能假设复制一个文件就完成了所有步骤。首次连接仍可能需要系统确认。应按“数据存在、项目选中、配置生效、系统授权、实际访问”的顺序验收，每一步都有明确结果后再进入下一步。

热点、网络切换与受管理设备

iPad 通过其他设备的热点上网时，其网络路径与热点提供设备自身的应用流量不必相同。不要把热点提供设备的连接状态，直接当作 iPad 请求已经走相同路径的证明。应在 iPad 上独立检查当前网络与连接结果；热点信号不稳、提供设备省电或上游网络变化，也都可能表现为间歇断流。

在 Wi-Fi 与蜂窝数据之间切换后，已有连接可能需要重新建立，解析结果也可能暂时沿用旧状态。先等待切换完成，再发起新的请求；若持续失败，停止连接后重新建立，并与稳定停留在同一网络的结果比较。On Demand 条件也要核对，防止切换网络时重复触发，或在预期之外重新连接。

学校或组织管理的 iPad 可能受到网络策略、证书、配置描述文件及 VPN 使用规则限制。对此应先确认设备管理要求，不要删除不属于自己管理范围的设置。若同一设备只有组织网络失败，应记录该网络下的现象并交由管理员核对。服务器参数、系统权限与组织策略需要分别处理，不能用修改认证字段替代权限确认。

完成交叉验证并保留恢复路径

需要交叉测试时，可让两台自有设备接入同一个允许使用的网络，并使用各自保存的相同有效信息，依次而非大量并发访问同一目标。结果不同则继续检查设备设置；结果相同而换网络后改变，则更接近网络路径差异。还应注意自己已有服务的并发限制，避免测试方式本身触发远端限制，造成错误结论。

最后回到平时的实际使用方式，验证前台访问、短时锁屏后的恢复和正常网络切换。不要只以一次 Connectivity Test 成功作为结束。保留可用 Config 的安全副本，记录修正的是权限、参数、规则还是网络条件；后续再次出现问题时，便能从变化点开始检查，而不是重新执行所有操作。