Shadowrocket 故障排查
连接、规则与 DNS

一、开关打不开：先检查系统连接权限

先区分开关不能操作、打开后立即回落，以及开关保持开启但请求失败。这三种现象属于不同层次。前两种优先检查系统权限、网络扩展和配置有效性；第三种说明连接入口可能已经建立，应继续检查节点、路由和 DNS。不要仅凭顶部状态图标判断已经能够访问目标网站，也不要把一次开关回落直接归因于服务器不可用。

保存现场，确认基础网络

先记下当前网络类型、选中的服务器、Global Routing 的值，以及是否启用了 On Demand。保存当前 Config，并记录最近一次成功连接之后改过的项目。随后关闭 Shadowrocket，用浏览器访问一个平时能直接打开的网站。如果关闭后同样失败，先处理 Wi-Fi 登录页、移动数据权限、路由器或系统网络限制；客户端连接排查需要以设备本身能够联网为前提。

公共 Wi-Fi 可能要求先完成网页认证。连接到无线网络不等于认证已经结束，系统也可能缓存之前的登录结果。保持客户端关闭，打开系统提供的认证页面，确认网络可正常使用后再尝试连接。若设备装有由单位或学校管理的描述文件，先查看相关网络策略；不要删除不清楚用途的管理项目，也不要试图绕过设备管理员设定的权限。

检查 VPN 配置与并行连接

1. 返回 Home，确认已经选中用户自己的有效服务器，而不是只导入了尚未选择的列表。
2. 开启连接，留意系统是否弹出添加 VPN 配置的授权提示；按系统要求完成确认。
3. 到系统设置的 VPN 管理位置核对连接记录，确认没有另一项连接正在反复接管。
4. 临时关闭 On Demand 后手动连接一次，分开验证手动连接和自动触发条件。

如果之前拒绝了授权，重新操作时可能需要先回到系统设置确认状态。只有在已经保存配置、并明确知道哪一项属于 Shadowrocket 时，才考虑移除旧的连接记录再由应用重新建立。移除系统连接记录与删除订阅不是同一操作，但仍应先备份，避免同时调整多个位置后无法判断原因。不要一开始就重置整台设备的网络设置。

开关立即回落时的观察顺序

先查看是否有明确的权限或配置错误，再观察回落发生在点击之后、切换网络之后，还是锁屏唤醒之后。若始终在启动时失败，检查当前配置能否正常读取，以及必填服务器字段是否为空。若仅在网络切换时出现，暂时停用自动连接条件并固定使用一种网络重试。每次只观察同一个动作，连续切换多个节点会掩盖真正的触发条件。

服务器配置错误可能造成连接后的请求失败，但不应把所有开关问题都解释成协议问题。记录界面给出的完整错误文字，优先查权限和配置读取。若应用有相关诊断记录，只复制错误类别与发生步骤；订阅地址、认证字段和服务器标识属于敏感内容，发送给支持人员之前应遮盖。截图也要检查是否包含二维码、完整地址或个人账号信息。

若重启应用后仍能稳定复现，可以在保存工作后重启设备，再用同一网络、同一配置验证一次。重启只用于排除暂时的系统状态，不是定位结论。复现记录应能回答“在哪一步失败、出现什么提示、关闭客户端后是否恢复”三个问题；这些事实比“连接不上”的笼统描述更有排查价值。

二、已连接但无法上网：区分节点与规则

开关保持开启以后，先把问题缩小为全部请求失败、只有部分域名失败，还是只有一个应用失败。分别选择一个可直接访问的网站、一个需要通过已有服务器访问的目标，以及实际出问题的应用进行验证。测试对象应由用户自己确定，并保持不变。频繁更换网站会把目标服务状态、缓存和路由差异混在一起，使结果难以解释。

用 Global Routing 建立对照

Global Routing 的配置、代理、直连分别对应 Config、Proxy、Direct。Config 按当前配置中的规则决定路径；Proxy 用于集中验证代理路径；Direct 用于观察直连路径。切换模式是诊断手段，不是建议长期使用某个姿态。测试期间固定服务器，并关闭旧网页重新发起请求，避免已经建立的连接继续沿用先前路径。

