Shadowrocket
故障排查大全

开关打不开或连接立即停止

先区分两种现象：点击 Home 的连接开关后始终没有进入连接状态，和已经连接但几秒后自动停止。前者优先检查系统授权、设备限制与配置是否有效；后者还要检查其他 VPN 配置、On Demand 条件和网络切换。记录点击后的提示原文、系统是否出现确认弹窗，以及开关何时复位。只凭“打不开”不能判断是服务器故障，系统尚未建立本地 VPN 会话时，反复更换服务器通常不能解决问题。

检查系统授权与设备限制

首次建立连接时，系统可能要求允许添加 VPN 配置，并通过设备密码或系统验证确认。只有确认来源为当前打开的 Shadowrocket 后才继续；如果刚才选择了取消，返回应用重新发起连接，查看是否再次出现授权。进入系统 Settings 中的 VPN 管理位置，核对是否存在对应配置；不同系统的入口名称与层级可能不同，可以使用系统设置搜索。配置存在仅说明系统保存了连接描述，不代表服务器验证已经成功。

如果设备由单位或学校管理，VPN 修改权限可能受管理策略限制。先查看是否存在管理提示，再向设备管理员确认允许的使用方式，不要删除不熟悉的管理配置。个人设备也应检查是否有其他正在连接的 VPN 服务：先在其自身设置里停止，再测试 Shadowrocket。排查时记录原状态，避免把原本用于工作网络的配置直接清除。若系统设置内开关也立即复位，应优先保留系统提示，而不是继续调整规则内容。

用最小改动区分配置与自动连接

暂时关闭 On Demand，并记录此前的条件。它可能在网络变化后重新发起连接，使“手动停止后又连接”看起来像开关失效。然后确认 Home 已选择一个参数完整的服务器，在 Config 中确认当前使用的配置能够正常读取。若故障紧接着编辑配置出现，先复制该文件，再恢复最近一次可用副本；不要把未经检查的大段配置覆盖到唯一副本中。规则、DNS 与改写内容都应分开恢复，才能确定是哪部分影响了连接。

退出当前操作流程后重新打开应用，再尝试一次；仍失败时，可在保存工作后重启设备，以排除暂时的系统网络扩展状态异常。重启不是服务器修复手段，如果每次都只能短暂恢复，应继续查找触发条件，例如从 Wi-Fi 切到蜂窝网络、锁屏后重新唤醒，或另一项 VPN 服务开始连接。每个条件分别测试，保留发生时间与现象，避免把几个不同问题混成一次故障。

确认恢复是否稳定

开关保持开启后，先访问一个平常可用的网站，再锁屏、解锁并重复访问。如果只看开关颜色而不发起真实请求，可能遗漏“会话已建立但业务不通”的问题。若开关稳定而网页打不开，转到下一章；若重新出现系统授权错误，保留提示并核对设备权限。需要重新获取应用时，按已购项目恢复说明操作；应用更新与恢复均通过 App Store，系统要求以 App Store 页面标注为准。

对外描述问题时，应写清“手动连接后立即停止”还是“网络切换后停止”，并附系统提示的文字摘要。配置名称、网络类型和是否启用 On Demand 有助于复现；服务器密码、订阅地址与身份凭据则不应放进公开截图。这份记录也是后续比较的基线：修复后回到同样网络和相同触发动作测试，才算完成验证。

显示已连接，但网页或应用无法上网

连接标志说明系统 VPN 会话已建立，不等于每个请求都能到达目标。一次访问还可能经过 DNS、规则匹配、服务器连接和目标站点响应。先暂时断开 Shadowrocket，测试同一网页：若断开后也失败，优先检查 Wi-Fi 登录认证、蜂窝网络权限、路由器和目标站点状态。公共 Wi-Fi 可能需要先完成系统认证页面；在基础网络尚未联网时，修改 PROXY 或 DIRECT 规则只会增加变量。

用 Global Routing 判断问题范围

记录原来的 Global Routing，再分别进行短时对照。配置对应 Config，按当前配置中的规则处理请求；代理对应 Proxy，通常用于把一般业务请求交给所选代理路径；直连对应 Direct，用于对照基础网络。它们是排查姿态，不是三个独立服务器。系统流量、配置中的特殊处理和具体功能仍可能影响结果，因此不要用一次对照推断所有请求的路径。每次切换后都应重新发起请求，而非只看已经缓存的页面。

