Shadowrocket 故障排查

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

开关无法保持开启，首先要区分“系统没有建立隧道”和“隧道已经建立但访问失败”。前者常表现为打开后立即退回、反复出现授权提示，或者系统设置中的 VPN 状态始终没有变化；后者通常可以保持连接，却无法加载内容。先停留在 Home 观察一次完整操作，不要连续快速切换，以免把正常的建立过程误认为无响应。

确认首次授权与本地配置

首次启用时，系统可能要求允许添加 VPN 配置，并通过设备密码或系统认证确认。只有在刚刚主动操作 Shadowrocket 时，才继续这次授权；若取消了弹窗，返回应用再次发起连接即可。应用内开关与系统授权属于两个步骤，导入了服务器并不代表设备已允许创建隧道。授权完成后，再观察系统状态与应用状态是否一致。

进入系统设置查看 VPN 配置，确认存在与 Shadowrocket 对应的项目。系统入口名称会随设备系统调整，应通过设置内搜索定位，不必拘泥于固定路径。若已经存在多个网络配置，先记录名称及用途，再暂时停止其他会接管设备流量的连接。不要直接批量删除，尤其是工作或学校管理的设备，部分配置可能由管理策略自动恢复。

检查 Home 中是否已经选中一项有效服务器，留意选中标记，而不是只看列表中是否有条目。打开该条目核对 Address、Port 与协议类型是否保存完整；如果刚才编辑后直接退出，重新进入确认修改确实保留。空缺字段或无法解析的配置可能让连接在启动阶段失败。服务器能否实际通信，应放到下一阶段验证，不能仅凭开关回退就断定远端故障。

排除按需连接与系统限制

如果手动关闭后又自动开启，先检查 On Demand。按需连接会按已配置的条件触发，它与用户手动操作同时存在时，容易造成“开关不听操作”的观感。记录现有条件，暂时关闭 On Demand，再做一次手动连接与断开对照。只有确认手动状态稳定后，才逐项恢复自动条件；不要一边修改按需规则，一边更换服务器。

若按钮不可操作、授权弹窗始终不出现，检查设备是否受到组织管理，以及系统是否限制修改 VPN。管理策略造成的限制应由设备管理员确认，反复重装应用通常不能改变策略。对于个人设备，可以先退出正在占用网络的任务，正常重新启动设备，再测试一次。重启属于清理暂态状态，不是修复服务器参数或网络条件的方法。

在需要网页登录认证的 Wi-Fi 中，应先断开隧道并完成网络认证，再启动连接。否则系统虽然已连上无线网络，实际外部通信仍被认证页面拦住。用普通网页确认基础网络恢复，而不是只依据 Wi-Fi 图标判断。切换到另一条已有可用网络后若开关能稳定保持，应继续检查原网络的接入条件，而不是立即清空应用数据。

何时重建 VPN 配置

只有在授权记录异常、系统状态与应用状态持续不同步，并且前述对照无效时，才考虑重建对应的 VPN 配置。先保留服务器资料与 Config 备份，停止连接和 On Demand，再删除确认属于 Shadowrocket 的系统 VPN 项，随后回到应用重新请求授权。删除系统 VPN 项与删除应用内服务器是不同操作，应仔细核对确认文字，避免误删仍需使用的资料。

完成重建后，以最少变量测试：一个已核对的服务器、手动连接、暂时关闭按需触发。若仍然立即退出，保存本次错误提示、复现顺序及系统中的连接状态；若开关已经稳定但不能访问，则转到下一章。不要把“恢复出厂网络设置”作为起手操作，它会影响其他网络记录，也可能让原本可对照的环境消失。

连接后无法上网：分开验证服务器与规则

连接状态只说明设备启动了相应网络通道，不能证明所有请求都已经抵达目标。排查时选一个自己明确可以正常访问的网页作为对照，再选实际失败的目标。记录是所有应用都失败、只有某个网站失败，还是仅部分资源加载不全。浏览器显示的通用错误有时涵盖解析、连接及证书问题，应保留原始提示，不要直接将它等同于服务器不可用。

用 Global Routing 建立对照