如果 Proxy 能访问而 Config 失败，优先查命中规则、所用策略和 DNS 结果，不要立即重建服务器。如果两种模式都失败，转查服务器认证、协议参数及网络条件。如果 Direct 可以访问某个站点而 Proxy 失败，说明这个站点在当前直连条件下可达，但还不能证明所有代理请求都有问题。每条结论都应限定在当时的网络、目标与模式之内。

检查规则顺序与策略目标

进入 Config，确认当前生效的文件就是刚才修改的文件。文件保存在列表中，不代表它已经被选用；远程更新后的副本也可能与手动编辑的副本不同。随后沿规则顺序检查目标域名：精确域名、后缀、关键词以及最终规则可能分别将它送往不同策略。通常先匹配的规则决定结果，靠后的正确规则不能修复前面已经发生的误匹配。

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

上面仅为规则语法说明，不是通用配置建议。第一行将指定域名及其子域名交给 PROXY，第二行拒绝精确域名，私有网段示例交给 DIRECT，FINAL 处理之前没有命中的请求。复制前必须理解目标范围，并与自己的网络环境核对。尤其不要把示例里的拒绝规则、地区规则和最终策略直接替换进正在使用的完整文件。

若规则指向自定义策略组，还需确认组内有可用服务器，并且当前实际选择符合预期。组名正确不代表其中选择正确，自动选择与手动选择也可能产生不同结果。排查时可以临时固定已有的一个可用节点，减少策略变化带来的干扰。验证完成后恢复原先的选择方式，同时保留本次成功条件的记录。

只有一个应用失败时

应用可能复用长连接、使用缓存地址，或同时请求多个域名。先完全结束该应用再打开，观察主页面、登录和媒体加载是否分别失败。一个网页正常不能证明应用依赖的全部域名正常。若诊断记录提供请求路径，按失败域名逐条核对，不要为了修复一个资源就把整份规则改成宽泛的关键词匹配。

局域网服务还要核对本地网络权限、设备是否在同一网络，以及请求实际使用域名还是私有地址。能上网但打不开打印机或家庭存储，不等同于外部服务器失败。最终只保留经过目标请求验证的修改；如无法确认是哪条规则起作用，恢复备份并从最小差异重新开始，避免积累互相覆盖的临时规则。

三、节点超时与速度慢：分开测连接和传输

节点超时表示某个测试或请求没有在等待时间内完成，并不能单凭这一结果断定服务器已经停止运行。速度慢则可能发生在解析、握手、首字节或持续传输阶段。先描述具体动作：是 Connectivity Test 没有结果，网页迟迟不出现，还是页面打开后下载缓慢。不同阶段对应的检查项目不同，延迟数字也不能直接代表下载速度。

确认服务器信息与测试含义

在用户已有服务器的信息页逐项核对地址、端口、协议和认证字段。不要仅凭节点名称认定它的地区或协议，名称只是备注。检查复制时是否带入空格、缺失字符或错误的端口；如果信息来自订阅，先保留原记录，避免把手动改过的节点与下一次订阅更新结果混淆。必要时用同一来源重新导入一个对照条目，而不是覆盖全部列表。

Connectivity Test 的结果应结合所选测试方式解释。某种测试可能只覆盖连接或特定目标，不能代替实际业务请求。测试超时而网页正常时，应检查测试目标和方式，不必据此删除可用节点；测试成功但网页失败时，则继续检查目标路径、规则与 DNS。测试和实际请求使用的目标不同，出现不同结果并不矛盾。

协议字段应成组核对

Shadowsocks 的加密方法和密码必须与服务器一致；VMess、VLESS 的认证信息与传输设置也必须对应；Trojan 的密码及 TLS 相关条件不能凭经验填写。若配置使用额外的传输路径、Host 或 Server Name，这些字段有各自作用，不能因为文字相似就互相替换。服务器地址用于定位入口，而证书验证所用名称可能不同，应以用户已有服务给出的参数为准。