如果 Proxy 可以访问而 Config 不行，打开当前实际启用的配置，核对目标域名会先命中哪条规则。常见情况是宽泛规则排在精确规则前面、策略指向已失效的名称，或 REJECT 规则覆盖了应用需要的资源。不要只搜索主页域名：一次打开应用还会请求认证、图片和接口等多个域名。结合请求记录核对具体失败项，比把所有流量永久改为 Proxy 更有助于定位原因。

按顺序阅读规则，而不是只找关键词

下面是说明匹配顺序的片段，不能直接代替用户的完整配置。规则通常自上而下匹配，先命中者决定处理；FINAL 负责此前未匹配的请求。示例中的私有网段仅用于说明局域网直连，实际还需核对本机网络和配置要求。涉及 IP 判断的规则与域名解析有关，不能把它们当作完全独立的设置。

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

如果 Config 和 Proxy 都失败，而 Direct 正常，先检查所选服务器与代理路径；如果只有一个网站失败，应继续区分目标服务异常、DNS 返回不合适、规则误匹配以及服务端拒绝访问。浏览器能打开也不能证明其他应用一定正常，它们可能使用不同域名、连接方式和缓存。用两个互不相关的网站及一个常用应用进行对照，可以避免把单个服务的问题误判成全局断网。

恢复原配置并验证实际请求

排查结束后恢复原先的 Global Routing，并只保留已经证实必要的规则修改。重新连接后发起新请求，确认网页正文和附属资源都能加载，再测试此前失败的具体操作，例如登录或图片上传。若仍有失败，记录域名、命中规则、策略及错误类型，按规则分流说明核对含义。不要同时加入大量例外规则；临时直连也应限定到已经确认的目标，防止改变其他请求的处理路径。

当现象表现为“域名打不开，但测试仍有结果”时，不要继续只改路由姿态，应进入DNS 问题一章。连接测试与真实网页访问覆盖的链路不同，一项测试成功只能证明它实际执行的那一部分成功。

节点超时、连接拒绝或协议握手失败

先保留错误类型，再检查服务器参数。超时通常表示在测试等待范围内没有获得预期响应，可能发生在基础网络、服务器端口、协议握手或目标请求阶段；连接拒绝通常更接近目标端口未接受连接；身份验证失败则应优先核对凭据。不同测试方式得到的结果不能直接互换。Connectivity Test 的结果应连同测试方式一起记录，不能把一个数字当作全部协议功能正常的证明。

先排除选错条目与地址错误

回到 Home 核对当前选中的服务器，而不只是最近点开的编辑页。订阅更新后可能出现名称相近的条目，旧条目也可能仍保存在列表中。进入对应编辑信息，逐项比较协议、服务器域名和端口，留意复制时带入的空格、全角符号，以及误把完整分享链接填进服务器地址栏。域名和端口承担不同作用，通常应按各自字段填写；不要凭名称中的地区或备注判断条目实际使用了哪个地址。

同一条目在 Wi-Fi 超时、在蜂窝网络正常，说明问题与接入网络或到服务器的路径有关，但还不能直接断言服务器完全正常。先确认两边基础网络都能访问普通网站，再在相近时间对照一次，避免把不同时段的负载变化混进结果。若所有已有条目在同一网络失败，而另一网络正常，应检查路由器限制、网络认证与 UDP 可用性；不应批量修改每个条目的密码来尝试碰运气。

按协议检查握手所需参数

对于使用 TLS 的配置，核对服务器提供的域名相关字段、设备时间和证书有效性。设备时间明显不正确会影响证书判断，应先恢复正确时间再测。不要把关闭证书验证作为常规修复方式，这会改变连接的身份校验边界。对于带传输层设置的协议，Host、Path 与 TLS 相关名称可能分别服务于不同层，不能因为内容相似就互相替换。字段含义见协议与填写项说明。

从分享链接导入后也要检查解析结果是否完整。如果原始信息缺少传输参数，单凭导入成功不能证明配置可用；应向原信息提供方核对，而不是按其他条目的设置猜填。手动修改订阅生成的条目前先复制一份，否则后续更新可能覆盖改动，使问题再次出现。记录修改依据，例如“与已有服务器说明核对后修正 Path”，比只记录“换了一个参数”更便于回溯。

用业务访问确认，不连续轰击测试

选择已核对参数的条目，进行一次测试并访问实际需要的网站。如果仍失败，保存错误摘要与网络条件，再隔一段时间复测；连续批量测试可能增加请求负担，也不利于观察偶发故障。仅某条服务器持续失败时，整理该条目的错误类型、发生时间和已做的对照，向你的服务商核实服务状态。提交前移除身份字段、密钥和完整订阅地址；排查需要的是现象与参数类别，不是公开凭据。

