Shadowrocket 故障排查手册

01 · 系统授权与连接生命周期

开关无法开启，或开启后立即关闭

先观察开关失败发生在哪个阶段：点击后没有任何变化、出现系统授权后未完成，还是短暂连接后立即断开。这三种现象对应不同检查入口。开关代表系统网络扩展的启动过程，不等于服务器已经能够转发流量。只有先让连接保持开启，后续的节点测试和网页验证才有明确意义。排查时暂时停用 On Demand，避免自动触发连接干扰手动观察。

先完成系统授权，再检查配置

首次开启时，系统可能询问是否允许添加 VPN 配置。确认当前操作来自刚刚打开的 Shadowrocket，再按系统提示完成授权和设备身份验证。若之前取消了弹窗，返回应用重新开启并观察是否再次提示。对于由学校或单位管理的设备，相关权限可能受管理策略限制；这类限制不能通过修改服务器参数解决，应先确认设备是否允许添加和运行相应网络配置。

进入系统 Settings，查找 VPN 相关设置，确认是否存在 Shadowrocket 对应的配置，并留意当前是否有其他网络连接处于活动状态。先停止其他连接，再回到 Shadowrocket 尝试，避免同时更改多个网络组件。不要仅凭状态栏是否显示标识判断成功与否：不同设备和显示场景可能隐藏部分状态信息，应结合应用中的连接状态以及系统 VPN 页面共同确认。

区分配置载入失败与服务器通信失败

如果系统授权已经完成，但开关仍立即退回，检查 Config 中当前选中的配置是否可以正常打开。特别留意刚刚手动编辑的字段、未完成的配置导入，以及引用的策略名称是否仍然存在。先恢复到修改前保存的副本，而不是继续叠加新设置。若恢复后可以保持连接，说明排查重点应放在配置差异，不应立刻删除应用或重建所有服务器记录。

同时确认 Home 中存在可用的服务器记录，并且需要使用代理的姿态下已经选中目标。服务器列表为空、分组选项失去引用，或者配置指向已删除的名称，都可能让后续连接行为与预期不同。可以暂时选择一条自己已经核实参数的记录进行最小测试。这里的“最小”是减少配置依赖，不是要求关闭证书验证，也不是把所有流量永久改成同一种策略。

使用可恢复的系统处理顺序

先正常关闭连接，退出当前编辑页面，再重新打开应用尝试一次；仍失败时重启设备，让系统网络扩展重新初始化。重启前保存尚未写入的配置修改。若只有切换网络后出现问题，先在稳定的 Wi-Fi 下验证，再单独检查移动网络权限。设备存储空间不足时，也应先释放必要空间，避免配置保存和诊断记录写入受阻，但不要未经核对就删除配置文件。

只有在配置已备份、已有服务器信息可以重新导入，并且确认系统配置确实损坏的情况下，才考虑移除系统中对应的 VPN 配置后由应用重新建立。操作前关闭 On Demand 并停止连接，避免删除后被自动触发流程打断。不要把“还原所有网络设置”作为第一步，它会影响设备上其他网络记录，且未必能修复参数错误。重新授权成功后，先测试开关能否稳定保持，再进入下一章验证实际通信。

02 · 基础网络、姿态与规则

显示已连接，但网页或应用无法上网

先关闭 Shadowrocket，访问一个平时能够直接打开的网页，确认设备本身已经联网。公共 Wi-Fi 可能需要先完成网络登录，路由器也可能只连接了局域网而没有可用的外部连接。基础网络未恢复时，修改代理参数不会解决问题。完成登录或修复网络后，再开启 Shadowrocket，使用同一个网页复测，尽量保持测试对象和时间相近。

用 Global Routing 缩小问题范围

Global Routing 的 Config、Proxy、Direct 是诊断中最有用的分界。Config 按当前配置的规则选择策略；Proxy 用于检查当前代理路径；Direct 用于观察直接连接的表现。它们不是网络质量等级，也不能保证所有目标都能访问。测试前记录原来的姿态，每次只改变这一项，并明确自己正在验证的是哪条路径，避免测试结束后忘记恢复。

如果 Direct 可以访问测试网页，而 Proxy 失败，先检查所选服务器，不要立即修改全部规则。如果 Proxy 正常，Config 失败，则查看目标在 Config 下命中了什么策略：可能是过早匹配的 REJECT，也可能是需要代理的目标被送往 DIRECT。若三个姿态都异常，还应回到基础网络、DNS 和系统连接检查，不宜仅凭一次网页失败认定订阅不可用。

