Shadowrocket
故障排查大全

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

连接开关打开后立刻回到关闭，优先检查系统是否允许建立 VPN 配置，以及当前是否存在其他连接配置的争用。此时还不能判断服务器是否可用：如果系统隧道没有成功建立，请求可能根本没有到达服务器。先观察是否出现系统提示，再区分“没有完成授权”“配置无法启动”和“启动后很快停止”，不要把三种现象统一归为节点超时。

完成授权，再观察开关状态

首次发起连接时，系统可能要求允许添加 VPN 配置。确认提示来自正在使用的 Shadowrocket，按系统流程完成验证，然后返回应用观察开关。如果此前选择了拒绝，重新发起连接并处理授权；如果没有再次出现提示，可到系统设置中搜索 VPN，查看是否已经存在对应配置。不同系统的入口层级可能变化，应以设备显示的名称为准。

系统中的 VPN 配置不是订阅内容，也不等同于服务器列表。删除它不会自动修好服务器参数，反而可能使应用需要重新授权。先确认当前配置对应哪个应用，避免误删工作或学校管理的配置。受管理设备可能限制 VPN 的添加或修改，若选项不可编辑，应向设备管理员核对限制，不能通过反复点击开关解决管理策略问题。

完成授权后先留在应用内，打开一次连接，等待状态稳定，再到系统设置核对 VPN 是否显示已连接。记录开关回落发生在授权前、授权后还是切换到其他应用之后。若只有进入后台才停止，应继续检查按需行为和系统状态；若在前台立即停止，优先查看应用当时的错误提示，而不是先调整网页规则或 DNS。

排除自动连接与配置争用

若关闭后又自动打开，先查看 On Demand 是否启用，以及它是否命中了当前网络条件。按需连接可能让手动开关的结果与预期不同，这不等于开关失灵。为建立清晰的对照，可临时停用自己的按需条件，手动连接一次；记录原设置，完成测试后再恢复。不要同时调整 Wi-Fi 条件、域名条件和服务器，否则难以判断是哪项改变产生了作用。

检查系统是否还有其他 VPN 配置正在自动连接。测试时一次只保留需要验证的连接，先停用其他配置的自动触发，再重试 Shadowrocket。对于不能修改的受管理配置，应保留现状并询问管理员。若开关终于保持开启，接着验证实际访问；系统显示 VPN 只能说明隧道状态，不能证明所有域名、所有协议和所有服务器均已正常。

若有多份配置文件，先确认当前启用的是预期文件，而不是只看列表中是否存在它。可保留原文件副本，用自己已经确认过的服务器和较简单的配置测试。若简化配置能启动，而原配置不能，应检查最近修改的配置段与格式；不要把订阅更新成功当作配置语法正确的证据，两者处理的内容并不相同。

按保留数据的顺序恢复

在确认没有未保存编辑后，可先正常退出应用再打开，随后重启设备，观察系统状态是否恢复。重启后先测试基础网络，再打开连接，这样能区分原本的联网问题和连接启动问题。若错误仍在，记录可见提示的原文、触发步骤及网络类型；只写“打不开”缺少定位信息，也容易让后续排查重复已经尝试过的操作。

重建系统 VPN 配置应放在上述检查之后，而且只处理明确属于自己的对应配置。重建后重新发起授权，再核对 On Demand 和当前服务器。重装应用则可能影响本地配置、历史记录与自定义设置，应先确认已有可恢复的信息。购买及重新获取的说明见已购恢复；系统授权的关系见VPN 配置提示说明。

已连接但无法上网：分开检查路由与出口

开关保持开启但网页无法访问，先建立三个对照：关闭连接时基础网络是否正常、打开后是否所有目标都失败、Global Routing 当前选中了什么。连接状态正常只表示系统隧道建立，实际请求还要经历域名解析、规则匹配、出口选择与服务器转发。沿这个顺序检查，比同时替换服务器、规则和 DNS 更容易得到明确结论。

先确认故障范围

关闭连接，访问自己平时能够访问的普通网页，确认 Wi-Fi 是否需要先完成网络认证。若基础网络也无法访问，应先处理路由器、信号或网络认证，再返回应用。打开连接后用同一个目标复测，并增加一个不同目标；如果只测一个网站，网站自身故障、账户状态或区域性服务异常都可能被误认为客户端问题。

