Shadowrocket
故障排查大全

先区分无法开启与开启后回落

开关无法保持开启，首先检查系统是否允许建立 VPN 配置，而不是立即修改服务器密码。请在 Home 选择已有服务器，确认没有停留在编辑表单，再尝试连接。第一次发起连接时，设备可能显示添加 VPN 配置的系统确认；只有确认来源为正在使用的 Shadowrocket，才按系统提示完成授权。若之前取消了弹窗，返回应用重新发起，观察是否再次出现确认。

把现象拆成三类记录：点击后完全没有变化、系统确认出现但未完成、开关短暂开启后自动关闭。第一类还需要检查应用是否能够正常响应其他操作，第二类关注设备授权，第三类则需要查看连接失败时的应用提示。不要只记录“打不开”，因为三类现象分别指向界面响应、系统权限与连接建立过程，后续处理顺序并不相同。

若界面暂时没有响应，可先等待当前导入或测试任务结束，再返回 Home 重试。正常退出并重新打开应用，可以排除一次性的界面停滞，但不等于修复了服务器问题。重复点击开关会混合多次连接过程，使错误提示难以对应具体操作；保留一次完整尝试的结果，比连续开关更有诊断价值。

检查系统配置与 On Demand

进入设备 Settings，在 VPN 配置管理位置确认 Shadowrocket 对应配置是否存在，并查看是否有其他网络隧道正在连接。管理入口会随系统界面变化，可以使用 Settings 的搜索功能定位。先断开其他活动隧道，再回到应用做一次手动连接测试；不要直接删除不认识的配置，尤其是由学校、单位或设备管理策略下发的项目。

如果开关关闭后又自动开启，或者切换网络时反复变化，应检查 On Demand。它可能按已设条件再次请求连接，这与普通的手动开关故障不同。先记下已有条件并暂时关闭 On Demand，只验证手动连接是否稳定。手动连接正常后，再逐项恢复按需条件，确认究竟是哪个网络条件触发了连接或断开。

对于受管理的设备，系统策略可能限制添加或修改 VPN 配置。若授权选项不可操作，或系统明确提示配置受限制，应向设备管理方确认允许的设置范围，而不是反复重装应用。应用内参数不能覆盖设备管理策略；只有先确认系统允许建立连接，服务器地址、协议与规则的排查才有意义。

保留资料后再做恢复操作

开关短暂开启后回落时，先核对当前服务器是否完整：地址和端口是否为空、协议类型是否选对、导入后是否仍指向一个已经失效的条目。以服务商提供的信息逐项对照，不要凭名称判断配置内容。若可见错误指向解析、认证或证书，应转到相应章节；此时系统授权可能已经完成，不必重复处理 VPN 配置。

需要重建系统 VPN 配置之前，先保存必要的配置文件和服务器资料，并确认仍可从你的服务商处获取订阅。移除系统 VPN 配置与删除应用是两种操作，影响范围不同；不要在尚未备份时同时执行。重建后先用一个已核对的服务器手动连接，暂不恢复复杂规则与 On Demand，以便判断基础连接是否已经恢复。

最后记录“系统确认已完成、其他隧道已断开、手动连接仍回落”这类具体结果。若重新启动设备后仍然复现，可结合应用内可见的错误信息继续定位。购买或应用来源疑问应另行查阅App Store 正版核对说明，不要把获取问题与连接参数问题混为一谈；系统要求以 App Store 页面标注为准。

先确认基础网络，再做模式对照

连接已建立但无法访问时，先暂时断开 Shadowrocket，用同一设备、同一网络访问平时可正常打开的页面。若断开后同样失败，应优先处理无线网络、蜂窝数据、路由器或网络登录认证。公共网络可能需要先完成登录页面，尚未获得基础网络访问能力时，调整代理规则通常不能解决问题。完成认证后再尝试建立连接。

基础网络正常后，固定同一个目标页面与同一个服务器，依次比较 Global Routing 的 Config、Proxy、Direct。这里的配置、代理、直连分别对应界面中的英文名称。每次切换后重新建立测试请求，避免只观察已经打开的页面；某些应用会复用旧连接，原来的连接未必立刻采用新的路由决策。