若握手成功但较大页面或上传任务失败，再转到速度章节检查持续传输、丢包与 MTU 相关边界，不要继续把所有问题都叫作节点超时。明确故障发生在哪一段，才能选择对应的修复步骤。

订阅更新失败、导入为空或条目重复

订阅处理至少包括取得地址、请求服务器、接收内容、解析格式和写入本地列表几个阶段。更新失败并不必然表示现有条目失效；旧条目可能仍能连接，失败的只是更新请求。先记录原有条目数量与名称范围，保存可恢复的副本，再执行一次更新并读取提示。订阅从你的服务商处获取；不要用来源不明的地址替换原订阅，也不要把用于鉴权的完整链接粘贴到公开讨论中。

确认导入内容与入口匹配

单节点分享链接、服务器列表订阅和完整配置文件不是同一种内容。前者描述一个条目，列表订阅用于持续获取一组条目，配置文件还可能包含规则与 DNS。把网页地址或配置文件地址填入不匹配的入口，可能得到“请求成功但没有可识别条目”的结果。先查看原提供方对格式和入口的说明，再按入门指南操作。需要区分分享链接结构时，可阅读分享链接与订阅链接的区别。

复制地址时注意是否只复制了可见标题、是否漏掉问号之后的参数，以及消息应用是否插入了换行。地址中的大小写和编码字符不应随意修改，尤其不要把半角符号替换为中文标点。若需要重新取得链接，应从原有服务商处获取并核对用途。订阅地址往往带有访问凭据，系统剪贴板、截图和浏览历史也可能保存它；诊断结束后应妥善清理不再需要的副本，而不是反复在不同应用间传播。

区分网络错误、响应错误与解析错误

请求超时应先检查订阅域名的解析与当前网络能否访问；证书错误应检查设备时间、域名与证书情况；明确的 HTTP 状态则提示响应已经到达一定阶段。401 或 403 常与身份、权限或访问限制有关，但具体原因仍需由服务端确认；404 可能表示路径改变或地址不完整；429 表示请求受到频率限制时，应停止连续刷新并按响应要求等待。不要通过重复点击掩盖最早出现的有效错误信息。

返回登录页、说明页或网络认证页面时，客户端可能收到了 HTML，而不是预期的订阅内容。这解释了为什么“能在浏览器打开”不等于“能作为订阅解析”。若原服务提供受保护的内容检查方式，应按其说明确认响应类型；不要把订阅凭据交给陌生的在线转换页面。某些订阅还有针对客户端格式的输出选项，应核对是否选择了 Shadowrocket 可识别的格式，而非仅凭地址后缀推断。

处理重复条目与更新后的变动

遇到重复条目时，先区分“同一订阅添加多次”和“服务端内容本身重名”。前者可在确认备份与归属后保留一个来源；后者应对照地址、端口和协议，不能只按名称删除。订阅更新还可能移除旧条目或修改名称，导致原选择发生变化。更新结束后回到 Home，确认当前选中项仍存在且参数完整，再发起真实访问。不要把“列表出现了新名称”直接当作更新完全正常的结论。

如果本地个别条目经过手动调整，更新前应复制为独立条目并标明用途。长期维护时，订阅生成内容与个人修订内容分开管理，可以减少覆盖造成的反复故障。若仅更新请求失败而旧条目可用，可暂时保留工作状态，记录错误与响应时间后向你的服务商核实。修复的验收标准应包括更新完成、条目可识别、当前选择正确及业务访问成功，而不只是错误提示消失。

连接可用，但速度慢或传输不稳定

先把“慢”改写成可重复的现象：首次打开等待很久、页面开始加载后持续缓慢、视频播放中断，还是上传大文件停住。首次等待更可能涉及解析与握手，持续传输则还受接入网络、服务器负载、目标服务、丢包和传输方式影响。低延迟不等于高吞吐量，短连接测试也不能预测长时间传输。不要仅凭某一次 Connectivity Test 的排序，认定某条服务器在所有业务中都更快。

建立相同条件下的对照

选一个内容和大小相对稳定的合法测试对象，在同一设备、同一接入网络与相近时段进行对照。暂停其他大流量任务，确认 Wi-Fi 信号和蜂窝数据状态，再分别测试基础网络与当前代理路径。记录开始等待、持续加载和是否中断三个维度，而不是只记一个平均数字。测试本身会消耗流量，也可能改变服务端负载，次数足以复现即可，不必持续运行大量并行任务。

