Shadowrocket
故障排查手册

01 / VPN CONFIGURATION

开关打不开或立即关闭

先区分授权失败与连接失败

Home 中的连接开关不能保持开启，首先检查系统是否允许建立 VPN 配置。首次连接时，系统可能要求确认添加 VPN 配置，并通过设备密码或系统认证完成授权。这个过程允许应用建立网络通道，不代表远端服务器已经通过验证。若弹窗被取消，应返回应用再次触发连接并完成确认，而不是反复改动服务器密码。先记下开关是在确认前关闭，还是开启片刻后关闭，两种现象的检查方向不同。

打开系统 Settings，在 VPN 相关设置中查看是否存在 Shadowrocket 对应的配置。不同系统界面的入口位置可能变化，可使用设置搜索定位。检查当前是否还有其他 VPN 会话正在运行；普通个人 VPN 连接通常不能同时保持多条。先结束其他会话，再回到 Shadowrocket 测试。不要在不清楚用途时删除所有网络配置，尤其是工作或学校设备上的受管理项目，这些项目可能承担必要的访问控制。

按可逆顺序处理残留状态

1. 停止当前连接，等待系统 VPN 状态解除，再重新打开 Shadowrocket。
2. 临时关闭 On Demand，避免系统自动连接与手动测试交替发生。
3. 确认已有服务器处于选中状态，保存配置后只进行一次连接测试。
4. 若仍立即退出，重启设备，随后在相同网络复测并记录结果。

若系统中已有配置，但应用持续无法建立会话，可以在确认配置备份完整后，移除明确属于 Shadowrocket 的 VPN 配置，再由应用重新申请。这里移除的是系统网络授权记录，不是远端账号的重置方式，也不能修复服务到期或参数错误。操作前应确认能重新找到已有配置；不要把重新安装应用当作第一步，因为本地服务器、Config 和诊断记录可能随之丢失。

检查系统限制与触发条件

受管理设备可能限制新增 VPN、修改网络设置或运行特定网络扩展。如果系统按钮不可编辑、提示由组织管理，或者配置被自动恢复，应联系设备管理方确认策略。设备密码、屏幕使用时间限制和管理策略是不同层级的问题，远端服务器信息不能改变这些限制。个人设备也应先确认系统空间是否紧张、其他应用是否同时出现异常，再判断是不是网络扩展启动失败。

On Demand 会按设定条件触发连接，因此“关掉后又自动打开”不一定是开关故障。先停用 On Demand，确认手动连接能够稳定保持，再逐条恢复触发条件。若只在切换 Wi-Fi、锁屏或离开某个网络后异常，应记录具体动作，而不是只写“偶尔断开”。固定触发条件后，同一组设置可以重复验证，才能区分系统重建会话与应用意外停止。

仍不能开启时，整理设备型号、系统要求核对结果、授权弹窗内容、是否受管理和重启后的复现步骤。应用获取与系统要求请查看正版核验说明，系统要求以 App Store 页面标注为准。不要通过连续删除配置掩盖最初的错误提示，原始提示往往比最后一次尝试更有定位价值。

02 / REQUEST PATH

已经连接，但网页无法打开

先建立关闭连接时的对照

先停止 Shadowrocket，在当前 Wi-Fi 或蜂窝网络中打开平时可以正常访问的页面。如果关闭连接后也失败，应先检查网络本身，包括 Wi-Fi 是否需要网页认证、路由器是否能够联网、蜂窝数据是否允许使用，以及设备是否处于信号不稳定的位置。公共 Wi-Fi 的认证页面可能需要在停止连接时完成；认证通过后再恢复测试。底层网络尚未可用时，继续修改规则通常只会增加变量。

若关闭时正常、开启后失败，再确认故障范围。分别测试两个不同目标，区分所有请求失败、单个应用失败与某个域名失败。使用相同页面和相同操作进行对照，避免一个测试打开的是已缓存内容，另一个测试需要重新请求网络。浏览器显示旧页面并不能证明连接正常；应重新加载需要联网的内容，同时观察应用中的请求记录是否出现对应访问。