先记下当前 Global Routing，再理解三种姿态的用途。Config 按当前配置中的规则选择策略；Proxy 用于把可接管的请求交给代理路径做对照；Direct 用于直连路径对照。它们不是按“效果强弱”排列的选项。测试结束后应恢复原来的姿态，尤其不要把临时的 Proxy 当作规则配置已经修复的证据。

若 Direct 可用而 Proxy 失败，优先检查默认服务器与协议参数；若 Proxy 可用而 Config 失败，重点查看规则命中与策略去向。若三者都失败，先彻底断开连接测试基础网络，再进入 DNS 章节。注意 Direct 状态下仍可能受到当前网络处理和解析设置影响，因此“切到 Direct”与“关闭连接”要作为两个独立对照记录。

沿着规则顺序查找去向

在 Config 中确认当前实际启用的文件，而不是只打开一个名称相似的文件查看。规则通常依次匹配，前面已命中的条目会影响后续是否还有机会参与。检查目标是否被过宽的 DOMAIN-KEYWORD、域名后缀规则或 IP 规则提前覆盖，同时核对命中策略是否存在、是否指向预期服务器。规则文字正确但策略不可用，同样会导致访问失败。

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

上例只说明匹配与兜底关系，不应直接覆盖现有文件。DOMAIN-SUFFIX 对示例域名及其子域名生效；DOMAIN-KEYWORD 范围更宽，修改前要考虑误匹配；FINAL 处理前面未命中的请求。示例域名需要按自己的目标调整，PROXY 还应结合当前默认服务器核对。若使用自定义策略名称，应检查名称和引用是否一致，不能把拼写差异当作网络问题。

页面文本能显示而图片、登录或视频失败时，不要只检查地址栏域名。一个页面可能从多个域名加载资源，也可能在认证过程中跳转。复现一次并查看应用中可用的请求记录，比较成功和失败请求的目标及策略。只增加有证据需要调整的规则，不要因为一个资源失败就把过宽的关键词规则放到顶部，扩大修改范围会掩盖真正原因。

确认应用与目标服务的边界

如果只有一个应用异常，先用浏览器访问同一服务的网页入口作对照；网页正常不代表应用内部接口一定正常，但可以缩小问题范围。检查该应用是否仍保留旧连接，切换策略后完全退出再打开，并重新触发请求。已有连接可能继续沿用先前建立的路径，不能要求修改规则后每条旧连接立即重新选择策略。

若失败表现为登录限制、账户提示或内容权限，应把目标服务返回的说明与网络超时分开。连接成功不负责改变服务端账户状态。恢复原配置后，再按指定网站规则写法整理需要保留的例外。只有目标请求稳定走向预期策略，且重新建立连接后仍可复现成功，才能认为本轮规则排查完成。

服务器超时：从可达性检查到协议认证

服务器超时不是一个唯一原因。地址解析失败、目标端口无法到达、协议字段不匹配、TLS 验证失败，最终都可能表现为等待后报错。先区分应用使用了哪种测试，再看实际连接时发生什么。某种延迟测试返回结果，只能说明该测试涉及的环节得到响应，不能据此保证认证、目标请求及持续传输全部正常。

先核对服务器资料是否对应

进入 Home 中当前选中的条目，与自己已有的原始资料逐项比较 Type、Address、Port 和认证字段。复制地址时容易带入前后空格，把完整链接误填到 Address，或把订阅地址当成单台服务器地址。端口应使用资料指定的数字，不要依据协议名称猜测。若通过扫描导入，导入完成后也应打开条目复核，扫描成功只代表内容被识别。

检查资料是否仍有效，以及服务端是否已经调整入口或认证信息。可先刷新自己已有的订阅，再比较新旧条目是否变化；若手工保存过专用参数，不要让更新覆盖后继续凭记忆补填。把“原资料如何写”“应用实际如何保存”“当前实际选中哪一项”放在一起核对，比反复尝试多组参数更容易找到错位。

先在当前网络测试，再换到另一条已有可用网络做同样测试。两条网络都失败时，优先检查服务器状态和参数；只有某条网络失败时，再考虑该网络的端口、传输类型或接入条件。这个对照不能直接判定任何一方有故障，却能避免把局部网络条件误当成配置错误。测试期间保持同一服务器和相同测试方式，才有比较意义。

按协议检查关键字段