如果所有网站都慢，先看接入网络和所选服务器；如果只有一个服务慢，应检查该服务的资源域名、分流路径和服务端响应。某些页面正文很快，图片或视频却慢，说明不同资源可能经过不同域名与路径。结合请求记录查找耗时部分，并在 Config 下核对规则；直接把整个配置替换成另一份复杂文件，会同时改变 DNS、规则和其他处理，反而失去可比较的基线。

检查握手、重复连接与传输边界

频繁断开重连会让 TLS 或其他协议握手反复发生，短请求尤其容易表现为加载迟缓。观察慢的同时是否伴随超时、连接关闭或网络切换；如果只在电梯、移动途中或弱信号 Wi-Fi 下发生，应先改善接入条件。若换到稳定网络后恢复，说明不应优先修改规则。对依赖 UDP 的传输，应核对当前网络是否支持所需通信方式，普通网页能打开并不能证明 UDP 路径质量良好。

较小页面正常而较大传输停顿，可能与丢包、路径 MTU 或服务端限制有关，但仅凭现象不能确认。不要随意在多个位置填写不同 MTU 值；只有当前协议明确提供相关设置、并有原服务器说明或可复现证据时，才在副本中调整一项并对照。对 WireGuard 等配置，还应核对允许的地址范围和实际路由。恢复默认或原始参数必须留有记录，避免临时试值长期遗留。

排除配置处理造成的额外等待

复杂规则、远程资源或请求改写可能增加处理环节，但不能因此把全部功能都判为故障。先复制当前配置，在副本中只停用最近新增的一组处理，测试同一业务；改善后再逐项缩小范围。涉及 HTTPS 检查或改写的设置会改变处理方式，应明确了解用途与证书边界后再操作，不要为追求速度扩大处理范围。完整配置的分段含义见配置文件分段说明。

还要检查规则是否把原本需要局域网访问的服务交给代理，或把依赖特定路径的资源送往直连。局域网打印、文件访问和普通网站的诊断不能混用。针对已经确认的目标修正规则后，应回到原 Global Routing 验证；永久停留在 Proxy 可能只是绕过了规则问题，并未真正修复配置。配置副本的作用是隔离变量，不是让多份未经整理的文件同时承担不同的隐含用途。

最终应使用真实任务验收，例如完成一次页面加载、连续播放一段内容或完成上传，并比较是否仍出现原来的停顿。若只有特定时段变慢，保留时段、接入网络和错误摘要，向你的服务商核实服务情况。不要把偶尔一次较快的结果当作修复完成，也不要把目标站点自身的限速归因于客户端设置。

DNS 解析失败与个别域名打不开

DNS 将域名转换为可连接的地址；服务器连接、规则判断和目标访问都可能依赖它。常见现象包括服务器域名无法解析、网页提示找不到地址、部分资源缺失，以及 Connectivity Test 有结果但实际网页打不开。先确定失败的是服务器域名还是目标网站域名，两者发生在不同阶段。前者可能让代理连接根本无法建立，后者则可能发生在已建立会话之后，不能用同一处设置一概处理。

先检查当前生效的解析来源

在 Config 中确认正在使用的文件，再查看其 [General] 段和相关 DNS 设置。系统 DNS、配置中的 DNS 与加密 DNS 设置可能共同影响不同请求；不能因为某一行写了 system，就推断所有解析都只走同一条路径。先记录原值，阅读该项在当前应用中的说明，再做单项对照。下面的片段只展示键值语法，不是适用于所有网络的推荐配置，也不应覆盖用户完整文件。

[General]
bypass-system = true
dns-server = system
ipv6 = false

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

如果问题出现在刚更换 DNS 之后，先在配置副本里恢复原来可用的设置，再重新连接并发起新请求。浏览器、系统和应用都可能缓存结果，因此旧页面继续失败或旧连接继续成功，都不一定代表修改没有生效。应关闭已有请求后重新访问，必要时重启受影响的应用；不要把清空全部设备设置当作清理缓存的常规步骤。每次只调整解析来源或一项相关选项，保留可回退路径。

区分超时、无记录与地址可达性

解析超时表示未及时得到响应，需检查 DNS 服务的访问路径；明确没有对应记录，则要核对域名拼写、记录类型与目标服务情况。解析已经返回地址，但连接该地址超时，问题可能转移到了路由或目标服务，并非继续更换 DNS 就能修好。使用加密 DNS 时，还要考虑其服务地址本身如何被解析、连接，以及是否需要先经过尚未建立的代理路径，避免形成启动依赖循环。

