Shadowrocket
故障排查大全

01 连接开关打不开：先确认系统权限

适用症状包括：Home 中连接开关打开后立即回落、系统反复要求添加 VPN 配置，或应用显示正在连接却没有进入稳定状态。此时不要先修改规则，也不要把问题直接归为服务器故障。开关能否保持开启，首先取决于系统是否允许建立网络扩展、当前配置是否有效，以及是否有其他连接任务正在接管同一条系统通道。

记录开关回落前发生了什么

先记下设备型号、当前网络、选择的服务器和 Global Routing 状态，然后尝试连接一次。观察系统弹窗是否出现、是否完成设备验证、开关经过多久回落，以及屏幕是否显示具体错误。一次完整观察比连续快速切换更有价值。反复点击可能让上一次连接尚未退出就开始下一次，使真正的失败阶段被等待状态覆盖。

断开连接后，用浏览器访问自己平时可直接访问的页面，确认 Wi-Fi 或蜂窝网络本身已经可用。如果当前无线网络需要网页认证，先完成认证再测试。能看到无线信号并不等于已经取得网络访问权限；网络尚未通过认证时，订阅、服务器握手和普通网页都可能同时失败，容易被误判为客户端开关异常。

核对 VPN 配置授权与系统状态

首次连接出现添加 VPN 配置提示，是系统对网络配置变更的授权流程。核对发起应用为 Shadowrocket 后，按系统要求确认。随后在系统设置中搜索 VPN，找到对应配置并检查状态；不同系统的菜单层级可能不同，以当前设备显示为准。不要仅凭顶部状态图标判断，部分设备和显示场景不会始终展示相同的状态标识。

如果此前拒绝了授权，回到应用重新发起连接，观察系统是否再次请求确认。如果对应配置已被手动删除，也应从应用重新建立，而不是自行填写一份名称相似的系统配置。已有配置存在却反复报错时，先保存应用内服务器和 Config，再考虑移除仅属于 Shadowrocket 的系统 VPN 配置并重新授权；不要删除无法确认归属的管理配置。

受管理设备先确认权限边界

学校或工作单位管理的设备，可能限制 VPN 配置变更。系统明确显示管理限制时，应由设备管理员核对策略，不要通过反复重建配置来绕过限制。

排除连接竞争，再建立最小测试

检查系统中是否还有其他已启用的 VPN 配置，或由网络扩展提供的过滤功能。先暂停自己明确了解且允许暂停的功能，再测试 Shadowrocket。此步骤只用于排除接管竞争，不意味着这些功能必然不兼容。若暂停后恢复，应分别重新启用并复测，定位具体组合，而不是长期关闭所有保护设置。

接着检查 Home 中是否确实选中了有效服务器，不能只确认列表里存在条目。以服务商当前提供的参数为准，选定一项自己有权使用且信息完整的服务器，暂时关闭 On Demand，手动连接一次。若开关能保持，但页面访问失败，故障已经进入数据通路阶段，应转到下一章，而不是继续删除系统配置。

如果应用无响应，可先正常退出应用、重新打开，再按相同步骤测试；仍无法建立时再重启设备。重启用于清理临时系统状态，不会修正错误密码、失效订阅或服务器端故障。重新打开后务必确认选中项没有改变，并等待连接明确结束后再进行下一次操作，避免把后台尚未完成的任务当成新的故障。

怎样确认已经解决

连接开关能够保持、系统显示对应 VPN 已连接，并且测试请求能完成，才算这条流程通过。若仍然回落，记录完整错误文字和发生阶段，再查阅添加 VPN 配置提示说明。反馈时提供必要的设备与错误信息即可，不要发送密码、订阅完整地址、二维码或含账户凭据的配置内容。

02 已连接但无法上网：分清路由与出口

连接开关保持开启，只说明系统隧道已经建立，并不能证明所有请求都有可用出口。此类问题应拆成三层：设备原始网络能否访问、选中的服务器能否转发、当前 Config 是否把请求交给预期策略。先保存当前配置副本和选中项，再用固定的测试页面进行对照；不要同时换服务器、改 DNS 和重写规则，否则恢复后也无法判断原因。

用 Global Routing 做短时对照

