Shadowrocket 故障排查大全

连接开关打不开或自动关闭

先判断开关停在哪个阶段

点击连接后没有反应、短暂开启后关闭、开启后反复重连，是不同的现象。先停在 Home，观察操作后是否出现系统授权提示，再到系统设置查看 VPN 状态。系统授权只表示允许创建连接所需的配置，不代表服务器已经通过认证，也不代表访问目标成功。若提示仍在屏幕上，先阅读并完成确认，不要在提示后方反复点击应用开关，以免把等待授权误判为连接卡住。

首次连接需要允许添加 VPN 配置，并可能要求设备密码或系统身份验证。若此前取消过授权，可返回应用重新发起连接。系统设置中的入口名称可能因系统不同而变化，可搜索 VPN 查看配置。只检查能够确认属于 Shadowrocket 的条目，不要随意删除单位、学校或设备管理要求保留的配置。受管理设备若限制添加 VPN，应交由设备管理员确认，修改服务器参数不能解除系统策略限制。

把本地网络与连接配置分开检查

先关闭连接，用浏览器访问平时能正常打开的页面，确认 Wi-Fi 或蜂窝网络本身可用。公共 Wi-Fi 可能需要先完成网页登录；此时即使图标显示已接入，也不等于已经获得互联网访问。完成网络认证后再连接。若基础网络也不通，先处理信号、账户网络状态或路由器连接，不要同时更换 Config。切换到另一种可用网络后重复一次，可以判断故障是否仅发生在当前接入环境。

基础网络正常后，检查 Home 是否确实选中了一个服务器，而不是只有订阅分组名称。打开所选条目，对照已有服务商给出的协议、地址、端口和认证信息。先保存当前 Config 的副本，再尝试使用已知可用的配置进行对照。若某份配置一启用就使连接结束，而其他配置能够保持开启，应优先检查该配置的语法和引用关系。不要直接覆盖唯一副本，否则会同时失去故障现场与回退依据。

处理自动连接与重复启动

如果开关刚关闭又重新打开，检查 On Demand 是否启用，以及当前网络是否符合它的连接条件。排查期间可以暂时关闭 On Demand，再手动测试，以免自动规则改变连接状态。设备中其他使用 VPN 配置的功能也可能影响当前连接；暂停能够确认且允许暂停的相关功能后复测。观察结果时记录是哪一个动作触发了状态改变，例如切换 Wi-Fi、锁屏或回到前台，而不是笼统记录“偶尔断开”。

若开关短暂开启后立即关闭，留意应用可见的错误说明或连接记录。配置解析失败、必要字段缺失、扩展启动中断与远端超时，需要不同处理。可先停止连接，退出到主屏幕后重新打开应用，再进行一次受控测试；仍无法恢复时再重启设备。重启能够清理临时系统状态，但不能修正错误的密码、无效的服务器地址或配置语法。恢复后也应重复原步骤，确认问题没有只是暂时隐藏。

开关已开启但无法上网

建立能够重复的访问对照

开关已开启只说明本地连接处于运行状态，不能据此断定远端服务器、DNS 和规则都正常。先选择两个平时能访问、用途不同的目标，分别记录页面完全打不开、只有图片失败，还是某个应用无法联网。关闭连接再访问同样目标，作为基础网络对照。如果关闭后仍失败，应先排除目标网站故障、网络登录状态与设备网络问题，不要继续在代理规则中寻找并不存在的原因。

测试时尽量使用同一浏览器、同一页面和相近时间，避免把缓存命中当成恢复。必要时重新打开页面，或选择一个此前没有打开过的普通页面。不要只凭某个应用首页能够展示内容判断网络正常，它可能正在读取本地缓存。若浏览器正常、单个应用异常，还应检查该应用是否获得蜂窝网络权限、是否正在进行后台任务，以及是否需要重新建立登录连接，暂时不要扩大为全设备故障。

用 Global Routing 区分规则与通道

