Shadowrocket 故障排查
连接、订阅与规则

开关打不开：先检查授权与系统限制

开关立即回落、持续停留在连接中、应用直接退出，是三种不同现象。先记下触发位置：是否尚未出现系统授权提示，是否刚允许添加 VPN 配置，还是选定某个服务器后才失败。此时不要把订阅全部删除，也不要连续点击连接。先关闭连接，等待系统状态稳定，再确认普通浏览器能通过当前网络打开原本可访问的页面。基础网络没有恢复之前，节点测试和规则调整都缺少可比较的条件。

核对 VPN 授权是否完成

首次连接时，系统可能要求允许添加 VPN 配置，并通过设备密码或系统认证确认。取消提示不会完成授权；应用内开关的短暂变化也不能代替系统确认。返回 Home 重新发起一次连接，完整阅读弹窗。随后在系统 Settings 中查找 VPN，确认存在对应配置。不同系统版本的入口名称与层级可能不同，可使用设置搜索定位。若配置存在但始终无法启用，先断开，再考虑只移除对应的 VPN 配置并重新授权，保留应用内服务器与 Config。

设备受单位或学校管理时，管理策略可能限制新增 VPN、网络扩展或后台连接。此类限制需要管理方确认，重新导入订阅不能改变系统政策。不要移除不清楚用途的管理描述文件。若同一设备还有其他 VPN 连接或依赖本地 VPN 的网络过滤功能，先暂停其中一个，再单独启动 Shadowrocket；同时改变多个网络工具的状态，会让失败原因难以辨认。

排除自动重连与配置错误

On Demand 可能使连接在手动关闭后再次建立，也可能在网络变化时重新尝试。为了观察一次完整的手动连接过程，先暂时关闭 On Demand，并记录原来的条件，测试结束后再恢复。若开关仅在选择某一条服务器信息时回落，检查 Add Server 中是否缺少地址、端口或协议必填参数。订阅名称正常显示并不代表每条记录都完整；导入过程中未被识别的字段，仍需和用户已有的原始资料逐项比对。

如果应用可以正常打开，但系统迟迟不给出授权结果，先关闭连接、退出应用，再重新打开；仍无变化时重启设备。重启是为了清理暂时的扩展状态，不是证明配置正确。重启后只测试原来那一条记录，不同时更新订阅或更换规则。若恢复正常，观察下一次锁屏及网络切换是否复现；若依旧失败，继续检查存储空间、系统限制和当前配置，而不是反复重装。

区分安装拦截与连接故障

应用根本无法打开时，应先处理安装，不进入后面的网络排查。Shadowrocket 支持 iPhone、iPad、Mac、Windows、安卓与 Linux。iPhone / iPad 版在 App Store $2.99 一次性付费，Mac（Apple 芯片与 Intel）、Windows、安卓、Linux 版免费。iPhone / iPad 系统要求以 App Store 页面标注为准；其他平台安装包通过本站下载页获取，实际文件由本站 /dl/ 提供。

桌面与安卓安装包没有代码签名，首次打开可能被系统拦截。确认文件来自本站后，Windows 可在 SmartScreen 的“更多信息”中选择“仍要运行”；Mac 在“隐私与安全性”中允许本次打开；安卓按系统提示为所用浏览器或文件管理器允许安装未知应用。Linux 还需确认文件权限与包格式。具体安装步骤见安装放行说明，不要用反复改规则处理安装问题。

连接后无法上网：分离隧道、服务器与分流

连接标志正常但页面打不开，首先要确认是全部请求失败，还是只有部分域名失败。先关闭 Shadowrocket，访问一个平时可以直接访问的页面；若仍失败，优先处理路由器、移动数据、无线网络认证或系统代理设置。酒店、访客网络等环境常要求先在浏览器完成网络认证，隧道提前建立可能影响认证页面出现。完成认证后再开启连接，避免把网络入口尚未放行误判为服务器故障。

用 Global Routing 做短时对照