分别记录浏览器和出现异常的应用是否一致。只有某个应用失败时，应考虑该应用自身的缓存、账户请求、独立解析或连接复用；所有应用失败时，才更接近共同出口或解析链路的问题。测试应使用相近时间和相同网络，避免在更换 Wi-Fi、切换服务器后，仍拿很久之前的成功记录作比较。

如果基础网络有登录页面，先关闭连接完成认证，再重新连接。网络认证未完成时，系统可能显示已接入 Wi-Fi，但只有认证相关地址能够访问。此时订阅更新、服务器测试和网页访问可能同时失败。不要为了绕过这个现象不断修改规则；先确认设备已经获得正常的基础网络访问能力。

使用 Global Routing 做有限对照

Global Routing 的配置、代理、直连分别对应 Config、Proxy、Direct。先记下原选项，再用短时间对照判断异常是否与规则有关。Direct 可帮助观察直接出口的结果，Proxy 可帮助观察代理出口的结果，Config 用于检查规则参与后的实际行为。它们是诊断条件，不是“切到某项就一定可用”的修复结论。

如果 Proxy 下目标可访问，Config 下同一目标失败，应重点查看规则是否把它送往了不同策略。若 Direct 正常而 Proxy 普遍失败，优先检查当前服务器及其参数。若三种选项均失败，也不能立即断定为 DNS：基础网络、目标故障和残留连接状态仍需排除。每次切换后重新发起请求，避免浏览器复用上一次连接。

通过应用提供的连接记录或诊断信息核对目标域名、命中规则与最终策略，入口名称以当前界面为准。若看到 REJECT，应先确认该拒绝是否来自预期规则；若看到 DIRECT，但目标需要通过自己的服务器访问，应检查规则顺序。不要只凭某条规则存在于文件中，就认定它一定会被执行。

按匹配顺序定位配置问题

规则通常按从上到下的顺序匹配，较宽的条件放在前面，可能提前覆盖后面的精确条件。以下只是用于理解顺序的片段，example.com 是说明用域名，不代表应当访问的服务。测试前复制原配置，只修改与异常目标有关的最小范围；不要直接用示例覆盖整份正在使用的配置文件。

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

FINAL 负责前面没有匹配到的请求，不能修正已经被前面规则命中的结果。排查局域网访问时，还应确认目标地址和当前网络的实际网段是否一致，不能假定所有家庭网络都使用示例网段。域名规则与地址规则的检查路径不同，遇到解析相关现象时，应结合下一步实际解析结果，而不是只调整末尾策略。

当同一目标在简化配置中正常、原配置中异常时，逐段恢复规则并复测，可缩小到具体条件。测试结束恢复原路由姿态，保留必要改动和原因，避免临时 Proxy 成为长期遗留设置。更多顺序示例见规则顺序与 FINAL；界面词含义可查术语手册。

节点超时：逐层核对服务器参数

Connectivity Test 显示超时，表示该次测试没有在预期时间内完成，不能单独证明密码错误、服务器停机或整个订阅失效。测试方式可能涉及不同的连接阶段，结果还受当前网络与目标影响。先区分单个条目失败、同一订阅全部失败、还是只有某一种网络失败，再决定从服务器参数、服务状态或本地网络哪一侧继续检查。

核对原始信息与实际条目

打开当前选中的条目，与自己服务商提供的信息逐项比对。先核对协议、服务器地址和端口，再核对认证与传输字段。注意粘贴时的首尾空格、误换行和全角符号；地址栏不应混入说明文字。导入后名称相同也不代表参数相同，应确认当前连接实际选中的条目，尤其是在重复导入后保留了多个相似名称的情况下。

对于订阅生成的条目，先保留原始订阅和当前记录，不要立即逐个手改。手动修改的字段可能在下次更新时被覆盖，还可能让你失去与原始信息的对照。若确认服务商调整了参数，先更新已有订阅并查看是否成功，再重新选择对应条目；更新失败时应转到订阅章节，而不是把旧条目的超时当作更新已经完成。

核对服务器地址时要区分域名和数值地址。域名依赖解析，数值地址则可能与证书中的名称不同。随意把域名替换成某个解析出的地址，可能改变证书验证或路由结果，不能作为通用修复方法。若怀疑域名解析异常，保留原地址，先记录解析表现，并按 DNS 章节做对照，避免把两类问题混在一起。

协议参数必须成组一致

