Shadowrocket
故障排查大全

先区分“开关立即回落”和“开关保持开启但请求失败”。前者优先检查 VPN 配置与系统管理限制，后者转到下一章，不要反复删除应用。

建立能重复验证的起点

关闭 Shadowrocket 的连接开关，暂时停用其他会接管网络的 VPN 配置，再用浏览器打开原本可以直接访问的网页。公共无线网络可能要求先完成网页登录，只有看到无线网络图标并不代表已经获得互联网连接。如果原始网络本身不能访问，先完成认证、重新连接网络或联系网络管理员；此时更换服务器、修改规则都不能解决底层连接问题。记录正在使用无线网络还是蜂窝网络，并记下故障出现前是否更换网络、恢复配置或修改系统设置。

准备一个最小记录：设备类型、网络类型、开关能否保持、失败发生的具体动作，以及出现的错误原文。不要只记录“不能用”，因为导入失败、连接失败和网页失败对应不同路径。测试期间固定一个已知服务器与一个目标网页，关闭不必要的下载任务。若同时更换服务器、配置和网络，即使恢复也无法判断是哪一步产生作用，下次出现同类情况仍需从头尝试。

重新确认 VPN 配置授权

在 iPhone 或 iPad 首次启用连接时，系统会请求添加 VPN 配置，应由设备使用者阅读提示并确认授权。若此前取消过，回到 Shadowrocket 再次开启并观察是否出现系统对话框。随后在系统 Settings 中查找 VPN 配置，确认列表里存在对应项目。不同系统版本的设置路径可能不同，可使用设置搜索；不要凭旧教程里的层级名称判断配置一定不存在。若设备受单位或学校管理，配置描述文件可能限制添加 VPN，需要管理员确认权限，不能通过反复重装绕过管理策略。

如果授权后开关仍立即回落，先重启设备再复测。只有确认某个旧 VPN 项目属于 Shadowrocket、并已备份应用内资料时，才考虑移除该系统配置，再由应用重新申请创建。系统中的 VPN 配置和应用里的服务器、Subscribe、Config 不是同一层内容，删除其中一项不等于其他资料已经备份。不要一次移除所有描述文件，也不要删除用途不明的证书与设备管理项目。

排除自动触发与连接冲突

检查 On Demand 是否正在按网络条件自动连接或断开。为避免自动策略干扰，先记下原来的条件，临时停止自动触发，仅用手动开关测试。若手动连接正常，再逐条恢复原条件，查看问题是否只在某个无线网络名称或网络切换时出现。系统可能同时保存多个 VPN 项目，应确认当前实际启用的是哪一个；不要把状态栏里的连接标识直接当成 Shadowrocket 已正常接管请求的证据。

如果应用本身无法打开、启动后立即退出，应先保存能够导出的配置，检查设备剩余空间，并通过 客户端下载页核对获取路径。iPhone / iPad 版从 App Store 获取，系统要求以 App Store 页面标注为准。Mac、Windows、安卓、Linux 的安装与系统放行步骤也集中在下载页，不要在连接故障阶段随意替换来源不明的安装文件。应用能稳定打开且开关能够保持后，再进入网络层检查。

先比较 Direct 与 Proxy 的结果，再判断是否只有 Config 失败。连接标识只说明系统存在 VPN 会话，不代表每个目标请求都能完成。

用三种姿态缩小故障范围

保留当前 Config 的副本，选中一个用户已有、参数可以核对的服务器。在 Global Routing 中依次测试配置姿态 Config、代理姿态 Proxy、直连姿态 Direct，每次切换后重新发起同一个网页请求。Direct 用于观察不经过所选代理服务器时的访问结果，Proxy 用于检查该服务器处理请求的情况，Config 则将规则判断加入链路。这里的对照是诊断手段，不是要求长期固定某一种姿态；测试结束应恢复符合实际需求的设置。