检查 Global Routing 当前采用配置、代理还是直连，对应界面词为 Config、Proxy、Direct。诊断时只临时改变姿态，并记下原值。Direct 用于观察基础网络路径，Proxy 用于观察经当前服务器的访问，Config 则按当前配置匹配规则。它们不是三种服务器，也不是一组速度档位。代理姿态可作为隔离规则问题的对照，但不保证所有目标都适合一直经由同一服务器访问。

如果 Proxy 正常而 Config 失败，检查目标是否被分到 DIRECT、REJECT 或一个不可用的策略组。读取配置时从前向后寻找匹配项，特别留意过宽的 DOMAIN-KEYWORD、网段规则和提前出现的兜底规则。若 Direct 正常而 Proxy 失败，则先验证当前服务器，不要急于修改域名规则。完成对照后恢复原姿态，再做下一项修改，避免临时测试设置留在日常使用环境中。

核对命中规则与必要的关联请求

一个页面通常不只请求地址栏里的域名，还可能依赖图片、脚本、登录与接口域名。主页面正常但登录失败时，查看应用当前能提供的连接记录，寻找失败发生时对应的请求和策略。若记录中可见目标命中 REJECT，应先确认该规则的原意，再在副本中做范围更小的调整。不要为了一个图片请求删除整组规则，也不要根据域名名称猜测归属；优先采用实际失败记录与服务说明。

下面的片段只展示规则语法与顺序：示例域名经 PROXY，符合地理库匹配的地址使用 DIRECT，其余流量交给 FINAL。它不是通用的完整配置，PROXY 必须在实际配置环境中能够正确指向可用策略。测试规则前先确认编辑的是当前启用的 Config，保存后按需要重新建立连接，并用同一目标复测。修改未启用的文件，不会改变当前运行结果。

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

若两种路径都能建立连接，却只有域名访问失败，继续检查 DNS；若仅个别服务器失败，转到超时章节。不要把浏览器报出的所有网络错误都解释为规则错误，证书、目标维护与账户登录也可能导致访问中断。完整记录“目标、姿态、服务器、结果”后再求助，比单独提供开关截图更有价值。还可对照开关已开却无法上网的逐项排查复核检查顺序。

服务器超时与连接认证失败

分清测试结果能证明什么

延迟测试、建立协议连接与打开实际网页，是三个不同层次。某个测试得到响应，只能说明该测试采用的路径在当时能够完成，不代表所有网页请求都能通过。反过来，测试显示超时，也可能与测试方式或测试目标有关，不能仅凭一个数值认定服务器永久失效。先记录使用的测试方式，再用同一服务器访问固定目标，结合实际错误判断问题发生在连接前、认证中还是请求转发后。

如果一组服务器同时超时，先切换基础网络进行对照；如果同一网络里只有一个条目失败，优先检查该条目的配置与远端状态。测试期间停止反复批量测速，避免额外请求干扰现象。每轮保留一个已知可用条目和一个失败条目，比较结果即可。已有服务商若提供维护或账户状态说明，应核对相关信息；本手册只说明配置使用，不提供或推荐服务器来源。

按地址、认证、传输顺序核对字段

先检查服务器地址是否误带协议前缀、路径、空格或换行，端口是否与提供的信息一致。地址栏需要填写主机名时，不应把整个订阅链接粘进去。复制过程还可能把全角标点带入密码或标识字段，造成看似一致却无法认证。不要凭经验更换端口或加密方式，应逐项对照原始配置；敏感字段只在设备本地核对，公开截图时遮住完整密码、标识与订阅凭据。

接着核对协议所需的认证与传输参数。Shadowsocks 的密码和加密方式需要一致；VMess 与 VLESS 的 UUID、传输方式及 TLS 相关字段不能混填；Trojan 通常需要同时核对密码和 TLS 信息。Hysteria2 与 WireGuard 也各有必要字段，不能把其他协议的参数直接套用。协议名称相同并不意味着所有服务器使用同一套选项，实际参数始终以用户已有服务的配置为准。

处理 TLS、时间与网络差异