检查规则顺序与实际目标

规则通常按顺序匹配，前面的宽泛规则可能覆盖后面的精确规则。下面片段用于说明先匹配具体条件、最后使用 FINAL 的结构，并非建议直接覆盖现有配置。PROXY 必须在当前配置中有可用的策略引用；若已有配置使用其他策略名称，应按实际定义核对。先在副本中编辑，再通过记录确认命中结果，避免仅根据文件里的文字猜测执行路径。

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

网页通常不只请求一个域名。页面主体、图片、登录接口和媒体内容可能分别连接不同目标，因此“首页能打开但登录失败”仍然可能是分流不一致。查看发生失败时的连接记录，找到实际失败的域名与命中策略，再判断是否需要调整规则。不要为图省事把大量无关域名全部改成同一策略，也不要依据网页标题推断所有请求都使用同一个地址。

排除应用自身会话与局域网影响

切换姿态后，原有长连接可能继续使用之前的会话。退出测试应用的相关页面，重新发起请求，必要时正常关闭并重新打开连接，再比较结果。对于只在某个应用出现的问题，应同时用浏览器验证同一服务，区分应用缓存、登录状态和网络路径。单个服务的维护、认证失败或访问限制，也可能表现为加载停滞，不能仅凭“其他网页正常”就断定规则一定没有问题。

访问路由器管理页、局域网设备或家庭存储时，重点检查局域网网段是否被错误送往代理。不要直接照搬示例网段，应以当前网络的地址分配为准。若连接记录显示规则正确，但域名始终解析失败，转到 DNS 章节；若域名已得到地址但服务器路径无法建立，转到节点超时章节。保留这个分支判断，可以避免在规则、订阅与系统设置之间反复来回修改。

03 · 端点、认证与传输

节点超时，或 Connectivity Test 失败

超时只表示某个测试在规定时间内没有完成，并不直接说明是哪一个字段错误。应先辨认测试类型：端口连接、代理后的网页请求、DNS 查询，以及应用内的 Connectivity Test，验证的层级并不相同。端口能够建立连接，不代表认证和数据转发一定成功；网页测试失败，也可能是测试目标暂时不可达。记录测试对象和错误内容，比反复点击测试更有助于定位。

从服务器地址与端口开始核对

打开对应的服务器记录，对照自己的服务商提供的信息检查 Address 和 Port。Address 通常填写主机名或地址，不要把完整网页地址、路径和多余空格一并粘贴进去。Port 应与服务器实际监听端口一致，不能根据协议名称推测。若地址是域名，先确认解析是否成功；若连解析都未完成，继续更改 Password 或传输设置通常没有意义。

随后核对协议类型与认证字段。Trojan 的 Password、VMess 或 VLESS 的身份字段、Shadowsocks 的加密方式和密码，分别承担不同作用，不能互相套用。导入成功仅说明文本被识别，不代表远端参数已经通过验证。尤其是手工填写时，应检查复制内容是否带有换行、首尾空格或全角标点；修改后保存，再重新选择该记录，确认测试的确针对刚刚编辑的条目。

TLS 与传输参数应分别检查

使用 TLS 时，Address 与 SNI 不一定相同：前者决定连接哪个端点，后者参与服务器名称指示及证书校验。应按已有服务器的实际约定填写，不要把任意域名填入 SNI。检查系统日期、时间与时区是否正确，时间偏差可能导致证书验证失败。若记录提示证书名称不匹配或证书过期，应核对远端部署，不要把忽略校验设置当成长期解决办法。

若服务器另有传输层要求，还需核对对应的 Host、Path 和传输类型。Path 的开头斜杠、大小写以及附加内容都可能影响路由，不能只看是否“大致相同”。Hysteria2 等使用 UDP 的连接，还应考虑当前网络是否允许相应流量；TCP 网页可访问，并不能证明 UDP 路径也正常。切换到另一条自己有权使用的网络进行对照，比同时修改多个协议字段更容易得出结论。

用交叉测试区分本地与远端问题

保持同一条服务器记录，分别在 Wi-Fi 与移动网络测试；再保持同一网络，测试另一条自己已有且确认可用的记录。前一组帮助判断网络差异，后一组帮助判断单个端点异常。不要同时换网络、换服务器、换配置，否则即使恢复也无法知道原因。若同一端点在不同网络都失败，而其他已有端点正常，应向原服务商核实端点状态和参数是否调整。

