Shadowrocket 故障排查手册

一、先建立可重复的排查基线

故障排查的第一步不是立即修改参数，而是确认问题发生在哪一层。Shadowrocket 建立连接时会依次涉及当前 Wi-Fi 或蜂窝网络、系统 VPN 配置、所选服务器、协议参数、规则匹配、DNS 解析以及目标站点响应。任意一层失败，都可能在表面上表现为“打不开网页”。如果跳过分层判断，只反复切换开关，往往会把一个明确问题变成多个变量同时变化的问题。

先记录现象，不用印象代替结果

开始前写下四项信息：异常发生在 Wi-Fi、蜂窝网络还是两者都发生；关闭 Shadowrocket 后普通网页能否访问；连接开关能否保持开启；异常是全部域名、单个域名还是某类应用。还应记录当前 Global Routing 是 Config、Proxy 还是 Direct，以及刚才是否更新过订阅、修改过 Config、切换过服务器或改变过 DNS。这里不需要保存敏感服务器内容，只需记录操作顺序和结果。

“能连接”与“能正确传输”不是同一件事。系统状态栏显示 VPN 标记，只说明系统接受了连接配置；它不代表服务器一定可达，也不代表规则一定把请求交给了预期策略。相反，某个网站打不开也不等于整个连接失效，可能只是该域名命中了 REJECT、DNS 返回异常、目标站点拒绝响应，或当前规则把它交给了不可用的策略组。

用最少变量完成四组对照

1. 关闭 Shadowrocket，在当前网络中打开两个平时稳定可访问的页面，确认本地网络本身能够传输数据。
2. 保持同一网络与同一服务器，将 Global Routing 暂时设为 Proxy，观察问题是否仍然存在。
3. 保持其他条件不变，将 Global Routing 改为 Direct，判断系统基础网络是否能在连接开启状态下正常工作。
4. 只更换一个已知参数完整的服务器，再重复测试，区分单个服务器问题与全局配置问题。

这四组结果可快速划定范围：Direct 正常而 Proxy 异常，重点检查服务器与协议参数；Proxy 正常而 Config 异常，重点检查规则、策略名称和 DNS；关闭连接正常、Direct 也异常，重点检查系统 VPN 配置、On Demand 或其他网络扩展冲突；所有状态都异常，则应先修复当前 Wi-Fi 或蜂窝网络。完成对照后再恢复原来的 Global Routing，避免把临时测试姿态长期当作正式配置。

确认应用来源与使用前提

如果设备上的应用来源、购买记录或应用身份无法确认，先到正版核验说明核对开发者 Shadow Launch Technology Limited、官方图标与应用 ID 932747118。Shadowrocket 是一次性买断的客户端，但客户端一次性买断 ≠ 线路套餐；后续连接需要用户已有自己的订阅或服务器信息。本手册只解释客户端内的诊断方法，不对服务来源作评价。

排查期间不要频繁删除 Config 或整批覆盖现有数据。更稳妥的做法是先记住当前选中的服务器和配置名称，对重要的自定义规则另行保存文本副本，再进行单项调整。若最终需要向自己的服务商反馈，至少应提供故障发生时间、网络类型、协议名称、Connectivity Test 结果及是否仅单个服务器异常；密码、完整订阅地址和身份凭据不应包含在普通截图中。

二、连接开关打不开或立即回落

Home 中的连接开关无法保持开启，通常发生在系统 VPN 配置尚未授权、现有网络扩展状态异常、On Demand 反复触发，或应用配置不能被系统接受时。这个症状与服务器超时不同：服务器超时往往允许开关保持开启，只是请求不能完成；开关立即回落则应优先检查设备侧的连接建立过程，而不是先调整规则。

检查首次授权和系统状态

首次开启连接时，系统会要求允许添加 VPN 配置，并可能要求使用设备密码、Touch ID 或 Face ID 确认。若授权流程中途取消，返回 Home 后再次开启，让系统重新显示确认步骤。授权完成后，可在系统设置的 VPN 相关页面确认 Shadowrocket 对应配置是否存在。不同系统界面的入口名称可能调整，因此只需确认系统中能看到该连接配置，不必依赖某一条固定菜单路径。