启用 TLS 的连接需要核对服务器要求的名称。服务器地址、SNI 与传输层 Host 可能各有用途，不应因为名称不同就全部改成一样。设备时间明显错误也会影响证书有效期判断，可检查系统日期与时区是否正确。遇到证书错误，先核对名称、时间及服务端配置，不要把跳过证书验证当作常规修复；它会改变验证边界，也会掩盖本应被发现的配置或证书问题。

若 Wi-Fi 失败而蜂窝网络正常，或反过来，说明接入网络差异值得继续检查。某些传输依赖 UDP，网络设备对 UDP 的处理可能与普通网页连接不同。先用服务商已经提供且确认支持的配置做对照，不要随意改协议名称，也不要盲目调整 MTU。只有在已经确认协议、认证和路径正确，并有可重复的小包正常、大请求失败现象时，才进一步调查路径与分片相关问题。

订阅更新失败或导入结果异常

先识别链接与失败阶段

订阅是用于取得服务器列表的地址，不等于单个服务器，也不等于 Config 配置文件。先确认用户已有服务商给出的内容属于哪一种，再使用对应导入方式。若把网页地址、账户后台地址或单条分享信息放进订阅入口，应用可能无法得到预期列表。检查时只核对链接结构与来源说明，不要把完整链接贴到公开对话中；其中的查询参数经常包含访问凭据，泄露后可能影响账户使用。

把更新失败分成无法发起请求、收到错误响应、内容解析失败和列表更新后不可用四类。无法请求时先查网络与域名解析；出现账户或链接失效提示时，核对原服务账户和链接状态；解析失败时，检查返回内容是否符合应用支持的订阅格式。若列表已经变化但无法连接，说明获取过程可能已经完成，问题应转向服务器字段或远端状态，而不是继续重复点击更新。

隔离订阅请求所走的网络

先确认基础网络可以正常访问，再执行一次手动更新。若当前连接本身已经失效，订阅请求又依赖它，可能形成无法更新也无法恢复连接的循环。可以在保留旧列表的前提下停止当前连接，使用可用网络重新尝试，并记录两种状态下的结果。不要假定所有订阅都应当采用同一请求路径，也不要因为一次失败就覆盖原始链接；应依据已有服务商的访问要求与实际对照结果处理。

公共 Wi-Fi 未完成认证时，请求可能被返回登录页面；某些服务异常时，也可能返回网页说明而不是服务器列表。这些内容即使能够在浏览器中显示，也不说明订阅格式正确。若出现解析错误，应优先核对响应性质，不要把整个网页复制到 Add Server。需要进一步确认时，向已有服务商描述应用显示的错误类别，提供脱敏信息即可，不公开提交包含账户信息的响应正文。

更新前后比较分组与选择状态

更新前记录当前分组、所选服务器名称及手动添加的条目，必要时保存独立副本。订阅更新可能替换该订阅管理的条目，手动改过的字段也可能被新内容覆盖。因此不应把对订阅条目的临时修改当作长期保存方式。更新后先看条目数量和分组是否符合预期，再确认当前选中项仍然存在。名称变化、重复名称或服务器移除，都可能使原本熟悉的选择不再指向同一条连接。

如果更新后只剩部分条目，先检查是否有筛选条件、分组折叠或显示范围变化，再判断数据是否缺失。若同名条目参数不同，应查看协议和地址，而不是只按名称辨认。订阅获取成功也不表示账户服务一定有效，服务期限、远端维护与认证信息仍需分别确认。反复删除整个分组再导入通常不能修复服务端返回内容，反而会丢失原有对照信息，使后续定位更困难。

恢复到可验证的订阅状态

恢复时保留一个来源明确的订阅分组，先进行手动更新，确认列表可用后再考虑自动更新选项。自动更新的具体入口与可用条件以当前应用界面为准，不应把它当成修复无效链接的工具。如果每次打开应用都会刷新并覆盖临时修改，先核对相关自动更新设置，再决定如何保存独立测试条目。测试结束后清理重复导入的分组，避免日后误选旧条目。

连接正常但速度慢或间歇卡顿

先给“慢”一个明确的范围