对于使用 TLS 的配置，连接地址与证书名称可能承担不同作用。Address 决定连接入口，Peer/SNI 参与服务端名称与证书相关处理；当原始资料明确提供了名称时，应原样对应，而不是将所有字段都替换成同一个 IP。设备日期时间明显错误也可能影响证书有效期判断。先核对时间与名称，再根据错误提示继续定位。

不要通过长期启用 Allow Insecure 来掩盖证书错误。这个选项改变了验证条件，即使短暂连接成功，也不能证明服务器配置正确。正确路径是核对服务端给出的域名、证书名称与 TLS 要求，再恢复验证条件。若资料不完整，应向自己的服务提供方确认必要字段；手册里的示例不能代替真实连接参数。

用实际请求完成最后验证

运行 Connectivity Test 后，再打开一个已知可用的目标网页，观察是否能完成内容加载。若测试有结果但网页失败，继续查看 DNS 和规则；若只有大请求失败，则转到速度章节排查传输和路径问题。不要把每一种测试读数互相横比，它们可能使用不同方法、目标与超时条件，数值差异不一定意味着同一连接性能发生变化。

WireGuard 要额外注意 Allowed IPs 与本地地址范围，它们不是用于填写目标网站的普通规则列表。握手相关状态与网页访问仍应分开检查，路由范围错误可能造成部分目标缺失。需要逐项理解时，可参阅WireGuard 配置字段说明，但不要直接照抄不属于自己的地址和密钥。

排查记录至少保留协议、测试网络、错误阶段和是否所有服务器都失败。若只有某一项失败而其他已有项可用，可以暂时使用已验证的配置保持对照，并把失败项单独交由自己的服务提供方核验。分享记录时隐藏认证值及完整服务器地址；保留字段名称与错误类别通常已足够说明问题，没必要公开整份连接资料。

订阅失败：区分请求、内容与导入结果

Subscribe 更新包含多个环节：应用读取地址、通过网络发出请求、取得响应、解析内容，再将条目写入本地。失败可能发生在其中任意一步。先记录原始提示和发生时机，不要一看到失败就删除现有分组。原来已经保存的服务器可能仍然可用，删除分组会失去用于对照的资料，也不一定能解决上游返回错误。

确认链接完整且来源对应

从自己的服务提供方重新复制订阅地址，避免通过多次转发取得被截断的文本。检查是否混入换行、空格、句末标点，特别是查询参数中的字符是否完整。链接中的认证参数属于敏感信息，不应放进公开截图、在线转换页面或留言。只需要确认字段结构时，用示例地址代替真实地址，不能为了排错而扩大凭据的传播范围。

确认拿到的是订阅内容地址，而不是账户管理页面、付款记录页面或需要先登录的网页入口。浏览器能打开一个页面，并不代表它返回了应用可解析的服务器资料。若响应实际上是登录提示、错误说明或维护页面，应用通常不能把它当作服务器列表导入。此时应回到自己的资料来源核对地址类型，而不是不断更改协议字段。

首次导入与日常更新也要分开判断。首次失败时，重点检查地址、响应格式和网络；以前成功而现在失败时，还要核对订阅是否更换、认证是否失效，以及服务端是否调整内容。不要仅凭本地分组名称判断新旧地址相同，分组名称可以保持不变，而实际保存的链接已经不同。检查时注意遮盖完整地址后再做记录。

建立可重复的更新测试

先在当前网络手动更新一次，等结果明确后再操作下一次。连续点击可能让多个请求叠加，也可能触发服务端的频率限制。若提示暂时无法请求，保持原条目，稍后再做单次测试。切换网络前记下是否正在连接、使用何种 Global Routing；否则一次成功可能只是更新请求采用的路径改变，不能说明链接内容已经修复。

当已有连接可能影响订阅请求时，可以在基础网络可用的前提下，断开连接再试一次；也可以在一条已验证可用的连接下作对照。具体请求路径还取决于应用内相关设置，应以实际记录为准，不要假定所有更新必然走同一路径。尤其要避免循环依赖：唯一服务器已经失效，却又必须通过它才能取得更新内容。

请求成功但条目为空，要检查响应是否含有有效服务器，以及应用是否支持该内容格式。请求成功但仅部分条目出现，则比较缺失条目的协议与字段，不要立刻覆盖所有原有资料。若能从自己的资料来源获得单台服务器信息，可以先手动添加一项验证连接，以此区分“服务器本身不可用”和“批量内容没有正确解析”。