如果系统页存在多个长期不用的 VPN 配置，先逐一确认当前实际使用的是哪一项。不要在多个连接工具之间连续抢占系统 VPN 状态；先将其他网络扩展全部断开，再回到 Shadowrocket 测试。系统在网络切换、设备刚解锁或恢复数据连接时可能短暂处于过渡状态，等待十到二十秒后再操作，比连续快速点击开关更容易得到可判断的结果。

把 On Demand 从手动连接问题中分离

On Demand 会根据已设置的网络条件决定何时连接。条件重叠、当前 Wi-Fi 名称变化，或规则同时包含连接与断开动作时，可能出现开关刚开启又被条件重新处理的现象。排查手动开关时，应先在 Settings 中暂时关闭 On Demand，只测试 Home 的手动开关。若手动连接恢复，说明系统授权和基本配置大体可用，下一步应逐条检查 On Demand 条件，而不是重建服务器。

检查条件时，从最具体的网络条件开始。若某条条件用于特定 Wi-Fi，应核对名称是否完全一致，包括空格和大小写；若条件基于网络类型，应确认设备当时确实处于对应网络。一次只启用一条条件，锁屏后重新解锁，再进行 Wi-Fi 与蜂窝之间的切换测试。只有每条条件独立工作后，才适合重新组合，避免多个条件互相覆盖。

重建系统连接而不破坏已有数据

确认授权完整、On Demand 已暂时关闭，但开关仍立即回落时，先正常退出 Shadowrocket，再重新打开；随后切换一次飞行模式，让系统重新建立网络接口。若问题只在某个 Wi-Fi 出现，可忽略该网络后重新加入，排除 DHCP 或局域网状态残留。若 Wi-Fi 与蜂窝都相同，再考虑重新创建系统中的 Shadowrocket VPN 配置。操作前应确认自己的服务器信息和 Config 已有可靠副本。

重建系统连接的目标只是让系统重新接受 VPN 配置，并不要求删除订阅或逐个删除服务器。完成后先关闭 On Demand，选择一个参数明确的服务器，将 Global Routing 设为 Proxy，只测试一个普通页面。如果开关能够保持开启，再按“连接后无法上网”章节继续；如果仍然立即回落，则重启设备后复测，并确认设备没有处于限制修改 VPN 的管理状态。

识别设备管理与网络限制

由组织管理的设备可能限制添加或修改 VPN 配置，系统通常会在授权时给出提示。此类限制不能通过更改 Shadowrocket 的协议参数解决，需要由设备管理方确认允许的网络策略。家庭网络中的路由器限制则通常不会让开关立即回落，而会表现为连接后服务器不可达，因此两者应根据开关是否能稳定保持来区分。

最终验证应保持条件简单：当前基础网络正常、On Demand 关闭、Global Routing 为 Proxy、只选一个服务器、连接后等待状态稳定。若完成这些步骤后开关可用，再逐项恢复原有设置，每恢复一项便测试一次。这样可以准确找到触发回落的设置，而不是在恢复全部配置后重新面对同一个问题。

三、连接成功但网页与应用无法上网

开关保持开启、系统也显示 VPN 状态，但网页和应用没有数据，是最容易混淆的一类故障。它可能由不可用服务器、协议参数错误、规则把全部请求送入错误策略、DNS 无法解析，或局域网地址被错误处理引起。应先判断是“所有请求失败”还是“部分请求失败”，再决定检查 Proxy、Config 或 DNS。

先用 Direct 与 Proxy 划分故障层

保持 Shadowrocket 开启，将 Global Routing 设为 Direct。若 Direct 也无法访问普通页面，说明问题更接近系统网络接口、本地网络或连接配置；此时先切换 Wi-Fi 与蜂窝，确认原始网络能否传输。如果 Direct 正常，再改为 Proxy。若 Proxy 全部失败，重点转向当前服务器、端口、协议与认证参数；若 Proxy 正常而 Config 失败，服务器本身通常不是首要原因，应检查规则与策略引用。

测试过程中应固定目标页面，不要每次使用不同站点。浏览器可能保留缓存，某些应用也会自动重试，因此可准备两个普通 HTTPS 页面，并在每次切换姿态后等待连接稳定再刷新。若一个页面正常、另一个页面失败，应记录失败域名并在 Data 或连接日志中查看它最终命中了哪条规则，而不是把结果概括成“网络时好时坏”。