在基础网络正常的前提下，选择一条用户已有且资料完整的服务器记录，然后用相同目标、相同网络进行对照。Global Routing 的配置、代理、直连对应 Config、Proxy、Direct。切换姿态用于缩小范围，不是长期修复方式。每次切换后重新发起请求；旧页面可能沿用已有连接或缓存，直接观察屏幕上是否出现旧内容并不可靠。

如果 Direct 下普通页面正常、Proxy 下同一页面失败，重点检查服务器参数及服务器到目标的路径。如果 Proxy 正常而 Config 失败，重点检查当前启用的 Config、规则顺序和策略名称。若三个姿态都失败，不能立即认定规则有问题，应回到基础网络、DNS 与系统连接状态。某些网站本来就对不同网络路径有不同访问条件，因此至少选取两个用途不同的测试目标，避免用单个网站的表现推断全部流量。

确认选中项与实际命中项一致

Home 中选中的服务器，不一定就是 Config 内每条策略最终使用的服务器。配置可以引用策略组，也可以让部分请求走 DIRECT 或 REJECT。打开请求记录，查找刚才测试的域名，核对命中的规则和最终策略。如果完全没有新记录，确认请求是否重新发出、系统是否仍连接到当前隧道，以及测试应用是否实际访问了网络。记录存在但策略不符时，先修正规则，而不是继续更换节点。

检查 Config 时，先确认正在使用的是哪一份文件，再编辑副本。规则通常从上到下匹配，具体域名规则应放在宽泛规则之前，FINAL 用于兜底。下面只演示规则顺序，example.com 是示例域名，PROXY 必须能在实际配置中解析为有效策略。不要把这段规则当作完整配置文件覆盖现有资料，也不要为了测试加入没有理解含义的大范围放行规则。

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

按错误阶段决定下一步

页面报域名解析错误时，转到 DNS 章节；长时间等待后连接超时，转到节点超时章节；建立连接后出现证书警告，则核对系统时间、目标域名和服务器提供的 TLS 参数。不要关闭证书验证来掩盖错误。只有某一个应用失败时，先确认其网络权限、登录状态与自身服务是否正常，再用浏览器访问同类目标作比较。

恢复后把 Global Routing 调回原定姿态，并再次检查一个应直连、一个应代理的请求。记录正常结果所对应的网络、服务器及配置名称。若只能靠 Proxy 暂时使用，也应保留“Proxy 正常、Config 异常”的结论，继续定位分流问题；全局改变请求路径可能绕开错误，却没有消除错误。规则匹配的进一步说明见自定义规则与 FINAL。

节点超时：按地址、端口与握手阶段检查

超时表示某个阶段在等待期限内没有完成，不等于服务器一定离线。Connectivity Test 的结果取决于测试方法、测试目标以及当时网络。某种探测成功，只能证明对应探测路径成功；实际网页还涉及 DNS、协议认证、TLS 与目标站点响应。先把“服务器完全连不上”和“能连接但网页失败”分开记录，不要把一个读数当作全部应用的可用性结论。

先检查地址与端口是否原样保留

在 Add Server 中核对服务器地址、端口及协议。地址栏通常只应放服务器主机名或地址，不要连同网页路径、说明文字一起粘贴；端口应与已有资料一致，不因协议名称自行猜测。注意复制时带入的空格、换行以及全角标点。若原始地址为域名，还要考虑它是否能够解析；若是 IPv6 地址，则需要当前网络具备相应可达性，不能仅凭其他网页可访问就认定这条地址也可达。

同一记录在无线网络失败、移动网络正常，说明问题与接入网络或路径有关，应检查无线网络的认证、路由器规则与上游连通性。两种网络均失败，但用户已有的另一条记录正常，则优先检查原服务器及其参数。如果所有记录突然同时失败，先核对基础网络和共同依赖的 DNS，不要逐条改密码。测试时每轮只换网络或服务器之一，使每个结果都有明确含义。

协议参数必须来自同一份资料