更新后核对选择与本地修改

订阅更新完成后，重新检查 Home 中的默认服务器。原来选中的条目若被替换、重命名或移除，当前选择不一定仍对应之前的入口。打开更新后的条目查看关键字段，再做 Connectivity Test 和实际请求。列表看起来数量正常，只能说明有内容被导入，不能证明认证有效、服务器可达或当前规则会选择这些条目。

区分订阅中的服务器资料与 Config 中的规则文件。刷新 Subscribe 不必然修复 Config 的规则顺序，重新载入 Config 也不能让失效订阅恢复。若曾手工修改订阅条目，更新可能让这些修改与上游内容重新对应；因此需要长期保留的自定义设置，应先确认保存位置和更新行为，再决定如何维护，而不是每次失败后凭记忆重填。

恢复时尽量采用小范围验证：先保留现有分组，再验证新地址的内容与一项服务器，确认无误后再整理重复项。删除前检查是否有规则或策略依赖相应名称。有关导入入口的基础操作可回到入门指南；有关购买和已有资料的区别可查看常见问题。本页只解释用户已有资料的处理流程，不涉及任何订阅来源推荐。

速度慢与频繁卡顿：按时间阶段定位

先描述慢在哪里：点击后长时间没有反应、首屏出现后图片缓慢、持续播放中断，还是大内容传输到一定程度停住。不同表现对应的检查方向不同。延迟测试较短并不代表持续吞吐一定较高；一次页面加载较慢，也可能只是该服务端响应缓慢。先用固定目标重复验证，再判断是否属于所有请求都受影响的普遍问题。

把解析、建连与传输分开

第一次访问慢、紧接着再次访问快，可能与 DNS 缓存、连接复用、目标服务缓存等因素有关，不能只据此判断代理速度。选择两个不同服务的普通页面，分别记录首次和再次打开的表现。保持同一网络与同一服务器，并在每轮之间说明是否重新连接。对照条件越清楚，越容易判断等待发生在连接建立前还是内容已经开始传输之后。

若页面很快显示标题，但图片或媒体持续等待，检查相关资源是否走了不同策略。一个网页的主域名与资源域名可能分属不同路径，不能只为主域名增加规则后就认定所有内容都走代理。先查看失败资源的请求去向，再调整最小范围的规则。只有确认路径一致，才继续比较服务器与当前网络的持续传输表现。

同时暂停照片同步、大文件上传及其他正在持续占用网络的任务。上传占满时，普通网页也可能表现为响应拖慢；此时反复更换服务器无法清理本地竞争。先以单一设备、单一任务观察，再逐项恢复其他任务。测试时不要同时运行多种性能测试，它们相互占用带宽，得到的结果反而难以解释。

检查网络切换与传输条件

Wi-Fi 信号较强不等于外部连接稳定。保持设备位置不变，先观察当前网络，再用另一条已有网络比较。如果只在某个位置或某个无线网络出现卡顿，应检查该网络的接入质量、认证状态和其他设备负载。移动过程中反复在 Wi-Fi 与蜂窝网络间切换，也可能让已有连接中断并重新建立，应将静止测试与移动测试分开记录。

只有部分协议在特定网络表现异常时，要核对它们依赖的传输条件。涉及 UDP 的协议应确认当前网络的实际支持情况；不能因为另一种测试有响应，就认为所有传输都可用。对照应使用自己已有且参数完整的配置，不应为了测试临时猜测端口、认证或传输方式。记录“同网络不同协议”时，也要注明它们是否实际上使用不同服务器。

小请求正常而大请求反复停住，可以进一步检查路径与 MTU 相关问题，但这应在地址、规则、DNS 和认证均已确认后进行。MTU 不是通用的提速开关，过小可能增加开销，过大也可能在部分路径上暴露分片或报文处理问题。仅当所用协议及设置明确支持该项时，先记录原值，再按资料建议做单变量测试，不要同时调整多个传输字段。

用有限测试得到可执行结论