出现证书或握手错误时，先检查设备时间、证书对应名称，以及参数是否被手动改动。不要通过关闭证书验证来掩盖错误；这样既改变了安全条件，也会让后续结果失去对照意义。Hysteria2 等依赖特定传输条件的协议还需要结合当前网络判断。协议名称相同不代表所有服务器都使用相同端口、认证格式或传输选项。

建立网络与节点的交叉对照

1. 固定同一目标、同一服务器，分别在 Wi-Fi 和移动网络发起新请求，记录差异。
2. 保持网络不变，仅切换到用户已有列表中的另一个节点，再请求同一目标。
3. 分别观察首次打开、页面资源加载和持续传输，不把三者合并成一个“速度”。
4. 在相近时间复测，关闭后台大文件同步，排除设备本身正在占用带宽。

只有某个网络失败，说明应优先调查该网络到服务器的路径、无线信号或访问限制；只有某个节点失败，则更值得检查该节点及其服务端状态。多个节点同时失败，也可能是它们共用一个入口或同一组参数，不能据此认定整个客户端异常。交叉测试的价值是缩小范围，不是证明某一方必然有故障。

速度下降时避免无依据调参

先比较同一设备在关闭客户端时的基础传输表现，再看代理路径是否额外变慢。无线干扰、移动网络信号、服务器负载、目标站限速和后台同步都可能造成变化。测试时不要同时进行多项大流量任务，也不要反复刷新产生大量并发请求；这会改变被测条件，并可能让服务器暂时进入限制状态。

若小网页正常而大文件停顿，先记录是否在不同目标上都能复现，再检查当前网络与协议的传输条件。MTU 等参数会影响数据包传输，但没有适合所有网络的统一值；缺少证据时不应连续试填数字。需要进一步求助时，提供网络类型、协议类别、失败阶段和已完成的对照，不提供密码或完整订阅地址。

更详细的节点观察方法可参阅延迟测试、地区与协议类型。结论应写成“同一目标在此网络与此节点组合下变慢”，而不是只记录一个延迟值。可重复的条件有助于区分偶发拥塞与持续配置问题，也能避免把临时恢复误认为某次无关修改有效。

四、订阅失败：先看返回内容，再看节点

订阅更新是一项获取并解析列表的操作，节点连接则是使用列表中某个条目的操作。更新失败不等于所有已保存节点立即失效，已有节点仍可连接也不代表订阅地址还能正常使用。先保留现有列表，记录更新提示、失败时间和当时的网络路径，不要为了一次更新失败就清空配置。恢复一个已经删除的订阅可能还需要重新核对来源信息。

检查链接完整性与内容类型

从用户自己的服务商提供的位置重新复制订阅地址，核对开头、路径和查询参数是否完整。聊天软件、换行或手动编辑可能让地址缺失一段；有些界面只展示缩略文本，不能把显示出来的省略形式当成完整链接。订阅地址往往包含认证信息，应视为密码保存，不要粘贴到公开帖子、在线解析页面或他人提供的检测工具中。

单个分享链接与订阅地址不是一回事。ss://、vmess://、vless://、trojan:// 通常用于表达单个服务器信息，订阅则提供可更新的集合。把单节点内容放进错误的导入入口，可能出现格式不识别或只得到一个条目。关于二者区别，可阅读分享链接与订阅链接格式说明，再回到对应入口操作。

按照失败阶段处理

如果有 HTTP 状态信息，应保留状态码和简短错误类别。认证失败、请求过于频繁、服务端异常分别需要不同处理；仅修改客户端 DNS 不能修复所有响应错误。链接能在浏览器打开也不能证明返回的是有效列表，因为浏览器可能显示账号登录页、说明页或访问提示。不要把这些页面保存后当作节点配置导入。

处理更新路径依赖

有些订阅域名在当前直连网络下不可达，而客户端当前选择的节点又已经失效，于是更新与连接相互依赖。先确认现有列表中是否还有用户自己的可用节点，再观察更新请求实际采用的路径。不要假设切换 Global Routing 后所有更新请求都会自动采用同一种方式；具体仍需结合当前设置、可用诊断信息和实际结果验证。