在 Global Routing 中，Config、Proxy、Direct 分别对应配置、代理、直连三种姿态。它们适合用来隔离问题，但不是三个可以随意混用的“修复按钮”。测试前说明目的：Direct 用于观察基础网络路径，Proxy 用于观察所选代理路径，Config 用于观察规则实际选择。各姿态只做同一请求的短时比较，完成后恢复原本需要的 Config。

若 Direct 下熟悉的页面也打不开，先退出连接，排查无线网络认证、蜂窝数据权限和当前网络状态。若 Direct 正常、Proxy 失败，优先转到服务器参数与可达性检查。若 Proxy 正常而 Config 失败，重点检查命中规则、策略名称和配置中的 DNS 设置。上述结论只针对本次测试目标，不能由一个网站推广到全部应用。

规则按顺序命中，不按“看起来更具体”排序

规则通常自上而下检查，前面的规则命中后，后面的规则就不会替同一请求重新决定策略。一个较宽的 DOMAIN-KEYWORD 放在前面，可能先于后面的精确域名规则生效；FINAL 则应承担前面均未命中时的兜底。先查看连接记录中的目标与策略，再回到 Config 查实际顺序，不要只搜索有没有某条规则。

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

以上仅演示规则语法和顺序，不是一份可直接覆盖现有设置的完整配置。PROXY 必须在当前配置与所选服务器的使用方式中有明确对应；自定义策略名称也必须实际存在。example.com 为教学域名，不代表某项业务应采用的策略。复制片段前先理解它改变了哪些请求，尤其不要把陌生配置整份覆盖到正在使用的 Config。

只改一条规则，观察一条新连接

假如只有某个域名失败，先确认实际请求是否还依赖登录、静态资源或媒体子域名。页面主域名走向正确，不代表其全部资源使用相同策略。借助连接记录找到失败目标，只对已确认的域名进行最小调整。修改后重新发起请求；已经建立的长连接可能继续使用原路径，不能用旧连接的表现判断新规则是否生效。

如果访问的是局域网设备，还要核对设备地址和当前无线网络是否处于同一可达范围。配置里出现私有地址 DIRECT 规则，不代表访客网络允许访问其他设备，也不代表蜂窝网络能到达家中地址。应先验证基础局域网连通，再检查规则；将所有流量切到 Proxy 通常不会解决局域网隔离，反而可能让定位更困难。

恢复条件要写清楚

找到异常规则后，保留修改前后的顺序及一次命中记录。恢复 Config，再复测网页、登录和必要的局域网访问，避免只修复单个页面却改变其他业务路径。

若规则调整后仍失败，而相同目标在 Proxy 下正常，可进一步检查配置中的解析与策略引用。术语含义可查术语手册；首次选择 Global Routing 的完整操作见使用教程。不要在没有记录的情况下连续添加大量规则，重复或相互覆盖的条目会让之后每次排查都更难复现。

03 节点超时：区分可达性、握手与参数

超时表示某一步在等待期限内没有得到预期响应，不等同于已经证明服务器停机。请求可能停在域名解析、建立连接、协议握手或目标转发阶段。先确认是单个服务器超时、已有订阅中的多个服务器超时，还是只有某个目标超时。把范围写清楚，才能决定应检查设备网络、服务商信息还是应用配置。

先确认测试到底测了什么

Connectivity Test 的结果受测试方法、目标地址和网络条件影响。某种探测失败，不必然代表实际网页访问失败；探测成功，也不说明登录、视频或持续传输一定正常。先查看测试所用方式和目标，再做一次真实业务请求。不要只依据列表中的单个测试数字反复切换服务器，更不要将不同方法的结果直接比较。

测试时固定网络、目标和所选服务器，等待前一次测试结束。随后只切换 Wi-Fi 与蜂窝网络再试一次；iPad 若没有可用的蜂窝连接，可使用自己信任的另一网络。若仅某个网络失败，说明需要继续检查该网络的路由、端口可达性或协议条件，而不是马上改写服务器密码。若所有网络都失败，再核对服务器端信息。

按协议检查必要字段

打开 Add Server 或对应服务器的编辑界面，对照自己的服务商提供的信息，逐项核对地址、端口、协议类型、认证字段及传输参数。地址前后多出的空格、错误端口、复制不完整的标识，都可能导致等待或握手失败。不要用“名称看起来一样”代替逐字段核验；显示名称只是便于识别，不参与证明连接参数正确。