对照服务器时，固定网络、目标、请求类型及大致测试时段。若不同服务器连接到不同地区或不同服务入口，它们的表现不完全可比。目的不是寻找一个看起来最小的读数，而是确认某项已有配置是否稳定完成自己的实际请求。短时间内不断切换会丢失连接复用条件，也更难判断持续卡顿是不是原来的问题。

如果只有一个目标慢，其他目标在相同条件下正常，先检查目标服务本身与其资源路径；如果全部目标慢，再回查本地网络和所选服务器。已有服务可能有自身状态、用量或并发约束，应从自己的服务资料核实，不要仅凭客户端界面推断。应用的客户端买断与服务端传输条件是不同事项，购买状态正常不能证明远端链路始终相同。

完成测试后，把临时姿态、测试规则及传输参数恢复，保留确实有证据支持的修改。有效记录应能说明“什么条件下慢、什么对照下恢复、改变了哪一项”。如果只记录某次测试结果，没有当前网络与目标信息，后续很难重复验证。对于首次连接尚未确认的情况，先阅读首次连接验证说明，不要在基础状态未知时进行性能调优。

DNS 异常：先确认解析结果与请求路径

DNS 将域名解析为后续连接需要的地址。域名访问失败可能与解析有关，但证书错误、连接拒绝或目标响应异常也可能发生在解析已经成功之后。先查看错误和记录中是否出现解析失败，再决定修改 DNS。不要把某个 IP 能响应当作域名解析一定错误：直接访问 IP 可能缺少目标主机名，也可能遇到不同证书或完全不同的服务。

检查基础网络与配置来源

先在断开连接后测试普通域名，再在当前配置下测试相同目标。如果基础网络本身无法完成解析，检查 Wi-Fi 认证、网络接入状态及系统中已有的 DNS 配置。若基础网络正常，启用后才失败，重点检查当前 Config 与应用中的解析设置。记录哪些设置来自配置文件，哪些是后来手工添加的，避免只改了一个入口却被另一个入口的配置影响。

确认所填解析地址的格式与所选方式匹配。普通服务器地址与加密解析端点不是可任意互换的字符串；当设置要求完整端点时，只填域名可能缺少必要路径，反过来把完整网址填进只接受地址的字段也会失败。应按当前界面说明和自己的配置资料填写，而不是从不同示例中摘取一部分拼成新的地址。

加密解析同样需要建立网络连接，端点使用域名时，还涉及如何先找到该端点的地址。若解析请求依赖代理，而代理服务器地址又需要依赖同一条尚未可用的解析路径，可能形成启动依赖。排查时应明确“先解析谁、请求走哪里、该路径是否已经可用”，不要只增加更多解析服务地址，列表变长并不等于依赖关系得到解决。

理解域名规则与地址规则的关系

域名规则根据目标名称判断，地址规则根据 IP 范围判断，涉及地址判断时可能需要先取得解析结果。检查规则时应同时观察请求携带的信息、解析结果与最终策略。不要认为把 GEOIP 放到文件某处，就能替代所有域名规则。规则先后顺序仍然重要，过早匹配的条目可能使后面的规则没有机会处理同一请求。

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

此片段只展示域名、地理地址规则和兜底的顺序，不是适合所有网络的完整配置。GEOIP 的判断与所使用的数据及实际解析地址有关，不能当作网站内容或账户归属判断。修改前先保存原文件，并核对 PROXY 所用服务器。若只是一个域名需要例外，优先采用范围明确的规则，不要为了它改变所有请求的兜底方向。

同一域名可能返回多个地址，也可能同时返回 IPv4 与 IPv6 结果。若只有部分网络或部分目标失败，检查当前网络是否真的具备相应地址族的可达性，并观察失败连接采用了哪个地址。不要把关闭 IPv6 当作固定答案；它只能作为有记录的临时对照，测试结束后应根据实际网络支持情况决定是否保留原设置。

清理缓存后验证新的请求

修改解析配置后，旧缓存与已经建立的连接可能仍然影响测试。优先使用应用当前提供的缓存清理操作；若界面没有相应入口，可以停止连接、重新建立，并完全退出后重开目标应用。不要为了清理一个域名的状态直接清空全部应用数据。每次测试都应重新触发失败请求，不能只看仍停留在屏幕上的旧错误页面。