如果列表中没有可用节点，可以在不泄露地址的前提下切换一个本来就能访问订阅来源的网络，或向自己的服务来源核对订阅状态。不要寻找来源不明的临时节点来完成更新。手动重试应有间隔，连续触发并不能修复认证或格式问题，还可能遇到请求频率限制，使原来的故障与新的限制叠加。

更新后的列表还需验证

更新成功后先检查节点数量变化、当前选择和协议字段，再连接其中一个已有条目验证目标请求。服务来源可能调整名称、入口或认证信息，旧的手动选择可能不再指向相同条目。对单个节点的本地修改也可能在订阅刷新后被替换，因此手动备注、订阅内容和完整 Config 需要分开管理，不能把三者当作同一份备份。

若订阅地址已经在公开环境泄露，应向原服务来源了解更换认证信息的方法，再更新客户端保存的地址。只删除聊天消息不代表旧地址已经失效。排查记录中仅保留域名的必要部分、错误类别和操作顺序；完整查询参数不应出现在截图或共享文档中。确认恢复后再安排自动更新，避免在原因未明时让后台反复请求。

五、DNS 问题：检查解析结果与实际路径

DNS 把域名转换为连接所需的地址。域名打不开、首次加载缓慢、只有部分资源失败，都可能涉及解析，但也可能是 TLS、目标服务或规则问题。先看错误发生在解析之前还是之后：拿到地址以后仍然超时，不应继续把全部注意力放在 DNS 上。解析成功只是得到候选地址，不能证明该地址在当前网络和路由条件下可达。

把域名、地址和规则分开记录

记录失败的完整主机名，而不仅是网站名称。同一服务的登录、图片和接口可能使用不同域名；主页面能打开而图片失败，可能对应完全不同的请求。若诊断记录能够显示解析结果，同时记下地址类型和发生时间。不要将完整访问地址中的认证参数一并公开，也不要为了验证而将私人内部域名发往不受信任的解析服务。

进入当前 Config，核对是否配置了自定义 DNS、域名映射或与解析有关的选项。先确认当前生效文件，再查看规则；只编辑一个未启用的副本不会改变请求结果。若使用远程配置，还应检查更新是否替换了本地设置。对比时保留原始文件，只修改一个解析项目，否则即便访问恢复，也无法知道是哪个变化起作用。

理解规则为何可能触发解析

DOMAIN、DOMAIN-SUFFIX 和 DOMAIN-KEYWORD 依据域名信息匹配，IP-CIDR、IP-CIDR6 和 GEOIP 则涉及地址范围或地址归属。域名请求经过地址类规则时，某些配置条件下可能需要先解析才能判断。理解这一点有助于解释“规则看起来正确但首次请求很慢”的现象：等待可能发生在地址判定阶段，而非代理连接阶段。

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

示例中的 no-resolve 表示不要仅为该地址规则主动触发域名解析，不是禁用所有 DNS，也不是强制全部域名走某个路径。它不能修复解析服务器不可达，更不能保证局域网名称可解析。规则示例只说明语法关系，实际部署还需考虑已有规则顺序、内部网络范围和目标服务，不宜将整个片段作为万能修复方案。

IPv4、IPv6 与网络切换

同一域名可能返回多种地址，而当前网络对 IPv4 与 IPv6 的可达性不同。如果只在某个无线网络失败，记录该网络的地址环境，再与另一种网络对照。不要把某次关闭 IPv6 后恢复访问解释成所有环境都应关闭 IPv6；它只是提示地址选择或相应路径值得进一步检查。调整系统网络条件之前，应先保存原值并明确恢复方法。

Wi-Fi 与移动网络可能提供不同的解析条件，切换以后缓存和已有连接又可能继续存在。每轮对照应重新发起请求，必要时结束目标应用再打开；连续点击刷新未必会产生新的解析。不要通过在地址栏直接输入某个 IP 来代替全部验证，因为 HTTPS 证书、虚拟主机和服务路由通常依赖域名，访问地址成功或失败都可能产生误导。

内部域名与缓存边界