检查 Config 中的策略名称和规则顺序

Config 按规则从上到下匹配，先命中的规则决定处理策略。规则末尾的 PROXY、DIRECT、REJECT 或自定义策略名称必须与当前配置中实际存在的策略一致。如果导入的 Config 引用了一个不存在的策略组，请求可能无法按预期处理。尤其在替换配置后，服务器仍然存在并不代表旧配置里的策略名称仍然有效。

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

上例中，特定域名先交给 PROXY，局域网地址直接连接，随后处理 GEOIP，最后由 FINAL 兜底。真实配置应按自己的使用目的安排顺序。若把 FINAL 放在中间，后面的规则不会获得匹配机会；若误把常用域名交给 REJECT，则会表现为单个站点立即失败；若局域网地址没有 Direct 规则，打印机、路由器管理页或其他本地设备可能在 Shadowrocket 开启后不可达。

查看请求是否真正发出

在 Data 中观察失败请求时，重点查看域名、连接结果、命中规则与策略，而不是只看总流量。完全没有记录，可能说明应用未发出请求、请求由缓存直接处理，或系统网络尚未恢复；有域名但解析失败，应进入 DNS 章节；有目标 IP 但建立连接超时，应检查服务器或目标路径；立即出现拒绝结果，则检查 REJECT 与目标站点响应。

某些应用会维持长期连接。切换 Global Routing 或服务器后，旧连接不一定立即重建，因此测试时应彻底关闭目标应用后重新打开，或等待其主动建立新会话。只在浏览器里反复刷新不能代表所有应用的行为。若浏览器正常而单个应用异常，先检查该应用是否使用特殊连接方式、是否缓存旧 DNS，及 Config 中是否存在针对其域名或 USER-AGENT 的规则。

处理局域网与网络切换边界

从 Wi-Fi 切到蜂窝时，原有连接会经历网络接口变化。Shadowrocket 通常会重新建立会话，但正在传输的请求可能失败一次。应等待状态稳定后重新测试，不要把切换瞬间的失败视为持续故障。如果每次切换后都无法恢复，检查 On Demand 条件是否在新网络上选择了不同姿态，或者 Config 是否对局域网和蜂窝使用了不一致的 DNS。

若只有局域网设备不可访问，应确认其地址范围，并使用适当的 IP-CIDR 规则交给 DIRECT。规则范围不要任意扩大，以免把本应由其他策略处理的公网地址一起包含。完成修改后重新加载 Config，再通过具体局域网 IP 测试。有关规则自上而下匹配和 FINAL 的详细说明，可阅读自定义规则与优先级。

四、节点显示超时或连接测试失败

服务器列表中的超时通常表示测试请求没有在限定时间内完成，但“超时”本身不能直接说明是服务器停止响应。域名解析失败、端口不可达、协议参数不一致、当前网络丢包、服务端限制或测试目标响应慢，都可能产生相似结果。正确做法是把“能否解析”“能否到达端口”“能否完成协议交互”“实际请求能否传输”分开判断。

理解 Connectivity Test 的边界

Connectivity Test 用于快速比较当前条目是否能够完成指定测试，但测试数字不是完整的使用体验。一次结果较高可能来自当时的网络抖动；一次超时也可能是短暂丢包。应在相同网络下间隔测试数次，观察是否持续超时，并用实际 HTTPS 页面复核。不要连续高频测试整个列表，这会同时占用本地网络与服务器连接，反而使结果更难解释。

如果只有一个条目持续超时，而同一订阅中的其他条目正常，优先检查该条目的服务器地址、端口与服务端状态。如果全部条目同时超时，先测试基础网络和 DNS，再换到另一种本地网络。全部条目在 Wi-Fi 超时、蜂窝正常，问题更可能位于当前 Wi-Fi、路由器或其上游路径；两种网络都相同，则应核对导入内容是否完整以及服务端是否发生统一变化。

逐项核对协议参数

手动添加服务器时，SERVER、端口、密码或认证信息、协议类型及其附加选项必须与用户已有的服务器信息一致。Shadowsocks 需要核对加密方式与密码；VMess、VLESS、Trojan 需注意地址、端口、身份信息以及 TLS、传输方式和 Host 等附加字段；WireGuard 需核对密钥、地址与路由范围；Hysteria2 还涉及对应认证与传输参数。不同协议字段不能凭经验互相套用。