用 Global Routing 判断问题所在

Global Routing 决定整体请求如何进入后续处理。配置姿态 Config 根据当前规则匹配，代理姿态 Proxy 用于检查选中服务器的路径，直连姿态 Direct 用于观察不经代理策略的访问情况。这三个姿态适合短时对照，不是通用修复按钮。测试结束后恢复原来需要的姿态，并确认当前启用的 Config 正是预期文件，不能只看文件列表中是否存在某份配置。

如果 Proxy 下正常而 Config 下失败，重点查看失败请求命中了什么规则，以及最终使用了哪个策略。较宽的 DOMAIN-KEYWORD、过早出现的 REJECT 或不符合预期的 DIRECT 都可能改变请求路径。规则通常按顺序判断，应先找到实际命中行，再检查它之前是否有更宽的条件。不要只在配置末尾增加一条正确规则，因为请求可能早已被前面的规则匹配。

用最小规则理解判定，不覆盖原配置

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

这里的 example.com 仅用于说明语法，不是连通性测试服务。DOMAIN-SUFFIX 匹配指定域名及其子域名；GEOIP 按地址归属判断；FINAL 为尚未匹配的请求提供兜底策略。若要试验，应复制现有 Config 后另存测试文件，并保留原文件。不要把这三行理解成适用于所有场景的完整配置，更不要把原有 DNS、策略与其他必要设置一起删除。

若 Proxy 与 Config 都失败，但 Direct 正常，转查服务器参数、远端可用性和代理路径中的 DNS。若只有某个应用失败，查看它是否使用了独立连接方式、是否保留旧会话，以及系统是否允许它使用蜂窝数据。必要时完全结束该应用后重新打开，确保测试的是新连接。重启目标应用与重建 VPN 会话应分开进行，才能知道是哪一步改变了结果。

发现 REJECT 命中时，先核实域名用途，临时停用单条疑似规则再复测，不要整体移除所有拦截规则。一个页面可能依赖多个域名，其中一个请求被拒绝就会造成部分空白或登录失败。相关边界见REJECT 规则写法说明。如果所有姿态都失败且底层网络正常，保留失败请求的时间与错误类别，继续检查下一章。

03 / SERVER PARAMETERS

节点超时与协议握手失败

测试结果先按层次解释

Connectivity Test 或服务器延迟测试只能说明某种测试方法在当时的网络中是否完成，不等于浏览器中的全部请求结果。测试失败可能涉及服务器地址解析、端口连接、协议握手或测试目标；测试成功也不能保证远端能够访问所有目标。先记下所用测试方式，再打开实际失败的页面进行验证。对比结果时使用同一种方法，不把不同测试产生的数字直接放在一起比较。

核对服务器地址时，注意复制过程中是否带入空格、换行或标点。地址字段应与已有服务信息一致，端口也必须对应当前协议入口。域名能够解析不代表端口可达，端口能够建立连接也不代表认证成功。若已有信息包含多个端口或不同传输方式，按对应关系逐项填写，不要把一个入口的地址与另一个入口的 TLS 或传输参数拼接使用。

检查协议字段之间的约束

TLS 中用于证书验证的服务器名称，与实际建立连接的地址可能承担不同职责；应以已有配置提供的信息为准。传输层的 Host、路径或其他字段也不应凭名称猜测。若服务端配置发生调整，旧订阅中的参数可能仍能导入但已经不能握手。先更新自己的订阅并确认更新成功，再比较更新前后的字段差异，避免在多个相似条目之间误选旧记录。

检查系统日期、时间与时区，优先使用系统自动设置。时间明显偏差可能影响证书验证或带时间约束的认证。遇到证书错误时，不应把关闭验证作为固定处理方法；应核对服务器名称、设备时间和远端证书状态。绕过验证会掩盖真正原因，也使后续无法判断是参数修复还是仅仅跳过了错误。恢复正确验证后再次测试才算完成排查。