家庭路由器、单位网络和局域网服务可能使用仅在本地网络有效的名称解析。改用另一组 DNS 后，这些内部名称可能失去解析来源，即使外部网站正常也会出现本地服务异常。先确认设备是否仍在相同局域网，以及相应域名是否需要本地解析。不要把内部域名失败简单处理成扩大 PROXY 规则；代理路径未必能访问对应私有地址。

浏览器、应用、系统和客户端都可能保留部分缓存，修改配置后应区分“旧连接继续工作”与“新请求已经恢复”。测试完成以后，再次连接原先失败的目标并检查实际命中路径。如果只有某个解析条件下稳定恢复，记录这个条件和适用网络，而不是把一组解析地址推广到所有设备。解析设置的正确性应由当前网络中的实际请求验证。

六、耗电与流量异常：观察持续活动的来源

耗电增加首先需要一个可比较的条件。设备温度、屏幕亮度、信号强弱、后台同步和实际传输量都会影响电池表现，不能只凭一次电量下降判断 Shadowrocket 异常。先在系统电池统计中查看同一时间段的活动，再记录当时是否下载文件、播放媒体或频繁切换网络。比较不同日期时，使用时长和业务量不同也会导致结果不可直接对照。

区分流量归属与活动来源

代理连接承载其他应用的数据，系统统计中的归属方式可能使部分网络活动集中显示在相关进程下。这不等于客户端自行产生了同等规模的业务请求。先检查照片备份、文件同步、应用更新和媒体自动播放是否正在运行，再观察暂停这些任务后流量是否下降。只看一项统计排名，无法确定真正发起请求的应用。

如果界面提供 Data 或连接记录，可用它观察活动是否持续，但要注意统计口径、重置时间和系统统计可能不同。累计流量、实时速率和某个应用的后台活动不是同一个指标。排查前记录起始状态，固定观察区间，再比较变化；不要把累计值当成当前瞬时流量，也不要用不同时间跨度的数字证明异常。

检查重复连接与失败重试

弱信号、频繁漫游或不稳定节点可能导致应用反复尝试建立连接。表面上没有页面加载成功，后台仍可能持续握手、解析和重试。固定在信号稳定的网络，选择用户已有的可用节点，再观察空闲状态是否仍有大量重复活动。若问题只在网络切换时出现，应优先记录切换顺序与自动连接条件，而不是立即修改全部协议设置。

On Demand 用于按条件触发连接，不等于所有场景都需要保持同一种触发方式。临时关闭后手动连接，可以帮助判断是否存在不断触发、退出、再次连接的循环。测试前记录原条件，结束后恢复；不要通过长时间反复开关获得结论，因为开关本身就会制造额外的连接活动，并使后台应用重新发起请求。

建立可复现的空闲对照

1. 让设备结束大文件任务，保持相近亮度和同一种网络，先记录正常使用状态。
2. 保存配置，使用一个已经验证可用的节点，暂时停止不必要的手动测试。
3. 锁屏后观察系统统计中的后台活动，并记下是否出现网络切换或推送密集时段。
4. 再在客户端关闭时做同类观察，比较现象是否仍然存在，不把结果外推到其他网络。

对照期间避免同时更新订阅、切换规则或大量运行 Connectivity Test。测试请求本身会产生网络活动，密集检测也可能让空闲状态不再成立。若使用自动更新功能，应核对更新间隔是否符合实际需要；没有必要为确认列表有效而持续手动刷新。出现更新失败时先查原因，反复重试可能让后台活动增加而问题保持不变。

温度、充电与连接条件

充电、系统恢复备份、索引整理和高负载应用都可能使设备发热。遇到明显过热时应先停止高负载任务，让设备回到正常工作条件，再进行排查，不要边充电边连续下载来比较客户端耗电。网络信号较弱时，设备维持连接的成本也可能增加；这种情况下更换稳定网络所得到的改善，不应被误记为某条规则带来的效果。