传输方式、Host、路径和服务器名称并非可以互相替换的字段。服务端使用特定传输配置时，客户端必须与其对应；不能看到 TLS 错误就随意更换名称，也不能把分享链接中不认识的部分全部删除。优先重新导入服务商当前提供的原始信息，再与手工条目比较；先保留旧项，避免覆盖后无法追溯差异。

TLS 报错与超时要分开处理

如果记录明确显示证书、名称或时间相关错误，应先核对设备日期与时间是否准确，再检查服务器名称是否与服务端要求一致。证书验证失败不是普通测速偏慢，关闭证书验证也不是通用解决办法。证书过期或部署不一致应由服务器管理方修正；客户端需要保留校验条件，避免用降低验证要求掩盖配置错误。

若同一服务器以前可用、现在全部请求失败，检查服务商处的账户有效状态、服务端变更通知和当前参数。应用购买完成不代表远端服务持续可用，更新订阅也不代表远端已经恢复。联系服务商时提供失败时间、网络类型、协议及经过脱敏的错误文字，比仅发送“超时”更有助于判断端口、认证或上游异常。

用替代项定位范围，而不是盲目轮换

只有在自己的已有信息中另有已知可用项时，才用它作对照。若对照项正常而原项失败，优先检查原服务器；若全部项都失败，回到系统权限、基础网络和 DNS。没有可靠对照项时，也可以通过切换网络和核对错误阶段逐步缩小范围，不需要为了诊断临时导入来源不明的条目或公开配置。

解决后应连续验证建立连接、打开目标和短时持续传输三个环节。一次探测通过只能说明当时某条探测路径可用。若连接刚建立就断开，记录断开发生在空闲、切网还是开始传输之后；这些条件分别指向连接维护、网络切换或传输路径问题，应进入速度与间歇中断章节继续排查。

04 订阅失败：分开检查获取、解析与导入

订阅更新是获取远端内容并解析为条目的过程，不是服务器连通性测试。更新失败时，已有服务器可能仍然可用；更新成功时，返回的服务器也可能因认证、网络或远端状态而无法连接。先分清失败发生在下载内容、识别格式还是保存条目，再决定是否修改链接。订阅地址应从自己的服务商处获取，本站只解释导入与设置。

先保住现有可用条目

操作前记录订阅名称、当前条目数量、选中项和最近一次错误文字。若现有条目还能工作，不要立即删除整个订阅分组，也不要把旧链接覆盖后才开始检查。可以在安全保存原始信息的前提下新建一个对照项，确认新链接能正确导入，再清理旧项。删除分组可能同时移除条目和关联选择，使原本可用的状态难以恢复。

区分单节点分享链接与 Subscribe 所需的订阅地址。单节点链接描述一个服务器，订阅地址通常用于获取一组可更新的内容；把其中一种放进另一种入口，可能表现为空列表或无法解析。复制时检查是否混入聊天说明、换行、标点或页面标题。不要自行删掉地址中的查询部分，它可能承载账户识别或格式选择信息。

判断是否真正取得订阅内容

地址存在不意味着当前能取得正确内容。服务端可能返回账户到期说明、登录页面、维护页面或错误响应，而不是客户端可解析的数据。如果能看到明确的状态提示，应先按服务商的账户说明核对有效性。不要把包含登录表单的网页当成节点配置，也不要尝试通过反复改变协议类型来解析一份本就不是订阅的数据。

获取失败还可能与当前请求路径有关：更新订阅所用的网络路径，不一定与某个网页的路径相同。先在当前基础网络可用的条件下手动更新一次，观察错误，再核对是否需要按服务商说明使用既有可用连接。不要为了取得订阅把全部业务长期切换到不同姿态；对照完成后恢复原配置，并记录哪种条件下请求成功。

订阅地址按凭据保护

完整地址、二维码和导出的条目可能包含认证信息。不要粘贴到公开评论、陌生解析页面或公开截图中；反馈时仅保留错误类型与已经遮去敏感内容的必要字段。

返回成功，但列表为空或条目不完整

如果应用提示已取得内容，却没有出现预期条目，检查服务商提供的格式是否适用于 Shadowrocket，以及账户当前是否确实返回服务器。不要根据其他格式的字段名称手工猜测转换。订阅与 Config 也不是同一类资源：一份规则配置并不必然包含服务器，一份服务器订阅也不必然携带完整规则。应使用各自对应的导入位置。