通过网络对照定位路径问题

保持服务器与参数不变，分别在 Wi-Fi 和蜂窝网络测试。如果仅一个网络失败，检查该网络是否存在访问限制、UDP 处理差异或地址族差异。这个结论只能缩小到网络路径，不能直接认定某个具体设备故障。若只有一个服务器失败，而同一订阅中用户已有的其他服务器正常，可优先向原服务方确认该入口状态，不必先重建全部客户端设置。

涉及 WireGuard 时，需要同时确认 Peer 能够完成通信，以及 AllowedIPs 是否覆盖希望经过通道的目标范围。握手和路由是两个问题，前者正常并不保证后者正确。私钥与远端公钥不能互换，分享诊断时也不能暴露私钥。字段含义可继续查看WireGuard 参数说明，不要通过随机更换密钥排查路径问题。

完成检查后，把故障描述写成“某网络下某协议的握手超时，另一个网络结果如何”，并附上已经核对的字段类别，而不是提交完整认证内容。若需更细的固定顺序，可查看节点超时检查清单。连续快速重试通常不能修复远端状态，反而会混淆不同时间的结果；取得可重复的样本后再决定下一步。

04 / SUBSCRIPTION UPDATE

Subscribe 导入失败或更新异常

区分获取失败与内容解析失败

订阅更新至少经过获取地址、请求服务器、接收响应和解析内容几个阶段。“更新失败”只是结果，首先要判断停在哪个阶段。没有收到响应与收到内容但无法识别，处理方法不同。前者关注网络、地址与认证，后者关注响应是否真的是 Shadowrocket 能识别的订阅内容。先保留原有可用条目，不要在每次更新失败后删除整个订阅组，否则会失去可供比较的旧配置。

从自己的服务信息中重新复制完整订阅地址，检查前后空格、换行、遗漏的查询部分以及误加入的中文标点。订阅地址通常包含访问凭据，不能放进公开截图、聊天记录或诊断附件。若必须展示请求结构，只保留域名和字段名称，并去掉字段值。不要为了测试而反复把完整地址粘贴到不同网页中，地址被其他人获得后可能带来账号或服务使用风险。

按响应表现选择检查分支

出现认证失败、权限不足或访问被拒绝时，优先在原服务方提供的账号页面核对订阅状态、地址是否已重置以及访问限制。重新购买客户端不会恢复远端认证。客户端一次性买断 ≠ 线路套餐，应用购买记录与用户已有服务的凭据是两套独立信息。相关购买事实见价格与买断说明，不要把 App Store 的已购状态当成订阅仍然有效的证明。

如果响应内容是登录页面、维护提示或其他网页，即使请求本身已经完成，也不代表订阅更新成功。客户端需要的是可识别的订阅数据，而不是浏览器能够显示的任意内容。遇到重定向时，还应确认最终响应是不是仍在预期的服务流程内。不要通过手工删除地址中的认证部分解决解析错误，这通常只会使请求转成未登录状态，进一步偏离原问题。

若当前连接本身不可用，订阅请求也可能被分配到失败的代理路径。先在保留旧条目的情况下，比较停止连接与使用已有可用连接时的更新结果，并注意当前 Config 对订阅域名的判定。不能假定所有更新请求都沿同一条路径，也不能因为浏览器能打开服务页面，就认定应用的订阅请求必然成功。两者的会话、认证与返回内容可能不同。

更新成功后仍要核对实际变化

1. 确认操作返回成功，并查看订阅组中实际出现的服务器，而不只看提示文字。
2. 检查当前选中的条目是否仍指向旧入口，必要时重新选择已有的新条目。
3. 核对名称相似的服务器所属订阅组，避免测试另一份残留配置。
4. 连接测试通过后再整理旧记录，保留能够回溯的配置副本。