如果 Direct 正常而 Proxy 失败，优先检查服务器状态、协议参数和远端连接能力。如果 Proxy 正常而 Config 失败，优先检查配置是否启用、规则顺序和策略指向。如果三种姿态都失败，先确认目标网页自身是否可用，再检查原始网络与 DNS。部分应用会复用已有连接，所以切换后应关闭旧页面并重新打开；必要时结束该应用的当前会话再测试，避免旧连接让结果看起来与当前姿态不一致。

检查当前配置，而不是只看配置列表

在 Config 中确认真正启用的是哪份配置。列表里存在文件不等于该文件正在使用；从订阅导入服务器也不等于已经切换到期望的规则配置。打开当前文件检查 Rule 部分，按从上到下的顺序阅读。通常首条匹配的规则决定请求走向，因此一条较宽的规则放在前面，可能使后面的精确规则没有机会生效。修改前复制文件，并给副本使用能够辨认的名称，避免把原配置与测试配置混在一起。

下面的片段仅用于理解匹配顺序：指定域名先交给 PROXY，局域网地址走 DIRECT，其余请求由 FINAL 处理。PROXY 所对应的实际服务器或策略仍需在当前环境中有效；片段本身不会创建服务器。GEOIP 的判断还依赖地址与相关数据，不能据此推断一个域名在所有网络中都会得到相同结果。不要把示例直接覆盖到包含必要本地规则的完整配置里。

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

只在部分网页失败时查命中记录

若多数网页正常，只有某个域名或某个应用失败，应查看对应请求实际命中的规则、最终策略及错误信息。一个页面可能同时请求主域名、图片域名和接口域名，首页文字能出现而图片一直加载，通常不能概括成“整个连接断开”。先确定失败的是哪一个域名，再决定是否需要调整单条规则。遇到 REJECT 命中时，应核实规则意图，而不是直接删除所有拒绝规则；原配置可能用于阻止特定类型请求。

对于局域网设备、打印机和内部网页，先确认目标地址属于当前所在网络，并检查是否被送往远端代理。无线网络中的设备隔离也可能阻止互访，这不是添加一条 DIRECT 就一定能改变的限制。若只有某个应用报告网络错误，还需检查其系统网络权限与自身服务状态。恢复后用相同目标再测试一次 Config，并撤销仅为诊断而添加的临时规则，保留最终有必要的最小修改。

超时只说明某项测试没有在等待时间内完成。它可能发生在地址解析、传输连接、协议握手或远端请求阶段，应先看测试类型与错误原文。

先判断是单个服务器还是全部服务器

在 Home 对已有服务器执行 Connectivity Test，记录哪些项目失败，再选其中一个进行实际网页访问。测试方法不同，探测的环节也不同：端口能够建立连接，不等于认证信息正确；一次网页测试成功，也不能保证所有目标请求都正常。如果只有一个项目失败，优先核对该服务器参数与远端状态；如果所有项目同时失败，先检查当前网络、域名解析、设备时间及共同使用的传输设置，不要逐个重建全部服务器。

在条件允许时，用同一设备切换到另一种已知可用网络，保持服务器与测试目标不变。如果结果随网络变化，说明问题更可能位于本地网络到服务器的路径，或当前网络对相应传输方式的处理。不要因某次切换成功就认定配置完全正确，仍需记录原网络是否需要认证、是否经过路由器过滤，以及失败是否只出现在网络繁忙时段。可重复的差异比偶然成功更有诊断价值。

逐字段对照已有配置

打开 Add Server 对应的编辑页面，从用户已有服务器资料逐项核对协议类型、地址、端口和认证内容。服务器地址应填写主机名或地址字段要求的内容，不要把网页链接的路径一并粘入；端口必须与服务端监听一致。密码、UUID、密钥和其他认证字段属于不同协议的参数，不能相互替代。复制粘贴后留意首尾空格、换行和全角标点，尤其是从聊天记录或文档中复制时，视觉相似的字符也可能导致握手失败。