通过 Scan QR Code 或 Import from Cloud JSON 导入后，也应打开条目检查关键字段是否齐全。二维码能够被识别，只说明文本格式可解析，不等于其中的服务器参数仍有效。若服务商已经调整服务器信息，应以用户从自己的服务商处取得的当前内容为准。不要在不知道含义时随机打开 TLS 选项、更换传输方式或改写 Host，这些变动往往会让原本接近正确的配置彻底不匹配。

区分延迟、丢包与吞吐

延迟反映一次往返所需时间，丢包会造成重传和停顿，吞吐则受服务器负载、路径容量、协议开销和本地网络共同影响。低延迟条目不一定在持续传输中更快，高延迟条目也不一定无法使用。因此选择时应先排除持续超时，再用相同任务比较稳定性。详细方法可参考延迟测试与真实体验的区别。

如果测试由正常突然变成全体超时，应回想变化发生前是否更新了订阅、切换了 Config、改变了 DNS 或更换了网络。恢复到上一个可确认的状态，一项一项重新应用变化。若确认地址和参数正确，但在不同网络、不同时间仍持续超时，应把测试时间、协议名称和脱敏后的错误现象交给自己的服务商确认服务端，而不是继续修改客户端中无关的规则。

五、Subscribe 更新失败或导入后为空

Subscribe 的作用是从用户已有的订阅地址读取服务器列表。更新失败可能发生在地址输入、HTTPS 访问、DNS、服务端响应、内容格式或本地列表写入阶段。导入后为空则不一定代表请求没有成功，也可能是返回内容不含 Shadowrocket 能识别的条目，或者原有筛选条件让条目没有显示。排查时应保护订阅地址，因为其中可能包含专属凭据。

先检查地址是否完整

在 Subscribe 中打开对应项目，核对地址开头、域名、路径和查询部分是否完整。复制时最常见的问题是前后混入空格、聊天工具截断较长地址，或只复制到问号之前。不要把真实地址粘贴到公开测试网站，也不要在截图中暴露完整查询内容。需要与服务商沟通时，可只展示域名和错误提示，并遮盖路径中用于识别账户的部分。

可先关闭 Shadowrocket 连接，使用当前基础网络访问订阅域名，判断域名是否能建立 HTTPS 连接；这一步不要求公开内容，只用于确认本地网络和域名解析。若关闭连接可访问、开启后失败，检查 Config 是否对订阅域名使用了错误策略。可以在规则靠前位置为该域名指定一个能够正常工作的策略，再重新更新，但不要把未知域名随意加入大范围规则。

区分网络失败与格式失败

网络失败通常表现为超时、无法解析域名或连接被中断；格式失败则可能快速完成请求，但没有生成服务器条目，或出现无法识别内容的提示。前者应按 DNS 与本地网络方向排查，后者需要确认服务端返回的是适用于 Shadowrocket 的当前订阅格式。客户端能够打开一个 URL，并不意味着返回文本一定包含可导入的数据。

若同一地址此前可以更新，近期突然为空，先不要删除旧列表。记录旧条目数量与更新时间，手动更新一次并观察结果；如果新内容异常，保留旧数据有助于继续验证。确认服务端恢复后再更新。若已经覆盖，重新导入前应先确认地址仍有效。订阅内容由用户自己的服务商维护，客户端无法修复服务端返回的空文本、错误页面或失效身份信息。

处理重复、重命名和筛选

多次添加同一地址可能生成多个 Subscribe 项目，使用户误以为更新没有作用，实际查看的是另一个列表。应核对订阅名称和地址域名，保留需要的项目，再手动更新。若使用了备注、排序或筛选，暂时清除筛选条件，确认新条目是否已写入。名称变化也可能让熟悉的条目看似“消失”，此时应按服务器地址和协议类型核对，而不是只凭显示名称判断。

订阅更新只负责同步服务器信息，不会自动保证当前 Config 中所有策略名称都与新列表一致。如果更新后服务器存在，但 Config 引用的自定义策略找不到可用成员，Config 姿态仍可能无法上网。可先用 Proxy 直接选择一个新条目测试，确认条目本身可用，再处理 Config 的策略关系。这样能避免把订阅写入成功误判为规则失效，也能避免把规则问题误判为订阅问题。