页面首次打开等待较久、下载持续速率偏低、视频间歇缓冲与游戏响应延后，不能用同一个延迟数值解释。先记录慢的是建立连接还是传输过程，是所有目标还是单个应用，是持续发生还是特定时段出现。若只有第一次打开慢，后续请求正常，应关注 DNS、握手与缓存；若连接很快但大文件持续停顿，则更需要检查链路稳定性、吞吐和远端负载，而不是只看测试列表中的数字。

测试时固定目标、服务器与接入网络，暂停系统更新、照片同步和其他大量传输，再观察同一任务。不要同时运行多个测速任务，它们会争用带宽，使结果失去可比性。比较时尽量安排在相近时间，避免把早晚网络负载变化误认为某个设置生效。若服务商说明存在流量或速率条件，应核对当前账户状态；客户端配置不能替代远端服务所能提供的实际容量。

沿基础网络、服务器、目标逐层对照

先在关闭连接的情况下访问基础网络可达的固定目标，观察 Wi-Fi 信号、路由器上行与其他设备的占用。信号格数较多也不保证无线环境稳定，干扰、距离和接入设备负载都可能影响传输。随后保持目标不变，用当前服务器重复测试。再切换到用户已有且确认可用的另一个服务器，比较是否只有单条路径变慢。不要一边换服务器一边改 DNS，否则无法判断改善来自哪一项。

若同一服务器对多数目标正常、只对某个目标偏慢，可能与目标站点负载、内容分发位置或两端路径有关。先核对 Config 是否让相关域名走了预期策略，特别是主站与图片、视频域名是否分开处理。需要时临时使用 Proxy 做对照，再恢复原姿态。单个视频无法达到预期清晰度，不足以证明整个连接故障，还应考虑播放服务自身的自适应逻辑、账户权限与缓存状态。

把延迟、丢包和吞吐分别看待

延迟描述一次往返或某个测试过程的等待时间，吞吐描述单位时间实际传输的数据量，两者相关但并不等同。路径响应快，仍可能在持续传输时受限；路径响应稍慢，也可能保持稳定下载。应用中的 Connectivity Test 适合帮助观察可达性，不应被当作所有使用场景的总分。选择服务器时结合日常任务结果，不要只为了更低的显示数值频繁切换，增加重连与握手成本。

间歇卡顿更需要观察连续性。若短时间内时好时坏，记录是否同时发生 Wi-Fi 漫游、蜂窝切换、锁屏唤醒或后台大流量任务。对于依赖 UDP 的业务，还应区分网页可用与该业务可用；网页主要路径正常，并不证明所有传输都受到相同处理。不要为了测试随意修改 MTU、并发或传输参数。只有存在明确证据和原始配置依据时，才在副本中改动，并安排可回退的对照测试。

保留稳定配置而不是叠加优化

若排查发现只是规则绕行，修正规则范围后应重新验证其他常用目标，防止局部改善带来新的访问问题。若只在某种网络发生，保留该网络与另一网络的对照记录，进一步检查接入设备；若多个网络上同一服务器都慢，则把重点转向服务器状态和远端路径。不要把无法解释的选项全部开启，所谓优化项叠加越多，越难判断是哪一项改变了连接行为。

DNS 解析失败与规则结果不一致

区分解析、连接和证书错误

DNS 负责把域名转换为后续连接使用的地址。域名无法解析、地址已经得到但连接失败、连接完成后证书不匹配，是不同阶段的故障。先查看错误是否明确涉及解析，再比较多个域名的结果。不要简单用某个网站的地址替换域名来验证全部流程，因为 HTTPS 通常还依赖正确的主机名与证书，直接访问地址失败并不能独立证明网络路径不可达。

如果多个应用都在打开新域名时等待，而已有连接仍能继续使用，解析路径值得优先检查；如果只有一个目标异常，则先确认目标自身状态与相关规则。浏览器、应用和系统可能保留各自缓存，因此切换设置后结果不会总是立即一致。测试前记录原设置，重新建立连接后重复相同访问，并区分刚打开的新请求与仍在复用旧连接的页面，避免把缓存差异误读为随机故障。