对照测试必须解释结果，不能只把某个模式当作永久解决办法。Direct 正常而 Proxy 失败，说明直接路径可用，但服务器路径仍需检查；Proxy 正常而 Config 失败，则优先检查规则命中、策略指向和 DNS。所有模式都失败时，再回到目标本身、设备网络权限与解析结果，避免把不同层面的故障归为一个原因。

根据影响范围检查规则

如果只有部分页面或应用失败，先记录一个成功目标和一个失败目标。查看失败请求实际使用的域名，以及是否经过预期策略。一个页面可能同时请求多个域名，主文档能够打开而图片或登录失败，通常需要继续检查相关资源请求。不要为了修复一个页面，把整个配置替换为宽泛的代理或直连规则。

Config 中的规则通常按顺序参与匹配，较宽的规则放在前面，可能遮住后面的精确规则。请检查自定义规则的位置、策略名称和最后的 FINAL。还要区分直接拒绝请求的 REJECT 与连接失败：前者是规则决策，后者是决策完成后访问路径没有成功。若应用内记录明确显示命中了拒绝策略，应先确认该规则是否符合原本意图。

下面片段只说明匹配顺序，不是可以替换现有配置的完整文件。示例先处理域名后缀，再处理指定地区的地址，最后给未匹配请求设置策略。示例域名仅用于语法说明，实际排查应使用你已确认的目标；改变 FINAL 会影响大量未命中请求，不应在没有记录原值时随意修改。

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

验证新请求与实际恢复范围

切换模式后，先结束失败页面的旧请求，再重新打开目标。浏览器可用新的标签页测试，其他应用则退出相关页面后重新进入。若只有缓存内容能够显示、刷新就失败，不能算网络恢复。验证时分别观察页面主内容、图片资源与一次需要网络的实际操作，避免把本地缓存或已有会话误认为完整访问成功。

若浏览器正常而单个应用失败，还需检查该应用的蜂窝数据许可、是否要求固定访问地区、是否依赖独立连接或账户状态。应用端返回的访问限制不等于隧道故障。不要持续切换服务器触发更多登录验证；先保留错误文本，确认失败发生在连接阶段还是已经收到服务端响应后。

恢复后，将 Global Routing 调回原本需要的模式，再验证原先失败的目标。只在 Proxy 下暂时可用而 Config 仍失败，应继续修正规则，不要将临时对照结果写成彻底解决。首次设置不熟悉时，可回看Global Routing 教程；零散提示与购买类疑问可查阅疑难解答。

把测试失败拆成可检查的阶段

Connectivity Test 显示失败，只能说明该次测试没有按预期完成，不能直接断言服务器永久不可用。首先确认测试对象是当前选中的服务器，并记录使用的测试方式。不同方式检查的层次不同：端口可达不代表协议认证成功，认证完成也不代表某个目标页面一定可访问。要把测试结果与实际请求放在一起解释。

先核对地址与端口，确认地址栏没有混入协议前缀、空格、换行或不属于主机名的路径。不要把订阅地址当成服务器地址，也不要把网页管理入口直接填入 Add Server。地址由域名表示时，还应检查本机能否解析该域名；解析失败发生在连接服务器之前，应先处理 DNS，而不是反复修改认证字段。

然后在相同配置下切换一次基础网络，例如从 Wi-Fi 改为蜂窝数据。若只在其中一个网络超时，检查方向偏向本地网络、路由路径或网络对所用传输方式的限制。若两个网络都失败，再与服务商确认服务器状态、端口和参数是否变化。每次对照保持服务器与目标不变，才能让网络差异成为有意义的证据。

按协议核对参数，不混用字段

Shadowsocks 应核对加密方法和密码，VMess 与 VLESS 应核对身份标识及服务端要求的传输设置，Trojan 则要重点核对密码与 TLS 相关字段。不同协议中的字段并不等价，不能因为两个条目使用同一地址就复制所有选项。导入成功只表示文本能够被解析，不代表导入内容与服务端当前设置一致。

