官方手册 · 问题诊断

Shadowrocket 故障排查大全

先确认故障发生在哪一层，再修改对应设置。本页按症状提供系统查阅流程；尚未完成首次连接，请先按快速上手教程操作，再带着具体结果返回对应章节。下文以用户已有自己的订阅或服务器信息为前提，不提供、不销售、不推荐节点或订阅。

适用于 iPhone / iPad。系统要求以 App Store 页面标注为准。界面词保留英文，位置与可用选项以设备上实际显示为准；本页的测试结果只用于缩小范围，不等同于对线路可用性的保证。

[General]

开关打不开、立即关闭或反复连接

先区分系统授权与服务器故障

在 Home 打开连接开关后，如果系统询问是否允许添加 VPN 配置，应先阅读提示，再按本人意愿允许，并完成设备验证。这个步骤是在系统中建立连接所需的配置，不是购买确认，也不是订阅导入。若之前取消了提示，返回应用重新尝试连接；若设备受管理，系统可能限制添加 VPN，此时应向设备管理方核实，不能靠反复修改服务器地址解决。

观察开关的实际过程：完全没有进入连接状态，优先检查授权和设备限制；短暂进入连接状态后关闭，可能涉及配置内容、网络可达性或连接过程中的错误；保持开启但网页不可用，则转到下一章。系统状态栏的标识只能说明连接状态的一部分，不能证明请求已到达目标。把这些现象分开记录，比笼统描述“打不开”更有助于定位。

检查系统中的连接与自动触发条件

进入系统 Settings，搜索 VPN，查看是否存在 Shadowrocket 对应的配置，以及是否有其他 VPN 连接正在使用。先主动断开不需要的连接，再回到 Home 测试。不要一次删除所有系统网络配置；其中可能包含工作或学校所需的设置。如果 VPN 项目不可编辑、显示受管理，或添加配置时被系统拒绝，应先处理设备管理限制，而不是继续调整 Config。

如果开关关闭后又自行打开，检查 On Demand 是否启用，以及当前网络是否符合其中的连接条件。为建立人工测试基线，可暂时关闭 On Demand，再手动控制连接；测试结束后按原记录恢复。自动触发与手动开关同时起作用时，看到的“反复开启”不一定是应用故障。还应留意系统中是否配置了自动连接条件，避免只修改应用内一处设置。

用最小变更建立可重复的测试

先确认不连接时设备能正常联网；需要网页认证的 Wi-Fi，应先完成该网络的认证页面。随后回到 Home，明确点选一个已有且参数完整的服务器，再尝试连接。若有配置加载错误，先查看提示内容和当前 Config，不要用重复开关掩盖错误。可以暂用已确认可用的简化配置作对照，但保留原配置文件，并记下切换前后的名称与 Global Routing 状态。

如果只在 Wi-Fi 下失败，在允许使用蜂窝网络且注意流量的前提下，用同一服务器再测一次；反之亦然。服务器、配置、目标保持不变，网络改变后结果随之改变，说明应优先调查接入网络。若两个网络均在同一阶段失败，再核对服务器参数及服务状态。不要同时更新订阅、切换配置和更换网络，否则即使恢复，也无法判断是哪一步起作用。

何时重建系统配置

完成上述检查后仍无法建立连接，可先断开连接，正常关闭再打开应用，必要时重启设备后复测。只有在确认系统 VPN 配置异常、已经备份且清楚恢复方法时，才考虑移除 Shadowrocket 对应配置，并让应用重新请求添加。移除系统配置不等于服务器、订阅与规则一定已经备份；不要把重建授权误当成配置恢复。重新授权后仍需重新核实 Home 的选中项目。

[Rule]

显示已连接，但全部或部分请求失败

先确认基础网络，再检查请求路径

先断开 Shadowrocket，用同一设备、同一网络打开日常可访问的页面。如果仍失败，应先处理 Wi-Fi 认证、蜂窝网络权限、路由器或接入网络问题。基础网络恢复后再开启连接，避免把接入故障误认为规则故障。若只有某个应用异常，应同时用浏览器访问另一个目标作对照；单个应用可能有自己的会话缓存、域名集合或连接方式，不宜直接推断全部网络失效。

