OFFICIAL MANUAL / DIAGNOSTICS

Shadowrocket
故障排查大全

按症状定位连接、订阅与配置问题。每次只改一个变量，保留原始配置，再用相同条件验证结果。

本页是官方手册的系统查阅部分。首次导入已有订阅、选择 Global Routing 和连接的连续步骤，见使用教程；已完成设置但出现异常时，再按下方目录选择对应章节。

01 / CONNECTION SWITCH

连接开关打不开或立即关闭

开关无法保持开启，与开关开启后网页打不开，是两个不同问题。前者优先检查系统是否允许建立 VPN 配置、是否有其他连接配置占用，以及当前配置能否正常载入；此时反复修改 DNS 或规则通常不能提供有效线索。先记下开关回落发生在授权前、授权后，还是连接数秒之后，后续处理要以这个时间点为分支。

先区分授权失败与连接失败

首次启用连接时，系统可能要求允许添加 VPN 配置，并使用设备认证确认。这是系统授权流程，不是订阅认证。应阅读弹窗所指向的应用，再在确定来源后完成授权。若此前取消了弹窗，可以返回 Home 再尝试启用；若设备显示限制提示，应检查设备管理政策，不要通过反复点按开关来绕过限制。

先关闭 Shadowrocket 的连接，再进入系统 Settings，查看 VPN 相关项目是否已有正在连接的其他配置。
暂时停止其他由用户自行启用的 VPN 连接或自动连接功能，返回 Shadowrocket，只测试一次开启。
若仍立即关闭，确认 Home 已选择一个实际存在的服务器，并检查 Config 中当前配置是否可读取。
记录系统提示和应用内错误，再决定是处理权限、恢复配置，还是继续检查服务器参数。

设备上存在多个 VPN 配置，不等于它们必须全部删除。需要隔离的是同时工作的连接或自动重连行为。公司或学校管理的配置可能受策略保护，删除还可能影响正常访问；这类情况应先确认管理要求。若一个连接停止后另一个立刻恢复，优先检查双方的 On Demand 或系统自动连接设置，而不是判断应用开关失灵。

用最小变更确认配置能否启动

如果异常始于导入配置之后，先保留原文件，再切回之前已验证能启动的配置。不要同时换服务器、换网络、改规则和重建 VPN，否则恢复后无法知道究竟是哪一项起作用。配置载入错误可能来自段落标题、选项拼写、策略引用或文件内容不完整；应读取实际报错位置，不要把所有启动失败都归因于服务器不可达。

当开关能保持开启但连接没有流量时，应转到下一章；当开关保持开启而测试服务器超时，应转到节点超时章节。开关颜色或系统连接标识只能说明连接状态的一个侧面，不能代替真实请求验证。测试时选择一个固定网页，先观察是否能建立连接，再观察应用内是否产生对应的请求记录，避免只看图标下结论。

若修改配置后问题仍存在，可以先正常重启设备，再复现一次。重启能清理临时运行状态，但不会修正错误密码或服务器参数。只有在确认本地信息已备份、账号恢复条件清楚，而且普通重启和配置切换均无效后，才考虑重建用户自己的 VPN 配置。系统网络设置重置影响范围更大，不应列为第一步。

恢复后的核对点

连接稳定开启后，先保持当前网络不变，连续完成打开网页、返回 Home、锁屏再解锁三个动作，确认没有新的关闭提示。随后再恢复确实需要的 On Demand 条件，并观察它是否引发重复连接。若问题只在锁屏后发生，应记录当时网络是否从无线局域网切换为蜂窝网络，这比单纯描述“后台断开”更有助于定位。

02 / TRAFFIC PATH

连接已开启，但无法上网

连接开启表示系统已建立相关网络处理路径，不表示服务器、DNS、规则和目标网站都正常。应先判断故障覆盖范围：所有应用失败、只有浏览器失败，还是仅某个域名失败。还要区分页面完全不能打开与页面文字出现但图片或登录失败；后一种表现经常涉及不同域名走了不同策略，不能简单视为整条连接失效。