启用 TLS 的连接还涉及服务器名称、证书有效性与设备时间。SNI 应遵循服务端提供的要求，不能随意填写一个能够打开的域名。证书报错时，先确认设备日期时间正确，再核对域名、SNI 与服务端证书。关闭证书验证不应作为常规修复手段，它会掩盖名称或证书配置错误，也会削弱连接身份校验。

若服务端使用 WebSocket 等传输方式，还需检查路径、Host 与 TLS 是否相互匹配。路径可能区分大小写，并可能要求保留开头的斜杠；不要把参数说明中的注释一起复制进表单。任何单项不确定时，都回到服务商提供的原始资料核对，避免通过连续尝试多个猜测值，让问题变成无法复现的组合。

区分持续故障与间歇性超时

只在某些时段超时，应记录发生时间、当前网络、服务器与测试目标，而不是只保存一张失败结果。短时网络拥塞、网络切换和服务端负载变化，都可能影响一次测试。采用少量、间隔进行的对照即可，不要持续高频发起测试；大量并行请求会增加干扰，反而让原本间歇的问题看起来持续存在。

若测试能够完成但实际页面仍失败，改用一个已知可访问的小页面，区分“服务器连接”与“经服务器访问目标”两个阶段。目标端限制、解析差异和规则指向都可能导致后一阶段失败。相反，测试目标本身不可用时，也可能出现应用实际访问正常而测试失败的情况，因此不能仅凭一项测试决定删除服务器。

向服务商反馈时，说明协议、错误类别、网络对照与复现步骤，不公开密码、身份标识或完整订阅链接。有关 Trojan 的字段含义，可进一步阅读Trojan 参数逐项说明。当参数已核实而远端仍不可达，应等待服务端确认，不要通过改动无关的本地规则扩大故障范围。

区分获取失败、解析失败和条目不可用

Subscribe 更新失败时，先确认失败发生在哪个环节：无法取得远端内容、取得内容但无法解析，还是更新完成后服务器无法连接。这三种现象不能使用同一种处理方式。订阅更新负责把远端信息导入应用，不负责保证远端每个服务器当前都可访问；服务器超时应在保留订阅更新结果后，转入上一章单独检查。

订阅链接从你的服务商处获取。复制时保留完整地址与查询参数，尤其注意长链接是否被聊天界面折行、截断，或混入前后空格。不要删除看起来像随机字符的部分，它们可能参与身份验证。也不要把服务商的账户页面、说明页面或配置展示页面当作订阅地址；能在浏览器显示文字，不代表返回的就是应用可识别的数据。

先记下现有订阅分组与可用条目，再执行一次手动更新并查看提示。若仍有可用服务器，保留这些资料，不要为了重试而删除整个分组。部分更新方式可能调整条目名称、顺序或内容，连接前应重新确认当前选中项。旧名称消失与订阅完全失效是不同情况，先检查条目是否已被替换或重新归类。

检查访问路径与返回内容

若获取阶段失败，确认当前基础网络可以访问订阅所在服务。必要时比较断开连接、使用已有可用连接时的更新结果，但每次只改变访问路径。用于更新的请求未必与普通页面请求走完全相同的流程，应以应用内可见结果为准。若服务商要求特定访问条件，先核对其说明，不要通过随意更改订阅地址的域名或协议来绕过报错。

收到认证失败或访问拒绝时，检查订阅是否被重置、账户授权是否变化，以及链接是否仍为最新有效地址。重复请求一个已经失效的认证链接，通常不能恢复授权。若响应提示过于频繁，应停止连续更新并按服务商要求等待。应用购买状态与远端订阅授权相互独立，重新购买客户端不会使失效的订阅自动恢复。

能够取得内容但解析失败时，需要确认服务商提供的格式与导入入口相符。返回内容有时可能实际是登录页面、错误说明或维护页面，而不是服务器资料；页面有文字并不等于格式正确。不要把整个网页复制进配置文件，也不要手工删改编码内容中的符号。应让服务商确认返回类型，并提供适用于当前入口的资料。

检查更新后的选择与持久化