回到 Home，核实当前选中的服务器，而不是只看列表中是否存在可用项目。列表更新后，原选中项目可能已经变更，名称相似也不代表参数相同。随后确认 Global Routing：配置对应 Config，代理对应 Proxy，直连对应 Direct。三个姿态决定主要请求的处理方式，但不能把其中任一姿态当成对所有 DNS、系统行为或目标网站状态的完整证明。

姿态	排查用途	结果边界
配置 / Config	按当前配置检查规则与策略。	需同时核对实际启用的 Config 与命中记录。
代理 / Proxy	与 Config 对照，检查服务器路径。	成功不表示原配置中的所有规则正确。
直连 / Direct	对照不经代理服务器的请求表现。	不等于完全退出 VPN 或还原全部 DNS 设置。

通过姿态对照缩小范围

固定同一个测试页面与服务器，先记下 Config 的结果，再临时切换 Proxy 重试。如果 Proxy 可用而 Config 不可用，优先查看该请求命中的规则与最终策略，而不是立即更换服务器。若两种姿态都失败，再检查服务器连接、DNS 和目标自身状态。测试后恢复原姿态，并重新打开页面；旧连接可能继续复用，单次刷新未必已经经过新选择的路径。

当 Direct 可访问而 Proxy 失败时，服务器路径值得优先调查，但仍需排除域名解析差异与协议参数错误。如果 Direct 和 Proxy 都无法访问同一个目标，而其他目标正常，可能是目标站点问题，也可能是此目标的公共依赖失败。应换一个独立目标作验证，不要连续使用几个实际上依赖同一登录服务或同一资源域名的页面，把它们误当作独立样本。

从实际命中规则回查 Config

确认 Config 中当前启用的是预期文件，再查看失败请求对应的域名、命中规则和处理策略。规则通常按顺序判断，前面的匹配可能让后面的精确规则无法生效。尤其注意宽泛的 DOMAIN-KEYWORD、范围较大的 IP-CIDR，以及意外指向 REJECT 的条目。下列片段仅用于解释规则顺序，不包含可用服务器信息，不应直接替换用户正在使用的完整配置。

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

在此顺序中，api.example.com 先由 DOMAIN 指定 DIRECT；其他符合 example.com 后缀的域名随后匹配 PROXY。局域网地址和 GEOIP 条目用于说明不同匹配类型，FINAL 是前面未匹配时的末尾处理。实际结果还受到请求能提供的域名信息、解析结果及配置其他部分影响。不要仅凭目标名称就认定某条规则必然命中，应以当前请求记录作为证据。

仅部分页面缺图或登录失败

一个页面通常涉及多个域名。首页文字出现而图片、验证或登录失败时，应分别查看失败的资源请求，不能只给首页域名加规则。先检查是否有明确的 REJECT 命中，再核对相关域名是否走了不同策略。只为已确认的依赖增加必要规则，避免用过宽的关键字影响其他请求。无法判断规则词含义时，可查阅术语表，首次连接验证则回到快速上手。

[General]

节点超时、测试失败与协议参数不匹配

把测试结果与实际访问分开理解

Connectivity Test 的结果与其测试方式、测试目标、当前网络和服务器状态有关。显示失败并不能单独证明每一种请求都会失败，测试成功也不能证明所有网页或所有传输方式都可用。先确认选中项目，再用一个明确目标执行实际访问，记录测试与访问是否一致。若测试目标本身不可达，可能出现测试失败但部分业务正常的情况，应先核对测试设置，而不是只按结果删节点。

区分连接超时、连接被拒绝、认证失败和证书相关提示。超时通常表示在等待窗口内没有得到所需响应，但仅凭“超时”无法确定是服务器离线、端口不可达、解析错误还是中间网络丢包。连接被拒绝与认证失败提供了不同线索，应保存原始提示原文。若界面没有详细错误，也可以记录失败发生在立即返回还是等待一段时间之后，作为后续对照依据。

先核对共同字段，再检查协议专属字段