对 VMess、VLESS、Trojan 等配置，应根据实际服务端要求检查 TLS、传输方式及相关字段，并非所有配置都需要相同选项。使用 WebSocket 时，路径和 Host 要与服务端约定一致，路径中的大小写与前导斜杠也应保留。使用 Hysteria2 或 WireGuard 时，还要考虑当前网络对 UDP 的处理；某个 TCP 探测有结果，不能用来证明 UDP 数据传输同样通畅。具体字段不明确时应向原配置提供方核实，不凭经验填入其他服务器的参数。

检查系统时间与握手边界

系统日期和时区异常可能影响证书有效期判断，也会干扰依赖时间的认证流程。在系统中开启自动设置日期与时间，确认显示正确后重新连接。遇到证书名称不匹配或证书过期错误时，核实服务器名称、SNI 和远端证书，而不是关闭验证来掩盖问题。地址可连接但握手持续失败，往往比单纯超时提供更多线索，应完整记录错误中提到的是证书、认证还是传输响应。

完成本地核对后，若一个服务器仍在多个正常网络中稳定失败，可以将协议类型、出错阶段、测试时间段和脱敏后的错误提交给用户原有服务商，请其检查监听、认证与服务状态。不要公开密码、UUID、完整订阅地址或配置二维码。有关更细的测试顺序，可继续阅读 节点超时、协议参数与系统时间排查。确认某项修改有效后再保存，避免将失败尝试长期留在配置中。

订阅更新分为请求地址、取得内容、识别格式和更新列表几个阶段。更新成功不等于服务器可用，服务器连接失败也不等于订阅地址失效。

确认地址完整且仍有访问权限

从用户已有服务商的管理页面重新复制订阅地址，核对是否遗漏查询参数、被聊天软件截断，或在首尾混入空格。地址中的令牌通常相当于访问凭据，不应出现在公开截图、工单标题或网页评论里。若曾重置订阅地址，旧地址可能不再有效；此时应替换为本人账户当前提供的地址，而不是重复更新旧项目。复制后先在应用中检查字段内容，不要把含有私人令牌的地址发送到在线转换或检测网页。

请求出现未授权或禁止访问的响应时，应检查账户登录状态、访问权限与订阅是否被重新生成；提示找不到资源时，应核对路径是否完整。响应状态只能提供方向，最终含义以用户已有服务商的说明为准。若地址由临时跳转生成，复制到的可能是登录页而非订阅内容。不要只因为浏览器可以打开一个页面，就断定该地址一定能被 Subscribe 识别，浏览器会话与应用请求所携带的状态可能不同。

下载不到内容时检查访问路径

如果更新一直等待或报告网络错误，先检查订阅域名能否解析，以及当前 Global Routing 会让该请求走哪条路径。某些情况下，更新请求需要经过一个已可用服务器，而当前列表恰好全部失效，就可能形成“需要更新才能连接、需要连接才能更新”的循环。处理前保留旧列表，选择用户已有且确认可用的连接方式，或在能够直接访问该订阅地址的网络下更新。不要为了打破循环随意导入不明配置。

同时检查设备时间与 HTTPS 证书错误。若只在公共无线网络失败，先关闭连接完成网络认证，再重新获取；如果网络返回的是认证网页，应用拿到的并不是订阅内容。可以记录响应是否为空、是否重定向、是否返回网页文字，但不要把完整响应原样公开，因为其中可能包含服务器地址与认证信息。网络路径恢复后重新更新一次即可，连续快速点击不会修复远端权限或内容问题，反而容易让观察结果混杂。

有内容却无法识别时检查格式

导入对象可能是服务器订阅、单条分享信息或完整配置文件，三者用途不同。应使用与内容类型匹配的导入入口，并以服务商提供给 Shadowrocket 的格式为准。若返回内容是登录页面、账户通知、错误说明或其他不被当前入口识别的文本，即使下载完成也会导入失败。不要手动删除看起来不懂的前缀或随意改变编码来“修复”内容，这可能破坏原本正确的认证参数，且使后续排查失去原始依据。