核对当前 Config 的解析路径

打开当前启用的 Config，检查 DNS 相关设置是否确实属于正在运行的文件。先了解原配置希望由哪一条路径完成解析，再检查解析服务器是否可达。只把地址换成一个熟悉的值，并不保证适合当前网络，也可能让本来可用的路径失效。若使用加密解析方式，其连接本身也需要网络、正确时间以及相应的握手条件，不能把“加密”理解为对所有网络环境都自动可用。

特别注意循环依赖：当前服务器地址需要先解析，而解析请求又只能通过尚未建立的连接完成，可能导致启动阶段卡住。排查时依据现有配置说明检查初始解析路径，不要同时替换服务器域名与 DNS 设置。若服务商明确提供独立的连接地址与握手名称，应分别放在对应字段，不能为了避开解析而随意用一个查到的地址永久替换，远端地址可能变化，也可能影响传输条件。

理解域名规则与地址规则的边界

DOMAIN 用于匹配完整域名，DOMAIN-SUFFIX 用于匹配指定域名及其下级域名，DOMAIN-KEYWORD 的匹配范围更宽。IP-CIDR、IP-CIDR6 与 GEOIP 则围绕地址或地址库判断。某个请求能否使用域名信息，与请求来源、解析过程和当前配置有关，不应假设每一条连接都一定能够命中域名规则。排查时先看实际记录，再解释规则，而不是只根据地址栏推断命中结果。

[Rule]
DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.org,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
FINAL,PROXY

示例中的两个网段是文档示例地址，不应替换成未经核对的大范围真实网段。no-resolve 用于避免为匹配相应地址规则而额外进行域名解析，并不是关闭所有 DNS，也不能修复解析服务器不可达。规则按顺序处理，过宽的前置匹配可能使后面的精确规则没有机会生效。修改时先使用最小范围的目标进行验证，再决定是否扩展，避免把局部问题扩大到其他应用。

检查 IPv6 与设备侧叠加设置

同一个域名可能得到不同地址类型，Wi-Fi 与蜂窝网络也可能具有不同的 IPv6 条件。若只有某种接入网络失败，应检查地址类型与当前路径支持情况，而不是立即关闭所有相关能力。系统中的描述文件、网络过滤或其他解析设置也可能改变实际行为；只检查自己能够确认的设置，受管理设备交由管理员处理。每次调整后重新建立连接，以减少旧会话造成的误判。

耗电增加、发热与后台活动异常

先看统计区间与实际用量

系统电池页面中的占比是选定时间区间里的相对结果，并不等于应用在任何情况下都有相同耗电。当天其他应用使用较少时，同样的连接活动也可能显示更高占比。先记录统计区间、屏幕使用时长、实际电量下降与是否持续传输，再判断异常。只看某一项百分比，无法区分正常的长时间网络转发、基础网络信号差和连接反复失败造成的额外活动。

比较时选择相近的使用条件：同样的接入网络、相似的屏幕亮度、相近的任务与持续时间。视频播放、云端同步和热点共享都会改变整机负载，不能把两天完全不同的任务直接比较。也不要把充电时发热与单独使用时发热混在一起。若设备明显高温、出现系统温度提示或电量异常下降，应先停止高负载任务，让设备恢复正常状态，再继续进行短时间、可控的诊断。

检查持续重连与后台大流量

连接不稳定时，反复解析、握手与重建会话可能增加活动。先观察开关与系统 VPN 状态是否频繁变化，再核对是否只有某个服务器或网络出现问题。若服务器持续超时，继续保持自动重试通常不能修复远端状态。暂停连接，检查基础网络，再切换到用户已有的可用条目做对照。与稳定连接相比，失败次数和触发条件更能帮助解释异常，而不是单纯比较在线时长。

同时检查正在同步照片、更新内容或恢复数据的应用。连接开启后，原本等待网络的后台任务可能开始传输，用户看到的耗电变化不一定来自连接本身。可在系统允许的范围内暂时暂停相关任务，再观察是否恢复。不要为了降低某一项统计而关闭必要的安全设置，也不要反复清空应用数据。应把传输量变化与电量变化放在同一时间区间里看，避免把正常的数据处理误判为故障。