打开该项目的编辑页面或 Add Server，对照已有服务商提供的原始资料，先检查类型、Address 与 Port。地址栏不应混入不需要的路径、前后空格或其他协议链接的内容；端口必须与该服务对应。服务器显示名称只是辨认标签，修改名称不会修复地址或认证。对自动导入项目，也应检查导入后的字段，不能认为扫描或订阅导入成功就等于参数组合一定可用。

协议	重点核对	常见误区
Shadowsocks	Address、Port、Password 与 Method。	密码正确但 Method 不一致，仍可能失败。
VMess / VLESS	UUID、传输方式、TLS 与服务端要求的附加字段。	沿用另一项目的传输参数，无法形成完整匹配。
Trojan	认证信息、TLS、服务器名称与传输配置。	把连接地址与证书校验名称混为一项。
Hysteria2	认证信息、TLS 及当前网络的 UDP 可达性。	普通网页可用不代表相关 UDP 路径可用。

UUID、Password、Method、Host、Path 和服务器名称等字段都应来自同一条有效配置，不能从不同项目拼接。某些传输方式需要特定路径或主机名，这些值不是任意备注；大小写、斜杠和是否启用 TLS 都可能影响连接。VMess 与 VLESS 的字段差别可结合协议字段对照文章查阅，但最终仍以已有服务端的配置要求为准。

证书与时间错误不要绕过

出现 TLS 相关错误时，先检查设备日期与时间是否准确，再核对服务器名称是否与证书匹配。连接用的地址、TLS 校验名称和传输层 Host 可能承担不同作用，不能为了让字段看起来一致而全部改成同一值。遇到证书过期或名称不符，应让已有服务商确认服务端状态；关闭证书验证会改变安全边界，不能把它作为通用修复办法，更不能据此判断原配置正确。

用网络与项目交叉验证，而不是连续重复测试

保持同一项目不变，在两个可用网络上各做一次测试；再在同一网络上选另一个已有且已确认可用的项目对照。如果所有项目只在一个网络失败，优先考虑该接入网络的传输限制或质量；若只有一个项目在不同网络都失败，则优先核对该项目参数与服务状态。涉及 UDP 的协议还应单独确认对应网络条件，不能用普通网页能打开来证明其传输路径正常。

需要向已有服务商反馈时，提供协议类型、失败阶段、网络类别和脱敏后的错误文字即可。完整订阅、UUID、密码、二维码与带认证的链接不应公开。若问题开始于一次订阅更新，先比较字段变化，再决定恢复原项目或等待服务端修复。测试得到稳定结论后停止高频重试，保留一个可复现案例；重复测试本身不会修正远端认证或端口配置。

[General]

订阅导入失败、更新为空与节点重复

分清订阅地址、服务器链接与 Config

订阅通常用于获取或更新服务器项目，Config 用于规则及相关配置，两者不能仅因内容都是文本就互换导入入口。先确认手中资料究竟是订阅地址、单个服务器链接、二维码还是配置文件，再使用应用实际提供的对应入口。导入成功只说明内容在当前步骤被接受，不代表网络连接与服务端认证都已通过。首次添加过程不熟悉时，先按快速上手教程完成一种导入方式。

从你的服务商处重新复制完整地址，注意是否夹入换行、中文标点、空格或说明文字。链接中的认证部分属于敏感信息，不应通过公开截图或公共文本处理工具检查。只比较是否完整，不要随意删掉问号后面的参数；这些参数可能正是订阅身份的一部分。若地址已经失效，应在已有服务商的账号页面核实状态，而不是尝试猜测或改写认证内容。

区分请求失败与内容不能解析

无法连接订阅地址，先检查当前网络是否能到达订阅所在服务；能请求但提示解析失败，则重点检查返回内容。登录页面、错误说明、账号状态提示都可能以网页形式返回，网络请求成功不等于返回了订阅数据。即便返回状态看似正常，也应结合错误文字判断。不要把 HTML 页面保存为配置文件继续导入，这只会把获取失败变成格式错误，掩盖最初问题。

若订阅只能通过某条已有可用连接获取，应先明确当前使用哪条路径，再执行单个订阅更新；如果现有列表仍有可用项目，先不要删除。相反，若订阅请求错误地经过已经失效的服务器，更新可能一直无法完成。可在确认规则和网络条件后换用可用路径对照，但不应盲目在 Direct 与 Proxy 之间反复切换。每次测试都记录实际姿态与选中项目。