先验证基础网络，再隔离路由模式

关闭 Shadowrocket 连接，用同一设备访问平时可正常打开的网页。如果基础网络也失败，先完成无线局域网登录认证、检查蜂窝数据权限或处理路由器连接。公共网络的认证页面有时需要在连接关闭时完成。基础网络恢复后再开启连接，避免把本来就没有互联网访问能力的网络误诊为配置错误。

基础网络正常后，记下 Global Routing 当前选项。配置模式按当前配置中的规则决定路径；代理模式适合临时验证所选服务器能否承载请求；直连模式可用于对照直连路径，但仍不能替代关闭连接后的基础网络测试。测试结束要恢复原来的工作模式，不要为了让单个网页打开而长期改变所有流量的处理方式。

Global Routing	排查时的用途	结果不能证明什么
Config（配置）	按配置规则观察实际命中与策略	单个目标正常，不代表全部规则正确
Proxy（代理）	临时隔离规则分流因素，验证所选服务器	请求正常，不代表配置模式中的策略引用正确
Direct（直连）	对照当前连接内的直连处理路径	不能代替关闭连接后的基础网络检查

从失败请求反查规则与策略

如果 Proxy 能访问而 Config 失败，优先检查该域名实际命中了哪一条规则，以及规则对应的策略是否指向预期服务器。规则按顺序匹配，更宽泛的规则放在前面，可能提前接管请求。不要只查你认为应该命中的那条规则；应根据当次请求记录核实实际结果，尤其要留意 DIRECT、REJECT 和最后的 FINAL。

下面是用于说明顺序的规则片段，不是完整可直接替换的配置。example.com 是教学域名；PROXY 必须在实际配置中有有效对应。第一条处理该域名及其子域名，第二条按地理数据库匹配地址，最后一条接收前面未命中的请求。真实配置应按自己的访问需求设计，并核对所用策略名称。

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

若 Proxy 同样失败，先换用自己已有且曾经验证可用的服务器进行对照。如果所有服务器都失败，继续检查 DNS、当前网络与共同配置；如果只有一个失败，转到节点超时章节。不要在这一步批量更新所有配置，因为一次引入多处变化，会让原有可用状态也失去参照，排错范围反而扩大。

区分网站异常与客户端路径异常

仅一个网站失败时，检查是否只有登录、视频或附件域名不能访问。网页通常会同时请求多个域名，主页面成功并不代表资源域名都成功。还应留意系统时间、证书提示和目标服务自身状态。出现证书警告时不要直接关闭验证；先判断是设备时间错误、认证页面拦截，还是服务器参数中指定的名称不一致。

完成调整后，用同一个目标重复测试，并记录当前网络、模式、服务器和命中策略。再选择一个走不同策略的目标，确认没有因修复局部问题而破坏其他访问。规则匹配原理可继续阅读规则关键字与匹配顺序；常见连接问答集中在常见问题。

03 / SERVER REACHABILITY

节点超时、认证失败与连接中断

节点测试超时，只能说明当前测试没有在限定时间内完成，不能单凭这一结果判断服务器永久不可用。测试方法、域名解析、传输握手和目标请求都可能影响结果。先记录测试名称和错误原文，再比较真实网页访问；如果测试失败而真实访问正常，应检查测试目标和方法，不要立即删除已有服务器。

按地址、端口、认证、传输逐层核对

进入已有服务器的编辑入口，对照你自己的原始资料逐项检查，尤其留意复制时夹入的空格、换行和全角标点。地址字段只应包含该字段要求的服务器地址，不要把完整分享链接塞进去；端口必须与服务端一致。服务器名称只是本地辨认标签，改名称不会修复地址或认证信息，也不应把名称当作服务端识别参数。