不同协议的字段不可混用。Shadowsocks 要核对加密方式与密码；VMess、VLESS 要核对用户标识与传输选项；Trojan 要核对密码及 TLS 相关设置。用户标识、密码即使只少一个字符，也可能导致认证阶段失败。导入链接后仍应查看关键字段是否被正确识别，尤其是链接中包含转义字符或附加传输参数的情况。不要用其他记录的参数拼接出一条看似完整的新记录。

TLS 的 Server Name 与连接地址可能不同，Host、Path 也可能承担不同作用，不能因为名称相似就全部填成同一个域名。检查系统日期和时间是否正确；时间偏差会使本来有效的证书看起来尚未生效或已经过期。遇到证书错误，应记录错误类别并核对资料，不随意接受不匹配证书。协议配置正确与证书可信是两个独立条件，绕过其中一个不能证明另一个成立。

识别 UDP 与路径差异

部分协议或功能依赖 UDP。Hysteria2 的连接表现可能受当前网络的 UDP 条件影响；WireGuard 也需要正确的密钥、地址、端点与路由范围。网页经其他记录正常，不能直接证明 UDP 路径正常。若失败只发生于某种协议，先核对该协议的必要参数与网络条件，而不是扩大修改所有服务器。也不要随意调整 MTU 等底层参数，除非已有稳定复现且其他因素已排除。

持续超时且原始参数确认无误时，向用户已有服务的管理方反馈测试时间、接入网络、失败阶段及脱敏错误文本。不要发送完整订阅链接、密码或密钥。若连接曾成功但随后失效，还要确认服务端是否变更地址、端口或认证资料。待对方确认后再更新记录，避免在旧参数上反复尝试。最后用实际请求验证恢复，并保留一条可重复的测试步骤，便于下次区分偶发拥塞与持续故障。

订阅失败或列表为空：分开检查获取与解析

订阅更新包含两个阶段：先取得服务器返回的内容，再把内容解析为服务器记录。更新报错可能发生在任一阶段；更新成功但列表为空，也不一定表示网络不可用。先保留原有记录，记下订阅分组名称、更新前后条目变化和错误提示。客户端一次性买断 ≠ 线路套餐，客户端安装或购买不会自动生成服务器信息。本站不提供、不销售、不推荐节点或订阅，本文只说明如何检查用户已有资料。

检查复制内容是不是订阅地址

从用户已有服务商处重新取得订阅链接，确认复制的是完整地址，而不是登录页面、管理页面或被截断的展示文本。订阅地址可能带有查询参数，删除末尾一段或把特殊字符转换为全角字符，都可能改变其含义。粘贴后检查首尾空格与换行，但不要随意改写参数顺序或解码内容。若资料提供的是单条分享链接，应按单条服务器导入处理，不把它误当成需要定期更新的订阅。

不要把真实订阅地址贴到搜索框、公开讨论区或在线解析网站。地址中可能含有可直接使用的访问凭据。需要记录错误时，只保留协议类型、域名的脱敏表示和错误类别。截图分享前遮住二维码、完整 URL、用户名以及可识别的服务器备注。二维码与文字链接可能携带相同权限，遮住其中一个并不能保护另一个。

判断网络请求是否真正取得内容

如果更新提示超时，先检查订阅域名是否能在当前网络解析，随后检查获取订阅时所用的路径。有些情况下，原有服务器已经不可用，而更新订阅又依赖当前代理路径，形成无法更新的循环。可以在基础网络可用且服务地址允许的前提下，比较断开连接后的更新结果；也可使用用户已有的另一条可用记录作对照。不要预设订阅必须走代理或必须直连，实际应由地址可达性决定。

如果错误提示包含状态码，应区分含义：认证或访问拒绝类响应通常需要核对链接权限；请求过于频繁则应停止连续刷新；服务端错误应等待已有服务管理方处理。即使返回成功状态，也可能取得登录页、验证页或普通说明页，而不是订阅数据。因此“浏览器能显示一个页面”不能证明订阅内容正确，更不应把页面文字整段复制进服务器地址栏。

列表为空时检查解析与显示条件