更新为空时先保留旧数据

一次更新后项目数量明显减少或列表为空，应先检查提示、订阅来源和账号状态，再决定是否继续。订阅可能暂时返回空内容，也可能因服务方调整而更换项目。反复刷新会覆盖观察线索；更稳妥的做法是先保留现有可用项目和配置副本，向已有服务商确认本次返回是否符合预期。若订阅内容有效但项目参数变化，需重新核对 Home 的选中项，而不是沿用旧名称判断。

订阅名称与服务器名称都不是服务有效性的证明。名称相同的项目可以有不同端口、协议或认证，名称不同的项目也可能指向相同服务。更新后首次连接应打开实际项目检查字段，尤其是协议类型、TLS 与传输相关参数。若应用提示某类型或字段不能处理，应按当前应用支持范围和服务方提供的格式核实，不能把所有解析失败都归因于网络质量。

重复项目与多订阅管理

同一订阅被重复添加、手动项目与订阅项目并存、多个订阅包含相同服务器，都可能造成重复显示。先辨认来源，再处理重复项；不要只按名称批量删除，以免同时移除唯一的可用配置。删除单个项目也未必改变远端订阅，下次更新仍可能重新出现。需要长期整理时，应明确保留哪个订阅源，再按来源管理更新和移除操作，避免在多个位置反复维护同一份信息。

对多个订阅，建议使用能区分来源与用途的本地名称，分别更新并确认结果，再继续下一项。一次更新全部订阅虽然方便，却不利于判断哪一个返回异常。详细整理方法见多个订阅管理文章。如果订阅能更新但所有项目都不能连接，转入参数核对章节；更新链路与服务器链路是两个问题，前者成功不能替代后者验证。

[Rule]

速度慢、首开等待与间歇性断流

先定义慢发生在哪一个阶段

把“慢”拆成几种现象：首次打开前等待较久、页面主体出现但资源加载缓慢、连续传输速度不足、使用一段时间后停顿，以及网络切换后短时不可用。它们分别可能涉及解析、连接建立、目标资源、传输质量或旧连接恢复。先记录一种最容易复现的现象，不要只比较一个测试数字。Connectivity Test 的用时不能直接换算成持续传输能力，也不能代表所有目标的访问表现。

先在断开连接的状态下检查基础网络，用同一个合法可访问目标、相同内容和接近的时间作对照。避免一边进行大文件传输、一边执行测试，也不要把不同清晰度的视频或不同大小的页面当作同样负载。蜂窝网络测试应注意流量和信号变化；Wi-Fi 则观察距离、干扰与其他设备占用。若基础网络本身不稳定，调整规则通常不能解决接入链路的波动。

固定变量比较服务器与网络

选择一个已有且确认参数正确的服务器，在同一网络访问两个独立目标。如果仅一个目标缓慢，先考虑目标服务或到该目标的路径；如果多个目标都慢，再换另一个已有服务器。随后保持服务器不变，换网络复测。这样能够区分服务器相关、目标相关与接入网络相关的差异。每组只做必要次数，避免高频测速产生额外负载，并让短时拥塞看起来像稳定规律。

如果只有 Config 姿态缓慢而 Proxy 正常，回查规则命中及使用的策略，不要马上改协议。某些资源可能被分到不同路径，造成页面主体快、登录或图片慢。若 Direct 快而 Proxy 慢，也只能说明当前对照中代理路径存在额外因素，不能证明客户端本身处理异常。应继续核对该项目的服务状态、传输方式和网络条件，再决定是否更换已有项目作长期使用。

区分 DNS 等待、连接建立与持续吞吐

首次访问等待较久，而同一页面随后明显更快，可能与 DNS 缓存、连接复用或目标缓存有关。需要到下一章分别验证解析与路由，不应立即把缓存清空后的一次访问当成稳定速度。若每次新连接都慢，应核对 TLS 与传输参数；若只有持续传输中断，应观察网络是否切换、服务端是否断开，以及问题是否只影响某类流量。结果要按现象分类，而不是统一写成超时。