不同协议的认证字段与传输要求不同。Shadowsocks 要核对服务端指定的加密方式与密码；VMess、VLESS 等要核对对应身份字段及传输配置；使用 TLS 时，要同时核对相关名称与证书要求。字段能保存，只说明输入被接受，不说明与服务端一致。不要用其他条目中“看起来相近”的参数替换缺失字段。

出现证书相关错误时，先检查设备日期与时间是否正确，再核对服务端要求的名称和证书状态。关闭证书验证不能证明配置已经修好，也会改变验证边界，不应作为日常排查的默认动作。若字段含义不明确，应向自己的服务商确认完整参数，而不是反复试填不同值；错误提示的原文通常比条目的显示名称更有帮助。

Hysteria2、WireGuard 等还涉及各自的传输与密钥设置，不能照搬其他协议的参数组合。某个网络能建立连接、另一个网络失败，可能与网络对相关传输的处理有关，但仅凭一次超时还不能确定。使用同一条目、同一目标分别测试自己的两个可用网络，保持其他条件不变，才能获得有意义的比较。

用交叉测试缩小边界

若只有一个条目失败，而自己已有的另一个条目在相同条件下正常，重点核对失败条目的参数和服务状态。若所有条目都失败，先检查基础网络和订阅是否过期或返回旧内容。不要连续高速发起大量测试；短时间内的网络拥塞、服务端限制与设备负载可能放大异常，使结果更难解释。

如果 Wi-Fi 失败而蜂窝网络正常，可先确认 Wi-Fi 已完成认证，再检查路由器网络及其解析环境；若设备没有蜂窝网络，可在条件允许时用另一个可信 Wi-Fi 对照。一次成功只说明当时条件下可用，不能保证长期稳定。完成对照后，恢复原网络并确认问题是否能够重复出现，避免把偶发成功当作最终结论。

向自己的服务商反馈时，提供协议类型、故障时间、网络类型、错误原文及是否只有一个条目受影响。隐去密码、身份字段、私钥和完整订阅地址；这些信息通常不需要出现在公开截图中。本手册只解释已有信息的核对方法，不提供连接服务。若服务器可以通过测试但业务仍失败，应返回“已连接但无法上网”章节检查实际路由。

订阅失败：区分获取、解析与更新结果

订阅更新是一条独立链路：先取得地址，再通过当前网络请求内容，随后解析成条目，最后写入本地列表。连接正常不代表订阅一定能够更新，订阅成功也不代表每个条目都能使用。排查时先记下准确提示，区分无法请求、返回内容不符、解析失败和更新后数量变化，避免用删除重加掩盖真正原因。

核对自己的订阅地址

从自己的服务商提供的正式信息中重新复制完整地址，检查是否缺少末尾参数、粘入空格或带入说明文字。网页管理入口、说明文档地址和订阅地址可能外观相近，但用途不同；能够在浏览器打开一个页面，不表示该页面适合作为订阅导入。不要根据地址中的某个词猜测格式，应以服务商对该入口的说明为准。

订阅地址可能包含访问凭据，应当像密码一样保存。反馈问题时不要公开完整地址，也不要把它粘贴到不明确的在线检查工具。可描述返回类型、错误代码或提示原文，但隐藏可识别账户的参数。如果怀疑地址已经泄露，先通过自己的服务商提供的管理方式处理，再更新应用中保存的地址。

先尝试一次手动更新，观察应用给出的结果，而不是只看条目名称是否改变。服务商可能没有修改条目名称，也可能在保留名称的同时调整参数；反过来，本地仍显示旧条目也不证明本次请求成功。更新前记录原有分组和当前选择，更新后核对实际内容，才能知道变化发生在哪一步。

判断请求失败还是内容不符

如果提示无法连接、超时或解析域名失败，先用当前网络验证基础访问，再检查订阅域名是否只能在特定访问条件下取得。若你已有可工作的服务器，可在服务商允许的条件下比较连接前后的更新结果，但不要为了更新而反复建立未知来源的配置。网络访问和返回内容要分开确认，不能把所有错误都归为格式问题。

若服务器返回登录页面、认证页面、错误页面或空内容，应用可能无法把它识别为订阅。状态码有助于定位，但不能单独替代返回内容检查：成功响应也可能携带网页，而非预期数据。收到拒绝访问类提示时，核对地址是否有效、自己的服务是否处于可用状态；不要在凭据没有确认前连续重复请求。