内容已取得但没有条目时，先清除 Home 中的搜索条件，展开对应分组，确认不是过滤或折叠造成的视觉空列表。再检查错误信息是否提到格式不受支持、字段缺失或内容无法识别。不同订阅格式封装的字段不同，不能只改链接后缀来转换格式。需要更换格式时，应使用用户已有服务提供的兼容格式说明，而不是把私密链接交给未知工具处理。

更新后只少了部分记录，应比较缺失条目的协议与参数，确认是否为服务端移除、名称改变或单条记录解析失败。不要只按显示名称判断同一服务器，因为名称可能重复或变更。若订阅更新覆盖了手动编辑的字段，应停止在订阅记录上反复修改，改为保留可管理的本地副本作诊断，并明确它不会自动继承后续变化。具体保存方式以当前界面提供的功能为准。

恢复后检查是否解决原始问题

订阅重新出现，只证明获取与解析完成，还需要选中一条记录进行实际连接。先确认分组条目存在，再核对关键参数，最后访问测试目标。不要同时更新 Config 和所有订阅，否则无法判断是哪一步恢复。若新链接可以更新而旧链接不行，应在确认恢复后停用旧地址，并向原服务管理方确认旧凭据是否已撤销。更细的失败分支见订阅更新失败与列表为空自查；链接类别见分享链接与订阅链接的区别。

速度慢与间歇断流：建立可比较的测试条件

低延迟不等于高吞吐量，吞吐量正常也不代表交互请求响应快。打开网页涉及解析、建立连接和等待首字节；下载大文件更受持续带宽、丢包与服务器负载影响。先描述慢在哪里：开始等待很久、传输一直很慢、播放一段后停顿，还是只在锁屏后断开。明确现象后再测试，避免把不同问题统一归结为“速度慢”，然后同时更换协议、DNS 和规则。

固定目标、网络和时间窗口

选择一个大小适中的合法测试资源，在同一接入网络、同一设备和相近时间内比较。先暂停系统更新、云端同步及其他大流量任务，确认设备没有明显发热。每次只更换一条用户已有记录，或只切换一次 Global Routing，保持其他条件不变。测速会消耗流量，移动数据环境应控制测试次数；持续跑大流量测试本身可能造成拥塞与发热，使后面的结果越来越差。

如果直连的普通页面也变慢，先观察无线信号、路由器负载和上游网络。靠近路由器后改善，说明局域无线条件值得优先处理；改用另一接入网络后改善，则关注原网络路径。若同一服务器在不同网络都慢，但用户已有的其他记录正常，可能是该服务器或其出口路径的限制。此时更改本地规则只能改变路径选择，不能提升远端实际可用带宽。

区分首次请求慢与持续传输慢

首次访问慢、重复访问明显变快，可能涉及 DNS 缓存、连接复用或目标内容缓存，不应仅凭这一现象认定节点不稳定。观察请求记录中的域名、命中策略及错误阶段。若请求被错误送往较绕的路径，修正规则后再测试；若已经命中预期策略，应继续比较解析时间、连接阶段与目标响应。记录只提供部分信息时，保留“不足以判断”的结论，不填入猜测的耗时。

持续下载时周期性停顿，可能与丢包、网络切换、无线干扰、服务端限速或应用自身缓冲策略有关。先在设备静止、不切换网络的条件下复现，再比较另一条已有记录。若仅某个目标慢，也可能是目标站点或其内容分发路径的问题。不要用单个视频或单个下载站代表全部访问表现，更不要为了追求某次测试读数而频繁变更长期配置。

断流时保留连接状态与时序

发生断流时，先看系统 VPN 状态有没有变化，再看 Shadowrocket 是否仍显示连接。状态保持但新请求失败，与系统隧道已经断开，需要走不同分支。前者检查服务器、DNS 和已有连接；后者检查网络切换、On Demand、系统限制与应用异常。记录断流是否紧跟锁屏、从无线转为移动网络、启用热点或进入低电量模式，时间上的对应关系往往比一次测速更有价值。