更新成功后，回到 Home 检查当前选中的服务器是否仍存在、所属分组是否正确，并对一个条目执行连接测试。若新条目全部失败，重点核对协议与服务商状态；若只有个别条目失败，保留其名称与错误信息反馈。不要把分组里条目数量变化直接解释为应用故障，远端内容调整也会改变本地结果。

手动修改订阅条目之前，要明确下一次更新是否会覆盖修改。为了验证单个字段，可以先保存原值，必要时建立独立的手动测试条目，再与订阅条目对照。不要同时在多个分组中复制和修改同一服务器，否则之后很难判断正在连接的是原始条目还是临时副本。验证结束后清理临时测试内容，保留清楚的命名。

如果长时间没有更新，先确认应用是否具备执行更新时所需的网络条件，再检查更新设置。后台执行受系统调度影响，不应把预期时间未出现更新直接视为订阅失效。手动更新成功而后台更新未按预期发生时，优先检查设备使用环境与系统限制，不必重新生成全部服务器参数。

最终应得到一条完整记录：链接来源已经确认、获取是否成功、解析是否成功、更新后哪个条目能够连接。仍无法判断时，把去除认证信息的错误文本和发生环节交给服务商，而不是发送完整链接到公开讨论区。订阅问题的简短问答可查阅疑难解答，首次导入的操作顺序则按使用教程完成。

先确定慢的是哪一种操作

“速度慢”应先拆成首次打开慢、持续传输慢、视频缓冲、偶发停顿或网络切换后中断。首次打开主要涉及解析、建连与握手，持续传输还受带宽、拥塞和目标服务影响；二者不能只用一个延迟数字解释。请选一个容易重复的操作，记录开始阶段和持续阶段各自的现象，再决定检查哪一层。

先在同一设备上观察基础网络，确认没有同时进行大文件同步、系统更新或多个应用的持续传输。Data 中的流量变化可以辅助识别活动，但流量大不等于某个服务器速度快，流量小也不等于连接失败。若其他应用正在大量使用网络，先等待它们结束，再做对照，避免把设备总负载误认为代理性能问题。

固定测试目标、服务器与 Global Routing 模式，在相近时间完成少量重复测试。不要一次更换网络、服务器和协议，然后将改善归因于其中某一个选项。可以先比较同一服务器在两种网络上的表现，再固定网络比较你已有的两个服务器；每一步只有一个变量，结果才能指向具体的瓶颈。

沿本地网络、服务器与目标分层比较

仅在某个 Wi-Fi 环境变慢，先检查信号强度、设备与接入点距离、路由器负载和网络登录状态。移动到信号更稳定的位置后重试，比直接调整协议参数更有解释力。蜂窝数据对照时，也要注意信号与网络制式变化；一次移动过程中的测试不能代表固定地点的正常表现。

同一网络中，仅一个服务器慢，而其他已有服务器正常，检查重点在服务器负载及到该服务器的路径。多个服务器都慢但 Direct 对照正常，也不能立即证明应用本身有问题，因为它们可能共享相似路径或远端出口。需要进一步比较目标、时段和协议，确认变化是否具有一致性，再向服务商提供可复现的信息。

只有某个网站或某项服务慢，先验证同一服务器访问其他目标的表现。目标的内容分发、账户限制、服务状态或访问地区都可能改变结果。测速文件的吞吐量不能代表所有网站的加载体验；一个连接下载很快，也不能证明短连接握手同样顺畅。测试要围绕实际失败的操作，而不是寻找一个看起来更好的数字。

检查传输特性，避免盲目调参

部分协议依赖 UDP，某些网络对这类流量的可达性与持续传输表现可能不同。使用 Hysteria2 或 WireGuard 时，应先确认网络与服务端支持相关传输，再检查协议设置。不能因为另一个 TCP 连接可用，就认定 UDP 路径完全正常。协议选择应与服务端配置对应，不要只修改客户端类型而保留原有参数。

MTU、并发和保持连接等设置不宜作为第一步尝试。比如特定路径上的分片或丢包问题，可能表现为小请求正常、大传输停顿，但相似现象也可能来自拥塞或目标限制。没有对照证据时随意降低 MTU，可能改变其他应用的表现。确需测试时记下原值，采用单项调整，并在没有改善时恢复。