只在开启 IPv6 后出现问题时，检查当前网络是否具备可用的 IPv6 路径，以及目标返回地址与实际路由是否匹配。可以在副本中做一次关闭 IPv6 的对照，但不能据此得出所有网络都应关闭的结论；恢复后仍需测试实际服务。若网络依赖特定地址转换机制，直接访问数字地址或只测一种地址族可能产生误导。将现象写成“某网络下某地址族失败”，比笼统写“DNS 不好”更准确。

检查本地映射与规则的联动

[Host] 中的本地映射可能覆盖正常解析结果，旧地址失效后就会表现为只有特定域名持续打不开。搜索配置中该域名的映射和相关规则，确认不是历史测试留下的内容；删除前保存副本，并说明其原用途。域名规则与 IP 规则也有先后关系：有些 IP 判断需要先取得解析结果。如果域名已被前面的规则匹配，后面的 GEOIP 或 IP-CIDR 不会再作为同一请求的普通后续匹配继续执行。

不要把网站临时解析到的地址直接长期写进 [Host]。使用内容分发或动态地址的服务可能随网络与时间返回不同结果，固定地址可能破坏调度，甚至造成证书、资源或可达性问题。同样，直接用 IP 打开 HTTPS 网站不是可靠的等价测试，因为证书名称和服务端虚拟主机选择仍可能依赖域名。测试需要说明究竟验证了解析、端口连接还是完整业务访问。

修复后分别验证服务器域名、此前失败的网站及其附属资源，再恢复 Config 下的日常使用姿态。如果故障仅在一张 Wi-Fi 网络出现，还应检查路由器 DNS 和网络认证状态。更多定位示例见DNS 解析失败排查；记录中保留域名类别、解析错误与命中策略即可，不应公开完整请求地址中的敏感参数。

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

系统电池页面显示 Shadowrocket 有较多活动，不一定说明消耗都由客户端自身的某个功能产生。VPN 会承接其他应用的网络流量，系统统计还会受到前台使用、后台通信和连接时长影响。先比较相同设备、相近时段与类似任务，记录屏幕使用、接入网络、充电状态和正在传输的业务。把播放视频时的统计与静置时的统计直接比较，无法定位额外耗电来自哪里。

先建立可比较的观察窗口

在设备电量与温度相对稳定时，选择一段正常使用时段观察，再查看系统电池与流量统计。无需追求固定的耗电百分比，重点是同类任务之间是否出现明显变化。先暂停大文件同步、连续视频、热点共享等已知高流量任务，确认没有系统更新或照片处理等同时进行。观察时尽量保持相同网络；弱蜂窝信号引发的无线通信开销，可能比规则处理更值得优先检查。

如果连接开关频繁变化，或请求记录持续出现失败重试，应先修复连接问题。重连、重新解析和反复握手都会增加活动，表现为后台一直忙碌。检查是否有多个自动连接条件互相影响，On Demand 是否在网络切换后反复触发，以及设备是否长期停留在信号不稳定的 Wi-Fi 边缘。关闭自动连接做短时对照时，要记录原设置；完成诊断后按实际需求恢复，而不是遗忘在测试状态。

检查诊断任务与持续网络请求

批量 Connectivity Test、频繁订阅更新、详细请求记录和长时间调试都属于额外工作。排查结束后停止不再需要的测试，恢复正常的记录范围，再观察系统统计是否趋于稳定。不要同时运行多组测试来验证耗电，这会让诊断过程本身成为负载来源。日志保留应以定位所需为限，较长记录还可能包含访问域名和请求信息，导出与分享前需要检查敏感内容。

如果设备静置时仍持续有流量，先确定是不是其他应用在后台同步。可在系统允许的设置范围内逐项暂停相关后台任务，再比较流量变化；不要未经确认就批量关闭全部应用权限。若只有某个应用打开后开始持续重试，查看其失败资源及规则路径，结合无法上网和 DNS 章节定位。解决请求失败比单纯限制客户端后台活动更接近根因，否则相关应用仍可能不断重新发起请求。

用配置副本隔离额外处理

故障紧接着新增配置内容出现时，复制当前文件，在副本中只撤回最近的一组变更，例如新增改写或更复杂的请求处理。保持同一服务器、同一 Global Routing 与同样业务，比较发热和活动现象。若同时换服务器、DNS 与配置，结果即使改善也无法知道原因。配置是否复杂不能仅靠行数判断，应看哪些处理实际命中了当前流量，以及它们是否持续触发新的请求或失败重试。