更新后数量减少，并不一定是导入丢失。原服务可能调整了条目、账号权限或订阅内容，也可能因筛选条件使部分记录不显示。应比较实际响应与组内结果，先确认原始内容是否包含预期条目。名称变化也不代表服务器参数完全变化；反过来，名称不变并不能证明地址、端口和认证信息仍旧一致。定位时应关注字段，而不是只比较列表外观。

手动添加的服务器与订阅管理的服务器应分开理解。直接修改订阅条目后，下次更新可能被远端内容覆盖；如需临时验证参数，应先保留原始值并记录修改原因。不要把长期维护建立在每次更新后重复改字段的流程上，若远端持续返回错误参数，应交由原服务方确认。客户端中的临时改动只能作为验证证据，不能修复订阅源本身。

若导入步骤本身不明确，返回入门指南核对已有订阅的添加流程；若属于账号与购买概念混淆，可查看常见问题。先确定故障所属阶段，再调整设置，比同时替换地址、规则和服务器更容易得到有效结论。

05 / PERFORMANCE BASELINE

速度慢、加载停顿与网络切换

把速度问题拆成不同现象

“慢”可能指第一次打开页面等待较久、下载持续速率偏低、视频间歇停顿，或网络切换后需要很久才能恢复。它们分别可能涉及 DNS、连接建立、持续吞吐和会话重建，不能只用一个延迟数字解释。先写清慢发生在哪个阶段，再选择对应测试。页面已经开始传输后的速度，与请求发出前等待的时间应分开观察，否则容易把解析问题误认为带宽不足。

建立对照时，保持设备位置、目标内容、网络和测试时段尽量一致。先停止连接观察底层网络，再使用同一已有服务器测试；随后只更换用户已有的另一个入口作比较。不要一边更换网络一边修改协议，否则无法判断结果来自哪个变量。测试内容应足够接近真实故障场景，单次短请求正常并不能排除长连接或较大传输中出现的问题。

延迟、丢包与吞吐分别判断

连接建立较快，只表示当前测试的往返和握手过程较顺利，不保证持续传输能力。远端负载、链路拥塞、目标服务限制以及 Wi-Fi 干扰都可能影响吞吐。如果多次测试中等待时间忽高忽低，先观察当前网络是否在移动、信号是否变化、设备是否自动切换接入点。距离路由器较远时，较高的无线重传可能比客户端规则更值得优先检查。

只有某个目标慢，而其他目标在同一路径下正常，应检查该目标的访问路径、内容缓存和服务状态。某些页面会先显示主体，再等待额外域名的资源；如果附属请求走错策略或被 REJECT，外观看起来也像持续加载。此时应查看请求记录中最后等待或失败的域名，而不是直接认定整个连接速度不足。完成针对性规则对照后，重新测试同一个页面。

配置中不同请求可能使用不同策略，因而同一设备上不同应用的体验不一定相同。用 Proxy 与 Config 做短时对照，可以检查是否为规则路径差异；但测试结束必须恢复需要的配置姿态。若 Proxy 下改善，继续定位具体命中规则，而不是把代理姿态当作所有场景的固定答案。若两种姿态都慢，应回到服务器与网络对照，避免不断增加规则。

MTU 与长连接只在有证据时调整

当小请求正常、较大传输卡住，或者某种网络下持续出现特定协议的停顿时，才值得检查 MTU 与路径相关问题。MTU 影响可承载的数据包大小，数值并非越大越快，也不是越小越稳定。优先使用已有配置提供的值或应用默认行为；需要试验时，每次只调整一个值并记录前后表现。不同协议和网络的适用情况不同，不应复制一个固定值到所有条目。

网络从 Wi-Fi 切到蜂窝后，原来的连接可能失效，需要重新建立会话。若切换后只有已有页面停住，而新打开的请求正常，优先刷新目标应用中的连接；若所有新请求也失败，再重建 Shadowrocket 会话。On Demand 可能影响自动恢复的触发时机，应先验证手动连接，再检查自动连接条件。切换测试应明确记录切换前后的网络，而不是连续快速来回操作。