对于格式不符，先确认服务商提供的订阅类型与当前导入方式匹配。服务器条目订阅与整份配置文件并非同一种内容，不能仅因为两者都通过一个地址取得，就放在相同入口处理。若导入后出现的是配置文件而非预期列表，应返回原始说明核对用途，不要通过改动文件扩展名来尝试修复。

处理更新后异常与自动更新

更新完成后，重新确认当前选中条目是否仍存在，所属分组是否变化，以及参数是否被替换。若服务商移除了某个条目，本地原来的选择可能不再对应可用项；应从自己现有列表中重新选择并验证。数量减少不一定是解析丢失，也可能是远端内容本身改变，需要结合更新提示与服务商说明判断。

打开应用时自动更新与手动更新的触发时机不同。若每次启动就发生错误，可临时关闭相关自动更新选项，用手动更新建立可观察的过程，记录完成后再恢复原设置。只有启动时失败而稍后手动成功，可能与当时基础网络尚未就绪有关；应先确认网络状态，不必立刻删除整个订阅。

如果手动改过订阅生成的条目，更新后变化可能来自远端重新写入。需要保留个别自定义设置时，先了解当前应用对本地编辑与订阅更新的处理方式，并保存必要副本。不要把对订阅条目的临时修改当作稳定备份；真正恢复所需的是有效原始地址、自己的服务信息和明确记录的配置差异。

重加订阅应是确认地址和格式之后的步骤。先保留旧记录，再用明确的名称区分测试项，验证成功后才清理重复内容。若新旧两项均失败，删除旧项不会改善请求链路。更细的触发方式见订阅手动更新与自动更新说明；首次导入入口见入门指南。

速度慢与中断：用同条件测试定位瓶颈

网页打开慢、视频缓冲、文件传输慢和连接频繁中断，反映的是不同指标。一次连接测试的响应时间不能代表持续传输能力，单个文件的速度也不能概括全部访问。先把症状写清楚：是首次打开等待很久，还是开始后吞吐较低，或者一段时间后突然停止。明确发生阶段，才能决定检查解析、链路、目标还是设备状态。

建立可以重复的测试条件

选择自己能够合法访问、内容相对稳定的目标，在相近时间内测试。记录网络类型、所选服务器、路由方式和是否有后台传输。不要同时更新应用、同步照片或下载大文件，再据此判断连接速度。设备正在进行的其他任务会争用网络和处理资源，先暂停与测试无关的大流量任务，才能减少干扰。

比较两次结果时，保持目标与操作一致。第一次打开网页可能需要解析域名、建立连接并下载资源，第二次可能直接使用缓存；因此“第二次更快”不一定来自刚才的设置修改。可关闭该目标的旧连接后重新测试，或按相同顺序多做几轮，观察趋势，而不是只挑其中最快或最慢的一次作结论。

如果关闭连接后访问同一个本来可直接访问的目标也慢，应优先检查基础网络与目标服务。Wi-Fi 信号强并不等于上游链路空闲，路由器负载和网络拥塞也会影响实际结果。换到自己另一个可信网络做对照时，保留相同服务器与目标；若只换网络就改善，排查重点应先放在原网络环境。

区分低响应时间与实际传输

Connectivity Test 的结果用于观察该次测试的完成情况，不应简单按数字排序后认定某个条目一定更适合所有业务。网页由多个域名和资源组成，持续传输还受出口带宽、目标负载及链路质量影响。低响应时间但文件慢，和高响应时间但传输稳定，可以同时存在；应按实际使用的目标验证。

若只有一个目标缓慢，先核对该目标是否命中了预期策略，以及是否有资源域名走了不同出口。页面主域名成功不代表图片、登录和媒体资源都使用相同路径。可查看相关连接记录，寻找失败或反复重试的请求；不要为改善一个页面而把所有规则全部改成同一策略，这会失去精确定位的机会。

若自己已有多个可用条目，可在同一时间段分别测试同一目标。只有一个条目持续慢时，核对其服务状态并向自己的服务商反馈；所有条目都慢时，仍需考虑本地网络或目标服务的共同因素。测试时避免频繁并行连接多个条目，串行对照更容易把某次结果对应到明确的出口。

处理中断、长连接与网络切换