如果更新后只出现部分服务器，先确认原订阅是否本来就只包含这些项目，再检查是否存在不受当前配置识别的字段或筛选条件。导入后的名称相同并不保证参数完全相同，尤其是在手动项目与订阅项目并存时，应确认当前选中的确实是刚更新的条目。修改订阅生成的服务器前先复制为单独测试项，因为后续更新可能重新覆盖手动更改；不要把临时改动误认为已经同步到远端。

更新成功后仍应选择一个服务器进行 Connectivity Test，再用实际网页验证。若获取与识别均正常，只是所有服务器连接失败，排查重点应回到协议参数或远端服务，而不是继续更换订阅入口。客户端一次性买断 ≠ 线路套餐；客户端的获取费用与用户已有服务的权限是不同事项。iPhone / iPad 版 App Store $2.99 一次性付费，Mac / Windows / 安卓 / Linux 版免费，购买客户端不会自动产生可导入的订阅内容。

延迟、网页首开时间和持续下载速度是不同指标。不要仅按一个延迟数值判断速度，也不要在多个变量同时变化时比较结果。

把“慢”拆成可观察的阶段

先描述具体表现：是输入网址后长时间空白、页面文字已出现但图片慢、下载开始正常后持续下降，还是锁屏或切换网络后断流。首次打开慢可能涉及 DNS、连接建立与 TLS 握手；持续传输慢更可能涉及带宽、丢包、远端负载和目标服务。只在一个应用或一个网站出现的慢，应先与其他目标比较，避免把目标服务限速、账号限制或页面资源问题都归因于 Shadowrocket。

固定设备、网络、服务器、Global Routing 与测试文件，关闭其他设备或应用的大流量任务，再做少量重复测试。比较直连和代理路径时，要选择两条路径都能够正常访问的目标，否则失败结果没有速度比较意义。记录大致时间段与表现，不要用一次测试结果概括全天状况；无线干扰、家庭网络占用与远端繁忙都可能随时间变化。测试目的在于定位瓶颈，不是制造看起来更好的单次数值。

按本地网络、传输路径、远端目标检查

先关闭连接验证本地网络的稳定性，在无线信号较好的位置复测，避免隔墙、拥挤信道或路由器负载带来的影响。如果同一设备直连也明显变慢，应先处理本地网络。若只有代理路径慢，再比较用户已有的其他服务器，保持目标不变；多个服务器都在同一目标上变慢时，还应考虑该目标自身限制。手机发热、低电量模式、后台大规模同步也会影响整体体验，应在相近设备状态下进行对照。

低延迟不等于高吞吐量。短探测只交换少量数据，可能无法体现长时间传输中的拥塞和重传；相反，距离较远的服务器虽然握手等待更长，持续传输未必更差。不要为了追求最低测试值频繁切换，导致应用连接不断重建。对于视频、实时通话和文件下载，应分别观察缓冲、连续性与实际传输表现，不把某一类业务的结果直接套用到所有用途。

按断流发生条件检查

如果只在从无线网络切换到蜂窝网络时断开，旧连接可能无法继续沿用，新请求需要重新建立。先等待连接恢复，再重新打开目标页面；若每次切换都不能恢复，记录开关状态、On Demand 条件和服务器连接错误，转到对应章节检查。若断流与固定的无线网络有关，核实该网络是否会定期重新认证、进入省电或限制长连接。不能仅凭“过一会儿就断”推断密码错误，因为认证错误通常在连接建立阶段便会出现。

若小请求正常、大文件或某些页面始终卡住，可以进一步检查丢包、传输方式与路径中的分片问题，但不要直接套用网上的固定 MTU 数值。不同网络、协议与隧道封装的开销不同，不合适的调整可能使原本正常的流量也受影响。只有在记录到稳定复现条件、保存默认值并理解相关设置用途后，才做单项对照；调整未改善就恢复，避免留下无法解释的长期参数。

用规则记录解释“有些内容慢”