测试期间减少其他大量传输、系统备份和应用更新，使结果更可比较。同时检查低数据模式、目标应用的流量设置与设备温度，这些因素可能改变应用行为。发热明显时先让设备恢复正常工作状态，再测试持续传输。不要通过同时启用更多诊断、更多自动测试来观察速度，额外活动本身也可能影响网络和耗电，使原始现象变得更复杂。

若慢主要集中在首次访问新域名，转到 DNS 章节；若伴随大量重连，回到节点超时章节。经过多组同条件对照后仍只在某个已有入口出现问题，可以把去除敏感字段后的时间、目标类型与复现条件交给原服务方确认，而不是继续随机调整客户端参数。

06 / NAME RESOLUTION

DNS 解析失败与域名访问异常

解析、连接与加密验证不是一回事

访问域名通常需要先取得目标地址，再建立连接，最后完成上层协议交互。页面打不开可能发生在任一阶段，DNS 只是其中之一。若记录明确显示解析超时、没有可用地址或解析结果异常，再进入本章检查。直接把网页中的域名替换成 IP 并不是可靠的通用测试，因为 HTTPS 还涉及证书名称与服务端按域名选择内容，替换后产生的新错误可能与原问题无关。

先确认失败范围，是所有新域名、某个域名，还是仅在 Config 姿态出现。已经访问过的目标可能使用缓存，短时间内继续打开并不能证明解析始终正常。选择相同域名重复测试时，应了解应用和系统可能各自保留缓存；重建会话后的结果也不一定等于清除了所有层级缓存。因此应同时观察实际请求记录，而不是仅凭刷新页面的快慢作判断。

检查解析器能否通过当前路径访问

查看当前 Config 中与 DNS 相关的设置，并确认它们来自哪份配置。订阅中的服务器条目与 Config 中的解析设置不一定同步更新；只更新订阅不能保证 DNS 设置也发生变化。若使用自定义解析器，需要确认当前网络和策略能够访问它。采用加密 DNS 时，还可能涉及解析器自身域名的首次解析、TLS 验证和请求路径，不能只凭地址看起来完整就认为一定可用。

若停用自定义 DNS 后恢复，说明问题可能位于自定义解析路径，但还不能断言是解析器服务本身故障。继续比较解析器在不同网络下是否可达、请求是否被错误分流，以及相关设置是否与当前配置的其他部分配套。优先恢复自己已经验证过的设置，再逐项引入自定义项。不要一次填写多个不清楚来源的地址，这会使失败顺序与实际使用对象难以追踪。

理解域名规则与地址规则的差别

域名规则和地址规则依赖的信息不同，地址规则的行为还可能受到是否触发解析以及相关选项影响。排查时应查看请求实际拥有的域名、地址和命中行，而不是假定每条请求都按同一过程匹配。如果同一个域名返回多个地址，其中部分路径不可达，表现可能是间歇成功。此时要把解析结果与连接失败对应起来，不能只保留一次成功样本。

IPv4 与 IPv6 的可达性可能不同。某网络宣告支持 IPv6，并不保证当前服务器、目标或全部中间路径都能顺利处理对应连接。若故障与地址族相关，应保持其他条件不变，比较解析结果及实际连接行为。不要在没有证据时把关闭某个地址族作为长期方案；调整后若恢复，也需要记录它解决的是哪条路径，以及是否影响原本可用的其他访问。

局域网名称与分流边界

家庭或工作网络中的本地设备名称，可能依赖本地解析或发现机制。将全部 DNS 请求送到远端解析器后，远端通常无法理解只在局域网内存在的名称。若外部网页正常而本地设备访问失败，应检查本地网络授权、局域网路径以及相关域名的处理方式，不要把外部解析器换得越来越多。局域网名称能否解析与是否允许访问设备地址，也需要分别验证。