从 Wi-Fi 切换到蜂窝网络时，网络地址与路径可能改变，已经建立的会话可能需要重建。看到一次短暂停顿，不宜立即修改协议参数。先等待网络稳定，再重新发起原操作；若只有切换瞬间失败而稳定后正常，应记录为网络切换相关现象，而不是持续性的服务器不可达。

如果固定时间后中断，记录大致持续时长、是否锁屏、是否切换网络以及开关是否仍保持开启。长连接中断与隧道关闭的处理不同：前者需要检查目标、传输和会话恢复，后者应回到权限、On Demand 与系统状态。设备发热或后台任务繁忙时，也应先让环境恢复正常，再做相同条件下的复测。

MTU 等底层参数不宜凭经验批量修改。只有出现可重复的特定现象，并且已有服务端或网络依据时，才在副本中做单变量对照；改动后记录原值和结果。随机调整多个参数，偶尔成功也难以证明原因。若没有明确依据，先处理信号、并发任务、规则命中与服务器状态，通常更容易形成有效结论。

最终保留一份简短记录：哪个网络、哪个目标、哪个条目、何种操作、是否可重复。向自己的服务商反馈时优先提供这些条件，而不是仅提供一张瞬时速度截图。测试结束恢复自动更新与正常路由设置，停止不必要的循环测试；持续测速本身会消耗流量和电量，也会改变你正在观察的网络负载。

DNS 问题：检查解析路径与规则结果

DNS 负责把域名解析为地址，但域名访问失败不一定都是解析故障。建立连接、TLS 验证或目标响应失败，也可能表现为网页打不开。先辨认可见错误是否明确提到域名解析，再核对应用的解析设置与请求记录。直接输入某个数值地址进行网页访问并不是等价测试，因为证书、虚拟主机和资源域名可能都依赖原始名称。

从域名与地址的关系开始

记录异常域名，确认是否只有该域名失败，还是所有需要新解析的目标都失败。旧页面仍能访问，不一定说明 DNS 正常，它可能正在复用已有连接或缓存地址。反过来，只有一个域名失败，也可能是该域名自身的记录变化。先增加不同域名的对照，再观察失败是否集中在同一类目标或同一网络。

查看当前配置中的 DNS 设置时，先保存副本，确认使用的是哪份配置，以及是否存在覆盖或按条件选择的解析路径。不要只修改文件中某个看见的地址，就假定所有请求都改用了它。配置文件可能没有启用，应用也可能存在其他相关设置；应结合实际诊断信息判断，而不是只检查静态文字。

如果解析器地址本身是域名，还要考虑它最初如何被解析；如果使用需要建立安全连接的解析方式，还涉及该解析入口的可达性与名称验证。添加更多解析入口不一定提高成功率，也可能增加等待或造成结果不一致。先使用自己了解且能够验证的设置，避免把不明确的地址列表当作通用修复方案。

把解析结果与路由规则一起检查

域名规则关注名称条件，IP-CIDR、IP-CIDR6、GEOIP 等规则关注地址或地址归属条件，二者可能在不同阶段影响最终策略。同一个域名解析到不同地址后，地址规则的命中结果可能变化。因此排查时不仅要问“有没有解析成功”，还要问“解析出了什么，以及该结果最终走向哪个出口”。

当记录显示目标命中非预期策略，先检查域名条件是否拼写正确、是否被更早的规则覆盖，以及末尾 FINAL 的策略。DOMAIN-SUFFIX 匹配范围与 DOMAIN 的精确范围不同，DOMAIN-KEYWORD 则可能匹配更多名称。不要为了修复一个目标而增加过宽的关键字规则，否则其他不相关请求也可能被改变。

若配置包含本地地址规则，应核对当前设备的真实网段和服务名称。局域网设备的名称解析有时依赖所在网络提供的机制，不能假定远端解析入口能够回答家庭设备名称。只有家中设备无法访问而普通网页正常时，先比较使用名称和使用设备实际地址的差异，再检查局域网路径及相关权限。

处理 IPv6、缓存与网络差异

有些域名同时返回不同地址族的结果，当前网络、服务器和目标对这些路径的支持可能不同。出现间歇性失败时，可观察失败是否总与某类地址结果相关，但不能仅凭看到 IPv6 地址就认定它有问题。先保留原配置做对照，并确认应用提供的相关选项含义；每次只改一项，测试后恢复或明确记录保留原因。