不同传输方式对网络条件的要求不同，特别是涉及 UDP 时，接入网络的可达性与稳定性可能影响结果。但协议不是按名称就能判断快慢的开关，必须与已有服务端匹配。不要自行修改为另一种类型，或随意更改带宽、连接相关参数以追求数值；错误参数可能使本来可用的项目失效。只有服务方明确提供对应配置时，才按其完整字段建立独立对照项目。

网络切换、后台应用与长连接

从 Wi-Fi 切到蜂窝网络后，旧连接可能需要重建。应等待网络状态稳定，再重新打开测试页面或重新发起应用请求；旧页面仍失败，不代表新路径同样失败。如果所有新请求也无法恢复，记录是否发生了 On Demand 条件变化，再断开重连一次验证。不要持续快速切换网络与开关，这会让连接建立、取消和系统网络变化交错，难以得到明确结论。

当速度问题只在特定时段出现，记录当时网络、服务器和目标，在另一个时段重复同样测试即可，不必长时间连续测速。若只在一个应用发生，检查该应用是否正在同步或复用旧会话；切换姿态后应重新发起请求。最终保留一组能复现差异的对照结果，比提供大量互不相关的数据更有用。确认是已有服务端或目标路径问题后，应将脱敏结果交给对应服务方检查。

[Host]

DNS 解析异常、局域网失联与规则不命中

先判断是否真的发生了解析失败

网页提示找不到服务器、应用在建立连接前失败，或记录中出现解析错误时，可以沿 DNS 方向排查；但 TLS 错误、认证失败与目标返回错误并不等于 DNS 故障。先用多个独立域名对照，观察是否只涉及一个域名或一类内部名称。直接把域名替换成 IP 访问通常不是有效验证：HTTPS 的证书、服务器名称与虚拟主机仍可能依赖域名，替换后失败也不能证明解析原本正常。

确认基础网络是否正常，再检查当前 Config 中的 DNS 相关设置、[Host] 内容，以及系统是否使用了额外的 DNS 配置。若存在多处设置，先记录各自来源，不要同时删除。应用、系统与特定应用自己的解析行为可能不同，单次请求记录未显示域名，也不一定说明完全没有发生解析。应结合请求类型、实际目标和连接结果判断，避免仅凭一个缺失字段就大幅调整配置。

检查 DNS 服务的可达路径

自定义 DNS 地址首先必须在当前网络和连接状态下可达。如果解析服务器只能通过某条代理路径到达，而建立该路径又依赖同一个尚未解析的服务器域名，就可能形成依赖问题。排查时先使用已经验证可达的原配置作为基线，再一次只调整一个解析相关选项。不要把多个不明来源的 DNS 地址堆在一起；数量增加不等于每个请求都有可靠的处理路径。

如果切换网络后才出现问题，检查原网络专用的解析服务是否仍被使用。例如内部名称可能只在特定 Wi-Fi 的 DNS 环境中有意义，蜂窝网络无法给出相同结果。也应检查是否误将服务端要求的 Host 或服务器名称当成 DNS 地址填写。修改后重新建立相关请求，必要时断开再连接以排除旧会话影响，但不要把反复重连当成清楚所有缓存的保证。

规则按顺序检查，域名与地址分开看

DOMAIN 处理完整域名匹配，DOMAIN-SUFFIX 处理域名后缀，IP-CIDR 与 IP-CIDR6 处理地址范围，FINAL 提供末尾处理。它们面对的信息不同，因此域名规则没有命中时，应先看请求是否具有可供匹配的域名，以及前面是否已有规则接管。不要把所有域名规则改成 IP 范围；同一域名可能解析到多个地址，地址也可能由多个服务共同使用，过宽范围会影响其他目标。

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,blocked.example.com,REJECT
IP-CIDR,192.168.0.0/16,DIRECT
IP-CIDR6,fc00::/7,DIRECT
FINAL,PROXY

这个片段故意展示一个顺序问题：blocked.example.com 已在前面的 DOMAIN-SUFFIX 命中 PROXY，因此后面的同名 REJECT 不会达到预期效果。若要对它单独处理，应把更具体的 DOMAIN 条目放在后缀规则之前。修改应在配置副本上完成，并用实际请求确认命中。这里的域名只是语法示例，不是测试服务；地址范围条目也需结合用户真实网络与现有策略决定是否适用。