若网络切换后才出现停顿，先等待系统完成新网络连接，再重新发起请求。有些应用会保留旧连接，切换后需要自行重连；这不等于所有流量持续不可用。对照浏览器的新请求与原应用的旧会话，可帮助判断故障发生在基础隧道还是应用会话恢复。不要同时反复开关连接和切换网络，避免干扰重新建立的过程。

验证改善时，至少重新执行原先变慢的完整操作，并观察是否持续稳定。若只是一次打开较快，不应立即保存大量未经验证的调参。记录哪个变量带来改善，以及恢复原值后是否再次变慢。更细的分层测试可阅读速度慢的逐层定位笔记；有关统计口径可阅读Data 页流量统计说明。

确认是否真的发生在解析阶段

DNS 问题常表现为服务器域名无法解析、部分目标提示找不到地址，或切换网络后同一域名得到不同访问结果。先区分无法解析服务器地址与无法解析目标域名：前者会阻止代理连接建立，后者可能出现在连接已经建立之后。记录具体域名与错误阶段，才能决定检查本地网络、应用中的 DNS 设置还是服务端路径。

不要用浏览器直接访问目标 IP 的方式替代全部解析检查。许多服务需要正确的域名来完成 TLS 与虚拟主机匹配，使用 IP 访问失败，并不能证明网络不通。同样，某个 IP 能够建立连接，也不能证明域名对应的页面必然可用。更可靠的做法是结合应用内可见的解析或请求记录，查看域名是否获得结果以及之后走向哪个策略。

检查时先使用你已知应当正常的目标，并保持当前网络不变。如果只有一个域名失败，确认拼写、域名本身状态与服务商给出的服务器地址；如果大量无关域名同时失败，才优先考虑解析服务或访问解析服务的路径。不要把个别服务端返回错误、账户验证失败或页面空白都统称为 DNS 故障。

检查解析路径、缓存与地址类型

查看当前 Config 中与 DNS 相关的设置，同时检查设备是否存在额外的 DNS 配置或网络管理策略。先列出有哪些设置可能参与解析，再决定测试哪一项。更换解析服务前，应确认所选地址的协议和网络路径可用；把一个无法访问的解析服务填进去，可能使原本仅影响单个目标的问题扩展为全部域名失败。

若使用加密解析，还需要检查其服务器名称、证书与访问路径。建立加密解析连接本身也可能需要先解析服务器名称，错误的依赖关系会造成启动阶段失败。因此，不能只看到“加密”就认为解析链路已经正确。按所用配置的说明核对，避免把普通 DNS 地址、加密解析地址及网页地址当成可以互换的内容。

修改后需要考虑缓存和旧连接。系统、应用与目标应用都可能保存此前结果，立即刷新一次未必会触发新的解析。先结束相关请求，重新建立连接并再次测试，必要时重启目标应用。不要连续切换多个解析服务却不记录结果，否则缓存尚未更新时看到的现象，会被错误归因于刚刚修改的设置。

还要留意 IPv4 与 IPv6 路径是否一致。某些网络能返回两类地址，但其中一种路径不稳定；另一些服务又依赖特定地址类型。不要为了修复单个目标而直接关闭所有 IPv6 相关能力。先比较不同网络、具体域名和失败地址类型，确认问题范围，再按当前配置支持的选项做最小调整。

把解析结果与规则顺序一起检查

域名规则和地址规则检查的对象不同。DOMAIN 关注完整域名，DOMAIN-SUFFIX 关注后缀，IP-CIDR 与 IP-CIDR6 关注地址范围。若请求先命中某条宽泛规则，后面的精确条目可能不会参与决策。解析结果变化也可能改变地址规则的匹配，因此“DNS 有结果”与“规则命中正确”仍是两项独立验证。

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

以上规则片段用于说明不同匹配对象，不是完整配置。完整域名条目在该示例中已经被相同策略的后缀条目覆盖，保留两行是为了对照语法，实际配置应避免没有必要的重复。私有地址规则只处理匹配的地址范围，不意味着所有局域网发现或设备通信都能仅靠这一行解决；局域网问题还应结合最后一章检查。