参数层	重点核对	常见表现
地址与端口	地址拼写、端口、当前网络可达性	解析失败、连接超时或连接被拒绝
认证信息	密码、UUID、加密方式与服务端要求	握手后失败、认证错误或连接关闭
TLS	服务器名称、证书、设备时间	证书校验或握手失败
传输设置	传输类型、Host、Path 等配套参数	基础端口可达，但应用请求无法建立

不同协议的字段并不通用。Shadowsocks 的密码与加密方式需要配套；VMess、VLESS 需核对对应身份信息及传输设置；Trojan 应核对密码和 TLS 相关参数；Hysteria2 还涉及基于 UDP 的传输条件。不能因为两个服务器地址相同，就把一个协议的参数整体复制到另一个协议中。以自己的服务端资料为准，不从错误提示中猜密码。

用受控对照判断网络与服务器边界

先在当前网络测试一个自己已有的其他可用服务器，再让原服务器在另一种可用网络下重试。前者改变服务器、保持网络不变；后者改变网络、保持服务器不变。若同一服务器只在一种网络失败，重点检查该网络的访问限制、认证状态或 UDP 条件；若它在不同网络都失败，而其他服务器正常，问题更接近服务器或账号状态。

测试时不要同时开启多个持续测速任务。短时间内密集建立连接，可能触发服务端并发限制，也会让设备负载和网络拥塞改变测试条件。一次测试结束后再进行下一次，至少保留一个完整错误样本。网络切换后应重新建立连接，避免把旧连接尚未恢复的状态误当作新网络的稳定结果。

认证失败通常需要核对原始凭据、账号有效状态及服务端变更，单纯改 DNS 不会修复密码错误。连接被拒绝与连接超时也不相同：前者可能意味着目标端口没有提供预期服务，后者可能发生在更早的路径或握手阶段。日志中的错误只是定位线索，仍需结合可复现对照，不要把某个短语当成唯一结论。

避免用降低验证要求掩盖根因

证书问题首先检查设备日期、服务器名称和原始设置。随意跳过证书验证会失去一项身份核对机制，也可能让真正的名称配置错误继续存在。若服务端使用特殊证书安排，应按自己掌握的部署资料处理；没有可靠资料时，保留原状态并向已有服务的维护方说明错误，不把安全选项当作通用加速开关。

04 / SUBSCRIPTION UPDATE

订阅导入失败、更新失败或列表异常

订阅更新至少包含获取地址内容、识别内容格式、保存服务器列表三个环节。导入报错不一定是服务器本身不可连接；同样，订阅能更新也不代表列表中的每个服务器都可用。排查时先确定失败发生在哪一步：请求根本没有返回、返回了错误页面，还是内容已获取但无法识别，这三种情况需要不同处理。

先确认链接属于哪类内容

单条分享链接、服务器列表订阅和完整配置文件用途不同。单条分享链接描述一个服务器，订阅地址用于获取可刷新的列表，配置文件还可能包含规则、DNS 和策略。不要仅凭链接外观判断用途，应对照自己已有资料的说明。导入入口不匹配时，重复粘贴不会改变内容性质，还可能在列表里产生难以辨认的重复项目。

复制地址时检查是否带入聊天软件的结尾标点、换行或显示用省略号。某些地址包含查询参数，少一个字符就可能导致认证失败；也不能擅自把地址里的协议、路径或参数改成看起来更熟悉的形式。订阅地址本身可能具有访问权限，应把它视为凭据保存，不要为了求助将完整内容发到公开页面。

记录当前服务器组名称与数量的大致变化，保留更新前仍可用的内容。
确认自己的原始订阅地址完整，且导入入口适用于该类内容。
手动更新一次，读取错误提示，区分网络失败、认证失败和格式识别失败。
更新成功后检查当前选中服务器与策略引用，再做实际连接测试。

检查订阅请求使用的网络路径