若更新后只剩部分条目，先查是否启用了名称过滤、是否存在不支持或不完整的字段，再核对服务商是否调整了返回内容。条目数量变化本身不能证明客户端丢失数据。对照原始订阅说明和更新后的名称，确认是不是服务器重命名或分组变化。不要为了凑回数量导入重复项，重复条目会干扰之后的选择与测试。

自动更新不能替代一次可解释的手动测试

先让手动更新稳定完成，再启用应用当前提供的自动更新选项。打开时自动更新的具体触发条件，以应用内设置说明为准；它不等于设备在任何后台状态下都会持续刷新。遇到自动更新未发生时，应记录打开应用的时机、当时网络和手动更新结果，而不是直接判断系统阻止了全部订阅访问。

更新成功后重新核对选中的服务器。有些条目名称或身份发生变化后，原来的选择可能不再适用；Config 中引用的分组或策略也需要保持对应。随后用实际请求验证，不能只看更新提示。更完整的操作位置与失败分支见订阅手动更新与自动更新说明，链接结构的区别见节点链接格式说明。

如果新订阅持续失败而旧条目仍可用，应暂时保留旧条目，并向服务商确认地址是否已重置、账户是否有效以及格式是否变更。频繁重置链接会让其他已配置设备一起失去更新能力，不能作为第一步。修复后检查自己的其他设备是否也需要同步变更，同时清理不再使用的旧地址副本，减少后续混淆。

05 速度慢与间歇中断：建立可重复的对照

速度慢需要先描述成可观察的现象：首次打开等待久、开始传输后速率低、视频持续缓冲，还是空闲一段时间后需要重新连接。这些表现可能来自不同阶段。连接列表中的探测时间不是持续带宽，也不能代表目标网站的响应。先固定目标、网络和服务器，避免用不同时间、不同内容的体验直接下结论。

区分解析等待、握手等待与传输受限

如果首次访问慢、之后相同页面较快，检查域名解析、连接建立和缓存因素；如果开始很快但大文件持续传输缓慢，重点检查网络质量、远端负载和目标服务的限制。若仅某个应用缓慢，应观察它依赖的域名、是否开启后台下载，以及请求是否走到预期策略。不能因为视频卡顿就认定所有网络请求都被同一因素限制。

做对照时选择自己有权访问且能够重复测试的内容，保持相近的文件大小与操作方式，并暂停设备上的大规模同步任务。测试前确认无线信号和蜂窝信号没有明显变化。不要连续发起大量测速；测试自身也会消耗带宽、产生服务器负载和电量开销，反而改变被测环境。少量可解释的重复，比大量截图更有诊断价值。

对照网络与服务器，但不同时更换

先保持服务器不变，仅切换网络。如果同一服务器在另一网络明显恢复，优先检查原网络的无线干扰、上游拥塞或特定传输条件。再保持网络不变，仅在自己的已有项中选择已知可用对照。若对照项正常，问题更可能集中在原服务器或其出口路径。每次切换后重新建立连接，并用同一目标复测，避免旧连接继续影响结果。

无线网络里，离接入点远、同频干扰或网络内其他设备正在传输，都可能带来抖动。先移动到稳定位置，确认基础网络访问也没有同样问题，再检查代理路径。若只有蜂窝网络下失败，也要核对应用的蜂窝数据权限和当前信号条件。不要将运营网络之间的差异解释为应用设置必然错误，应保留对照条件交给相关服务方判断。

间歇中断要记录触发动作

空闲后中断、锁屏后中断和切网后中断不是同一种症状。空闲中断可能涉及连接维护与服务端超时；切网后中断可能是旧路径连接尚未重建；锁屏后的表现还受应用自身的后台任务方式影响。记录是所有应用一起失败，还是只有一条长连接失效。若新开网页正常而旧会话停住，优先让业务重新建立连接，不必立即重置整份配置。

对于依赖 UDP 的业务，普通网页成功不能证明其路径正常。若出现只在某类通话、实时传输或特定协议上失败，应核对服务器是否支持对应流量、协议参数是否完整，以及当前网络是否允许所需传输。不要盲目调整 MTU 或套用网上的固定值；这类参数必须结合实际路径和服务端要求，修改前记录原值，并用同一业务验证。

测速结果只说明测试条件