如果关闭客户端后仍有持续发热或快速耗电，继续检查系统与其他应用；如果只在某个配置、节点或自动连接条件下复现，则保存这个最小复现条件。不要为了减少统计中的数值而随意关闭证书验证或删除必要规则。可靠的处理结果应同时满足正常请求可以完成、空闲活动回落，以及恢复原设置后问题能够被解释。

七、更新后异常：核对变化，不直接归因

“更新以后发生”说明时间先后，不等于更新就是原因。应用更新、系统升级、订阅刷新、远程 Config 变化和服务器调整可能在相近时间发生。先列出这几类变化，标记哪些是已确认、哪些只是推测，再按最接近故障的操作检查。不要凭印象填写版本号或更新时间，也不要把网络偶发恢复当成问题已经找到。

保留旧状态与当前状态

操作前导出当前配置，保存用户自己的订阅来源，并记录当前选中的节点与 Global Routing。备份文件可能包含服务器认证信息，应存放在自己的受控位置。若有更新前备份，先比较规则顺序、策略目标、DNS 和协议字段，不要一开始就覆盖现有文件；当前状态本身也是定位差异的重要证据，覆盖后可能无法重现。

先验证基础路径：关闭客户端能否直接联网，手动连接能否保持，Proxy 能否访问固定目标，Config 是否出现不同结果。通过相同的最小测试，把更新后的问题重新归入权限、服务器、规则或解析层次。这样即使缺少更新前的完整记录，也能避免围绕“新版本不正常”反复猜测，而不检查实际失败点。

辨别配置更新与应用更新

订阅更新可能替换服务器参数，远程 Config 更新可能调整规则与策略；这两类变化并不要求应用同时更新。检查本地手动修改是否被远程内容覆盖，当前生效文件是否改变，以及原先选中的策略组是否仍有相同条目。若只恢复一个节点就能工作，应继续比较该节点的信息，不要把整个配置文件替换成来源不明的内容。

系统升级以后，还应复核 VPN 权限、网络连接记录和相关自动连接条件。若系统显示明确的授权要求，按提示完成；若只是旧连接状态不一致，先断开再手动连接一次。重新建立系统连接记录应放在备份之后，且仅针对确认属于 Shadowrocket 的项目。删除所有网络配置会扩大影响范围，不适合作为首轮检查。

重新安装之前先确认可恢复

重新安装不是备份方式。删除应用前，确认自己能够恢复 Config、订阅和必要的服务器信息，并知道哪些内容只保存在本地。对照导出的文件是否可读，记录手动规则与节点备注，尤其不要假设购买记录会自动恢复业务配置。若只是一个目标站失败，优先查该目标和规则，通常没有必要先移除整个应用。

需要获取安装文件时使用下载页的平台分区。iPhone / iPad 经 App Store 获取，系统要求以 App Store 页面标注为准；Mac、Windows、安卓和 Linux 使用本站提供的安装包入口。iPhone / iPad 版为 $2.99 一次性付费，其他上述平台免费。不要将客户端获取与用户已有线路的服务状态混为一谈。

涉及重新安装时的系统放行

桌面与安卓安装包没有代码签名，首次打开可能被系统拦截。确认文件来自本站后，Windows 可在 SmartScreen 的“更多信息”中选择“仍要运行”；macOS 在“隐私与安全性”中核对被拦截项目并选择“仍要打开”；安卓按系统提示允许当前来源安装未知应用，完成后可收回该来源的安装权限。不同系统措辞可能略有差异，应核对实际文件再操作。

macOS 若提示应用已损坏，应先确认安装完整、来源正确，再按安装放行说明检查隔离属性；Linux 则按发行版与包格式检查安装结果，AppImage 需要可执行权限。不要为了启动一个文件而全局关闭系统防护，也不要把启动被阻止与连接后请求失败当成同一故障。两者发生在不同阶段，需要分别验证。

形成能够复查的结论

恢复后重新执行最初失败的动作，确认目标请求、规则命中和网络切换都符合预期。记录真正有效的差异，例如重新选择了有效节点、恢复了被覆盖的规则或补齐了授权，而不是只写“重装解决”。如果仍然失败，将操作缩短为几个可重复步骤，并附上脱敏错误信息；版本信息从应用实际界面读取，不在记录中凭记忆补写。