恢复后，分别确认服务器域名能够解析、失败目标能够解析、新请求命中预期策略，而且实际页面可用。若其中一项仍异常，继续沿对应层排查，而不是不断添加新的解析地址。向服务商反馈时可提供已遮去敏感资料的域名、错误类别和网络对照；不要公开包含账户标识的专用地址或完整配置文件。

先检查是否存在持续传输与重连

耗电异常应结合设备 Settings 中的电池使用记录、屏幕使用情况与当时的网络活动判断。VPN 连接承担其他应用的网络转发，系统显示的归属并不总能直接代表单个应用主动产生的全部活动。不要只凭一个百分比认定配置有问题；先记录异常发生的时段，确认是否同时有视频、同步、上传或长时间网络传输。

将排查分为静置和使用两种状态。静置对照时，保持相同网络、相近电量和相近观察时长，避免同时充电、下载或移动位置。使用对照时，执行同一种操作并记录持续时间。短时间内的电量显示会受温度和系统估算影响，不适合得出精确耗电结论；应优先寻找持续传输、重复连接这类可以直接观察的线索。

连接不稳定可能导致不断重试，进而增加网络活动。查看是否在 Wi-Fi 与蜂窝数据之间反复切换，是否处于信号较差的位置，On Demand 是否在相邻条件之间反复触发。先稳定基础网络，并暂时关闭按需条件做一次手动连接对照。若重连停止后耗电现象缓解，再逐项恢复条件，而不是一次关闭所有功能。

减少诊断干扰，不牺牲正常验证

排查时可能临时开启详细记录或频繁运行 Connectivity Test。取得必要证据后，应恢复原有记录级别并停止重复测试，避免把诊断活动本身当成日常负载。若 Data 中持续出现增长，要结合其他应用当前行为检查；云端同步、媒体上传与后台传输可能在屏幕关闭后继续进行，不能仅凭设备看起来静置就认定没有流量。

设备明显发热时，先停止高负载测试，让设备回到稳定温度，再比较连接表现。温度变化可能影响系统性能与无线通信，边充电边进行持续传输也会增加干扰。不要为了收集更多数据持续进行压力测试。日常排查的目标是复现实际问题并确认改善，不是测出设备或网络能够承受的极限。

电池问题也需要检查设备整体状态。如果断开连接后仍有相同的异常耗电，继续查看系统电池记录与其他应用活动，而不是持续调整代理参数。若只有特定网络与特定服务器组合下出现异常，优先调查连接重试与传输稳定性。把观察范围收窄到可复现的组合，才能避免将设备电池状态误认为单一应用配置问题。

更新后从最小可用配置恢复

更新后出现异常，先区分应用更新、系统更新、订阅更新和 Config 内容更新。它们可能发生在相近时间，但影响对象不同。记录最后一次正常使用时的网络与配置，确认当前服务器、Global Routing 和配置文件是否仍为原选择。订阅重命名、策略指向变化或系统权限状态变化，都可能使异常看起来像由应用更新直接造成。

先正常重新打开应用，必要时重新启动设备，随后用一个已核对的服务器与简单的访问目标测试。暂时停用自己添加的复杂规则、按需条件或其他扩展配置，但保存原始内容。每恢复一项就验证一次；若基础连接正常，加入某项设置后才失败，便可把调查范围限定到该项，而不必删除全部应用数据。

检查 Config 中失效的策略引用、已被移除的服务器名称及格式错误。旧配置能够保存，不代表其中引用的对象仍然存在。若出现明确的解析提示，按提示定位相应行，保留修改前后的差异。不要从不同来源拼接大量参数来修复单个错误；配置之间的依赖关系可能使表面上正确的片段在组合后失效。

只有在资料已备份且明确需要时，才考虑移除系统配置或重新安装应用。应用获取与更新统一通过 App Store，恢复购买与设备兼容性可查阅已购恢复说明，系统要求以 App Store 页面标注为准。恢复后先验证基本连接，再逐步导回资料；完整复现步骤比未经验证的“更新后就坏了”更利于定位。

比较设备时先对齐网络与资料