向服务商说明问题时，提供经过脱敏的错误类型、网络环境和测试时间即可，不要公开完整认证信息。如果端口连接成功而实际网页请求失败，继续检查认证、传输和目标响应；如果所有已有端点都只有某个网络失败，应先排查该网络及路由器。有关 Trojan 字段的逐项含义，可进一步阅读Trojan 参数说明，避免用试填方式替代参数核对。

04 · 获取内容、解析与本地列表

订阅无法更新，或导入后没有服务器

订阅更新包含多个独立阶段：连接订阅地址、取得响应、识别内容、解析记录，以及更新本地列表。列表为空不一定表示地址无法连接，也可能是服务器返回了登录页面、错误说明或不被当前入口识别的内容。先记录更新时显示的错误，再检查地址和响应层级。不要连续删除原有列表，因为旧记录可能仍可使用，也是判断本次更新差异的重要参照。

先区分订阅地址与单节点分享链接

从自己的服务商处核对完整订阅地址，确认复制时没有漏掉查询参数、末尾字符或必要的认证部分。订阅地址与单节点分享链接用途不同：前者通常用于取得一组可更新的记录，后者描述某一条连接。把单节点内容放进订阅更新入口，或把配置文件地址当成服务器订阅，可能导致识别失败。应根据内容类型选择入口，而不是仅凭地址看起来很长就判断它是订阅。

同时检查复制内容是否包含说明文字、引号、空格或换行。某些分享操作会把标题与地址一起复制，应只保留实际地址。订阅中的认证信息属于敏感内容，不应粘贴到公开的链接检查页面，也不要直接发到讨论区请求他人代测。需要展示问题时，可以描述错误类别，并把地址中的身份信息完整移除，而不是只遮住其中几个字符。

判断请求失败还是返回内容不正确

如果报错涉及主机解析、连接超时或 TLS，先检查订阅域名的解析和请求路径。订阅更新是否经过代理可能受设置与配置影响，不能因为网页可以打开就推断更新也走同一条路径。若当前服务器已经不可用，而订阅请求又依赖它，就可能形成更新失败的循环。应在允许且可用的网络环境中验证请求，并保留原配置，避免把“更换线路”和“重新获取订阅”混成一个动作。

如果错误显示访问被拒绝或资源不存在，优先核对地址是否已被服务商更换、认证是否失效，以及账户状态是否允许读取。出现重定向时，还要确认最终响应是否确实为订阅内容，而不是需要登录的网页。即使浏览器显示页面成功，也可能只是展示了一份错误说明；反过来，浏览器下载或显示文本，也不代表其中每条服务器记录都能被当前导入入口正确识别。

列表为空时检查筛选、解析与覆盖关系

收到内容后仍看不到记录，先清除 Home 中可能存在的搜索条件，展开对应分组，并确认正在查看刚刚更新的订阅。对照更新前后的条目数量和名称，判断是完全未解析，还是仅部分协议或字段未被识别。如果订阅本身含有筛选条件，核对它是否把所有记录排除；不要仅根据一个空分组就反复导入同一地址，否则容易生成难以辨认的重复项。

订阅更新可能重新生成受其管理的服务器记录，手工修改这些记录后，再次更新时改动可能被覆盖。因此需要长期保留的个人调整，应先确认管理方式并留存副本。为区分内容问题与网络问题，可以用自己已有的一条完整服务器信息手动添加测试：若手动记录正常，而同源订阅持续无法解析，重点就在订阅格式与响应内容，不应再反复修改系统 VPN 授权。

若需要重新梳理入口，可阅读订阅与单节点导入方法；若不确定内容类型，可查阅分享链接格式说明。恢复后保留一次成功更新的观察结果，再设置适当的更新频率，不要用高频重试掩盖持续的请求错误，也不要把更新按钮当成服务器连通测试。

05 · 等待阶段与持续传输

连接可用，但打开慢或传输不稳定

“慢”应先拆成等待首个响应、网页资源加载和持续传输三个阶段。点击后长时间没有响应，常与解析、建连或握手有关；页面先出现文字但图片迟迟不全，可能涉及多个目标的路径差异；开始正常、持续传输时越来越慢，则还要考虑拥塞、丢包和服务器负载。明确慢发生在哪一步，比单看某个延迟数字更有诊断价值。