核对 On Demand 与诊断活动

On Demand 根据设定条件触发连接；如果网络环境不断切换，条件又频繁满足与失效，可能出现重复建立连接。排查期间先记下规则，再暂时关闭 On Demand，手动保持一次稳定连接。若活动明显减少，继续检查具体触发条件与当前网络变化，而不是直接认定该功能本身不可用。恢复时一次启用一项条件，确认在锁屏、切换网络与回到前台时的行为符合预期。

持续批量测试、长时间保留详细诊断记录以及重复更新订阅，也会增加网络或本地处理。诊断结束后停止不再需要的测试，只保留足够定位问题的脱敏记录。若使用复杂 Config，先复制保存，再停用与当前测试无关的额外处理，观察差异。不要直接删除所有规则；规则减少与电量改善之间未必有直接关系，真正需要验证的是哪一项工作造成持续活动或重复失败。

用分组对照确认调整有效

可以分成三轮观察：基础网络下的正常任务、手动稳定连接下的相同任务、恢复 On Demand 后的相同任务。每轮保持时间和任务接近，记录电量变化与连接是否重建。若只有某个 Wi-Fi 环境明显异常，应继续检查信号和路由器；若多个网络都在同一配置下重复出现，则保留配置副本与触发步骤。短暂重启后改善不能代替长期验证，至少再覆盖一次原先容易出问题的使用场景。

应用或系统更新后出现异常

先确认究竟改变了什么

问题发生在更新之后，不一定由更新本身引起。同一时间可能还发生订阅自动刷新、服务器维护、网络切换或 Config 更换。先列出最后一次正常使用到首次失败之间的变化，确认更新的是应用还是系统，以及是否同时更新过订阅。保留现有配置，不要连续执行重装、清空和重新导入，否则多个变化叠加后，很难判断哪一步真正影响了结果，也无法向后续排查提供可靠现场。

更新应用后先打开 Home，确认服务器列表、当前选中条目与启用的 Config 是否仍符合预期。界面位置变化不等于原有内容丢失，可先查分组和当前文件，再决定是否重新导入。若只是某个入口名称或位置不同，应依据当前界面操作，不要套用旧截图猜测。应用获取与更新统一通过 App Store；需要核对购买或恢复流程时，参阅已购恢复说明，不另寻其他获取方式。

按系统状态、配置、远端逐层复测

先关闭连接，验证基础网络，然后重新建立一次手动连接。若系统重新请求 VPN 授权，阅读并确认；若设备受到管理限制，交由管理员核对策略。更新系统后出现连接异常，可以停止连接并重启设备，再做同一项测试，但不要把重启后的短暂成功直接视为解决。还应覆盖之前的失败动作，例如锁屏唤醒或 Wi-Fi 切换，检查连接能否在同样条件下保持正常。

接着使用原服务器，在 Direct、Proxy 与 Config 之间做受控对照，并恢复原姿态。若只有 Config 异常，应检查配置语法、策略引用和规则顺序；若所有经服务器的访问都失败，应回到地址、认证与传输字段。某些旧配置依赖较严格的字段关系，问题暴露后应对照已有服务商的当前配置说明逐项核对，而不是盲目添加不认识的选项或把验证要求全部放宽。

处理配置迁移与订阅覆盖

如果异常紧随订阅刷新出现，比较刷新前保存的副本与当前条目，重点看协议、地址、端口、TLS 和传输字段。名称未变不代表内部参数没有变化。若手动修改过订阅管理的条目，刷新可能将其恢复为订阅内容；此时应把确认有效的测试配置单独保存，并向已有服务商核对差异。不要反复修改同一订阅条目后又立即更新，否则每次测试都可能在不同参数上进行。