同一订阅在 iPhone 正常、iPad 失败时，先确认两台设备真的使用相同网络。iPhone 可能已经切到蜂窝数据，而 iPad 仍停留在需要认证或信号较弱的 Wi-Fi。查看实际网络状态，再核对所选服务器、Global Routing、Config 与订阅更新时间。只比较服务器显示名称不够，同名条目中的参数也可能不同。

在两台设备上使用同一目标、相同服务器与相同模式，分别发起新的访问请求。不要用一台设备已经缓冲好的页面，对照另一台设备刚开始的访问。若条件对齐后仍只有 iPad 失败，检查该设备的 VPN 授权、日期时间、设备管理策略和额外网络配置；服务器已经在另一台设备工作，并不能排除本机权限或配置差异。

应用购买与配置迁移也要分开处理。同一账户下的已购获取、设备兼容性与系统要求以 App Store 页面标注为准；已经安装应用不表示服务器资料会自动完整出现。先按iPad 获取说明确认应用，再从你的服务商处获取订阅并完成导入，之后才比较连接表现，避免把缺少配置当成购买恢复失败。

检查多任务、休眠与网络恢复

iPad 使用分屏或多任务时，应用可能显示在较窄的区域，部分设置入口需要展开或滚动才能看到。参数含义不会因为窗口变窄而改变，但操作时容易遗漏隐藏在下方的字段。核对 Add Server 时逐项滚动检查，保存后返回条目再次查看。不要仅凭编辑页面上半部分正确，就认定全部参数已经完整保存。

合盖、长时间静置或网络切换后出现异常，应分别验证系统网络恢复、VPN 连接状态和目标应用会话。先确认设备可以正常访问基础网络，再检查 Shadowrocket 的连接；最后重新打开目标页面。如果新请求正常而原来的视频、文件传输或会话仍停顿，问题可能在目标应用没有及时恢复旧连接，不必立刻重建全部服务器配置。

On Demand 在 iPad 上也应按实际网络条件逐项验证。设备可能长时间连接同一个 Wi-Fi，但中途经过休眠、认证过期或接入点切换。先用手动连接确认基础可用，再恢复按需设置，分别测试唤醒、离开网络和重新连接网络后的行为。不要把一次唤醒成功视为所有网络条件都已覆盖，保留实际使用场景的验证记录。

区分局域网地址、发现机制与代理路径

访问家中存储、打印设备或其他局域网服务失败时，先断开连接做对照，并确认设备确实处于同一可互访网络。访客 Wi-Fi、接入点隔离与不同网段，本身就可能阻止设备之间通信。如果断开后仍不可访问，应先处理路由器或设备权限；只有基础局域网路径正常，才继续检查 Config 的路由规则。

局域网发现与直接访问地址是两种行为。直接访问已知地址正常，但自动发现失败，可能涉及发现报文、网络隔离或系统的本地网络权限；不能仅通过添加一条域名规则解决。若相关应用需要本地网络权限，在设备 Settings 中检查其授权状态。不要把所有发现问题都归因于 DNS，也不要随意给整个网络增加宽泛策略。

确需让某个私有地址范围直接访问时，先确认真实网段，再使用对应的 IP-CIDR 或 IP-CIDR6 规则，并把位置放在会遮挡它的宽泛规则之前。不要将示例网段原样当成家庭网络事实。对于同时具有域名与地址的服务，还应核对域名解析到了哪里，避免域名走向远端地址，而你只修改了本地私有地址规则。

测试时分别验证已知地址访问、域名访问和设备发现，三个结果都记录。若只有发现失败，应继续调查发现机制；若域名失败而地址正常，回到 DNS 章节；若所有局域网目标都失败，检查网络隔离与规则顺序。这样的拆分可以防止为了修复一个入口，改变所有其他访问路径并引入新的问题。

最后形成一份可复现记录：设备型号类别、当前网络、连接模式、目标类型、错误文本和对照结果。发送前遮住订阅地址、认证字段与账户信息。基础连接恢复后，再回到使用教程完成日常验证；需要快速核对常见结论时查阅疑难解答。保留这份记录，下次出现类似症状时即可从已验证的层级继续，而不是重新改动全部设置。