建立条件一致的对照

选一个能够稳定复现的目标，在相近时间、同一网络、同一设备和同一服务器下重复两三次即可。测试期间暂停系统大文件同步、其他设备的大量传输以及不相关的后台任务。网页内容本身也会变化，所以应尽量使用相同页面和操作。不要同时运行多个高流量测试，它们会争用同一条连接，最终测到的是相互干扰后的表现，而不是平时使用的速度。

随后分别比较 Wi-Fi 和移动网络，或比较自己已有的其他服务器，每次只更换一个条件。若所有服务器仅在同一 Wi-Fi 下慢，检查路由器、无线信号和当前网络负载；若仅某一条服务器慢，优先关注该端点及其到目标的路径。若只有一个目标慢，应考虑目标服务本身的响应和资源分发，不要把它直接归结为客户端整体性能问题。

延迟、带宽与实际体验不是同一个指标

低延迟通常有利于交互和短请求，但并不代表持续下载一定更快；较高延迟也不必然意味着带宽不足。应用内的测试还受到测试地址、请求类型及超时阈值影响。判断可用性时应以实际任务为准，例如登录能否完成、视频是否持续缓冲、文件传输是否中断。不要依据一次测试结果频繁切换服务器，切换本身会终止部分会话并增加新的握手成本。

Global Routing 也会影响结果。Config 下可能只有部分资源经过代理，而 Proxy 下会把更多请求送入所选路径；两次观察若未注明姿态，就不是严格的对照。检查连接记录中是否存在反复失败的资源，尤其是登录接口、媒体分片和解析请求。若某个请求不断重试，页面整体看起来会很慢，但真正需要修复的可能只是某一条规则或一个无法访问的域名。

按链路特征处理，不盲目调整参数

Wi-Fi 信号较弱、设备频繁在不同接入点之间切换时，可能出现吞吐下降和连接重建。先靠近接入点测试，并确认设备没有在多个网络之间自动切换。若当前网络需要登录，登录会话到期也可能让后台连接反复失败。对于使用 UDP 的协议，应单独比较当前网络是否存在明显限制或丢包；其他协议能用，只能说明另一条传输路径可用，不能证明所有流量条件都相同。

不要在没有依据时改动 MTU、并发或协议高级参数。MTU 不匹配确实可能影响传输，但类似症状也可能来自目标服务、无线链路或远端拥塞。只有在问题稳定可复现、已有明确部署要求，并且保存原值后，才逐项调整并对照。更改后若没有稳定改善，应恢复原值，避免留下多个互相掩盖的设置，使下一次排查更难解释。

最后检查设备温度、电量状态和本地存储压力。长时间传输、屏幕录制与其他计算任务并行时，设备整体性能变化也会影响体验。先停止无关任务，让设备恢复正常工作状态，再复测相同操作。如果慢主要发生在第一次打开，而后续访问正常，可继续检查 DNS 缓存和连接复用；如果只有持续传输不稳，则把重点放在网络波动、远端状态和会话中断记录。

06 · 名称解析与连接路径

DNS 解析失败，或只有部分域名打不开

DNS 负责把域名转换为连接所需的地址，它与“连接哪个服务器”“使用什么分流策略”有关联，但不是同一个环节。域名未能解析时，请求可能还没有进入目标连接阶段；得到地址后仍可能因路由、端口或目标响应失败。排查时先看记录中的错误属于解析、建连还是 TLS，避免把所有网页打不开的情况都归到 DNS，也避免仅因为解析有结果就排除 DNS 相关差异。

分别检查服务器域名与目标域名

至少区分三类名称：代理服务器的域名、订阅地址的域名，以及要访问的网站域名。代理服务器域名若无法解析，连接本身就可能建立不了；订阅域名失败会影响更新，但未必影响已有记录；目标域名失败则可能只表现为部分服务异常。这三类请求可能使用不同的设置和路径，应分别观察，不要因为订阅可以更新就断言所有解析都正常。

系统 DNS 取决于当前网络提供或设备指定的解析设置；自定义 DNS 则使用配置中的解析端点；DNS over HTTPS 通过 HTTPS 传输查询。加密传输改变的是查询通道，并不自动保证端点可达，也不保证它适合当前网络。若 DNS over HTTPS 的端点使用域名，还需要考虑端点本身如何完成初始解析，不能把解析请求绕回一个尚未建立的依赖链。