测试目标、时间、网络与服务器共同决定结果。一次低探测时间不能保证持续传输，一次高峰期缓慢也不能证明设备配置永久失效。

判断目标服务与本地配置的边界

如果只有单一目标缓慢，而其他相似请求正常，检查目标服务本身、账户状态和资源加载情况。应用内置浏览与独立浏览器可能使用不同缓存、登录状态和连接复用方式，不能把差异直接归因于分流。结合连接记录查看失败资源，确认是等待响应、重复重试还是策略不符合预期，再回到规则章节做最小修改。

处理完成后，应验证首次打开、短时持续使用以及一次正常切网后的表现，而不是只复测最快的一次。若需要向服务商反馈，整理目标类型、网络类型、故障时段和对照结果，不发送完整认证参数。若缓慢同时伴随设备发热和耗电升高，继续检查后台传输、重试循环与诊断频率；这往往比单纯更换服务器更接近根因。

06 DNS 问题：检查域名、解析路径与规则

DNS 负责把域名解析为地址，但网页失败并不都属于 DNS。先看错误是否明确发生在解析阶段，再核对服务器域名和目标网站域名是否分别能够解析。代理服务器自身的域名解析失败，会使连接尚未建立就中止；目标域名解析失败，则可能发生在隧道已经开启之后。两者表面都像无法上网，处理位置却不相同。

从失败域名开始，而不是先换解析服务

记录具体失败目标和错误文字，确认是否为一个域名、某类子域名，或所有域名。如果只有单个域名失败，先检查拼写、服务是否存在和是否需要登录。不要用网页首页能打开来证明所有资源解析正常，页面依赖的图片、认证和接口可能使用不同域名。连接记录能帮助定位真正失败项，比直接更改全部 DNS 设置更有针对性。

若服务器地址本身为域名，先核对域名没有过期、写错或被服务商替换。不要随意把解析得到的一个地址固定写进配置：服务端可能使用动态调度，TLS 名称也可能仍需原域名。确需用地址作对照时，应依据服务商提供的说明，并保留服务器名称等相关字段。否则一次临时测试可能引入新的证书或路由问题。

解析设置必须与访问路径一起看

在 Config 中检查是否存在自定义 DNS 设置、是否导入了改变解析行为的配置，以及这些解析请求是否需要经过特定出口。解析服务不可达时，配置即使写法正确也不会有结果。若同时存在系统侧网络解析设置，应把它们作为独立变量逐一核对，不要一次全部删除。先确认哪一层实际生效，再判断是否存在重叠或冲突。

某些加密解析方式还需要先到达其服务器并完成连接。若当前网络无法到达该端点，或者访问端点又依赖尚未完成的解析，就可能出现等待链。此时应回到当前配置的完整设计，检查初始化路径，而不是继续堆叠更多解析地址。恢复到自己此前验证过的配置副本，通常比混合多份来源不同的 DNS 设置更便于定位。

域名规则与地址规则的观察结果不同

DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD 关注域名条件，IP-CIDR、IP-CIDR6 和 GEOIP 则与地址判断有关。后者的结果可能取决于是否已经取得地址，以及应用实际发起的是哪种请求。不要只根据域名的归属猜测地址规则必然命中；服务端可能通过不同区域、不同地址族或内容分发路径返回结果，应查看实际记录。

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

这里的 no-resolve 用于说明该地址规则不主动为匹配而触发域名解析，不是关闭整个应用的 DNS。示例依然只是规则片段，并未定义完整服务器和解析方案。尤其不要把此选项追加到所有规则后面当作加速办法；改变是否解析会改变可参与判断的信息，必须结合规则目的和当前应用支持的语法使用。

IPv4、IPv6 与缓存需要分别验证

某个网络提供 IPv6，不代表每个服务器和目标都具备同样的路径条件。如果只在特定网络失败，检查错误是否集中于某个地址族，并核对服务商当前支持情况。不要把全局禁用某类地址作为永久默认处理；先确定实际失败路径，再依据配置说明做对照。局域网中的设备发现或本地域名，还可能依赖当前无线网络提供的解析条件。

修正解析设置后，旧缓存和已建立连接可能继续影响短时结果。可以断开并重新连接，再重新打开目标应用发起新请求，必要时等待缓存自然失效。不要宣称某个刷新动作必然清除所有层的缓存，浏览器、系统、应用和远端都可能缓存。验证时记录新连接的结果，而不是反复刷新同一条尚未结束的请求。

