官方手册 / 按症状查阅
Shadowrocket 故障排查大全
从连接状态开始，依次检查服务器、模式、规则与 DNS。每次只改变一项，用相同目标复测，避免把不同原因混在一起。
首次配置请先读使用说明，按快速上手主线完成导入与连接。本页用于连接失败后的系统查阅；已有连接基础的用户，可以直接从下方目录进入对应症状。
以下操作以用户已有自己的订阅或服务器信息为前提。客户端一次性买断 ≠ 线路套餐。本站是官网与官方手册，不提供、不销售、不推荐节点、订阅或服务商。
01 开关打不开：先检查 VPN 配置授权
Home 中的开关无法保持开启，首先属于本机连接建立阶段的问题。它与网页打不开不是同一个症状。应先观察点击开关后是否出现系统授权、是否立即退回关闭状态、是否只有状态文字改变。把这三种情况分开记录，后续检查才有明确方向。此时反复更新订阅通常不能解决系统权限问题，也不应先修改 DNS。
确认本机网络与系统弹窗
先关闭 Shadowrocket 的连接，在 Safari 中打开一个当前网络本来就能访问的页面。若公共 Wi-Fi 需要先完成登录，先完成网络认证，再返回应用。基础网络尚未接通时，VPN 开关即使短暂打开，也无法证明远端服务正常。使用蜂窝数据时，还要在系统设置中检查应用的蜂窝数据权限，避免只有 Wi-Fi 下可以操作。
首次建立连接时，系统可能询问是否允许添加 VPN 配置。核对请求来自 Shadowrocket 后，按系统提示确认，并完成设备要求的身份验证。如果之前取消了弹窗，回到 Home 再次发起连接，观察系统是否重新询问。弹窗未出现不等于已经授权，应继续到系统设置中的 VPN 管理区域查看是否存在对应配置。
系统菜单名称和所在层级可能随系统语言与版本变化，可在设置中搜索 VPN。检查的是配置是否存在、是否能够启用，以及设备有没有限制，而不是盲目寻找固定的一条菜单路径。受组织管理的设备可能限制新增 VPN；此类限制需要由设备管理方核实，修改服务器字段不能绕过本机策略。
排除连接冲突，再重建必要配置
如果设备同时保存了其他 VPN 连接，先确认当前由哪一个配置接管网络。暂停其他正在使用 VPN 通道的功能后，再单独测试 Shadowrocket。部分网络过滤功能也可能占用相关系统能力，应逐项停用验证，而不是一次关闭所有设置。若停用某项后恢复，再单独启用它复测，才能确认是否存在冲突。
开关关闭后又自行恢复，检查 On Demand。按网络条件触发的自动连接可能在手动断开后再次建立通道。排查期间先记录条件，再暂时关闭 On Demand，用手动开关做一次完整测试。不要把按需重连误判为开关失灵，也不要在未记录条件前直接清空自动连接设置。
若系统中已经存在 Shadowrocket 配置，但每次启用都立即失败，可先退出当前连接并重启设备，再复测一次。只有问题仍然稳定复现时，才考虑移除对应的系统 VPN 配置，并由应用重新申请添加。操作前保存应用内配置与服务器信息；系统 VPN 配置、Config 文件和订阅列表是不同层次，不要连同其他资料一起删除。
如何判断这一阶段已经通过
开关能够保持开启，系统 VPN 状态与应用显示一致，说明本机通道已经建立，但还不代表服务器认证、域名解析和目标访问都成功。下一步应转到“连接后无法上网”。如果仍然立即断开，记录错误出现的位置与原文，并注明是在授权前、授权后还是切换网络时发生。这样的信息比“连不上”更容易用于定位。
02 已连接却无法上网：拆分模式与规则
VPN 标识表示设备建立了本地通道，不表示每一条连接都已成功送到目标。应用选择的服务器、Global Routing 模式、当前 Config 和 DNS 都会影响最终结果。先准备两个原本应当可访问的测试目标：一个用于检查本地网络，一个用于检查已有服务器的转发。两者都应使用熟悉的普通页面，不要只测试单一应用的内容加载。
先固定服务器，再比较三种姿态
回到 Home，确认 SERVER 中实际选中的条目。显示在列表里不等于被选中，订阅更新后条目排序变化也可能造成误认。先对选中条目运行 Connectivity Test，再记录结果。测试有数值只能表明该测试路径得到响应，不能据此认定所有网站、传输方式和 DNS 查询都能正常工作。
接着查看 Global Routing。配置姿态 Config 按当前配置决定去向；代理姿态 Proxy 用于检查通过当前服务器访问的情况；直连姿态 Direct 用于对照本地网络路径。临时切换模式只服务于定位，不是长期修复方式。记录原模式后再切换，每次使用同一测试目标，测试结束后恢复。
| 姿态 | 排查用途 | 结果提示 |
|---|---|---|
| Config | 验证当前规则与策略 | 仅此模式失败，优先查规则命中 |
| Proxy | 验证当前服务器路径 | 失败时继续查服务器与解析 |
| Direct | 对照基础网络 | 失败时先检查本地网络条件 |
如果 Proxy 可访问而 Config 不可访问，重点不应继续放在密码上。进入 Config 确认当前启用的文件，检查目标是否命中了 REJECT，或被指向一个不存在、未正确配置的策略。若 Direct 正常而 Proxy 失败，也不能立即断言规则错误，应转到服务器超时和 DNS 两章继续区分。
从实际命中回看规则顺序
规则通常按顺序匹配，较早的宽泛规则可能抢先处理连接。DOMAIN-SUFFIX 覆盖指定域名及其子域名，IP-CIDR 针对地址网段，FINAL 处理前面未命中的连接。排查时应看实际目标及命中结果，而不是只在文件里找到一条看似相关的规则。一个网页还可能请求多个子域名，主页面成功不代表图片与登录接口也成功。
[Rule]
DOMAIN-SUFFIX,ads.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY以上是规则顺序示例，不是适用于所有网络的完整配置。较具体的 ads.example.com 写在较宽的 example.com 之前，才不会被前面的后缀规则提前处理。GEOIP 依赖地址归属信息，不能代替所有域名规则。不要将整个示例覆盖到现用 Config；应复制配置后，只修改已确认有问题的一条。
把应用问题与网络问题分开
若 Safari 能访问，只有某个应用失败，先检查该应用是否使用独立域名、实时通信或额外传输方式。重新打开应用可以触发新连接，但不要立即清除登录资料。若页面内容来自缓存，看到旧内容也不算验证成功；应刷新并确认新请求确实完成，再回看连接记录对应的时间与目标。
每改一条规则就重新发起同一请求，确认错误是否消失。若切换网络后才恢复，应保留这一条件，继续检查本地网络和解析，不要把偶然恢复归功于最后一次无关修改。更短的操作清单见开关已打开却上不了网的逐项排查；首次连接步骤则回到使用说明。
03 服务器超时：分清传输、TLS 与认证
“超时”说明某个阶段在限定时间内没有完成，但并不直接说明密码错误。域名未解析、地址不可达、端口不通、TLS 握手中断，以及服务端没有响应，都可能表现为等待后失败。先记录使用的网络、服务器条目与错误原文，再按“地址与端口、传输参数、TLS、认证”的顺序检查，避免一开始就同时修改全部字段。
用相同条目做网络交叉测试
保持同一个 SERVER 条目不变，分别在可用的 Wi-Fi 与蜂窝数据下测试。若只有一个网络失败，说明问题可能与该网络的接入条件、解析、地址族或传输限制有关。不要据此直接删除条目。若同一网络下用户已有的另一个条目正常，则可以进一步缩小到当前服务器、端口或协议参数，而不是整个应用。
查看服务器地址是否包含多余空格、换行或粘贴残留。地址与端口应按服务商给出的字段分别填写，不要把完整网页地址直接放进主机名字段。若使用域名，检查它是否仍指向预期地址；若服务商已调整入口，应以用户自己的最新配置为准。不要凭经验把端口改成常见值，端口必须与服务端监听一致。
Connectivity Test 的测试方式与真实业务未必完全相同。某条目测试没有结果，不代表所有请求必然失败；反过来，测试有结果也不证明 TLS、认证和所有传输均正常。应补做实际页面请求，并查看错误停在哪个阶段。仅重复运行延迟测试，通常不会增加足够的诊断信息。
逐项核对协议参数，而非套用通用值
在 Add Server 或条目编辑页中，先确认协议类型。Shadowsocks 的加密方式与密码、VMess 或 VLESS 的 UUID、Trojan 的认证信息都需要与服务端一致。不同协议的字段不能互相套用。同样写着 TLS，也不意味着传输路径、主机名和端口可以照搬；应与用户已有的原始参数逐项对照。
| 字段组 | 检查内容 | 常见混淆 |
|---|---|---|
| 地址与端口 | 目标主机、监听端口 | 把管理页面地址当作服务器地址 |
| 认证 | UUID、密码或密钥 | 复制时带空格、使用旧凭据 |
| TLS | 服务端名称、证书、设备时间 | 把连接地址与证书名称强行设为相同 |
| 传输 | 类型、Host、路径等 | 漏写路径前导斜杠或改变大小写 |
TLS 的服务端名称用于证书验证与握手，它不一定等于连接地址。Host 和路径则可能属于传输层要求，也不能随意用服务器域名替代。遇到证书错误时，先检查系统日期与时间是否正确，再核对名称和证书有效性。不要把关闭证书验证当作正常修复，这会掩盖名称不匹配或连接目标不正确的问题。
识别需要服务端确认的边界
若字段完全一致、多个网络都失败，而本地基础网络正常，应由用户向自己的服务商确认入口是否仍有效、认证是否变更、服务端是否正常监听。可提供发生时间、协议、错误类型和已做过的对照测试，但不要在公开记录里贴出完整凭据。客户端无法通过改 DNS 修复一个已经停止响应的远端服务。
涉及 WireGuard 时，握手与有业务流量是两件事；涉及 Hysteria2 时，还要考虑当前网络对 UDP 的实际可用性。不要为了“全部兼容”而把所有选项都打开。每种协议只保留服务端明确要求的参数，必要时阅读VMess 与 VLESS 字段说明，先确认字段含义，再决定是否修改。
04 订阅更新失败：区分获取与内容解析
订阅导入至少包含两步：取得地址返回的内容，再把内容解析为服务器条目。地址可以打开，不等于返回的是可用订阅；导入得到条目，也不等于这些条目当前能够连接。先判断失败发生在读取地址、返回内容、解析条目还是连接服务器阶段。已有服务器无法使用时，不要默认问题一定来自订阅更新。
先检查地址本身与账户状态
从用户自己的服务商处重新复制订阅地址，检查开头、结尾、查询参数是否完整。某些地址包含用于识别账户的凭据，少一个字符就可能返回拒绝访问。复制时不要把说明文字、引号或尾部标点一起放入地址字段，也不要擅自删除看起来很长的查询参数。长地址应在私密环境核对，不要粘贴到公共讨论区。
如果页面要求先登录，或返回账户提示，这与可以直接读取的订阅内容不是同一种入口。应使用服务商明确提供给客户端的订阅地址，而不是后台管理页面。订阅内容可能采用不同编码或格式，不能仅凭浏览器显示为一串文字就判断错误，也不能把网页正文保存后当作配置文件导入。
还要检查用户已有服务的有效状态和使用限制。客户端的一次性购买与远端服务分别计算，客户端一次性买断 ≠ 线路套餐。应用购买成功并不会自动生成服务器信息。本站只说明导入与检查方法，不提供订阅地址；遇到账户状态或地址失效，应由用户向自己的服务商确认。
用返回结果决定下一步
更新时若出现网络超时，先验证基础网络，再检查订阅域名的解析与访问路径。若出现认证类错误，应优先检查地址是否失效、凭据是否已重置。若出现解析失败，则重点检查返回内容是不是订阅格式，是否变成登录页、提示页或空内容。不要把所有错误统一解释为“节点坏了”，因为有些失败甚至尚未取得服务器列表。
已有可用连接时，订阅请求可能受到当前连接状态、路由与解析的影响。保持地址不变，分别在断开连接和当前可用连接下各试一次，并记录差异。测试目的是确认地址获取路径，不是要求长期依赖某种模式。若两种状态都失败，再换基础网络复测，避免用连续刷新代替对照。
短时间频繁更新可能触发远端请求限制。出现限制提示后，应按服务商给出的条件等待，不要不断删除再添加同一个地址。若重新导入前需要修改订阅记录，先保存原记录名称与必要设置，并确认旧条目是否被其他配置引用。贸然清空会同时破坏原本可以使用的选择关系。
导入成功后验证列表与选中项
更新完成后，查看条目数量与名称是否符合预期，再检查当前选中的 SERVER。旧条目被删除或改名后，原选择可能不再对应想使用的入口。选择一个用户已有的条目做 Connectivity Test，再请求实际页面。只有列表刷新、选择正确、连接成功三个环节都通过，才能判定这次更新达到了使用目的。
手动修改订阅生成的条目时，要预期下次更新可能覆盖这些改动。需要保留的差异应单独记录，必要时在不影响原订阅的副本中验证。订阅通常用于维护服务器信息，Config 用于控制规则与其他设置，二者并不天然互相替代。导入服务器后仍然需要确认 Config 与 Global Routing 是否符合原使用方式。
05 速度慢：区分延迟、吞吐与单站响应
“慢”需要先描述成可观察的症状：页面开始加载前等待很久，内容开始后下载缓慢，视频反复缓冲，还是只有一个站点响应迟缓。这些情况可能涉及不同阶段。Connectivity Test 的数值主要用于比较测试路径的响应，不能直接换算成下载速度。测试数值较小的服务器，也不一定在当前时段具有更高的可用吞吐。
建立可比较的测试条件
固定同一台设备、同一个 Wi-Fi 位置、相同服务器与相同目标文件，先暂停设备上的大流量任务。云端同步、系统更新与视频播放会争用网络，导致两次测试缺乏可比性。不要在一次测试中同时换服务器和换网络，否则结果改变后无法判断是哪一个因素生效。每次只做一个对照，并记录大致时间。
先关闭连接测基础网络能否稳定加载普通页面，再开启连接测试同一目标。若关闭时已经明显缓慢，应先处理 Wi-Fi 信号、路由器负载或接入网络问题。蜂窝数据的信号与网络拥塞也会变化，信号格数并不能完整代表传输质量。可移动到信号稳定的位置再复测，而不是立即修改协议。
避免短时间重复进行大量大文件测试。测速本身会消耗用户自己的网络流量，并可能让设备升温。观察目标是稳定性、开始响应的时间与持续传输表现，不是追求某个固定数字。若只有首次访问等待较长，后续请求恢复，应优先关注 DNS、首次握手和缓存，不要直接认定服务器带宽不足。
按影响范围选择排查方向
多个目标都慢，而本地直连正常，重点检查当前服务器路径、远端负载和协议传输。只有单个站点慢，则可能是站点本身、内容分发位置或该域名的分流结果。先看连接记录中目标实际走了哪条策略，再决定是否调整规则。对所有域名统一改为 Proxy，可能掩盖错误，却不一定改善原问题。
图片快而视频缓冲，或网页正常但实时通信不稳时，要考虑连接类型差异。部分功能依赖 UDP，部分使用较长的持续连接。只有 TCP 测试通过不能覆盖所有应用场景。可让用户自己的服务商确认当前条目是否支持所需传输，并检查本地网络条件；不要凭一项延迟测试推断整个协议功能齐全。
切换 Wi-Fi 与蜂窝数据后，如果慢的问题跟随同一服务器出现，说明服务器或远端路径值得优先检查。如果只在一个网络出现，应保留原服务器字段，把重点转向本地链路、地址族和网络接入条件。若同一网络中用户已有的其他条目表现正常，也应记录这项证据，减少无关的配置修改。
谨慎处理 MTU 与重试
小请求正常、大请求停顿，某些情况下可能与路径 MTU 有关，但这是后续分支，不是常规第一步。先排除丢包、服务器负载与目标站点问题。只有当前协议和设置确实提供相关参数，且已保存原值时，才按已知网络条件做单项测试。不要复制来源不明的统一数值，也不要把所有慢速问题都归因于 MTU。
持续断开重连会增加握手与解析开销，也可能中断尚可维持的长连接。应给一次请求合理的观察时间，并区分新连接建立慢与已建立连接传输慢。若重连后短暂恢复，又在高流量时再次下降，记录这一规律，而不是把不断重连当作解决办法。这样的条件能帮助判断远端限制、链路拥塞或设备热状态。
成功标准是同样条件下目标任务恢复稳定，而不是测试数字偶然改善。完成定位后，恢复为符合原用途的 Global Routing，撤销没有证据支持的试验参数。若需要保留例外规则，应写明目标与原因，避免日后忘记临时设置，使下一次排查面对更多不可解释的变量。
06 DNS 异常：把解析与连接分开验证
DNS 把域名转换成地址。服务器延迟测试有结果，但网页提示找不到主机、等待很久或部分资源不显示时，需要把解析作为独立环节检查。也要注意，浏览器显示的证书错误与域名解析失败不是同一个问题。先记录具体域名、错误文字与发生时的连接模式，再看请求是否取得地址、取得了哪一类地址。
先确认当前配置与查询路径
进入 Config 确认实际启用的文件，查找其中影响 DNS 的设置。只修改一个没有被启用的文件不会改变运行行为。若存在自定义解析服务、Host 映射或其他解析相关覆盖，应先记录原值，分清当前请求由哪一层处理。系统、路由器与应用内配置可能共同参与，不应假设每次查询都直接使用同一个解析来源。
选择一个出现问题的完整域名，与另一个正常域名对照。使用应用内可用的诊断与连接记录，观察是否有解析结果、是否超时，以及后续连接是否继续进行。若域名能够得到地址，但 TCP 或 TLS 随后失败，重点已经转向网络与握手；此时反复更换 DNS 可能只是改变了目标地址，并没有修复真正的故障。
自定义 DNS 服务本身也需要网络可达性。其地址若还依赖一个尚不能完成的解析过程，就可能产生启动阶段的依赖问题。检查配置中解析请求的实际去向，以及连接建立前后是否表现不同。不要同时更换解析服务、改 Global Routing 并清空规则，否则无法知道哪一步改变了解析路径。
检查 Host、IPv6 与网络差异
过期的 Host 映射可能把域名固定到旧地址，掩盖正常 DNS 的变化。先在配置副本中停用与故障域名有关的映射，再重新发起请求。对于依赖内容分发的站点，固定地址还可能失去适合当前网络的位置。不要把一次偶然可用的地址长期写死，也不要用直接访问地址的结果替代完整的域名访问测试。
有些网络能够返回 IPv6 地址，却未必具有稳定的 IPv6 连通性。若问题只在特定网络发生，应查看失败连接实际使用 IPv4 还是 IPv6，再结合基础网络测试判断。不要仅因返回了某类地址就认定解析错误。临时调整地址族相关设置时，必须记住原值，并在切换网络后复核，避免修复一个环境却损坏另一个环境。
局域网设备名称、内部域名与公共域名也可能需要不同解析路径。公共解析服务未必知道本地设备的名称；公司或家庭内部资源可能依赖所在网络的解析信息。若只有内部资源失败，先验证本地网络与访问路径，再检查这些域名是否被错误送到远端。不能用“所有域名都交给同一解析服务”作为通用答案。
理解域名规则与地址规则的边界
DOMAIN 和 DOMAIN-SUFFIX 直接针对域名，IP-CIDR 与 GEOIP 则面向地址。某些地址规则的判断涉及解析结果，因此规则命中与 DNS 并非完全独立。排查时先使用具体域名规则确认策略，再看地址规则是否改变结果。不要在还没确认目标域名的情况下不断添加宽泛关键词规则，这可能影响不相关的请求。
[Rule]
DOMAIN,portal.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,10.0.0.0/8,DIRECT
FINAL,PROXY此处示例说明具体规则应先于宽泛规则，不能代替实际网络方案。portal.example.com 是教学域名，不是真实服务入口。修改后应重新发起请求，让新连接使用新结果；系统和应用缓存可能使旧结果继续保留一段时间。不要把“保存后没有立刻变化”直接判断为配置没有生效。
解析成功的验证应同时满足：域名得到合理地址、请求走预期策略、实际页面完成加载。更多细节见DNS 设置与解析失败检查。术语不熟悉时，可先查概念速查，再回到当前故障域名继续验证，不必一次重写整个 DNS 配置。
07 耗电与发热：先看活动，再看重连
VPN 持续开启时，经过通道的数据处理会计入相关系统活动，但电池页面中的占比不是独立的耗电测量仪。某个时间段其他应用活动减少，Shadowrocket 的比例也可能上升。判断异常需要结合总电量变化、屏幕使用、网络流量、设备温度和是否反复重连，不能只凭单个百分比认定应用存在故障。
建立同等条件下的观察区间
在系统电池页面查看所选时间段，区分屏幕开启与关闭时的消耗。记录期间是否观看视频、进行文件传输、导航或云端同步。高流量任务经过 VPN 时，相关处理自然增加；这与待机时持续唤醒是不同问题。应选择使用习惯相近的两个观察区间，而不是拿繁忙的一天与几乎未使用设备的一天比较。
同时记录网络类型与信号条件。弱信号蜂窝网络会让设备为维持传输付出更多代价，Wi-Fi 信号边缘也容易造成重试。若设备只在某个位置发热，先移动到网络稳定的位置观察，不要先修改规则。若只在充电并执行大流量任务时升温，应暂停任务并等待设备恢复正常温度，再继续对照测试。
系统刚完成较大更新或设备刚恢复资料时，后台整理和同步也可能影响电量。此时应等相关活动趋于稳定，再判断连接是否造成持续额外消耗。不要在设备高温时反复测速；测速会增加负载，既放大耗电，也让后续性能数据失去可比性。若系统提示温度异常，应优先按系统提示处理。
检查 On Demand 与重复建立连接
打开连接记录，观察是否短时间反复断开和建立。每次重连都可能需要解析、握手和认证，比稳定维持通道产生更多额外工作。若重连发生在 Wi-Fi 与蜂窝数据切换时，检查网络稳定性；若只针对某一条目，则回到服务器超时章节核对字段与远端状态。不要把自动重连次数多当成连接“更可靠”的证据。
On Demand 的条件若过于频繁地变化，可能导致连接行为与预期不同。先记录条件，在可控环境暂时关闭自动触发，手动连接后观察是否仍然反复重建。若关闭后稳定，应逐项恢复条件，找出触发差异，而不是长期反复手动关闭开关。需要按需使用时，应保留清晰、能解释的条件设置。
部分协议涉及保活设置，用于维持网络映射或连接状态。保活间隔过于频繁可能增加网络活动，但随意停用也可能影响特定网络的可达性。只有用户原有配置明确提供此参数，且理解其用途时才做调整。不要照搬其他协议的数值，更不要为了待机数据好看而牺牲原本必要的连接能力。
收敛后台任务与诊断活动
排错期间避免持续运行大范围 Connectivity Test，也不要让诊断记录长期保持不必要的高细节状态。测试和记录本身也会产生处理与存储活动。收集到足够证据后，恢复日常所需设置，观察正常使用中的电量变化。若用户配置含有额外处理任务，应在副本中逐项停用验证，不要直接删除无法解释的内容。
还要确认连接中是否有应用不断失败重试。某个目标被 REJECT 后，部分应用可能持续重新请求；错误解析也可能导致同样行为。此时应修复规则或解析路径，而不是只降低测试频率。将连接记录中的频繁目标与当时运行的应用对应起来，能帮助区分后台业务流量和通道自身的维护活动。
最终应记录一个可复现结论，例如“相同网络下，仅某条目持续重连时发热”，而不是“打开就耗电”。如果在暂停大流量、稳定网络、恢复必要设置后仍有明显异常，保存脱敏记录与电池观察条件，再进一步反馈。不要为了验证而让设备持续高温，也不要把恢复出厂设置作为这一类问题的常规步骤。
08 更新后异常与 iPad：还原设备差异
更新后出现问题，先确定变化发生在哪一层：应用更新、系统更新、订阅刷新、Config 替换，还是设备换网。这些事情可能在同一天发生，但不能因为时间接近就认定原因相同。记下最后一次正常使用时的服务器、模式与网络，再对照当前状态。排查目标是找出行为差异，不是寻找一个未经验证的旧配置来覆盖全部设置。
保留资料，再做最小范围复测
先保存当前 Config、自定义规则以及必要的服务器信息。确认哪些资料来自订阅、哪些是手动输入，避免重建后无法恢复。接着重启应用并使用现有配置测试，必要时重启设备，让系统网络状态重新建立。若问题仍然存在，建立配置副本，仅保留必要规则与一个用户已有的服务器作对照，不要先清空正常资料。
若最小配置正常，而原配置失败，应分组恢复原有规则和设置，逐步找到差异。每次恢复后使用同一目标复测，不要一次把所有内容加回去。若两者都失败，再检查系统 VPN 授权、基础网络与服务器参数。错误提示若指向配置语法，应先检查提示附近的分隔符、策略名称和字段，不要只关注刚修改的那一行。
更新记录与系统要求以 App Store 页面标注为准。需要核对应用时，使用正版核验说明，确认开发者 Shadow Launch Technology Limited、官方图标与应用 ID 932747118。Shadowrocket 是 Apple 平台的闭源商业应用，更新与重新获取都通过 App Store；不要把重新购买当作修复网络配置的方法。
iPad 与 iPhone 的差异要逐项核实
同一份服务器信息在 iPhone 可用、在 iPad 不可用时，先确认两台设备实际上处于同一网络。iPhone 可能正在使用蜂窝数据，而 iPad 仍连接 Wi-Fi，名称看起来相近也不能代替检查。若 iPad 只有 Wi-Fi 能力，应在另一个可用网络下复测，避免套用不适用于当前设备的蜂窝数据检查步骤。
应用购买记录不会自动证明所有本地配置已经一致。检查两台设备选中的 SERVER、Global Routing、启用的 Config、DNS 相关项与 On Demand 条件。手动输入的字段尤其需要逐项对照；复制配置时也要确认复制的是当前使用文件，而不是之前保存的旧文件。只比较条目名称不够，同名条目的地址与参数可能已经不同。
iPad 上的布局可能因为横竖屏、窗口大小或多任务状态而变化。某些列表与编辑区域可能同时显示，应根据 Home、Config、Settings 等界面词确认所在区域，不要只按按钮在屏幕左侧或右侧的位置寻找。需要输入长地址时，检查键盘自动处理是否带入空格或标点，保存前重新核对内容。
睡眠唤醒、局域网与重装边界
如果仅在 iPad 长时间待机后失效，先观察唤醒后的网络是否已恢复，再手动断开并连接一次。若重新连接后恢复，记录是否伴随网络切换或 On Demand 条件变化，继续检查重连与解析。不要把每次唤醒都重建所有配置作为固定操作；这会掩盖真正的恢复时序问题，也容易丢失排查证据。
只有局域网设备、家庭内部页面或打印功能失效时，检查相关系统权限以及目标流量是否按预期 Direct。内部地址段、内部域名和公共互联网目标的处理条件不同，应结合实际地址与解析结果判断。不要为解决一个本地目标而把全部流量长期改为 Direct，也不要添加覆盖过宽的地址规则影响其他连接。
确需重装前，先确认配置备份可读取、手动条目可恢复，且用户知道自己的订阅地址保存在哪里。已购恢复和通用购买适用性以 App Store 页面标注为准，详见iPad 获取说明与换机恢复说明。购买恢复解决的是应用获取，不会自动重建用户原有的服务器与规则。