修复后用原先失败的域名、新发起的连接和目标应用各验证一次，并恢复临时关闭的诊断设置。若只修复了浏览器，而其他应用仍失败，继续查看应用是否保留旧会话或使用自己的解析行为。DNS 调整不是对所有连接错误的统一处理；明确解析已经成功后，就应转查端口、TLS 与策略，不要继续反复清理缓存。

07 / ENERGY AND LIFECYCLE

耗电、发热与反复重连

先看相同使用条件下的变化

耗电异常需要与实际使用场景一起判断。持续传输、较弱的蜂窝信号、频繁切换网络、视频播放和屏幕常亮，都可能同时增加能耗。系统电池页面显示的是特定统计周期内的使用情况，不应把某个应用占比高直接理解成它独自造成了额外耗电。先比较相近时长、相同网络和相近操作下的表现，再判断是否与 Shadowrocket 的连接或配置变化有关。

记录异常开始前改过哪些设置，例如新增 On Demand 条件、启用更详细的诊断、换用另一已有服务器或导入新的 Config。一次只恢复一项到之前状态，并留出足够时间观察。不要用数分钟的短暂静置推断整天的电池表现，也不要一边充电、一边进行大量传输，再与未充电时的轻度使用比较。测试条件差异过大时，数字变化缺少解释价值。

检查重连循环与持续失败请求

连接反复建立和中断会产生额外网络活动。先观察 VPN 会话是否稳定，以及异常是否集中在锁屏、离开 Wi-Fi 或信号变弱之后。若服务器参数错误导致持续失败，应先处理连接问题，不要仅靠降低诊断显示量来处理表面现象。相同应用持续重试失败请求时，也可能造成活动增多，需要同时确认发起请求的应用与失败原因。

On Demand 是触发连接的机制，与请求进入连接后的规则匹配不是同一层。触发条件如果与实际使用场景不匹配，可能表现为不需要时频繁建立会话，或网络变化后反复恢复。先停用 On Demand，验证手动开启后的稳定性，再逐条恢复条件。每加回一项，都经过正常的锁屏和网络切换过程测试，不要同时恢复全部条件后再猜是哪一项造成变化。

让诊断只在排查窗口中运行

详细日志、频繁的 Connectivity Test 和持续观察请求记录适合短时定位，不宜因为担心故障而一直主动测试。采集到能重现问题的记录后，应恢复日常使用所需的诊断级别。日志里可能含有目标域名、地址和使用时间，保存与分享也应遵循最小范围原则。关闭额外诊断后仍需用相同场景复测，确认改善并非只是因为同时停止了大量实际使用。

配置中如果存在高频自动任务或依赖外部资源的处理，应检查它们是否反复失败、是否确有使用必要。先复制配置作对照，再临时停用新增部分，保留核心连接与规则。不要整份清空后看到耗电下降就认定某条规则有问题，因为流量路径和使用行为都可能随之改变。定位应逐步缩小到一个组件，并能在恢复该组件后重复出现相同现象。

区分连接空闲与实际传输

VPN 标识持续存在，不意味着设备始终以同样强度工作。空闲连接和大量数据处理的能耗不同，后台应用同步也可能让看似静置的设备继续传输。若锁屏后仍持续发热，可先检查系统电池与网络活动，再逐个停止非必要的后台任务。不要为了观察而不断点亮屏幕、刷新测试页面，这些动作本身会使设备难以进入与日常相同的空闲状态。

协议、网络与服务器路径的组合可能影响能耗，但不能仅按协议名称作统一结论。保持服务入口与其他参数尽量一致的对照才有意义；用户已有的不同入口往往还存在远端位置、负载和传输设置差异。优先处理可确认的重连、失败请求与弱信号，再考虑更细的参数调整。未确认根因前，不要把所有后台连接需求都关闭，以免影响正常通知或同步。

有效的耗电报告应包括观察时长、屏幕使用情况、网络类型、是否充电、On Demand 状态以及连接是否重建。若更新或换机后才出现异常，保留这些条件并进入下一章。系统对能耗的归因有统计边界，单张电池截图无法替代可重复的对照过程，也不能据此推导固定的耗电承诺。