若是打印机、家庭设备或内部域名失败，应先在同一无线网络下验证直接访问，并确认设备允许局域网访问及网络没有客户端隔离。私有地址规则不能代替本地域名解析。最终应同时验证服务器域名、普通目标域名和确实需要的本地目标；只有这些实际需求恢复，才算完成 DNS 调整，而不只是某次解析测试返回了地址。

07 耗电异常：结合流量与 On Demand 判断

系统电池页面中 Shadowrocket 占比较高，不等于应用正在独立产生同等比例的业务流量。隧道承载其他应用的请求时，相关处理可能计入它的使用情况；百分比还会受到同一统计周期内其他应用用电量的影响。先看使用时长、屏幕活动和实际业务，再判断是否异常，不要只凭一个相对占比关闭所有连接功能。

先建立相同使用条件的观察窗口

选取两段使用方式相近的时段，记录网络类型、连接时长、主要应用和是否发生大量上传下载。系统更新后的后台整理、照片同步、媒体播放和信号不稳定，都可能改变耗电。若一段时间在强信号无线网络，另一段在弱信号蜂窝网络，两者不能直接用于评价某个开关。先控制环境，才能看出设置变化是否真的有效。

同时检查设备是否明显发热、连接是否频繁断开重连，以及日志中是否出现持续失败的请求。错误配置导致的反复重试，会同时增加等待、流量和处理开销；此时应先修复服务器、DNS 或规则问题，而不是只把连接关闭。若业务在后台持续传输，暂停该业务再观察，比单独调整隧道更能判断流量来源。

On Demand 是触发连接的条件，不是省电保证

On Demand 用于按配置条件请求建立连接，其效果取决于具体规则和系统触发。它不代表系统能理解每个应用的使用意图，也不保证所有场景都比手动常驻省电。若条件过宽，普通后台请求也可能不断触发；若条件配置不符合实际使用，又可能在需要连接时没有及时建立。应先明确希望何时连接，再选择条件。

排查时先记录原有条件，然后暂时关闭 On Demand，手动建立一次连接并观察。若手动模式稳定，而按需模式反复启停，检查条件是否随网络变化来回匹配，以及是否存在其他自动连接设置。不要一边修改条件一边快速切换网络；每次变更后给系统完成断开与重建的时间，并在正常使用中验证，而不是只看开关瞬间状态。

不同场景采用不同的连接管理方式

长时间持续使用同一组业务时，频繁建立和断开不一定更合适；短时偶尔使用时，则可以在完成任务后主动断开，或依据自己理解的条件使用 On Demand。这里没有对所有设备通用的固定方案。重要的是连接方式与业务需求一致，并且不会为了减少图标出现而造成应用不断失败重试，最终产生更多网络活动。

如果每次手动关闭后又自动连接，先核对 On Demand 及系统中对应 VPN 的按需状态，不要把它误认为开关失灵。关闭用于测试的自动触发条件，再断开连接，观察是否保持。若设备受管理，还需确认是否存在管理员设置的连接要求。不要移除未知管理配置；系统策略与个人应用选项应分别判断，处理权限也不同。

诊断本身也有成本

密集测速、长时间保留详细记录、持续刷新失败页面都会增加活动。取得必要证据后，结束额外测试，并按实际需要恢复诊断设置。

区分客户端处理与远端连接问题

如果耗电同时伴随速度慢，应查看是否存在大量重传、频繁握手或不可达的解析端点。保持同一业务，仅替换自己的已知可用服务器作短时对照，观察发热与稳定性是否一起改善。若所有服务器在某个弱信号网络下都异常，应优先改善基础网络条件，而不是连续尝试更多配置。客户端无法消除无线网络本身的耗能。

判断改善时应比较相近时长内的实际电量变化、设备温度和任务完成情况，而不只是应用排名下降。某个应用占比下降也可能因为其他应用用电增多。不要承诺固定的省电比例，也不必为了追求最低占比放弃必要的稳定连接。对自己需求而言，连接稳定、失败重试减少且电量消耗合理，才是有效的调整结果。

更细的场景取舍可查后台常驻与 On Demand 说明。如果关闭额外诊断、修正重试原因后仍持续异常，应保留使用场景、系统电池记录和经过脱敏的错误摘要，再考虑更新或恢复配置。不要在没有备份的情况下直接重装，否则既丢失排查证据，也可能把原有服务器和规则一并清除。