对于特定协议，不应仅凭名称推断它一定更省电或更耗电。接入网络质量、重传、连接数量和业务类型都会改变结果。若需要比较用户已有的不同条目，应在同一任务中逐个测试，并确认它们都能稳定完成请求；一条不断失败的连接与另一条正常连接之间的耗电差异，首先反映的是可用性差异，而非协议本身的固定结论。

验收时回到日常使用条件，观察是否仍出现同样的异常后台活动，并确认停止临时记录后网络功能保持正常。向服务支持描述问题时，提供系统电池页面的时间范围、主要使用任务、是否充电、网络类型与重连现象。不要只提交一张百分比截图；缺少使用条件的统计不能可靠区分客户端处理、其他应用流量和无线网络开销。

更新后异常与 iPad 专项排查

更新后第一次发现故障，说明问题与更新时间接近，但不自动证明更新是唯一原因。应用、系统、订阅内容和接入网络可能在同一时段变化。先记录实际发生的变更：应用是否刚更新、系统是否重启、订阅是否自动刷新、配置是否被替换，再重现同一个失败动作。更新记录与系统要求以 App Store 页面标注为准，不凭印象猜测某个具体版本引入了什么行为。

保留旧配置，检查当前选择

先复制当前配置和必要的个人条目信息，妥善保管其中的凭据。回到 Home 检查当前服务器，进入 Config 确认启用文件，再核对 Global Routing 与 On Demand；列表存在不代表当前选择与之前一致。订阅更新造成的条目更名、移除或参数变化，常与应用更新恰好同时发生。将本地副本与当前内容按段比较，比直接重置全部设置更容易发现真正的差异。

如果异常只在旧配置出现，使用副本撤回最近变更，或以已经验证过的最小内容逐步恢复。读取配置时出现明确错误，应先修正对应行的语法、分段和策略引用，不要忽略提示继续叠加其他配置。查看应用内说明时保留英文设置词，避免因中文转述而找错选项。配置恢复后还需重新验证真实请求；能够打开 Config 页面并不等于每个字段都适合当前网络。

区分同一购买记录与同一网络配置

iPad 使用购买时的 Apple ID 在 App Store 查询已购状态，相关恢复步骤见iPad 获取说明与已购项目恢复。购买记录决定应用获取资格，不应假定它会自动恢复所有本地服务器、订阅与配置。若应用提供导入或同步入口，应确认来源、内容和当前生效文件；不要因为设备上已经显示应用名称，就判断两台设备的网络设置完全相同。

比较 iPhone 与 iPad 时，应先让两台设备使用同一 Wi-Fi、同一已有服务器和等价配置，再访问同一目标。如果一台走蜂窝网络、另一台走 Wi-Fi，结果首先包含了网络路径差异。还要核对 iPad 是否连接键盘、扩展坞或以太网配件，以及系统是否使用了不同网络服务。配件改变接入路径后，DNS、局域网访问和 On Demand 条件都可能与原 Wi-Fi 环境不同。

检查分栏操作、休眠与局域网访问

iPad 的分栏或较宽布局可能同时显示列表与详情。编辑某个文件并不一定等于已经将它设为当前配置，查看某个服务器也不等于连接选中了它；操作后回到 Home 和 Config 再核对实际选择。使用多任务切换时，还应区分“应用窗口重新显示”与“连接重新建立”，连接状态应以实际开关、系统状态和请求结果共同判断，而不是依据窗口是否仍在前台。

如果只有休眠唤醒后失败，记录唤醒前后的网络、是否经过登录认证以及 On Demand 状态。先用手动连接测试恢复，再观察自动连接是否在同样条件下触发。局域网文件、打印或设备发现失败时，检查系统对相应访问的授权，以及目标是否仍在同一网段；部分发现机制依赖组播，普通网站访问成功不能证明局域网发现正常。不要为解决一个局域网目标而删除全部分流规则。

重新安装应留在已经备份、完成配置对照且确有必要之后。它可能清除本地内容，但不会替你修复服务器端参数或订阅权限。需要获取应用时仅通过 App Store，正版核验可对照开发者 Shadow Launch Technology Limited、官方图标和应用 ID 932747118。完成处理后，分别测试手动连接、锁屏唤醒、网络切换和此前失败的具体任务；将有效步骤记录为简短结论，保留其他设置原状，后续才有可靠的复现基线。