修改解析设置后，旧缓存和已有会话可能继续生效。先重新建立连接，再重新发起目标请求，必要时正常关闭并打开相关应用，以减少旧状态影响。不要把第一次仍然失败就视为设置无效，也不要把一次缓存命中视为已经修复。应观察多个新请求是否在相同条件下稳定完成，再决定是否保留改动。

如果同一配置在一个 Wi-Fi 正常、另一个网络异常，检查原网络是否需要认证、是否提供了不同的解析环境，以及解析入口是否可达。切换网络时，服务器与目标保持不变；若解析错误消失但连接仍失败，就继续检查传输阶段。排错应允许发现多个问题，而不是强行用一个 DNS 设置解释所有症状。

恢复时优先回到之前已确认可用的解析设置，再逐项加入必要修改。保留异常域名、错误原文、网络类型及命中策略即可，不需要公开完整浏览记录。相关关键字可查术语手册；当 DNS 已成功而请求仍失败，应回到服务器参数或规则章节，避免在解析层反复修改已经正常的部分。

耗电与更新后异常：保留基线再比较

连接开启期间耗电增加，需要结合流量、信号、重试和设备任务判断。系统电池统计中的应用占比不是额外耗电的直接测量，也不能单凭一个百分比认定配置异常。更新后出现问题同样需要拆分：应用更新、系统更新、订阅更新和配置修改可能发生在接近的时间，但它们影响的内容不同，应先建立清楚的时间顺序。

观察耗电发生时的实际任务

先到系统电池信息中查看对应时间段，确认当时是否有视频、文件同步、大量下载或较差的网络信号。网络流量经过隧道时，相关处理会与设备使用情况共同影响能耗；连接开启的时长本身不足以推算耗电。比较时尽量保持屏幕亮度、网络、业务和持续时间相近，避免拿待机状态与持续播放状态作对照。

若在几乎没有主动使用的情况下仍持续发热，先观察是否存在循环更新、频繁连接测试或失败请求不断重试。暂时停止自己设置的自动任务，保留正常连接做对照；确认改善后再逐项恢复，以找出触发因素。不要一次关闭所有功能后就断言某个协议耗电，因为并发任务和网络重试可能才是主要差异。

同时检查信号环境和网络切换。设备在不稳定网络间反复切换，或者长时间尝试连接不可达的目标，可能增加额外活动。先换到稳定的已有网络，保持相同配置观察；若设备仍明显发热，应停止高负载测试，让设备恢复正常，再继续记录。测试本身不应成为持续耗电和发热的来源。

更新后先确定到底更新了什么

记录最近变更的是应用、系统、订阅还是手动编辑的配置。订阅更新可能替换服务器参数，配置更新可能改变规则，而应用更新不代表自己的服务状态同步变化。先检查当前所选服务器、启用配置和 Global Routing 是否仍与原来一致；很多“更新后失效”的现象，实际发生在当前选择变化之后。

应用的获取与更新通过 App Store 进行。核对正版时可查看开发者 Shadow Launch Technology Limited、官方图标和应用 ID 932747118，具体入口见正版核对说明。系统要求以 App Store 页面标注为准。不要仅凭界面外观变化判断应用来源，也不要用未经核对的配置内容代替产品本身的核验。

若原配置在变更前正常，先使用保留的副本做对照，确认是规则变化还是服务器本身不可用。备份中的服务器也可能已经失效，所以“旧配置同样失败”不能单独证明应用更新有问题。要结合基础网络、服务状态与简化配置共同判断，尽量找到能够重复的最小条件，而不是只以时间接近推断因果。

按低风险顺序恢复与反馈

先保存未提交的编辑，再正常退出并重新打开应用；随后在网络稳定时重建一次连接。如果系统刚完成更新，可重启设备后复测，但重启只是清理临时状态的对照步骤，不是每种故障的固定答案。恢复后仍应检查原来的自动更新、按需规则和路由选项，避免临时调整改变了日常使用方式。

当问题仅在某份配置出现，复制该文件并逐步移除最近新增的部分，比清空全部设置更容易定位。涉及服务器密码、密钥或身份字段时，不要把原文件公开分享。保留最小规则片段、错误原文和复现步骤即可；如果删去某段后恢复，再逐项确认具体条件，不必立即替换整份配置。

重装之前确认自己掌握有效订阅地址、必要服务器信息和本地自定义配置。重新从 App Store 获取应用并不自动恢复所有本地数据，购买记录与配置备份是两回事。相关流程见换机与重装恢复。如果尚未确认数据可恢复，先保留现状，继续做不涉及删除的检查。