若更新时出现域名解析或连接超时，先确认基础网络能否工作，再判断订阅请求是否依赖当前已失效的连接。部分地址在直连路径和现有连接路径上的表现不同，应通过一次受控切换确认，而不是不断点击更新。若必须依赖已有可用连接才能获取订阅，应先使用自己已经验证可用的服务器完成更新，避免形成相互依赖。

如果返回内容是登录页面、验证页面或访问错误说明，客户端无法把它当作服务器列表正常解析。浏览器能显示一个页面，只能证明收到了内容，不证明内容是有效订阅。不要把页面另存后的文字当作配置强行导入；应核对自己的账号状态、地址有效性及原始资料，必要时向已有服务的维护方询问该地址实际返回的内容类型。

更新后列表变空或大量项目变化时，先停止连续更新，检查是不是导入了另一个地址、原订阅已撤销，或服务端调整了返回列表。若已保留更新前的记录，可以比较组名和服务器名称，但不要依赖名称推断连接参数完全一致。名称相同的项目也可能变更地址或认证信息，仍应进行一次真实连接验证。

处理重复项目与失效引用

手动添加的服务器与订阅生成的服务器可能同时存在。清理前要确认它们的来源，避免把仍需保留的手动项目一起删除。若规则策略曾直接引用某个服务器名称，订阅更新后的重命名可能使引用失效；此时应检查策略实际指向，而不是只看列表里“还有很多服务器”。先修复引用，再决定是否整理重复项。

客户端列表、订阅服务的账号状态与配置中的规则是三个层面。更新服务器列表通常不等于更新全部规则，也不应假定会自动修复手动修改的 DNS。恢复后核对更新时间显示或更新结果提示、列表内容、当前选择和一次实际访问。对仍不明白的内容类型，可阅读分享链接与订阅的区别。

05 / PERFORMANCE

延迟正常但速度慢、视频卡顿

延迟、吞吐量和网页完成时间衡量的不是同一件事。延迟测试主要反映一次特定交互的耗时，不能直接换算成可持续下载速度；视频播放还受目标服务、缓存、码率和分段请求影响。先把“慢”改写成可观察的表现，例如首次打开等待很久、开始很快随后停顿，或仅大文件传输缓慢，再选择对应测试。

建立可以重复的对照条件

固定同一网络、同一设备、同一目标和同一服务器，结束其他大流量任务后重复一次。若同时更换测试网站和服务器，两次结果就难以比较。网页缓存也会影响第二次打开速度，因此应记录是首次加载还是重复加载；视频则记录是否只在拖动进度后卡顿。测试目标自身负载变化同样会影响结论，不以一次结果判定整条路径。

先关闭连接对照基础网络的速度，再开启并确认目标走的是预期策略。如果基础网络本身就慢，应先检查无线信号、路由器负载与蜂窝覆盖。无线局域网显示已连接，并不代表信号质量和出口带宽都良好；离路由器较远、频繁切换接入点或同时有其他设备占用，都可能让连接测试偶尔正常而持续传输不稳定。

暂停后台备份、应用更新和其他主动传输，记录设备是否发热。
以固定目标完成基础网络与连接开启后的对照，确认 Global Routing 和命中策略。
只切换到自己已有的另一个可用服务器，保持其他条件不变，再重复请求。
最后才切换网络，比较问题是否随服务器、目标或网络一起变化。

区分解析等待、握手等待与持续传输

首次打开长时间空白、随后内容迅速出现，可能涉及 DNS 或连接握手；页面持续一点点加载，则更接近吞吐量、重传或资源请求问题。应结合请求记录观察失败域名、连接建立情况及错误，而不是仅凭体感修改所有设置。若主页面正常但图片慢，检查图片域名是否走了不同策略，下一步应查规则而不是整体测速。