建立稳定的更新顺序

建议在基础网络正常时执行更新：先确认关闭连接能够访问普通页面，再更新单个 Subscribe；更新完成后查看条目是否变化；选择一个条目执行 Connectivity Test；最后再启用原有 Config。自动更新间隔不宜短到频繁打断使用，也不应依赖每次连接时同时完成大量请求。若更新只在某一网络失败，应记录网络类型，转到 DNS 章节继续判断。

如果错误发生在扫描或文件导入，Scan QR Code 需要完整清晰的内容，Import from Cloud JSON 则需要结构符合应用可识别的格式。能够选择文件并不代表文件内容正确。导入前保留原始数据，出现错误时回到信息来源重新取得有效内容，不要手工猜测缺失字段。完整上手路径可参阅使用说明中的导入步骤。

六、速度慢、视频停顿或连接不稳定

速度问题应拆成设备本地网络、服务器状态、传输路径、协议特性与目标站点五层。单次测速数字无法代表持续体验，某个应用停顿也不能直接证明服务器吞吐不足。有效的排查需要相同设备、相同网络、相同时间段和相同测试任务，只改变一个变量，并至少重复两到三次。

先测基础网络的上限

关闭 Shadowrocket，在当前 Wi-Fi 或蜂窝网络下完成一次基础测试，并观察是否存在明显抖动。若基础网络本身不稳定，开启连接后通常只会放大重传与延迟，不应先调整协议。Wi-Fi 环境还需观察与路由器的距离、频段拥塞、同一网络中其他设备的大流量任务，以及设备是否正在进行系统同步。切换到蜂窝复测，可以快速判断问题是否只属于当前 Wi-Fi。

测试下载、网页打开和视频播放时，应分别记录“开始响应需要多久”与“持续传输是否稳定”。前者更多受 DNS、握手和延迟影响，后者更接近吞吐与丢包。网页首屏慢但后续传输正常，可能是解析或握手路径较长；很快开始但中途反复停顿，则更应关注丢包、服务器负载和路径波动。

比较服务器时保持其他条件一致

选择两个用户已有且参数完整的服务器，将 Global Routing 暂时设为 Proxy，在同一网络下用同一任务测试。不要一边更换服务器一边改变 DNS 或协议选项。若只有一个服务器持续较慢，问题更接近该服务器或其路径；若所有服务器都慢，而关闭连接正常，检查本地网络对相关协议的传输质量、DNS 与设备状态；若关闭连接也慢，应先处理基础网络。

服务器地区只是影响路径的因素之一，不能仅根据名称判断速度。实际路径可能受网络时段、服务端负载与目标站点接入位置影响。Connectivity Test 较低只表示测试往返较快，不保证持续吞吐更高。应优先选择多次测试稳定、实际任务连续、错误率低的条目，而不是只追求列表中的最小数字。

检查协议与附加参数是否匹配

协议设置错误通常不仅是速度慢，还会伴随重连、握手失败或完全不可用。若连接能够工作但不稳定，应先确认参数与服务端一致，再考虑网络特性。不要为了追求速度随意更换加密方式、TLS、传输方式、UDP 相关选项或 WireGuard 路由范围。客户端与服务端不匹配时，任何所谓“优化”都没有可靠基础。

部分实时应用依赖 UDP，部分网络对 UDP 的表现可能与 TCP 不同。若网页正常但实时语音、游戏或视频通话异常，应记录应用类型和网络类型，并在自己的服务器信息允许的范围内确认 UDP 支持。该判断不应通过盲目切换所有选项完成，而应依据协议要求逐项核对。无法确认服务端能力时，应向自己的服务商询问当前服务器支持的参数。

处理时段性与切换后的短暂波动

若白天正常、固定时段变慢，应在相同时段比较基础网络和多个服务器，而不是跨时段比较。网络拥塞往往具有时间特征，只有同时记录关闭连接结果，才能区分本地接入拥塞与服务器路径变化。切换 Wi-Fi、蜂窝或服务器后，旧连接可能继续存活一段时间，应重新打开目标应用，让它建立新会话再判断。

完成测试后恢复 Config，并检查速度问题是否只影响某类域名。若 Proxy 正常而 Config 慢，可能是该域名被 Direct 处理，或 DNS 选择了不合适的地址。此时继续增加服务器测试没有意义，应查看规则命中和 DNS 结果。更完整的分层案例可阅读速度慢的四层定位方法。