某些连接跨网络切换后不会自动恢复，需要由应用重新建立。此时先重新发起一个小请求，确认新连接能否成功，再决定是否断开重连。若只有旧下载任务停住，而新页面可以打开，说明可能是旧会话失效，不一定是整个隧道不可用。强制重连会中断其他正常会话，因此应先判断影响范围，再采取动作。

用 Data 辅助解释，不把统计当诊断结论

Data 中的流量读数可以辅助发现后台大流量，但统计维度、时间范围及清零时机会影响解释。某条服务器累计流量高，不代表它当前速度快；某个应用流量低，也不代表它没有连接失败。先确认统计口径，再与实际测试时段对应。按服务器和按应用查看的注意事项见Data 页流量统计说明。如果需要重置统计，先保存原读数，避免清除用于比较的证据。

DNS 与规则命中异常：区分域名、地址和策略

DNS 负责把域名解析为地址，规则决定请求使用哪条路径，两者相关但不能互相代替。域名打不开可能是解析失败，也可能是解析正常而目标连接失败。某个地址能连接，也不证明域名路径完全正常，因为 HTTPS 常依赖正确的域名与证书。不要直接把网页域名换成地址来判断全部问题，更不要在看到解析错误后同时加入多个陌生 DNS 地址。

先确认失败发生在哪一层

重新访问目标并查看请求记录：是否出现域名、是否取得地址、最终使用什么策略、错误是在解析前还是连接后发生。若多个不相关域名都解析失败，应检查当前 DNS 设置及其可达路径；只有一个域名失败，则考虑该域名本身、缓存或对应规则。测试目标最好包含一个平时能正常访问的普通域名，用它建立参照，而不是只检查原本就存在访问条件差异的目标。

加密 DNS 还需要能够连接到对应服务端，某些情况下又需要先解析该服务端的域名。如果 DNS 请求的出口依赖一条不可用代理，就可能表现为所有域名同时失败。检查时把“解析服务器是谁”和“到解析服务器的路径是什么”分开记录。不要仅根据协议名称推断一定可用，也不要为临时排错永久关闭系统或配置中的必要保护。

检查规则顺序与策略引用

规则从上到下匹配，先命中通常先执行。DOMAIN 针对完整域名，DOMAIN-SUFFIX 针对域名后缀，IP-CIDR 针对地址范围，FINAL 为前面未命中的请求提供兜底。域名规则与地址规则的判断依据不同；涉及地址判断时，还需考虑是否已取得地址以及配置选项如何处理解析。排错时先用明确域名做小范围测试，不直接引入宽泛的关键词规则。

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

这个片段演示具体规则先于宽泛规则：intranet.example.com 会先命中第一条，而不是后面的同后缀规则。GEOIP 使用地址归属数据，不等于识别网站的语言、经营地区或内容类型，数据也可能与实际出口情况不同。PROXY、DIRECT 与 REJECT 是策略含义，实际配置中的代理策略还必须能正确引用可用服务器。规则写对但策略指向失效记录，仍会访问失败。

分别检查 IPv4、IPv6 与局域网域名

某些域名同时返回 IPv4 和 IPv6 地址，而当前网络或服务器可能只对其中一类工作正常。若现象随接入网络变化，检查地址族差异，避免直接得出“DNS 返回错误”的结论。局域网设备还可能依赖路由器的本地解析或特定搜索域，改用外部解析后，普通网站正常但打印机、文件服务或内部域名失败。这属于解析范围变化，不应通过把全部请求改为代理来处理。

修改 DNS 或规则后，需要重新发起连接和请求，旧连接及缓存可能继续影响结果。先等待相关状态更新，再用相同目标测试，必要时重启测试应用。清理缓存只是排除旧状态的方法，并非长期解决办法。确认恢复后保存修改前后的差异，删除为测试加入的临时规则，并检查局域网访问是否受到影响。若仍无法确定原因，提交脱敏后的命中规则、地址族与错误阶段，比只说“域名打不开”更便于继续定位。