对于网页部分资源失败，分别观察主域名、资源域名与认证域名。它们可能使用不同解析结果与不同规则，单个域名恢复并不代表整个页面链路完成。若应用自行使用其他解析方式，相关流量表现也可能不同于普通系统请求；应依据可观察记录定位，不能保证只改一项 DNS 设置就会改变所有应用的解析行为。

本章的结束条件是：目标域名能够取得可用结果，后续连接使用预期路径，且重新连接后仍然成功。如果解析成功但握手失败，应回到协议章节；如果只有 Config 失败，应回到规则章节。保存最终采用的解析方式及修改原因，方便以后更换网络时判断是环境变化，还是自己的配置重新引入了依赖问题。

耗电与更新后异常：先恢复可比较的基线

耗电排查与更新排查都需要前后条件可比。先记录异常开始前改变了什么：应用更新、系统更新、订阅刷新、Config 修改、网络变化，还是新增自动连接条件。多个变化发生在同一天，并不能证明某一个变化就是原因。先保留当前状态与备份，不要立即删除应用；否则既可能丢失本地资料，也会失去用于比较的原始条件。

区分后台传输与连接重试

在系统电池统计中查看对应时间段，同时记录屏幕使用、媒体播放、文件同步与网络切换情况。VPN 应用涉及设备网络处理，统计表现不能简单理解为所有流量都由它主动发起。若其他应用持续上传或下载，网络处理也会持续发生。比较前先暂停大流量任务，在相似的屏幕使用和网络条件下观察，不要拿两种完全不同的使用场景直接下结论。

反复超时与自动重连也可能增加网络活动。查看是否只有某项服务器失效，或设备在弱信号区域不断切换网络。先更换为自己已有且已经验证可用的配置，再观察重试是否减少。若连接稳定后耗电表现恢复，应继续检查失败项，而不是保留失败服务器再尝试用其他开关掩盖。记录重试与网络变化的对应时间，比只记录剩余电量更有帮助。

暂时关闭 On Demand，测试手动保持与手动断开能否稳定。自动条件过于频繁触发时，设备可能在连接、断开与重新尝试之间反复变化。排查完成后逐项恢复条件，而不是一次全部打开。若启用了持续性的诊断记录或频繁手动测试，也应在取得必要信息后停止；诊断行为本身会增加活动，不能一边持续制造负载，一边评估静置表现。

更新后先核对保留下来的设置

应用更新后，先确认 Home 中选中项、Global Routing、当前 Config 和 On Demand 条件，再重新建立连接。列表存在不代表默认选择保持不变，文件名称相同也不代表启用状态相同。按更新前的记录恢复基线，使用一个已核对服务器与一个普通目标完成验证。若此时可用，再逐项恢复自定义规则和其他设置，避免直接把所有异常归因于更新。

如果同一时间也更新了订阅，核对服务器内容是否发生变化；如果系统同时更新，重新查看 VPN 授权与其他网络配置的状态。时间上的接近只能提供线索，不能替代对照。某些异常来自已有连接没有重新建立，正常断开、重新连接和重开目标应用即可验证；若设备系统状态持续不同步，再按开关章节处理，而不是立即重建全部配置。

更新只通过 App Store 进行。核对应用时以开发者 Shadow Launch Technology Limited、官方图标和应用 ID 932747118 为准，系统要求以 App Store 页面标注为准。需要重新安装前，先阅读已购恢复说明；购买记录用于恢复应用获取资格，并不等于本地服务器、规则文件和自定义参数已经有了完整备份。

备份、恢复与异常记录

备份时分别确认 Config、服务器资料和其他需要保留的设置，不能只导出一个规则文件就认为所有内容都已保存。打开备份检查可读性，并确认自己知道每份文件的用途与恢复入口。含有认证资料的文件应保存在受控位置，不要放进公开分享目录。涉及 iCloud 时，应确认同步实际完成，而不是只凭开关已开启就删除原设备上的内容。

确需重新安装时，先完成备份与购买账户核对，再按 App Store 的购买和设备适用性说明恢复。首次恢复只导入最小可用资料，验证连接后再逐步恢复其他配置；如果一恢复某个文件就重新出现异常，该文件及其依赖便是下一步的重点。具体迁移顺序可查阅配置备份与换机恢复。