配置迁移也可能涉及文件选择与策略关联。先确认当前启用的是预期文件，再检查其中引用的策略是否仍有对应对象。复制文件不等于复制所有外部依赖，导入成功也不代表所有引用都可用。遇到解析错误，保留具体错误与对应行附近的脱敏片段，只修复能够解释的问题。不要把整份 Config 替换成来源不清的配置来“验证”，那会同时改变分流、解析和处理逻辑。

最后再考虑重建与重新下载

只有在服务器信息、订阅来源和 Config 副本已经妥善保存，并且明确知道如何恢复时，才考虑重建应用自己的 VPN 配置或重新下载应用。重新下载前确认使用原购买账户，避免把商店账户问题与连接问题混在一起。保存到外部位置的文件也应检查是否真正可打开，而不是只看到文件名。应用内历史状态未必能完整恢复，依赖这些状态排错时，应先完成必要记录再进行清理。

iPad 连接、恢复与多设备差异

先区分购买状态与配置状态

同一购买账户下的应用获取，与设备上的服务器配置是两件事。先在 iPad 的 App Store 核对应用购买状态，系统要求、兼容性与是否通用购买均以 App Store 页面标注为准。能够重新下载应用，并不意味着 iPhone 上的订阅、服务器选择与 Config 已经自动出现在 iPad。首次打开后应检查实际内容，再按快速上手教程导入自己已有的信息，不要用购买成功代替连接前核对。

若商店显示的购买状态与预期不同，核对用于 App Store 的账户，而不是只看系统顶部的账户名称。应用 ID 应为 932747118，开发者为 Shadow Launch Technology Limited。相关恢复步骤见iPad 获取说明。购买问题先在商店层面处理；服务器认证或访问问题则按本页流程检查，两者没有直接替代关系。客户端买断获得的是应用使用资格，不包含线路服务。

对照两台设备的真实配置

iPhone 正常而 iPad 失败时，先让两台设备接入同一个可用 Wi-Fi，在相近时间访问同一目标。比较所选服务器、Global Routing、当前 Config 和 DNS 条件，不要只比较服务器名称。订阅更新时间不同、同名条目参数变化或启用文件不同，都可能造成差异。对照时把两台设备都调整到已记录的测试状态，每轮只修改一台的一项设置，避免两边一起变化后失去参照。

传递配置时使用自己能够确认且受控的方式，导入后逐项核对地址、端口、协议与必要认证字段。不要通过公开文档或公开图片传递完整订阅链接，也不要把二维码理解为天然不含敏感信息。若某种同步方式只传递了 Config 文件，还应确认文件引用的服务器或策略是否存在。文件能够打开，并不意味着所有依赖已到位；出现未知策略时应先补全对应关系，而不是随意改成另一个名称。

检查 iPad 的网络与系统限制

部分 iPad 仅能使用 Wi-Fi，不能照搬蜂窝网络对照步骤；可改用另一处可信且可用的 Wi-Fi 检查。支持蜂窝网络的设备，则分别核对网络权限与当前数据连接。使用手机热点时，iPad 看到的是热点提供的接入环境，仍需验证基础网络是否正常。不要因为 iPhone 自身能够访问，就推断热点下的 iPad 一定具备相同路径；共享连接、信号和会话条件都可能不同。

学校、单位或家庭管理中的 iPad，可能受到 VPN、账户或网络策略限制。首次连接若无法添加 VPN 配置，先检查系统提示并联系管理员，不尝试删除管理要求保留的内容。公共网络需要网页登录时，应先完成基础网络认证，再启动连接。若只有某个应用失败，检查其网络权限和账户状态；若所有应用都失败，才继续按服务器、DNS 与规则顺序排查，避免把局部权限问题扩大处理。

验证锁屏、多任务与长期使用

iPad 常在分屏、多任务和较长待机之间切换，界面处于后台并不等于连接已经停止。用系统 VPN 状态和实际请求共同判断，不要只看应用窗口是否在前台。若从锁屏恢复后失败，记录唤醒前后所连接的 Wi-Fi、On Demand 条件与开关状态，再手动重建一次连接对照。只有自动条件下复现时，优先检查条件规则；手动连接也失败时，则回到基础网络与服务器可达性。