七、DNS 解析失败、域名打不开或结果异常

DNS 把域名转换为 IP 地址。DNS 异常常表现为域名打不开、直接输入 IP 却可能有响应、部分域名时好时坏，或切换网络后短时间使用旧结果。它也可能与规则共同作用：Shadowrocket 需要先知道域名或目标地址，随后再按 DOMAIN-SUFFIX、GEOIP、IP-CIDR 等规则决定策略。解析与分流不是同一层，但两者会互相影响最终表现。

先判断是不是解析问题

选择一个失败域名和一个正常域名，在相同状态下分别测试。若 Data 中失败请求显示无法解析、没有目标 IP 或很快返回 DNS 相关错误，解析问题的可能性较高。若已经得到目标 IP，但连接阶段超时，则应回到服务器或路径排查。不要仅凭浏览器显示“找不到服务器”就下结论，因为浏览器可能用统一提示覆盖不同底层错误。

比较 Direct、Proxy 与 Config 的结果。Direct 正常、Config 异常，可能是配置中的 DNS 设置或规则造成差异；Proxy 正常、Direct 异常，可能是当前本地网络 DNS 对目标域名响应异常；三种姿态都失败，则应检查域名本身、设备网络和缓存。每次切换后重新打开浏览器标签，必要时短暂切换网络以促使系统建立新的解析流程。

检查 Config 中的 DNS 与 Host

.conf 的 General 段可以包含 DNS 相关设置，Host 段则可为特定域名指定映射。错误的 Host 项会让域名始终指向不正确的地址，即使外部 DNS 正常也无法恢复。检查时先搜索失败域名是否出现在 Host 段，再检查 General 中的 DNS 设置是否来自可信且当前可达的来源。不要同时加入多个不理解用途的解析选项。

[General]
dns-server = system

[Host]
router.example.com = 192.168.1.1

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

示例使用 system 作为说明性设置，并给局域网示例域名指定地址。真实配置应根据自己的网络需求决定。Host 映射具有明确覆盖作用，地址变化后若没有同步修改，会产生稳定但错误的结果。排查未知配置时，可先保存副本，再暂时移除与失败域名相关的 Host 项复测。配置文件各段结构可参考General、Rule、Host 与 URL Rewrite 说明。

理解域名规则与 IP 规则的先后关系

DOMAIN、DOMAIN-SUFFIX 和 DOMAIN-KEYWORD 依据域名匹配，IP-CIDR、IP-CIDR6 与 GEOIP 依据目标地址匹配。若域名规则已经命中，后续 IP 规则通常不再决定该请求；若没有域名规则命中，解析得到的 IP 可能继续参与 GEOIP 或 IP-CIDR 判断。规则顺序不合理会让请求走到意外策略，表面看起来像 DNS 返回错误，实际是匹配结果不符合预期。

排查单个域名时，可临时在靠前位置添加精确 DOMAIN 或合适的 DOMAIN-SUFFIX 规则，并指定已验证可用的策略。若问题消失，说明原规则路径值得继续检查；如果仍失败，则应查看 DNS 与目标连接。临时规则验证完成后应整理回正式配置，避免长期积累大量互相覆盖的例外项。

清理缓存时保持操作有序

系统、浏览器和应用都可能缓存 DNS。更改 DNS 后立即刷新一次，不一定会产生新解析。可关闭目标应用，断开 Shadowrocket，切换一次飞行模式后重新连接，再测试同一域名。不要同时重启路由器、删除 Config、修改服务器和清理应用数据；这些操作叠加后即使恢复，也无法识别原因。

若只有某个 Wi-Fi 出现解析异常，检查路由器分配的 DNS、局域网中的自定义解析以及是否存在失效的本地域名映射。蜂窝正常可作为对照，但不意味着 Config 一定正确。如果多个网络都对同一域名返回异常，检查 Host、规则和域名本身。记录失败域名、命中策略、是否获得 IP 和网络类型，通常足以把问题定位到解析前、解析中或解析后三个阶段。

八、耗电异常与 App Store 更新后异常