服务器地理位置、当时负载、目标网站连接质量和路径拥塞都会影响性能。低延迟服务器不一定在当前目标上具有更高吞吐量；同一个服务器访问不同网站也可能表现不同。使用自己的现有服务器做对照即可，不需要为了排查新增服务。只有多次在相同条件下得到一致结果，才适合判断某条路径不适合当前用途。

涉及 UDP 的应用或协议应单独观察。某些网络对 UDP 的处理与普通网页连接不同，网页可打开不能证明实时音视频或基于 UDP 的传输一定正常。不要一次改变传输协议、端口和高级参数；先核对服务端支持条件，再作有记录的单项测试。随意填写更大的带宽参数不会提升真实出口能力，还可能让拥塞表现更明显。

控制高级调整的范围

MTU 等网络参数不适合当作通用提速选项。如果只有较大请求卡住，而小请求反复成功，应先收集具体复现方式和网络对照结果，再按已确认的环境需求调整。每次修改前记下原值，修改后重复同一个失败请求，未改善就恢复。缺少明确症状时，保留默认值通常比叠加多个未经验证的设置更容易维护。

测试期间设备过热、低电量或持续录屏，也可能改变实际体验。先让设备回到正常温度，再进行短时对照；不要用持续跑满网络的方式验证日常网页问题。恢复的标准应是原先失败的任务稳定完成，而不是某一次测试数字更漂亮。若主要表现是首次解析等待，转到DNS 章节；若伴随持续发热，继续查看耗电章节。

06 / NAME RESOLUTION

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

DNS 负责把域名转换为后续连接需要的地址。服务器延迟测试正常而网页打不开，可能是测试与网页使用了不同域名、不同解析路径或不同规则。应先确认失败发生在解析阶段，还是已经得到地址后连接失败；两者都可能表现为浏览器等待，但处理方向不同。应用内能看到的错误和请求记录，比单独一张空白页面更有参考价值。

从一个具体域名开始检查

选定一个反复失败的域名，记下失败时间和当前网络。再用一个平时正常的域名作对照，观察是否所有解析都失败。所有域名失败时，先检查配置中的 DNS 地址是否写错、该解析服务能否经预期路径访问；只有个别域名失败时，再考虑域名自身记录、缓存、分流或地址族差异，不要直接替换整套 DNS 设置。

配置可能包含系统解析、指定解析服务以及不同请求路径的安排。应先查看当前实际生效的 Config，确认不是在修改一个未启用的文件。服务器地址如果本身也是域名，同样需要先完成解析；若解析路径又依赖尚未建立的服务器连接，就可能形成依赖问题。排查时应把“服务器域名解析”与“目标网站域名解析”分别记录。

结合规则理解解析与连接的关系

域名规则与地址规则的匹配对象不同。DOMAIN 匹配具体域名，DOMAIN-SUFFIX 匹配域名后缀及对应子域名；IP-CIDR 按地址网段匹配，GEOIP 依赖地址与数据库信息。一个请求最终走哪条策略，需要结合实际命中判断。不能因为配置里出现了某个域名，就认定它一定优先于前面的其他规则。

[Rule]
DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,PROXY

这个片段仅用于展示匹配对象。示例网段是文档用途地址，不代表可用服务；no-resolve 表示该地址规则不为匹配主动触发域名解析，不等于关闭所有 DNS。若不理解这一边界，给地址规则批量加上该参数，可能使原本依赖解析结果的判断不再按预期发生。完整规则仍应结合现有策略与实际目标设计。

修改解析设置前保留原配置，只改变一个解析来源或一个关联选项，然后重新建立连接并复现同一请求。浏览器、应用、系统和连接内可能各有缓存，修改后短时间仍出现旧结果，并不必然说明新设置无效；但也不要反复清空全部环境。先关闭并重新打开目标应用，必要时正常重启设备，再比较记录中的解析和连接结果。

区分地址族、加密解析与目标服务问题