耗电与更新后异常：先恢复稳定基线

耗电突然增加，要结合网络活动和观察时段判断。系统可能把隧道承载的网络活动归入相关应用，应用排名靠前并不能单独证明发生故障。先比较相似使用强度下的电量变化、屏幕开启时间、移动信号、设备温度与流量，再检查是否持续重连。更新后出现异常也应先确认配置是否改变，不把时间先后直接当作原因。保留原配置，有助于判断是网络环境变化还是本地状态变化。

查找持续活动而非只看电量排名

暂停下载、云端备份、媒体上传和连续测速，等待设备温度回落，再观察一段普通使用。弱移动信号、热点共享和频繁网络切换都会增加系统工作量，必须与客户端行为分开考虑。如果关闭其他大流量活动后明显改善，继续检查产生流量的应用；如果空闲时仍明显发热，查看是否有循环连接失败、不断更新订阅或重复请求的迹象。没有明确证据时，不要删除所有服务器尝试“清理”。

On Demand 的条件若与当前网络频繁变化，可能反复触发连接。先记录原条件，短时关闭自动连接，保持手动连接观察。改善后逐项恢复条件，找出与异常对应的设置。不要把永久关闭连接当作修复，也不要同时关闭所有系统网络能力。需要全天连接的使用场景，应在稳定条件下重新验证锁屏、唤醒与网络切换，避免只完成前台短测就结束排查。

降低诊断本身的额外负担

长时间记录详细日志、频繁探测大量服务器以及不断刷新订阅，都可能制造额外活动。仅在复现窗口内保留必要诊断，定位后恢复普通设置。日志中可能包含访问域名和连接资料，导出前先审查并脱敏。记录应覆盖“开始测试、触发现象、结束测试”的短时段，过长的记录既增加处理负担，也容易淹没真正有用的错误信息。

若设备存储空间紧张，系统与应用更新、缓存写入和配置保存也可能受影响。先通过系统存储管理释放已确认可以删除的内容，再重新启动应用。不要手动删除不明内部文件。电量测试尤其应避免边充电边比较温度；充电过程本身会改变热状态。每轮保持亮度、网络和应用使用相近，才能判断调整是否具有持续效果，而不是一次偶然波动。

更新前后分开比较应用与配置

应用更新与订阅更新、Config 更新是不同动作。回忆异常前实际做过哪一种：只有应用发生变化，还是服务器参数和规则也同时改变。先确认当前选中服务器及启用的 Config，检查 Global Routing 是否符合原意。若 Proxy 正常而 Config 异常，优先比较配置差异；若所有姿态都失败，回到基础网络与服务器参数。不要为了验证更新问题反复卸载，因为卸载可能一并丢失尚未备份的资料。

iPhone / iPad 的应用更新通过 App Store 管理；Mac、Windows、安卓与 Linux 的新版安装文件从客户端下载页获取。重新安装涉及系统拦截时，先确认本站来源，再按下载页的安装放行步骤处理。安装前保存现有 Config、手动服务器和必要备注，备份文件包含敏感资料，应放在自己可控制的位置，不上传到公开空间。

恢复顺序与复现记录

需要重新建立测试环境时，先完成系统授权，只导入一条用户已有且参数明确的记录，验证实际访问，再加入原 Config，最后恢复订阅与 On Demand。每一步都检查同一个目标，并记录何时开始失败。这样可以区分应用基础连接、服务器资料与复杂配置三个层次。如果导入完整备份后立即复现，而单条记录正常，应检查备份中的设置，不继续重复安装。

反馈更新后异常时，说明设备型号、系统环境、网络类型、失败步骤及脱敏错误文本；应用信息从当前界面读取，不凭印象填写。说明“是否能稳定复现”和“最小配置下是否出现”尤其重要。恢复后保留一份已验证配置，并在下一次调整前做副本。日常维护不必追求频繁重置，关键是让每一次改动有记录、能够撤回，并确认原有使用场景仍然正常。