Shadowrocket 作为网络扩展持续处理流量，连接时产生一定电量消耗属于正常现象。需要排查的是相同使用场景下电量消耗突然明显增加、设备持续发热、后台流量长时间不下降，或从 App Store 更新后原有配置行为发生变化。判断时应结合系统电池统计、Data 中的流量活动、网络质量和最近的设置变化，而不是只看某一小时的百分比。

区分客户端处理与应用流量

系统电池统计可能把经由网络扩展处理的活动计入 Shadowrocket，但真正持续产生流量的可能是前台视频、云同步、照片上传或其他后台应用。先在 Data 中观察连接是否持续有请求，再逐个暂停高流量应用。若停止相关应用后流量和发热很快下降，重点应放在流量来源，而不是立刻修改协议。

网络信号差会增加重传和无线电工作时间。蜂窝信号较弱、Wi-Fi 边缘覆盖或网络频繁切换时，设备可能不断重建连接。应在稳定 Wi-Fi 下使用相同服务器和 Config 复测一段时间。如果稳定网络下恢复正常，说明耗电与当前接入环境关系较大。持续超时的服务器也会触发重试，应先换到已确认可用的条目。

检查 On Demand 与高频后台行为

On Demand 条件若反复满足和失效，可能使连接频繁建立与断开。查看问题是否集中在离开某个 Wi-Fi、锁屏解锁或网络切换之后。排查时暂时关闭 On Demand，改用手动连接；若耗电和发热下降，再逐条启用条件。条件应清晰、互不冲突，不要让同一网络同时满足连接和断开逻辑。

Subscribe 的自动更新、Connectivity Test 和大量并发请求也会产生短时活动。不要设置过于频繁的更新节奏，也不要在后台连续测试全部服务器。若 Config 中存在复杂的脚本化处理或大量规则，先使用简化配置复测，判断问题是否与特定处理链有关。简化测试必须保留原配置副本，确认后再逐项恢复。

更新后先验证配置是否仍完整

Shadowrocket 的唯一获取与更新入口是 App Store。更新完成后若出现异常，先不要删除所有数据。依次确认当前服务器仍被选中、Subscribe 项目仍存在、Config 仍是原来使用的项目、Global Routing 没有被改成测试姿态、On Demand 条件仍符合当前网络。界面位置可能调整，但应以当前应用内实际标签为准。

接着执行一组最小测试：关闭 On Demand，Global Routing 设为 Direct，确认基础网络；改为 Proxy，选择一个参数明确的服务器；最后恢复 Config。若 Direct 与 Proxy 正常而 Config 异常，应检查配置兼容性和规则；若 Proxy 异常，重新核对服务器参数；若开关无法保持，则回到第二章检查系统授权与 VPN 配置。这个顺序可以避免把更新后的单项变化误认为全部数据损坏。

何时需要重启或重新建立配置

更新后系统网络扩展状态没有正确收敛时，正常退出应用并重启设备可以清除暂时状态。若重启后仍无法建立连接，再考虑重新创建系统 VPN 配置，但不应先删除服务器和订阅。重新建立后使用最简单条件测试，确认成功再恢复 On Demand。设备受管理时，还应确认管理策略没有在同一时间发生变化。

如果耗电问题只能在特定协议、特定服务器或特定网络复现，应把这三个条件固定下来，比较前后结果。若所有配置在不同网络都持续异常，可记录系统电池统计时间段、Data 活动情况与复现步骤，再等待 App Store 后续提供的更新说明。本站不编写版本号或发布日期，实际变更内容以 App Store 页面为准。

九、iPad 专项：分栏、网络切换与已购恢复

iPad 上的 Shadowrocket 与 iPhone 使用相同的核心概念，但横屏分栏、多任务、键盘操作、Wi-Fi 使用比例和后台状态会让故障表现有所不同。排查时不要只照搬 iPhone 上的点击位置，应根据当前横屏或竖屏布局确认 Home、Config、Settings、Data 和服务器详情所在区域。系统要求与兼容性始终以 App Store 页面标注为准。

先确认购买与应用身份

已使用同一 Apple ID 购买 Shadowrocket 时，可从 iPad 的 App Store 已购项目中查找并重新下载。若商店显示状态与预期不符，应先核对当前登录账户、商店地区以及开发者 Shadow Launch Technology Limited 和应用 ID 932747118。详细步骤见iPad 获取说明与已购恢复说明。