先阅读现有配置，再做单项替换

打开当前生效的配置，确认是否存在 dns-server 等相关设置，检查是否同时在多个位置留下了历史修改。下面的片段只展示 [General] 与规则段的组织方式，其中 system 表示使用系统解析来源，不是对所有网络的统一建议。不要把它直接追加到已有文件末尾形成重复段落；先理解现有配置，再在副本中修改相应字段。

[General]
dns-server = system

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

修改后重新发起测试请求，并留意缓存影响。某个应用可能保留旧解析结果或已有连接，即使配置已变更，界面表现也不会立即改变。先关闭相关页面并重新打开，必要时正常重连 Shadowrocket，再比较记录。不要依靠不断更换解析服务器来碰运气：应保留一个可解释的基线，并确认每次修改究竟改变了解析来源还是请求路径。

关注地址族、局域网与分流一致性

同一域名可能返回 IPv4 和 IPv6 地址。如果当前网络对某个地址族的连接不稳定，可能出现时好时坏或等待后才成功的表现。应结合失败记录中的实际目标地址分析，而不是把“返回多个地址”当成异常。不要长期用关闭某个地址族来掩盖未知问题；如果确实需要临时对照，应记录原设置，验证结束后恢复，并检查所用服务器和网络对相应路径的支持情况。

局域网名称还可能依赖路由器或特定的本地发现机制。更换为远端解析来源后，家庭设备名称可能无法解析，但直接访问正确的局域网地址仍然可用。遇到这种情况，应检查局域网解析与 DIRECT 规则是否配合，而不是把局域网设备也送往代理。另一方面，目标解析所得地址与最终连接路径不一致时，也可能影响访问结果，需要同时核对命中规则和解析来源。

若只有单个域名失败，先比较它在不同网络下的表现，并检查目标是否已经更换域名、证书或服务入口。不要凭一次解析结果判断内容服务状态。若大量域名都失败，而服务器端点仍能连接，应重点检查解析端点可达性和配置依赖。更完整的字段解释见DNS 设置说明；修复后至少复测普通网页、原失败目标和需要使用的局域网资源，确认没有只修好其中一类。

07 · 后台任务与重复连接

耗电增加、设备发热或后台活动偏多

先区分“电池页面把流量处理归在 Shadowrocket 名下”和“设备确实出现额外耗电”。网络扩展持续处理经过的流量，系统统计可能把部分相关活动计入其使用记录；这并不意味着每一次耗电变化都由客户端设置造成。应同时比较总电量下降、实际使用任务、屏幕开启时间和网络条件，不能只看某个应用在列表中的占比就下结论。

在相近任务下建立电量基线

选择一段日常能够重复的使用过程，记录使用的网络、屏幕状态和主要任务。连续视频、文件同步与待机的流量差异很大，不能直接比较。设备温度、充电状态和无线信号也会改变耗电表现；移动网络信号较弱时，通信本身可能增加能耗。先在信号稳定、设备温度正常的环境中观察，再判断异常是否与 Shadowrocket 连接同步出现。

不要为了排查一开始就关闭所有功能。先查看有没有持续的大流量任务，包括照片同步、文件传输和其他应用的后台请求。即使前台没有操作，这些任务仍可能经过当前连接。暂停与测试无关的任务后，观察网络活动是否明显减少；如果减少，重点应放在流量来源和任务安排，而不是把正常的数据转发误认为连接空闲时仍在大量耗电。

查找失败重试与自动触发循环

如果设备在基本没有使用时仍持续发热，检查连接记录是否出现重复解析、反复握手或短时间内大量失败。失效的服务器、不可达的订阅地址和某个应用不断重试的接口，都可能产生额外活动。先定位最频繁的失败目标，再修复对应问题。不要通过永久隐藏错误记录来处理，因为记录变少并不代表后台重试已经停止，只是失去了观察依据。

On Demand 应重点检查触发条件是否与日常网络变化相冲突。设备在 Wi-Fi 与移动网络之间切换，或者网络登录状态发生变化时，可能反复触发连接。先记录当前条件，暂时关闭自动触发，用手动连接观察一段相同任务；如果循环消失，再逐项恢复条件。不要把“自动连接频繁”直接解释为功能异常，它也可能忠实执行了过于宽泛或互相交替满足的条件。