局域网设备与内部域名专项

打印机、家庭存储或内部服务在连接后不可用时，先断开连接验证设备本身可达，再区分目标是直接地址还是内部域名。地址可达而名称不可用，优先检查解析；两者都不可达，再检查局域网地址的处理策略、网络隔离及应用权限。广播或组播发现与普通单播请求并不相同，增加一条 DIRECT 规则不一定能恢复自动发现，应分别测试已知地址访问与设备发现功能。

在系统 Settings 中查看相关应用的本地网络权限，并核实设备是否处在同一局域网；访客 Wi-Fi 或网络隔离也会让设备彼此不可见。若使用 [Host] 固定映射，应确认该地址仍属于预期设备，尤其在网络切换或路由器分配变化之后。不要为暂时恢复访问而永久写入未经确认的地址。修正后逐项恢复原有 DNS 设置，以确定真正起作用的变更，避免长期保留互相重叠的临时配置。

[General]

耗电增加、发热与后台频繁重连

用相近负载比较，不只看百分比

系统电池页面中的占比是所选时间范围内的相对结果，不是某个应用单独消耗的固定电量。设备总使用量、屏幕亮度、信号、后台同步和其他应用活动都可能改变占比。先在系统 Settings 的电池信息中查看活动时段，再对照问题发生时的实际操作。不能仅因 Shadowrocket 出现在列表中就断定异常，也不能用两个使用负载完全不同的时段直接比较。

建立短时对照时，尽量保持网络、屏幕状态、前台应用和使用内容接近，记录是否正在传输大量数据、更新订阅或进行诊断。若断开连接后依然明显发热，应先检查其他持续活动和基础网络，而不是只修改规则。电池健康、设备温度与充电状态也会影响体验；排查目的在于找出可重复的变化，不是凭一次观察计算客户端应有的固定耗电值。

先检查弱信号与重连循环

弱信号、Wi-Fi 边缘覆盖或频繁切换网络会让连接不断重建。若设备在不同网络间来回切换，先固定到一个稳定网络观察；如果是特定服务器反复失败，换用另一个已有且确认可用的项目对照。连接本身无法完成时，持续尝试可能伴随额外网络活动，应先处理失败原因。不要为了保持表面连接状态而缩短重试间隔，也不要让无人使用的测试长期重复运行。

检查 On Demand 是否在当前网络条件下持续触发，是否出现手动关闭后又自动连接的现象。可暂时关闭 On Demand 建立基线，再手动连接测试；结束后恢复所需条件。自动连接规则应该反映实际使用需求，不能为了排错把所有网络都设为持续触发后忘记恢复。如果系统还存在其他自动 VPN 连接条件，应一并记录，避免两个来源的行为被误认为同一个应用在反复重连。

观察真实请求，避免把后台流量当故障

前台应用退出后仍可能有系统同步、消息连接或其他后台请求。若可用的连接记录显示持续活动，先辨认请求来源与时间，确认是否与照片、文件或其他同步任务重合。仅看到流量持续存在，不能证明连接组件异常；只有请求反复失败并持续重试，才需要追查对应域名、规则和服务器路径。不要为了减少可见请求而批量 REJECT，误拦依赖可能反而增加重试。

某些诊断设置会增加记录工作量。排查时可按需要短时启用，复现一次并保存脱敏信息后，恢复日常设置，不要长期维持详细记录、连续测试和频繁手动刷新订阅。记录文件还可能包含域名、地址等个人网络信息，分享前应检查内容。若问题只在打开某项诊断功能后出现，可单独关闭该项作对照，但保留其他变量不变，以免失去判断依据。

规则、业务负载与恢复顺序

如果只在使用某个应用时耗电明显增加，先确认该应用是否有高负载业务，再检查相关请求是否不断失败。Config 中不合适的 REJECT 或路径选择可能使应用重复连接，但不能据此断言规则越少越省电。应针对明确的失败请求调整一个条目，并观察功能与请求是否恢复。不要随意移除整个规则文件或关闭必要的 TLS 验证，这些操作改变的边界远大于当前耗电问题。