反馈时写明实际系统和应用信息、变更顺序、可重复步骤以及已经验证的结果，避免仅说“更新后坏了”。本文不固定列出应用版本或更新时间，实际发布信息以 App Store 页面为准。对于耗电，补充相同条件下的使用时段和任务；对于连接，补充开关状态和错误原文，两类信息不要混作一个结论。

iPad 专项：区分设备、网络与配置差异

相同订阅在 iPhone 正常、在 iPad 异常时，先不要认定订阅不支持该设备。两台设备可能连接了不同网络，使用不同的配置文件、路由选项或服务器条目，也可能保存了不同时间更新的内容。把“相同”落实到具体参数，再逐项比较。iPad 的系统要求与兼容性以 App Store 页面标注为准。

先对齐应用与系统状态

在 iPad 上打开对应的 App Store 产品页，核对应用身份与兼容性；购买及获取说明见iPad 设备说明。同一账户的购买记录和本机保存的配置不是同一件事，应用安装完成后仍需确认自己的订阅或服务器信息是否已经导入。不要把另一台设备的正常状态当作本机已经具备全部配置的证据。

首次连接也需要处理系统 VPN 授权。若界面布局因屏幕尺寸不同而变化，应按 Home、Config、Settings 等原文寻找对应功能，不要只记住按钮在手机上的位置。分屏或窗口宽度变化可能影响可见区域，但不改变检查顺序：先确认当前条目，再确认配置和路由，最后打开连接并验证实际访问。

部分 iPad 只有 Wi-Fi，不能用蜂窝网络进行同机对照；此时可在条件允许时选择另一个可信 Wi-Fi。支持蜂窝网络的设备则应记录切换前后的结果。比较 iPhone 与 iPad 时，尽量让两者处于同一网络和相近时间，避免一台使用蜂窝网络、另一台使用待认证 Wi-Fi，却把差异归因于设备型号。

逐项比较配置，不只比较名称

在两台设备上分别查看选中的服务器地址、端口和协议，再核对当前启用的配置及 Global Routing。显示名称相同仍可能对应不同条目，尤其在重复导入、手动编辑或订阅更新后。不要直接覆盖 iPad 的全部内容；先记录差异，必要时在副本中修改一项，再观察是否改变故障表现。

确认两台设备是否都完成了同一次订阅更新，以及远端返回内容是否相同。若一台保留旧参数、另一台已经更新，异常可能来自内容时间差。先在出现问题的设备上手动更新并查看结果，再重新选择当前可用条目。如果更新本身失败，转到订阅章节处理，不要继续拿两份不同内容做设备对比。

若只在某台设备上对特定目标失败，检查该设备是否有本地规则、不同解析设置或其他系统配置。同步文件不一定包含所有应用级设置，也不代表系统权限完全一致。逐项对齐时保留原值，避免为追求“完全一样”而删掉设备原本需要的局域网或工作环境配置。

检查局域网、按需条件与长时间使用

iPad 常在固定 Wi-Fi 中使用，打印、投屏或访问家庭存储时，需要区分局域网路径和远端访问路径。如果只有这些功能异常，先关闭连接做对照，核对设备实际地址与所在网段，再检查相关规则及系统中的局域网权限。不要为了恢复一个本地服务，就把所有互联网请求改为 Direct。

On Demand 的条件应按当前 iPad 的实际网络核对。即使复制了相同条件，两台设备所处的 Wi-Fi、网络类型或域名触发过程也可能不同。暂时停用自己的按需条件，用手动开关建立基线，再恢复并逐项测试。相关触发思路见On Demand 设置说明。

若长时间锁屏后访问失败，先观察开关是否仍开启、系统 VPN 是否连接，以及重新打开目标后能否恢复。只有旧会话失效与整个连接停止，是不同故障；应记录锁屏前后的网络变化，而不是直接认定后台连接不可用。分屏中运行的其他任务也可能占用网络，速度测试时应保持相似的设备负载。

最终用一张自己的对照记录收尾：同一网络、同一条目、同一配置、同一目标，各设备分别出现什么结果。如果基础条件一致仍能稳定复现差异，再整理系统信息与错误原文进行反馈。常见的简短解释可查常见问题；若需要重新走完整流程，回到入门指南，按导入、路由、授权和验证的顺序逐步完成。