在 Config 姿态下，页面主文档、图片与接口可能分别命中不同策略，因此应查看慢请求的域名与最终路径。若只有某条规则对应的策略慢，先确认其指向的服务器是否仍然有效，而不是直接将全部请求改为 Proxy。连接记录中持续重复的失败、重试和重新解析，往往比单次测速更能解释体感延迟。完成诊断后停止不必要的压力测试，恢复日常配置；同时运行多个测速任务会占用带宽，也会让后面的观察失真。

DNS 故障不只是“有没有返回地址”。需要同时检查谁发起查询、使用哪个解析路径、返回哪些地址，以及连接最终选择了哪一个地址。

先辨认解析失败的证据

当浏览器报告无法找到服务器，或连接记录显示域名解析失败时，先确认域名拼写、原始网络和当前配置中的 DNS 设置。若多个无关域名同时失败，优先检查解析器可达性；若只有一个域名失败，应考虑域名本身的记录、缓存与该域名对应的规则。通过地址可以连通而通过域名失败是线索，但不是完整结论：HTTPS 服务通常依赖正确的主机名与证书，直接在浏览器输入地址可能出现不同结果，不能据此简单判定服务器正常或异常。

检查 Config 中是否存在自行添加的 DNS 项目、静态映射或针对某些域名的特殊处理。先保存副本，再与原始配置对照；不明白用途的设置不要一次全部替换。系统层的 DNS 描述文件、路由器设置和应用自己的解析路径也可能同时存在，实际由谁处理某个查询需要通过记录确认。仅看到系统里填写了某个解析器，不能推断所有代理请求一定使用它；同样，应用内设置也不必然覆盖设备上每一种请求。

防止解析与连接相互依赖

若解析服务本身使用域名，而访问它又依赖尚未建立的代理路径，可能出现启动阶段的依赖循环。先确认服务器地址如何解析，再确认解析器本身如何被访问，最后检查目标域名的查询路径。排查时可回到已知可用的基础设置验证，不要同时叠加多个加密解析选项和复杂分流。任何解析器都有自己的网络可达条件，添加更多地址不一定提高可靠性，也可能使失败表现变得随机。

如果使用加密 DNS，应核对协议、地址格式、端口与证书名称是否符合配置要求，并确认当前网络能够到达相应服务。看到 HTTPS 可以访问普通网页，不能证明特定解析端点一定可用。若请求需要代理，所指向的策略也必须已经有效；若走直连，应验证直连路径。不要通过关闭证书验证来应付时间错误或名称不匹配，先修正设备时间与地址，再重新观察失败是否消失。

区分地址族、规则与缓存

同一域名可能同时返回 IPv4 与 IPv6 地址。如果其中一种地址族的路径异常，表现可能是首次等待很久、某些请求失败而另一些成功。应查看实际选用的地址及错误，确认是解析阶段失败还是连接阶段失败，不要一遇到问题就永久关闭 IPv6。规则中的 IP-CIDR 与 IP-CIDR6 对应不同地址族；依赖地址判断的规则也可能因解析结果不同而改变命中情况，单独检查域名规则通常不足以解释全部路径。

修改 DNS 或规则后，旧缓存与复用连接可能继续影响结果。先重新发起请求，必要时重新连接 VPN 或重启正在测试的应用，再比较记录；不要在缓存尚未变化时连续改动多组设置。局域网里的内部域名可能只能由所在网络的解析器识别，强行交给外部解析路径反而会失败。对于家庭或办公内部服务，应同时检查域名解析和局域网路由，确保解析到的内部地址确实从当前网络访问。

最终验证应包括一个普通网页、一个此前异常的域名和一个需要访问的内部服务。每个目标记录解析是否成功、最终策略和访问结果。确认恢复后清理仅用于测试的静态映射与临时规则，避免地址变化后再次失效。有关 DOMAIN-SUFFIX、IP-CIDR 和 FINAL 的设置关系，可结合 设置说明查看；若只希望确认常见错误含义，可查阅 疑难解答。