减少不必要工作，而不是牺牲诊断能力

检查是否设置了过密的订阅更新或批量测试。自动更新和测试都有实际网络成本，已有内容不需要在每次页面切换时重新获取。按使用需要安排更新，并在排查期间避免连续测试整份列表。如果只是验证某条服务器，单独测试即可。诊断结束后，把临时开启的详细日志恢复到日常所需的级别，并处理不再需要的诊断文件，避免长期保留大量敏感记录。

对于连接保活、超时和协议相关参数，应遵循已有服务器的要求，不建议为了省电任意设成极端值。过短的超时可能造成反复建连，过于频繁的保活也可能增加后台通信；但参数作用受协议、远端与网络环境共同影响，不能照搬一个固定数字。修改前保留原值，改变后观察真实任务和待机表现，而不是只看几分钟内电池百分比有没有变化。

若耗电变化与系统更新、设备迁移或大批文件同步同时发生，也应等待相关后台工作结束后再比较。重启设备可以排除部分临时状态，但不能替代持续观察。设备明显过热时先停止高负载任务，待温度恢复再测试；不要让长时间测速成为新的发热来源。若在相同任务、稳定网络、关闭重复测试后仍持续异常，整理连接频率与失败类别，进一步核对配置及系统状态。

08 · 配置差异与可恢复操作

应用或系统更新后出现异常

更新发生在故障之前，并不自动证明更新就是原因。同一时间还可能发生订阅内容变化、网络切换、服务器维护或配置自动刷新。先记录“最后一次正常使用”和“第一次出现异常”之间做过哪些操作，区分应用更新、系统更新与配置更新。保留旧配置和当前配置的差异，比立即重装更有价值，也能避免修复过程中丢失唯一可工作的记录。

先核对获取来源和兼容性

Shadowrocket 是闭源商业应用，只通过 App Store 获取和更新。购买与正版信息可在下载页的核验章节查阅，重点核对开发者 Shadow Launch Technology Limited、官方图标和应用 ID 932747118。系统要求以 App Store 页面标注为准。不要根据旧文章中的系统要求判断当前设备是否兼容，也不要把应用购买记录与本地配置是否保存混为一谈。

若应用能够打开，先检查 Home 选中的服务器、Global Routing 姿态和 Config 中生效的配置是否与之前一致。更新后出现提示时，应阅读具体内容再操作；某些问题只是原先选择的记录已经被订阅刷新替换。确认配置存在后，正常断开并重新连接一次，再用原来的测试目标验证。不要在尚未确认当前状态时连续导入多个备份，使文件和策略名称发生新的混淆。

按系统、应用、配置三层做对照

先在关闭连接的状态下验证基础网络，再测试系统连接能否保持，最后测试代理后的实际访问。这样可以把系统授权问题与规则问题分开。如果开关立即关闭，回到第一章处理；如果连接保持但只有 Config 失败，优先比较配置；如果某一条服务器在所有姿态相关测试中都失败，则检查它是否恰好在同一时间更换了参数或停止服务。

配置比较时，重点看最近修改的 DNS、规则顺序、策略名称和远程引用，不必从头重写整个文件。旧副本可以用于对照，但不应不加判断地覆盖所有新内容。远程配置即使文件名没有变化，实际内容也可能已经更新，因此应保存可阅读的本地副本。若恢复某个字段后问题消失，再确认这一结果能够重复，避免把网络偶然恢复误认为字段修改有效。

重建与重装之前先确认备份边界

应用购买恢复、服务器记录恢复和配置恢复是三件事。App Store 能帮助找回已购买的应用，但不等于自动找回全部本地记录、认证信息和手工修改。决定重装前，确认已有订阅地址仍可取得、手动服务器参数有安全备份、配置副本能够打开，并且理解哪些数据依赖同步。不要在唯一一台保留完整配置的设备上，未经检查就执行删除。

使用 iCloud 或文件导出备份时，应实际核对目标设备或备份文件，而不是只看同步开关已经开启。认证信息和订阅地址具有敏感性，导出文件应保存在受控位置。有关迁移步骤可阅读配置备份与换机恢复。若需要重建系统 VPN 配置，先按第一章处理，通常不必把所有应用数据一起清除。