八、iPad 专项：购买、迁移与横屏检查

iPad 的连接排查仍遵循权限、服务器、规则和 DNS 的顺序，但购买恢复、横屏布局与配置迁移容易产生额外误判。先确认设备上确实安装了 Shadowrocket，再核对 Home 中选中的服务器、当前 Config 和 Global Routing。不要因为另一台设备可以连接，就假定这台设备上的所有条件一致；网络、权限、配置副本和连接记录都可能不同。

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

iPhone / iPad 版在 App Store $2.99 一次性付费，Mac、Windows、安卓、Linux 版免费。已经购买的 iPhone / iPad 用户，在 App Store 使用原购买账号时，可到已购项目中查找并重新下载；实际下载状态以商店记录为准。应用的购买资格不等于订阅、节点和 Config 已自动迁移，安装完成后仍要核对本地数据。

在商店中核对开发者 Shadow Launch Technology Limited、官方图标和应用 ID 932747118。系统要求以 App Store 页面标注为准。若搜不到应用，先核对自己账号的商店地区与已购项目，不要把搜索结果缺失误认为客户端连接故障。关于同账号购买与布局的说明，见iPad 共享购买与横屏界面差异。

横屏分栏时确认真正选中的项目

横屏或分栏环境中，列表选择与右侧详情可能同时出现。看到某个节点的详情，不一定说明它已经成为当前连接所用节点；打开某个 Config 的内容，也不一定说明该文件正在生效。修改之后返回连接入口，重新核对当前选择，并以实际请求验证。不要仅根据详情页停留位置推断连接正在使用哪个服务器或规则文件。

分屏、窗口尺寸和系统显示设置会改变可见区域。找不到按钮时先恢复单应用全屏，确认界面位置后再回到原来的使用方式。不要在操作尚未完成时连续点击多个列表项目，尤其是编辑、选择和连接动作可能处于不同区域时。排查记录应写清点击了哪个项目、保存在哪里，以及最终连接入口显示的状态，而不是只记截图中的某一列。

按数据类别迁移，再分步验证

迁移前分别确认服务器或订阅、Config、手动规则和必要备注是否已经保存。完整 Config 与单个分享链接覆盖的范围不同，导入一个节点不会自动带来全部规则。优先使用应用实际提供的导入、导出功能，并在自己的受控设备之间传递；传输文件和二维码可能包含认证信息，不应保存在公开相册、共享文档或公开聊天记录中。

在 iPad 上先导入用户已有的一个可用节点，用 Proxy 验证固定目标，再启用准备迁移的 Config。这样可以把服务器可用性与规则问题分开。如果一开始同时导入大量配置并启用自动连接，失败后很难知道是哪一个环节造成。测试成功后再补齐其余条目，并核对订阅更新是否覆盖了刚才的手动修改。

同一 Wi-Fi 下也要比较网络条件

两台设备显示同一个无线网络名称，不一定代表具备相同权限或使用相同路径。访客网络隔离、局域网访问权限、地址类型和缓存都可能不同。访问家庭存储或局域网服务失败时，先确认设备所在网络、相关权限与目标地址，再检查 DIRECT 规则。若 iPad 没有移动数据能力，不应为了对照而假设存在另一种网络；可以改用自己可访问的其他无线网络。

锁屏唤醒后失败，则记录是否在唤醒时发生网络变化、自动连接是否重新触发，以及旧应用连接是否仍被复用。先重新发起请求，再检查系统 VPN 状态，不要直接删掉迁移后的所有数据。若只在某个应用中出现，回到第二章检查该应用依赖的域名；若所有新请求都失败，按第一章与第五章复核权限和解析条件。

到这里仍无法定位时，整理一份脱敏记录：设备类别、网络类型、失败步骤、错误文字、关闭客户端后的表现，以及已经做过的单变量对照。不要附上完整订阅、二维码或密码。带着这些事实回到对应章节复查，通常比重新导入全部配置更容易缩小范围；若尚未完成首次连接主线，可返回使用教程逐步验证。