先看同一时段的屏幕使用、网络活动和连接错误，再判断耗电来源。系统电池页面中的归因不能直接等同于客户端额外消耗的全部电量。

选择可比较的观察时段

在系统电池使用页面查看异常发生的时间段，区分屏幕开启时的高负载与待机时的持续活动。视频播放、文件下载、照片同步和应用更新都会产生流量，经过 VPN 的网络工作也可能影响系统对活动的归因。不要只看某个百分比就下结论：该比例可能表示所选时段内的相对占比，而不是设备总电量减少了相同数值。记录设备是否发热、信号强度和实际使用内容，才能建立有意义的对照。

做对照时尽量保持亮度、网络、应用使用和时长接近，分别观察连接开启与关闭的表现。不要把一次空闲待机与一次长时间视频会话相比，也不要为了测试持续点亮屏幕或反复测速。蜂窝信号较弱、无线网络频繁掉线以及设备正在处理大量后台任务，都可能显著增加消耗。若关闭连接后异常仍持续，应扩大到系统与其他应用层面检查，而不是继续修改规则。

先查重复失败，再查设置复杂度

查看是否存在同一域名持续失败、服务器反复重连或订阅不断更新的情况。短时间大量重试可能同时消耗网络与处理资源，应该先解决引发重试的根本原因：例如服务器认证失效、DNS 请求无法完成、某个应用始终访问被拒绝的地址。不能只通过隐藏记录来处理，因为记录消失不代表重试停止。可暂时关闭正在大量请求的应用，再看连接活动是否明显减少，以确认流量来源。

核对是否开启了不必要的频繁测试、过密的自动更新或额外诊断记录。测试周期和记录选项应按实际需求设置，不存在适用于所有设备的固定最佳数值。排查结束后关闭为定位故障临时开启的详细记录，避免长期积累数据与增加处理工作；必要信息导出后妥善保存，并删除含有私人地址的临时文件。若设备空间不足，还应处理系统存储问题，不能将应用反应迟缓一概视为网络耗电。

按网络条件检查 On Demand

On Demand 用于按条件触发连接，设置不当时可能在网络变化或条件交替满足时反复动作。先记下每条条件的对象、顺序和动作，再临时停止自动触发，用手动连接观察一段相近的使用过程。如果手动状态稳定，而恢复某条条件后频繁重连，应重点检查该条件是否与其他条件重叠，或是否依赖一个经常变化的网络状态。不要同时新增和删除多条条件，否则很难确定真正产生影响的那一条。

需要长期保持连接时，应先确保所选服务器在日常网络中稳定，而不是用自动触发不断补救一个持续失败的连接。回家、离开办公网络和无线转蜂窝是适合重点观察的场景，记录每次切换后开关是否保持、请求是否恢复，以及是否出现循环重试。对于受管理设备或网络，还应考虑系统策略造成的断开与重新建立，不能把所有自动变化都归因于应用内设置。

确定停止排查与恢复原状的条件

如果暂停异常应用请求、修正服务器错误或调整一条自动条件后，设备温度与待机表现恢复，应再用同样条件复测，确认改善可以重复。若消耗仍明显异常，可重启设备并检查系统正在进行的后台处理；重启后立即测试的短时波动不应当作长期结论。充电时发热也可能来自系统充电与任务调度，应与未充电、相似使用强度的状态分开记录。

排查结束应恢复必要的规则与连接策略，撤销临时的全量代理、详细诊断和高频测试。保留简短结论即可：异常时段、相关请求、有效修改和复测结果。没有可重复证据时，不建议清空全部配置或恢复整台设备设置；这些操作成本高，也可能清除有助于定位问题的信息。若需要进一步咨询，可使用下一章的脱敏记录清单说明问题，而不是发送包含完整订阅的备份。

更新后先核对仍在使用的服务器、Config 与系统权限；iPad 与其他设备结果不同，应比较网络和参数，不要假定同一账户下的设备状态完全一致。