若异常仍能稳定复现，整理操作顺序、当前网络、失败阶段、是否只影响一个协议，以及哪些对照已经成功。提交时隐藏订阅链接、认证值与个人请求内容。耗电记录要说明实际使用负载，更新问题要说明哪些配置也发生过变化。恢复正常后关闭临时诊断，保留经过验证的备份，让下一次环境变化有可以返回的起点。

iPad 专项：拆开账户、网络与配置差异

iPhone 正常而 iPad 异常时，不要直接把问题归结为设备型号。两台设备可能使用不同的网络、购买账户、默认服务器、Config 或解析设置。先确认要比较的是获取资格、应用打开、连接建立，还是实际访问。每次只比较一层，把成功设备作为参照，但不要在没有备份的情况下覆盖另一台设备已有的专用配置。

先确认获取与授权状态

iPad 的获取入口同样是 App Store。若此前已经购买，先核对当前用于商店购买的 Apple ID 是否与原购买记录对应，再查看已购项目中的状态。设备登录的 iCloud 账户与用于商店购买的账户可能不是同一个概念，应以实际购买记录为准。系统要求、购买适用性与家人共享条件，以 App Store 页面标注为准，不要只依据另一台设备可以安装推断。

可以正常获取应用后，继续检查 iPad 自己的 VPN 授权。另一台设备已授权，不代表这台设备已经允许添加配置。首次连接时观察系统弹窗并完成设备认证；受管理的 iPad 还要核对组织策略是否允许相应网络配置。开关无法保持的情况按第一章处理，不能用恢复购买代替系统授权，也不能把授权问题当作订阅格式问题。

应用界面可能随窗口大小、横竖屏与系统显示方式调整。查看 Home、Config 或 Settings 时，先确认实际进入的页面和当前选中项，不要机械对应另一台设备上的按钮位置。编辑后返回列表，再重新打开确认保存结果；分屏状态下尤其要检查操作是否真的提交，而不是仍停留在尚未确认的编辑内容中。

建立两台设备的最小对照

让两台设备先使用同一条可用 Wi-Fi，核对同一个已有服务器、相同 Global Routing 和相同目标网页。不要一台使用蜂窝网络，另一台使用无线网络后直接比较连接结果。即使网络名称相同，也要分别确认是否需要网页认证。若 iPad 的基础网络在断开连接后仍异常，先修复网络接入，再继续应用内排查。

如果 iPad 使用个人热点，应额外确认热点来源设备当前网络与连接状态，并用普通网页验证 iPad 的基础访问。热点提供的是接入条件，不能据此假定 iPad 已继承来源设备的全部规则和连接设置。以 iPad 上实际建立的连接与请求记录为准，不要通过来源设备的状态图标判断 iPad 当前流量一定采用了哪条路径。

逐项比较 Type、Address、Port、认证字段及 TLS 相关字段，随后比较当前 Config 与 DNS。同步完成与连接成功是不同问题：文件出现在两台设备上，不证明两端实际启用了同一个文件。若服务器名称相同但内容不同，应以字段核对为准；若内容相同仍表现不同，则继续比较系统网络配置、地址族可达性和当前接入条件。

检查后台、休眠与恢复后的连接

只在锁屏后或唤醒后异常时，记录唤醒前后的 Wi-Fi 状态、是否发生网络切换，以及 On Demand 是否触发。先用手动连接在固定网络复现，再加入锁屏和唤醒动作。不要把前台应用界面没有持续显示状态变化，直接当作隧道已经停止；实际请求和系统状态应一起判断。反过来，系统仍显示连接，也不能保证休眠前的每一条远端连接仍然有效。

若唤醒后第一次请求失败、重新连接后恢复，检查是否为旧连接没有及时重建，或者当前网络已经变更。先完全重开目标应用，再断开并重建连接，分别记录哪一步恢复。只有当手动流程稳定后，才调整 On Demand 条件。不要用不断自动重连作为长期替代方案，否则可能掩盖弱信号、认证过期或某个服务器持续失效的问题。

迁移配置后，重新运行 Connectivity Test 并完成实际网页验证，再测试自己常用的应用。确认稳定后保留这台 iPad 的已验证备份，不必强求所有设备的设置逐字相同；不同接入网络可能需要不同的有依据调整。需要重新核对获取入口时，前往iPad 获取说明；需要从头建立连接时，返回入门指南按主线操作。