iPad 专项检查：同步配置不等于同步环境

同一份资料在 iPhone 正常、iPad 失败，先比较两台设备的网络与系统授权，不要直接认定平板需要另一套协议。即使连接同名无线网络，也可能处于不同访客网络、不同地址族或不同管理策略。先让两台设备使用尽量一致的接入条件，分别关闭连接验证基础网络，再选择同一条用户已有服务器进行短时测试。比较时保持 Global Routing 一致，避免把配置差异误认成设备差异。

确认 iPad 自己完成首次授权

在另一台设备完成过的 VPN 授权，不会代替这台 iPad 的系统确认。首次启动连接时，应在 iPad 上完整允许添加 VPN 配置，并完成系统认证。若弹窗没有出现，检查系统中是否已经存在对应配置，以及是否被设备管理限制。学校或单位配发的设备可能有专门的网络政策，不能通过重复导入订阅绕过。管理限制不明时，应先联系管理方确认可用条件。

屏幕较大、窗口可并排，不改变连接的系统级性质。把应用切到后台或移出当前窗口，并不等于断开 VPN；反过来，前台显示 Home 也不能证明系统仍有有效隧道。观察时同时核对系统 VPN 状态与应用内连接状态，再重新发出请求。若只有窗口切换后旧页面停住，先尝试新请求，区分旧会话失效与整个连接中断。

逐项比较服务器与 Config

导入相同订阅后，两台设备可能选择了不同记录，或其中一台尚未更新。先比较服务器名称之外的协议、地址、端口与关键传输参数，凭据仅在本地核对。再比较启用的 Config、Global Routing 和策略组选择。相同文件名不保证文件内容相同，手动修改或后续更新都可能产生差异。只看列表外观一致，无法证明实际请求路径一致。

如果通过 Scan QR Code 导入，确认扫描的是服务器资料还是订阅链接；二者后续更新行为不同。通过分享功能传递资料时，也要确认传递内容完整。导入成功后在 Add Server 中检查必填字段，随后进行实际访问，不把“已出现一条记录”当作配置全部正确。分享二维码时注意周围环境，二维码中可能包含与文字凭据相同的敏感信息。

检查局域网与网络切换场景

iPad 常与打印机、文件服务及其他局域网设备配合使用。普通网页可用而局域网资源不可用时，检查目标地址范围是否走 DIRECT，以及本地域名是否仍能按原方式解析。局域网网段并不总是 192.168.0.0/16，应以实际网络为准，不要只复制示例规则。若应用请求局域网权限，按实际用途决定是否允许；VPN 状态正常不能代替应用自身所需的系统权限。

带移动网络的 iPad 从无线切换到移动数据后，原连接可能需要重新建立；仅无线网络的设备则可能在唤醒后经历重新接入。观察故障是否固定发生于切换或唤醒，并在网络稳定后发起新请求。若重连可以恢复，继续检查 On Demand 条件及服务器对路径变化的表现。不要在切换过程中同时更新订阅，否则两个事件交叠，难以判断真正触发因素。

已购恢复与可执行的反馈清单

换机或重新安装时，先确认 App Store 使用的是原购买账户，再在已购项目中查找应用。商店购买恢复与应用内服务器资料恢复是两回事：前者解决应用获取，后者需要用户自己保存的配置或订阅。iPhone / iPad 版 App Store $2.99 一次性付费，两种设备通用；Mac、Windows、安卓、Linux 版免费。商店显示与系统要求以 App Store 页面标注为准，恢复步骤见已购项目说明。

提交 iPad 专项问题时，按顺序写明基础网络是否正常、VPN 授权是否完成、同一记录在另一设备是否可用、三种姿态的对照结果，以及问题是否只发生在锁屏或网络切换后。附上脱敏的命中规则和错误类别，不附完整订阅或二维码。这些信息足以让后续排查沿着已知边界继续，而不必从头猜测。若尚未完成首次导入，先返回快速上手主线；若已能连接但部分请求失败，返回本页的连接与分流检查继续定位。