恢复后按固定顺序验收：确认应用可打开、系统授权完成、配置已选中、已有服务器可用，再测试订阅更新和日常目标。每一步通过后才恢复自动任务，避免多个后台动作同时发生。若异常仍可复现，记录系统环境、应用内可见的相关设置、最小复现步骤和脱敏错误；不要公开完整配置来证明问题。记录应说明操作与结果，而不是只写“更新后坏了”。

09 · 独立设备、共享配置与局域网

iPad 上异常，而 iPhone 使用正常

先把 iPad 当作独立设备检查，不要把 iPhone 的成功结果直接套用。两台设备可能连接不同的 Wi-Fi、使用不同的解析来源，或者选中了不同的配置和服务器。即使显示相同的订阅名称，最后更新时间与内容也可能不同。先让两台设备处在同一网络，再逐项比较可见设置，明确差异发生在设备环境还是配置本身。

确认购买、权限与设备网络条件

iPad 的获取说明见iPad 购买与首次打开。已购应用的重新获取与适用范围以 App Store 页面标注为准，系统要求同样以 App Store 页面标注为准。应用已经安装不代表系统 VPN 授权已经完成；在 iPhone 上完成的授权不会自动替代 iPad 的本机授权。先检查 iPad 的系统 VPN 页面，再测试开关是否能够保持。

在受管理的 iPad 上，还要确认设备策略是否允许相关连接。移动网络机型与仅使用 Wi-Fi 的设备，能够使用的测试路径也不同；没有另一条独立网络时，不应把无法完成交叉测试误判为某个参数已经正确。可以在有权限使用的另一处 Wi-Fi 下进行对照，并留意公共网络是否需要各设备分别登录。iPhone 已经通过登录，并不保证 iPad 的网络会话也已完成。

逐项比较，而不是整份覆盖

先比较 Global Routing、当前 Config 和所选服务器，再比较协议字段、DNS 和规则。订阅名称一致但服务器列表不同，可能只是其中一台尚未成功更新；条目名称一致但认证字段不同，也可能来自手工修改。比较时不要通过聊天工具发送完整凭据，可以在各自设备上对照原服务商信息。确认差异后只修复对应项目，避免把 iPhone 的局域网专用规则直接覆盖到不相同的网络环境。

横屏、分屏和窗口大小变化可能改变导航呈现方式，但不会把 Config、Home 或 Settings 的逻辑含义变成另一套设置。如果某个按钮没有出现在熟悉的位置，先退出搜索、关闭编辑状态并检查当前栏目，不要反复导入同一份内容。列表过长时还应检查筛选条件和分组是否展开。界面位置变化与服务器通信失败应分别处理，不能因为找不到入口就认定配置丢失。

检查休眠恢复、网络切换与局域网访问

如果问题只发生在唤醒之后，先记录设备休眠前后的网络是否相同，以及 On Demand 是否发生了重新连接。打开一个新的网页请求，比观察之前停留的页面更可靠，因为旧页面可能保留已中断的会话。若重新连接后恢复，应继续检查网络变化与自动触发条件，不要仅通过延长屏幕常亮时间掩盖问题。待机行为还应结合电量章节检查重复重连，而不是只看前台开关状态。

iPad 经常用于访问家庭存储、投屏设备或其他局域网服务。连接后这些功能异常时，先检查它们使用的实际地址和本地网络权限，并核对相应网段是否走 DIRECT。设备发现可能依赖广播或本地发现机制，单条域名规则不一定覆盖整个过程。先验证直接访问已知局域网地址是否成功，再区分名称发现、应用权限和网络转发问题，不要把所有相关功能都归到 DNS。

配置同步也需要单独验收。文件已经出现在另一台设备，不代表它已经成为当前生效的 Config；服务器记录存在，也不代表已经选中。迁移后应在 iPad 上重新执行一次完整但简短的验证：选择配置、选择已有服务器、确认姿态、开启连接、访问原来的测试目标。全部通过之后再恢复自动更新与 On Demand，这样一旦问题重现，就能确定是哪一步引入了新的条件。

最后用相同目标完成两台设备的对照，并记录仍然不同的设置。如果 iPhone 正常、iPad 在同一网络和相同参数下仍失败，继续查看 iPad 本机的系统授权、解析结果和错误阶段；如果两台设备同时失败，则把重点转回共同的网络、服务器或订阅。日常操作不熟悉时返回使用说明，字段含义不明确时查阅术语手册，不必为解决一个局部问题重新建立整套配置。