08 更新后异常与 iPad：保留差异再恢复

“更新后开始异常”描述了时间关系，并不自动证明应用更新是唯一原因。同一时期可能还发生系统更新、订阅刷新、服务器变更或网络环境变化。先列出最后一次正常使用到首次失败之间发生的事情，再确定最小复现步骤。保留当前配置副本和错误信息，避免一开始重装就失去比较依据，也避免将旧问题带入新设置后再次出现。

先判断变化来自应用、系统还是配置

检查异常是否影响全部服务器、全部网络和全部目标，还是仅限一份 Config。如果同一服务器在 Proxy 下可用，而在更新后的 Config 下失败，应比较规则、策略引用和解析设置。若只有订阅刷新后的条目失败，优先核对返回参数。应用更新、订阅更新与 Config 更新是不同操作，排查记录中应分别写清，不能都简称为“更新了”。

应用更新与重新获取统一通过 App Store，系统要求以 App Store 页面标注为准。需要确认来源时，核对开发者 Shadow Launch Technology Limited、官方图标和应用 ID 932747118；具体步骤见正版核对说明。购买记录说明应用取得情况，不代表配置自动正确，也不代表自己的远端服务器当前可用。

按可逆顺序恢复，不先清空全部数据

先正常关闭再打开应用，确认当前服务器、Global Routing 和 Config 没有改变；随后在必要时重启设备并复测。若问题仍在，用自己保留的已知可用配置副本做对照，而不是导入来源不明的整套设置。原配置先保留，只改变当前激活项。发现差异后逐项迁移需要的规则，确认策略名称与服务器关系仍然存在。

只有在明确怀疑系统 VPN 配置损坏时，才按第一章的方法重新授权。重新授权解决的是系统配置层，不会恢复被删除的订阅、密码和自定义规则。重装应用放在更后面：先确认原始订阅地址、服务器信息和必要配置已安全保存，并了解应用当前支持的导出内容。导出文件也可能含凭据，应存放在自己控制的安全位置。

iPad 上先核对账户、选择项与网络差异

iPhone 可用而 iPad 失败时，先确认两台设备使用的是同一份有效信息、同一个服务器和相同 Global Routing。显示名称相同不代表内部参数一致；迁移后也可能没有激活预期 Config。分别查看实际选中项、规则命中和错误阶段，再比较差异。不要仅因为使用同一 Apple 账户，就认为应用内全部设置会自动同步并保持一致。

iPad 的窗口布局可能因屏幕和显示方式不同而呈现侧栏或不同信息密度，操作时应按 Home、Config、Settings 等界面名称定位，而不是照着某个按钮的屏幕坐标寻找。分屏下可见区域缩小也不表示设置丢失。先退出遮挡或展开对应区域，确认当前操作的是服务器编辑、配置选择还是系统权限，避免在错误位置重复导入。

仅有无线网络的 iPad 无法用自身蜂窝网络完成对照，应选择另一个自己信任的网络。若 iPhone 正在使用蜂窝网络，而 iPad 使用需要认证的无线网络，两者不是有效的同条件比较。还要核对当前无线网络是否限制设备间访问、本地网络权限是否适用于所需业务；能打开普通网页，不代表能访问打印机或内部域名。

已购恢复与配置恢复是两件事

重新获取应用时，在 App Store 使用实际购买所对应的 Apple 账户查找已购项目；显示和适用范围以商店页面为准。iPad 的兼容性及购买适用范围同样以 App Store 页面标注为准。应用恢复完成后，仍应核对自己的订阅和 Config 是否存在，不能把恢复应用等同于恢复所有业务设置。操作顺序见已购项目恢复说明。

最后保留一份可复现结论

记录故障症状、触发条件、唯一修改项和复测结果。若问题仍在，附设备与网络信息及脱敏错误摘要；不要提供订阅全文、密钥或完整导出配置。

恢复后，按使用教程重新验证导入、选择 Config、授权连接和实际访问四个环节，再检查 On Demand 与必要的局域网业务。若再次复现，回到本页对应症状章节继续缩小范围，不要重复清空。可靠的结束条件是同样操作能够稳定成功，并且原有需求没有因临时绕过而受损，而不是某一次重启后暂时看起来正常。