同时存在 IPv4 与 IPv6 记录时，不同网络的可达性可能不同。如果仅某种网络下出现等待，需核对最终使用的地址和连接错误，而不是立即认定域名不存在。直接输入 IP 访问网页也不是可靠替代测试，因为网站可能依赖主机名、证书名称和虚拟主机。IP 访问失败，不能单独证明原域名解析错误。

使用加密 DNS 时，它本身也需要可达的连接路径，并可能涉及证书和系统时间。启用加密不意味着任何网络下都能解析成功。若变更后所有域名都失败，先恢复之前可用的设置，确认是否是解析服务不可达或路径依赖，再逐项调整。不要通过关闭证书验证来掩盖解析连接中的身份校验问题。

若同一域名在其他正常网络也无法解析，问题可能位于域名本身；若能解析但连接失败，应回到服务器和规则章节。修复后至少检查一个原先失败的域名、一个正常对照域名和当前服务器域名，确认没有只修好其中一段。更细的症状对照见DNS 解析失败排查笔记。

07 / BATTERY AND ACTIVITY

耗电异常、发热与后台反复连接

系统电池统计中的占比，需要结合统计时段和设备整体使用量理解。某个应用占比上升，可能是其他应用使用减少，也可能与经过连接处理的流量、持续重试或前台诊断有关；不能只看一个百分比就判断能耗异常。先记录充电状态、屏幕使用、网络类型与实际发热，再比较相近条件下的表现。

把空闲耗电与传输耗电分开

下载文件、播放高清视频、云端同步和热点共享都会产生持续网络活动。连接处理这些流量时可能增加设备工作量，但真正触发请求的应用未必是 Shadowrocket。先暂停自己明确知道的大流量任务，保持其他使用习惯一致，观察空闲时是否仍持续发热。不要一边运行密集测试，一边用电池变化评价日常待机。

在系统 Settings 的电池记录中，选择与问题发生相符的时段，查看前后台活动和其他应用是否同时活跃。若设备正在充电、刚完成系统更新或进行照片处理，也应单独注明。这些条件会影响温度与耗电，混在一起比较无法隔离原因。记录描述最好是“同一网络、屏幕关闭、暂停同步后仍反复连接”，而不是只有“感觉更费电”。

检查 On Demand 与网络切换

On Demand 用于按条件建立连接，不是必须始终启用的排错前提。若问题表现为关闭连接后又自动开启，先检查自己的 On Demand 条件以及系统中其他自动连接配置。可临时停用相关自动行为，手动连接进行对照；确认稳定后再逐项恢复，避免多个条件同时影响，造成反复启动与停止。

弱无线信号、频繁进入离开无线覆盖区，以及蜂窝信号变化，都可能引发连接重新建立。此时持续重试本身会消耗资源，也可能伴随网页短暂中断。把设备放在信号稳定的位置测试，再比较移动过程中的表现。若只有网络切换时出现异常，应记录切换前后的网络，而不是直接把所有后台活动认作客户端问题。

记录系统电池统计时段、当前网络和设备温度，停止主动测速。
暂停已知大流量任务，观察空闲时是否仍出现持续请求。
暂时停止 On Demand，使用手动连接对照是否还有重复连接。
只切换到自己已有的稳定服务器，观察重试和发热是否一起减少。
恢复必要功能后再次核对，保留能够复现问题的最小条件。

减少没有必要的诊断负载

长时间保留详细诊断记录、持续执行 Connectivity Test 或反复更新全部订阅，会额外产生网络与处理工作。排查时可以短时开启需要的记录，抓取一次有效失败样本后停止；不应把诊断任务长期留在后台当作运行状态指示。恢复常规设置后，还要确认没有其他自动化流程继续重复触发测试或请求。

如果某个服务器持续握手失败，连接重试可能比稳定连接更消耗资源。此时应先按节点超时章节修复地址、认证或网络条件，而不是只减少日志。若只有一个目标应用持续请求失败，也要检查它对应的规则与 DNS；错误策略造成的重复请求可能表现为耗电上升，根因却在具体目标的连接路径。