一次有效对照应包含开始状态、使用内容、是否连接、当前网络与结束现象，不必公开完整使用记录。若稳定网络、已确认可用的服务器和常规设置下仍能复现异常，可再用简化配置副本测试，并记录是否仅发生于特定业务。若设备持续异常发热，应先停止高负载与连续诊断，按系统提示处理设备温度；待状态正常后再继续，不要让测试本身成为额外负载。

[General]

更新后异常、配置恢复与 iPad 专项检查

先确认改变的是应用、系统还是配置

问题发生在更新之后，不等于更新本身就是原因。先回想同一时间是否还更新了订阅、切换了 Config、改变了网络或修改了系统权限。把应用更新、系统变化与配置内容变化分开记录，再按前文流程建立最小测试。不要编排一个无法核对的原因，也不要在未备份时连续重装。若错误与特定 Config 直接相关，应先对照配置内容，而不是从购买状态开始排查。

应用获取与更新统一通过 App Store。需要核对产品时，使用正版核验说明检查官方图标、开发者 Shadow Launch Technology Limited 与应用 ID 932747118。系统要求以 App Store 页面标注为准。已经能够正常打开应用但服务器失败，通常还需要检查连接参数与服务状态；购买记录正常并不代表订阅仍有效，也不代表远端服务器保持可用。

先备份，再做可逆的恢复

在修改或恢复前，分别确认服务器项目、订阅来源与 Config 是否已有可用副本。导出 Config 不应被当作已经备份所有服务器认证信息；同步是否启用、同步了哪些内容，也应以实际界面与恢复结果核实。备份可能含敏感字段，应保存在本人可控的位置。操作顺序可参考配置备份与迁移文章，但执行前仍需确认当前设备上的实际选项。

恢复时先建立一个参数明确的已有服务器项目，完成系统授权并验证基本连接，再恢复 Config，最后逐项恢复其他设置。若一开始就把所有旧内容一起导回，出现问题后仍无法区分来源。每恢复一类内容，重复同一个测试目标并记录结果；一旦故障重新出现，就在最近恢复的范围内查找。这样比删除全部数据后凭记忆重新填写更容易回退，也能保护仍可用的信息。

iPad 不能只按 iPhone 的结果推断

同一份资料在 iPhone 可用而在 iPad 失败时，先检查两台设备是否真的处在相同网络。iPhone 可能已经使用蜂窝网络，而 iPad 仍连接需要认证的 Wi-Fi；具备蜂窝连接的 iPad 也应核实实际接入状态与权限。把网络条件确认一致后，再比较 Home 选中项目、Global Routing 和正在使用的 Config。不要只比较项目名称，应查看地址、端口、认证及传输相关字段。

iPad 的横竖屏、分栏或窗口布局可能让入口位置与 iPhone 不同，但不能据此判断功能缺失。应按 Home、Config、Settings 等实际界面词寻找对应项目，而不是机械照搬截图坐标。首次添加 VPN 的系统授权需要在该设备上独立完成；另一台设备已经允许，不代表当前 iPad 已经授权。系统 Settings 中的本地网络权限及受管理限制，也应在 iPad 上逐项核查。

换机购买恢复与配置恢复分别处理

换设备后，在 App Store 使用原购买账号检查已购项目，并按页面显示重新获取；可用性、兼容性与购买权益以商店页面标注为准。应用重新出现，并不表示原服务器、订阅与 Config 会自动完整恢复。购买恢复操作可查阅已购恢复说明，配置则按本人保存的副本逐项核对。不要为了修复连接问题重复付费，先确认当前缺少的是应用权益还是使用资料。

如果 iPad 仅在访问打印机或内部设备时失败，回到 DNS 与局域网章节检查权限、网络隔离和内部名称解析；若仅在锁屏或切换网络后异常，回到耗电与 On Demand 检查流程。最后整理一份脱敏记录：设备类型、网络类别、连接是否建立、所用姿态、故障阶段和单变量对照结果。保留错误文字，去掉密码、UUID、完整订阅及二维码，即可形成可复现而不泄露认证信息的问题说明。