更新前后对照，不急于重装

在调整前导出能够保存的服务器与配置资料，确认备份文件确实能够辨认用途，并保留当前配置副本。备份可能包含敏感内容，应保存在本人控制的位置，不公开上传。更新后先检查选中的服务器有没有变化、Global Routing 是否符合预期、当前 Config 是否仍是原文件，以及系统 VPN 配置是否存在。不要把更新与订阅自动变化混为一谈：两者可能恰好发生在相近时段，应分别检查。

如果旧配置在更新后异常，先使用用户已有且参数明确的一项服务器进行最小连接测试。最小测试成功说明基础连接仍有工作条件，再逐项恢复原配置的规则、DNS 与自动触发设置；若最小测试也失败，则回到系统权限、原始网络和协议参数检查。不要为验证一份复杂配置而连续覆盖多个文件，应始终留下能回退的原件，并明确记录当前正在测试的文件名称。

核对获取路径与首次打开放行

iPhone / iPad 版通过 App Store 更新与重新获取，核对开发者 Shadow Launch Technology Limited、官方图标和应用 ID 932747118。系统要求以 App Store 页面标注为准；重装前确认资料已备份。iPhone / iPad 版 App Store $2.99 一次性付费，Mac / Windows / 安卓 / Linux 版免费。已购恢复与账户地区问题请阅读 重新获取说明，不要把客户端获取状态与已有订阅的访问权限混淆。

其他平台安装包由下载页通过本站 /dl/shadowrocket/ 路径提供。Mac 需在“关于本机”确认 Apple 芯片或 Intel，再选择对应安装包；首次出现无法验证开发者提示时，在系统隐私与安全性中核对后选择“仍要打开”。Windows 遇到 SmartScreen，可在核对本站获取路径后查看“更多信息”与“仍要运行”；受管理设备应遵守组织策略。安卓按系统提示允许所用浏览器安装未知应用，完成后可收回该权限。详细步骤见 安装放行表。

iPad 专项：比较网络、配置和使用场景

同一份订阅在 iPhone 正常、iPad 异常时，先确认两台设备真的连接同一个网络，而不是一台使用蜂窝网络、另一台使用无线网络。公共网络可能对每台设备分别认证，手机已认证不代表平板也已完成。对照选中的服务器、协议字段、Global Routing 和当前 Config，确认不是一台保留旧列表而另一台已经更新。设备之间能够同步某些资料，不代表所有本地设置与系统权限始终一致。

只有无线网络功能的 iPad 无法直接通过蜂窝网络做对照，可在条件允许时连接另一个已知可用的无线网络，或使用本人设备提供的热点。保持服务器与目标网页不变，观察问题是否随网络变化。如果使用分屏，一侧应用正常并不能证明另一侧应用请求相同域名或采用相同连接路径；应分别记录实际目标。连接到内部网页或打印机时，还要确认所在无线网络允许设备互访，而不是将局域网隔离误判为规则错误。

若只在锁屏后、长时间闲置后或重新唤醒时失败，先查看开关是否仍保持、网络是否重新认证，以及 On Demand 是否在唤醒后重新触发。重新发起一个新请求再判断，不要仅根据旧页面上停留的加载提示下结论。若需要重建 VPN 配置，先完成备份并仅处理用途明确的项目。iPad 并不需要一套另行猜测的协议参数，同一服务器仍应与原服务资料一致，差异应从设备网络与本地状态中逐步寻找。

整理能用于复现的脱敏记录

仍未解决时，整理设备与系统类型、网络类型、开关状态、Global Routing、故障动作、错误原文，以及已经测试的对照结果。说明“何时开始、哪些目标受影响、关闭连接后是否恢复”，比只说更新后不能用更有帮助。截图应遮住订阅令牌、认证字段、二维码和不准备公开的服务器地址；也不要直接发送完整备份。完成恢复后，按 快速上手教程重新执行导入、连接与验证，并将本次有效步骤留作下次查阅依据。