设备明显发热时，先停止高负载任务并放在正常通风环境，待温度恢复后再做短时测试。不要在异常温度下长时间重复测量，因为设备的性能与网络行为可能已经改变。电量变化不能按短暂时段机械外推为全天耗电；应使用相似时长、相似网络和相似使用量的记录作比较，才有判断价值。

08 / RECOVERY AND IPAD

更新后异常与 iPad 专项恢复

更新后出现问题，先确认实际改变了什么：应用更新、系统更新、订阅更新和配置切换可能发生在相近时间，不能都归因于应用。记录最后正常使用的环境与目前差异，再按前面章节定位症状。价格、系统要求与设备兼容性以 App Store 页面标注为准；应用获取与更新均通过 App Store，正版核对可查看下载说明。

先备份，再按影响范围恢复

保留当前配置、自己手动添加的服务器资料与必要的订阅地址，确认备份存放在自己可控的位置。包含密码或订阅参数的文件不要公开分享。随后正常重启设备，在原网络和原目标上复现一次；如果恢复正常，再观察是否只是临时运行状态。若仍失败，分别检查基础网络、连接开关、服务器、规则和 DNS，不直接清除全部数据。

若异常紧随配置编辑发生，优先恢复之前可用的配置副本；若紧随订阅更新发生，核对服务器变化和策略引用；若只有系统升级后 VPN 授权状态异常，再检查系统 Settings 中自己的 VPN 配置。恢复应沿着已知变化逐层进行，而不是把重新安装、删除配置、重置网络当作一组连续动作执行。

重新获取应用之前，先确认购买时使用的 Apple 账号与已购记录。应用购买记录不等于服务器资料备份，重新下载也不会自动修复失效订阅。已购恢复入口与注意事项见换机与重装恢复，也可阅读原账号恢复购买说明。不要为排查连接问题而先退出账号，增加额外变量。

iPad 上区分购买、配置与实际连接

iPad 上应分别确认应用是否可获取、自己的配置是否已导入，以及连接是否确实开启。这三件事不能互相替代。同一购买账号的已购获取与通用购买范围，以 App Store 页面标注为准；即使已成功获取应用，也仍需核对自己的订阅、服务器和规则。不能因为另一台设备正常，就假设本机已具有相同设置。

横屏、竖屏和分屏可能改变入口在屏幕中的位置，但不会改变排查顺序。编辑前先确认当前选中的服务器组与 Config，避免在分栏显示中修改了另一个项目。若切换窗口后发现选项不符合预期，应返回 Home 重新核对当前选择，再进行实际请求测试，不凭窗口位置或上一次停留页面判断当前生效状态。

只有无线局域网连接的 iPad 与同时具备蜂窝连接条件的设备，能够进行的网络对照不同。不能切换蜂窝网络时，可以在自己有权使用的另一处正常无线网络上测试。若同一配置在两台设备表现不同，先比较网络、系统授权、Global Routing、当前服务器和实际配置内容；只比较服务器名称，很容易漏掉参数差异。

处理锁屏、切网与单个应用异常

若 iPad 在锁屏后恢复访问较慢，先观察是否发生无线网络重连，再看 VPN 是否重建。不要只依据状态栏标识判断，因为不同显示环境下可见信息并不相同。解锁后用固定网页复现，记录首次请求是否失败、随后是否自行恢复；若只在某一网络发生，优先检查该网络的连接稳定性和自动认证条件。

外接键盘、浏览器多窗口或不同应用中的网页，可能对应不同缓存和会话。仅一个窗口异常时，先关闭该窗口并重新打开目标，确认是否属于登录或缓存问题；其他应用正常时，不必立即重建整台设备的网络配置。若所有应用都失败，再回到基础网络与全局路由检查，保持从局部到整体的处理范围。