08 / RECOVERY AND IPAD

更新后异常与 iPad 专项检查

更新后先保留配置，再重建会话

系统或应用更新后出现异常，先记录更新后首次观察到问题的条件，不要立即认定更新改变了全部设置。远端服务、当前网络和订阅内容也可能恰好发生变化。先结束旧会话，重新打开应用并建立连接；如果现象仍在，再核对选中服务器、Global Routing 与当前 Config。保留更新前可用的配置副本，能帮助判断是否是选择状态或配置内容发生差异。

一次完整的恢复顺序可以是：确认底层网络正常，核对当前选择，临时关闭 On Demand，手动重连，然后按本页相应章节检查错误。重启设备适合清理暂时状态，但不能替代参数验证。若重启后只短暂恢复，应记录再次失败前发生了什么，例如锁屏、网络切换或订阅更新。恢复时间长短与触发动作，比单纯写“重启无效”更能缩小范围。

应用更新与重新获取统一通过 App Store，系统要求以 App Store 页面标注为准。购买与恢复操作见已购项目恢复说明。重新安装前，确认本地服务器、Config 和所需记录已经妥善保留，并且已有服务信息仍可重新取得。应用购买记录并不等于本地配置备份，恢复已购应用也不会自动保证所有自定义参数都回到原样。

iPad 先核对选择状态与网络权限

iPad 上即使使用相同的已有订阅，也应分别确认当前选中服务器与 Config，不能因为 iPhone 正常就假定两台设备状态一致。较大的屏幕可能同时显示列表与详情，查看某个条目的详情不一定意味着它已经成为当前连接所用条目。回到 Home 核对实际选择，再建立一次新会话。以当前界面显示为准，不通过列表位置或上一次打开的详情推测连接对象。

检查 iPad 当前使用的是 Wi-Fi 还是蜂窝网络；不同设备可能根本不在同一路径上。具备蜂窝能力的设备还应核对系统对应用数据使用的允许状态。若只在访问局域网设备时失败，再检查本地网络相关授权与对应规则。iPhone 与 iPad 的对照要尽量接入同一网络、使用相同配置和相同目标，否则设备差异与网络差异会混在一起，不能据此定位到应用。

锁屏、多任务与配置迁移

在多任务或分屏状态中，界面是否仍停留在前台，与系统 VPN 会话是否持续运行是两件事。应通过系统状态和新请求结果判断连接，而不是只看某个窗口是否刷新。若锁屏后恢复出现问题，分别测试原应用中的旧连接与新发起的请求；只有旧连接失败时，先刷新目标应用，所有请求都失败时再重建 VPN。这样可以避免把应用会话问题归因于设备连接整体停止。

迁移配置时，将服务器信息、Config 与系统 VPN 授权分开处理。前两者需要确认导入内容和选择状态，后者通常需要在新设备上重新授权。包含认证信息的配置应通过自己控制的安全方式保存，不要把它作为普通示例公开分享。迁移完成后先验证一个已有服务器，再检查规则和自动连接，最后恢复其他自定义设置，避免一次导入所有内容后难以确认故障来源。

形成可以交接的故障记录

若同一配置在一台设备正常、另一台异常，逐项比较系统权限、网络、时间、应用设置与实际请求记录。不要直接复制全部系统网络设置，也不要清除设备中与本问题无关的管理配置。针对 iPad 的获取与首次打开事项，可查看iPad 说明；换机时的已购恢复步骤还可参阅换机后恢复应用笔记。

最后，把问题整理成可重复的最短流程：在什么网络上、采用哪个姿态、执行什么动作、出现什么错误、哪些对照正常，以及最近只改动了哪一项。附带经过脱敏的错误类别和时间即可，不必提交全部历史记录。若恢复后再次出现相同症状，沿原来已验证的顺序复查；若症状变化，则回到对应章节重新建立基线，不把一次有效的恢复操作当成永久适用的处理方案。