Shadowrocket 是一次性买断客户端，但客户端一次性买断 ≠ 线路套餐。iPad 重新下载应用不会自动产生服务器信息；用户仍需使用自己已有的订阅或服务器信息。若 iPhone 中已有配置，迁移时应使用应用支持的导入方式并检查敏感字段，不能只依赖界面截图重新输入，因为较长身份信息和协议附加参数很容易遗漏。

理解横屏分栏造成的“找不到”

横屏时列表与详情可能同时显示，选中项的内容会出现在另一栏。用户点击 Config 或服务器列表后若认为“没有打开”，应观察右侧详情是否已经变化。竖屏时同一内容可能采用逐层进入方式，因此返回路径也不同。切换方向后若布局没有及时更新，可先等待界面重排，再关闭并重新打开应用，不必因此删除配置。

外接键盘和触控板不会改变规则逻辑，但可能让焦点停留在搜索框或编辑字段，导致滑动和快捷操作与预期不同。编辑服务器参数后，应明确完成保存并返回列表，确认当前条目仍被选中。iPad 屏幕能够同时展示更多字段，也更容易让用户误把详情栏中的旧条目当作当前条目，因此测试前应回到 Home 核对实际选中的服务器名称。

处理 Split View 与后台恢复

在 Split View 或其他多任务状态下，应用窗口尺寸会变化，网络扩展则继续由系统管理。缩小窗口不会直接断开连接，但目标应用进入后台、网络从 Wi-Fi 切换或系统回收资源时，原有会话可能需要重建。排查某个应用在分栏中无法联网时，先让两个应用分别全屏测试，再恢复分栏。若全屏正常、分栏异常，应关注目标应用的后台与会话恢复，而不是先改 Shadowrocket 规则。

锁屏较长时间后重新打开 iPad，状态栏可能先显示旧状态，随后才完成网络恢复。应等待 Wi-Fi 图标和 VPN 状态稳定，再发起测试。若 On Demand 已启用，观察它是否按当前 Wi-Fi 条件建立连接；若没有，暂时关闭 On Demand 并手动开启，以区分条件判断和连接本身。频繁开合保护套造成的锁屏切换，也可能放大条件配置不合理的问题。

检查 iPad 常见的 Wi-Fi 场景

iPad 常在固定 Wi-Fi 中长时间使用，因此 DHCP 地址变化、路由器重启、本地 DNS 缓存和局域网设备访问问题更容易积累。关闭 Shadowrocket 测试基础网络，再用 Direct 检查系统连接，最后用 Proxy 检查服务器。如果只有打印机、文件设备或路由器页面不可访问，应确认局域网 IP-CIDR 规则交给 DIRECT，而不是替换远端服务器。

在需要网页登录确认的公共 Wi-Fi 中，应先关闭连接，完成网络本身的登录流程，确认普通网页可用后再开启 Shadowrocket。登录页没有完成时，服务器测试通常会统一超时，容易被误判为订阅或协议问题。若从一个 Wi-Fi 移动到另一个同名网络，On Demand 可能仍按名称处理，但两个网络的实际环境不同，因此应结合地址和可访问性复测。

迁移 Config 后逐层验证

从其他 Apple 设备导入 Config 后，先检查 [General]、[Rule]、[Host] 与 URL Rewrite 是否符合 iPad 当前网络。固定局域网地址、特定 Wi-Fi 的 DNS 或只适用于原网络的 Host 映射，都可能在 iPad 上产生差异。不要一次启用所有附加处理；先验证服务器，再验证基础规则，最后恢复 Host 与改写项。

完整验证顺序仍然是 Direct、Proxy、Config。iPad 上若浏览器正常而分栏中的某个应用异常，关闭该应用后重新打开，让它建立新连接；若所有应用都异常，查看 Data 是否有请求和规则命中；若连接开关回落，检查系统授权；若仅域名失败，检查 DNS。有关 iPad 的已购重新下载和布局差异，可继续阅读iPad 重新下载与横屏分栏说明。

如果按本手册仍无法定位，请整理可重复步骤：设备类型、网络类型、Global Routing、协议名称、是否仅单个服务器受影响、Connectivity Test 结果、规则命中与错误发生时间。向自己的服务商反馈时只提供脱敏信息，不展示完整订阅地址、密码或身份字段。