Shadowrocket故障排查大全

连接开关打不开与 VPN 配置权限

开关刚打开就退回关闭状态，先检查系统是否允许建立 VPN 配置，而不是立即更换订阅。服务器不可达通常出现在连接建立后的请求阶段；如果系统配置尚未获准，服务器参数再正确也不会进入正常转发。先关闭连接，确认设备本身可以浏览普通网页，再观察重新打开开关时是否出现系统授权、身份验证或管理限制提示，并记录提示的完整内容。

首次授权与误点拒绝后的处理

在 iPhone 或 iPad 上，首次启动连接可能出现添加 VPN 配置的系统提示。确认操作来自刚打开的 Shadowrocket 后允许添加，并按系统要求完成设备身份验证。允许添加只代表系统同意建立网络扩展配置，不表示订阅已有效，也不表示服务器一定在线。若此前点了拒绝，返回应用重新尝试；如果不再弹出提示，再到系统设置的 VPN 管理位置检查是否存在对应配置。

系统设置的菜单层级会随系统调整，可通过设置搜索查找 VPN。检查配置名称和所属应用，避免把其他用途的配置误当作 Shadowrocket。若对应项目已损坏或重复，先保存应用内配置、关闭连接，再移除确认属于 Shadowrocket 的失效项目，返回应用重新授权。不要一并删除学校、单位或设备管理下发的配置；这类项目可能由管理策略控制，应先确认设备的使用权限。

开关回落、自动重连与配置冲突

如果授权完成但开关仍立即回落，检查是否有另一个 VPN 连接正在接管网络，包括具有 VPN 接口的网络过滤工具。临时停止其他连接后再测试，不要同时改变 DNS 和规则。若开关关闭后又自行打开，优先检查 On Demand 以及系统中对应的按需连接设置；这是连接触发条件与手动操作发生了交叠，不能单凭开关变化认定应用崩溃。

受管理设备可能限制添加 VPN 或修改网络扩展。此时反复重装不会解除策略，还可能丢失现有配置。先看系统是否显示管理描述文件，再将限制提示交给设备管理员确认。普通个人设备则可以在保存配置后重启一次，排除网络扩展暂时未释放的状态。重启后先测试最小配置与一个已有服务器，确认开关稳定，再恢复 On Demand 等自动化条件。

区分权限问题与程序退出

应用退到后台并不等于连接停止，应以系统 VPN 状态和实际请求为准；但如果打开特定配置就退出，应单独保留该配置副本，检查近期新增的规则、外部资源与异常长的配置内容。不要连续导入同一份文件制造更多副本。可先选用此前正常的配置复测：旧配置正常而新配置异常，说明应继续检查配置差异，不必先处理账号或订阅有效期。

桌面与安卓遇到首次启动拦截时，应先按下载页的安装放行说明完成系统确认，再回到连接诊断。Mac 可在隐私与安全性查看“仍要打开”，Windows 可在确认包来源后查看 SmartScreen 的更多信息，安卓需为实际执行安装的应用允许安装未知应用。安装阶段无法启动和连接阶段无法联网是两类问题，应分别记录，避免把放行操作当成网络修复。

已连接却无法上网：先分清分流模式

系统显示 VPN 已连接，只能说明网络扩展处于工作状态，不能证明所有请求都成功到达目标。遇到全部网页打不开，先关闭 Shadowrocket，用同一网络访问此前能够直连的页面。如果关闭后仍失败，应先处理 Wi-Fi、蜂窝数据、网络认证或系统时间；如果关闭后恢复，再围绕所选服务器、Global Routing 和 DNS 做对照。每次测试都应使用同一个目标，避免混入网站本身的变化。

使用三种模式建立对照

Global Routing 的 Config 按当前配置处理流量，Proxy 用于把适用的请求交给代理路径，Direct 用于直连对照。排错时可以临时切换，但应先记录原模式及选中的配置。若 Proxy 正常而 Config 失败，优先检查规则命中、策略指向与配置资源；若 Proxy 失败而 Direct 正常，优先检查服务器或代理路径；若两者都失败，则需要回到基础网络、DNS 和目标服务检查。

上述结果是定位线索，不是绝对证明。某些目标本身无法通过当前直连路径访问，Direct 失败便没有比较意义；应用也可能沿用已建立的连接，使刚切换模式的请求仍使用旧路径。切换后关闭目标应用的旧页面，再发起一个新的请求；必要时断开并重新连接 Shadowrocket。不要只刷新一个长期停留的页面就下结论，也不要用 VPN 图标代替实际访问验证。

检查规则顺序与最终策略

Config 下检查当前真正选中的文件，而不是仅查看文件列表中刚导入的名称。规则通常按顺序匹配，较宽泛的条目放在前面可能抢先命中，最后的 FINAL 决定此前未命中请求的去向。下面是语法示例，不是可直接替换你现有配置的完整文件。示例域名只用于说明；在修改前，应先确认你的配置中 PROXY 与 DIRECT 所代表的处理方式。

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

如果只有某个网站失败，检查是否存在针对它的 DOMAIN、DOMAIN-SUFFIX 或 REJECT 条目，并查看该请求实际命中的规则。网站可能调用多个不同域名的登录、图片和接口服务，首页能打开不代表全部依赖都采用了正确策略。先从失败请求的域名追查，而不是把整个规则文件删掉。若命中策略引用了不存在的策略名或不可用服务器，应修复引用关系后再复测。

只在有证据时修改配置

可保留一份原配置，再建立只含必要规则的测试副本，用同一个已有服务器进行比较。测试副本恢复正常，说明问题更可能来自复杂规则、资源引用或附加设置；两份均失败，则回查服务器与解析。不要同时替换配置、订阅和系统网络设置，否则即使恢复也无法知道原因。需要理解三种模式的使用边界，可继续阅读Global Routing 三种模式说明。

修复完成后切回日常使用的 Config，并再次验证此前失败的页面、普通直连页面和一个常用应用。临时 Proxy 测试通过不代表分流已经修好。记录最终修改的是哪条规则、哪个策略或哪项解析设置，随后撤销用于测试的临时条目。保留这一组最小复现步骤，下次出现相同症状时便能直接比较，而不必从整份配置重新猜测。

节点超时与协议参数不匹配

节点超时需要按“地址解析、端口连接、协议握手、目标请求”四层拆开判断。Connectivity Test 没有返回结果，不一定表示服务器完全离线；测试目标不可达、测试方式不适配或协议握手失败，都可能显示相近现象。先记下失败发生在单个服务器还是整组服务器，以及是否只在某个网络出现。服务器信息应以从你的服务商处获取的当前资料为准，不凭名称推断协议。

先确认地址和端口能否到达

在服务器详情中核对地址是否混入空格、换行或协议前缀，端口是否与服务端一致。地址栏通常应填写主机名或 IP，而不是把完整网页地址原样塞入。若使用域名，先判断它是否能正常解析；若使用 IP，则仍可能需要单独填写用于 TLS 的服务器名称。只有某个 Wi-Fi 失败而蜂窝网络正常时，应检查该网络的登录认证、UDP 条件或出口限制，不要立即重置全部服务器。

整组服务器同时超时，还应检查是否来自同一域名、同一订阅或同一网络出口。看起来不同的名称可能实际共用同一个基础地址。先用已知此前可用的条目做对照，再确认服务端是否正在维护、授权是否仍有效。不要无限重复测试：连续并发探测会增加网络负担，也可能触发服务端限制。等待上一轮结束，保留少量代表性样本，通常更容易看出规律。

逐字段核对握手条件

端口可达但实际请求失败时，重点检查身份验证、加密方式和传输设置。Shadowsocks 的加密方法与密码必须匹配；VMess、VLESS 的用户标识和传输配置要与服务端一致；Trojan 需要核对密码与 TLS 条件。不要仅因为服务器地址相同就沿用旧字段。订阅更新可能改变传输方式，而手动创建的条目不会自动获得这些变更，应与当前资料逐项比较。

出现证书错误时，先检查设备日期、时间和时区，再核对服务器名称与证书是否匹配。不要把跳过证书验证当成常规修复；它会削弱连接身份确认，也无法解决地址错误或服务端证书过期。WebSocket 场景还要区分连接地址、Host 与路径各自的用途，某一项看似重复也不应随意删除。错误原文中的握手、认证或证书提示，比一个笼统的超时结果更有诊断价值。

测试结果与实际访问交叉验证

延迟测试只描述特定测试方式下的响应，不代表页面加载、持续下载和视频播放都正常。若测试失败但实际访问正常，先检查测试目标和方法；若测试正常但网页失败，应继续检查 DNS、规则和目标服务。使用同一网络、同一目标、同一配置比较多个已有服务器，才能缩小变量。相关选择方法见延迟测试、地区与协议类型说明。

需要向服务商反馈时，提供协议类型、失败网络、报错时间范围、是否所有服务器受影响，以及经过遮盖的错误信息。不要发送完整订阅链接、用户标识、密码或私钥。客户端侧能验证字段一致性与故障范围，但不能代替服务端日志；如果多个网络均在同一握手阶段失败，应由服务端确认认证、监听端口与证书，而不是持续在本地改变无关参数。

Subscribe 更新失败、空列表与重复条目

Subscribe 获取失败与订阅内服务器不可用是两件事。前者发生在下载、授权或解析订阅内容时，后者发生在已导入条目的连接阶段。先保留旧列表，记录更新时的错误原文，再判断是无法访问订阅地址、返回状态异常，还是内容无法解析。不要因为一次更新失败就删除仍然可用的旧条目；删除后重新添加可能让原本可比较的配置差异一起丢失。

检查链接完整性和访问路径

订阅链接从你的服务商处获取，复制时应包含完整查询参数。聊天应用自动换行、末尾标点、前后空格，以及把字符实体当成原始符号粘贴，都会改变链接。示例中的 token 仅说明格式，不能用于实际更新。不要在公开截图、问题标题或浏览器分享记录里展示真实链接；它往往包含能够读取你个人服务器列表的授权信息。

https://example.com/sub?token=xxxx

若报错与主机名解析、TLS 或超时有关，先关闭连接，确认基础网络可用，并检查设备时间。再观察当前更新请求是否依赖一条已经失效的代理路径；如果只有代理开启时更新失败，可以在记录原设置后临时使用可用的网络路径重试。不要假设订阅更新必然跟随某一种 Global Routing 行为，应以当前设置、请求记录和实际测试结果为准。

区分授权失败与内容格式错误

返回未授权、禁止访问或地址不存在时，先从服务商提供的信息确认链接是否撤销、重置或过期。反复刷新不会修复失效授权。若返回的是登录页面、网络认证页面或错误提示文本，即使网络请求成功，也不是客户端能直接导入的服务器数据。公共 Wi-Fi 尚未完成认证时尤其容易发生这种情况，应先在关闭连接的状态下完成网络登录，再重新获取。

请求完成但导入为空，检查来源提供的格式是否适用于当前导入方式。Subscribe、单个服务器链接、二维码和 Config 文件承担不同用途，不应互相替代。不要只根据文件扩展名判断内容，也不要把网页说明页地址当作订阅地址。若资料包含多种格式，按服务商标注选择适用于 Shadowrocket 的内容；缺少说明时先询问格式，而不是将同一地址在所有入口重复尝试。

处理更新后消失、重复与手动修改

更新后服务器数量变化，可能是远端列表调整、过滤条件变化或原条目被替换，不能直接视为客户端删除错误。先检查 Subscribe 对应的分组，再查是否把手动条目与订阅条目混在同一视图。订阅管理的字段可能在下一次更新时被远端内容覆盖；需要保留个别修改时，应先确认管理方式，必要时创建清楚命名的手动副本，并记录它不再自动跟随订阅更新。

重复条目通常来自同一链接多次添加、不同订阅包含相同服务器，或手动副本与自动更新列表并存。清理前核对每组的来源与更新时间记录，不要只凭显示名称删除。保留一个确认有效的 Subscribe 项，再逐步移除重复来源。若新列表覆盖了旧参数而连接开始失败，可对照尚未删除的副本查看地址、端口、TLS 与传输字段，把明确差异交给服务商核实。

恢复后建议暂停不必要的手动连续刷新，按实际需求更新，并保留最近一次有效配置副本。准备重新导入时，先阅读Subscribe 导入步骤，确保使用同一入口与正确类型；二维码来源则参考Scan QR Code 操作说明。如果授权链接疑似泄露，应从你的服务商处处理授权重置，再更新客户端记录，而不是仅修改本地显示名称。

速度慢、网页卡顿与连接中断

速度慢要先说明“哪一种慢”：首次打开等待很久、图片持续加载缓慢、大文件速率偏低，还是用一段时间后中断。它们分别可能与 DNS、握手、持续带宽、丢包或网络切换有关。记录发生时的网络、目标、所选服务器和是否正在进行其他下载，再与关闭 Shadowrocket 的同类操作比较。不要用一次延迟数字推断整条链路的吞吐，也不要把目标网站限速当成客户端性能问题。

建立可以重复的测试条件

优先选一个你平时稳定使用的目标，在同一地点与同一网络中重复操作。测试时暂停系统更新、云端同步和其他大流量任务，避免把争用带宽算作代理损失。Wi-Fi 信号格数不能完全代表传输质量；拥挤的无线环境、路由器负载和上行占满都可能造成等待。先比较靠近路由器与原位置的表现，再比较 Wi-Fi 和蜂窝网络，能够把局域网因素与远端链路因素分开。

比较多个已有服务器时保持目标、协议使用方式与测试时段尽量一致。某个服务器的地理名称并不能直接说明路径长短，延迟低也不保证高峰期有足够可用带宽。至少观察首次响应与持续传输两个阶段：前者慢而后者稳定，适合查解析与握手；前者快但后者持续停顿，则更应关注丢包、服务端负载或目标限制。测试数据只对当时条件有效，不宜据此给出固定排名。

检查分流与连接复用造成的错觉

页面不同资源可能命中不同规则，其中一组请求失败会拖住整页。先查卡住的域名，而不是只测试首页域名。Config 失败而临时 Proxy 正常时，回到规则与策略定位；两者都慢时再比较服务器和基础网络。切换服务器后，已存在的长连接可能继续使用原来的路径，因此应关闭相关会话并重新发起请求。只有新连接的结果，才适合用来判断切换是否生效。

若问题表现为通话、游戏或其他实时应用中断，应单独确认其是否需要 UDP，以及当前协议和网络是否允许相关流量。网页能打开并不能证明 UDP 正常；使用 UDP 的协议也可能在特定 Wi-Fi 下无法建立。不要随机改动 MTU 或传输参数，先证明故障只在某一类数据包或某种网络上发生。确需调整时，以服务端建议为基础，保留原值并逐项复测，避免把一种故障变成多种故障。

用 Data 与请求记录缩小范围

查看 Data 时，应先确认统计范围、时间段与当前连接状态。某服务器的流量增长，说明有数据经由该项处理，但不能证明目标全部加载完成。按应用观察时，还要考虑系统服务、后台刷新与缓存；一个页面从缓存打开，也不能用于测试实际速度。可先记下基准读数，执行一次明确的请求，再看增量与请求记录是否对应。详细读数含义见Data 页流量统计说明。

连接在息屏、离开 Wi-Fi 或进入蜂窝网络后才中断，优先把它记作网络切换问题。重新连接后若立即恢复，检查 On Demand 条件和原会话是否已经失效，而不是连续更换全部服务器。移动环境下网络地址变化很常见，某些长连接需要重新建立；是否能恢复新请求，比旧会话是否保持更能反映当前配置是否有效。可以在静止环境下复测，排除移动造成的干扰。

完成定位后撤销为测试加入的临时规则与特殊参数，恢复日常配置，再验证浏览、持续传输和网络切换三个场景。不要长期保留多组互相重叠的“优化”设置；额外设置本身也会增加诊断成本。能明确说明哪一项修改解决了哪一种症状，才算形成可复用的修复记录，而不是仅在某一次测试中偶然变快。

DNS 解析失败与规则命中异常

DNS 问题常表现为域名打不开、首次访问等待很久、部分资源失败，或同一网站在不同网络中结果不同。判断重点是解析是否完成、返回结果是否可达，以及解析请求走了哪条路径。不要把“使用域名失败、直接输入 IP 成功”当成唯一判据，因为 HTTPS 证书、虚拟主机与网站路由常依赖域名，直接访问 IP 可能得到完全不同的服务，无法形成可靠对照。

区分解析超时与解析后连接失败

先查看请求记录中的错误阶段。如果尚未得到地址就等待超时，检查 DNS 服务器的可达性及其使用路径；如果已经得到地址但连接失败，应转到目标连接、规则或 IPv6 路径检查。多个不同域名同时异常时，解析链路值得优先检查；只有单个域名异常，则还要考虑该域名本身的记录、证书或服务状态。记录失败的完整主机名，避免把接口子域与主页域名混为一谈。

设备可能同时受到系统 DNS、Wi-Fi 手动 DNS、应用内配置和其他网络过滤设置影响。先记录每一层原值，再确认当前实际生效的来源。不要同时在系统和应用中连续更换多组地址，这会让测试结果无法解释。使用加密 DNS 时，还需确认它的主机名自身能够解析、TLS 可以建立；把一种解析协议换成另一种，并不会自动消除到解析服务器之间的网络故障。

检查 DNS 与分流是否互相依赖

某些配置需要先解析服务器域名才能建立代理，但又把解析请求安排到尚未建立的代理路径，可能形成依赖循环。遇到启动阶段解析失败，应检查服务器地址的解析路径，而不只是网页域名。对照此前正常的配置，确认哪些请求使用系统解析、哪些使用配置内解析。修改时优先恢复一个能启动的最小路径，待服务器连接成立后，再逐步恢复其他 DNS 条件。

基于域名的规则与基于地址的规则处理对象不同。DOMAIN-SUFFIX 可以匹配指定域名及其子域；IP-CIDR、IP-CIDR6 和 GEOIP 则与地址有关。添加 no-resolve 的地址规则时，通常意味着不为匹配该规则主动触发域名解析，并不表示整个客户端关闭 DNS。下面仅演示规则结构：文档保留地址与 example.com 都是教学素材，不能代表你的局域网范围或真实业务需求。

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

IPv6、缓存与局域网边界

域名同时返回 IPv4 与 IPv6 时，两条路径的可达性可能不同。如果只在某个网络出现长时间等待，检查是否优先尝试了一条不可用的地址路径。可在保存原设置后临时调整相关 IPv6 选项进行对照，但不要把永久关闭 IPv6 作为普遍结论。测试应观察新请求是否恢复，并在其他网络复验；否则可能只是用一种网络的临时绕行，掩盖了配置与实际网络能力不一致的问题。

修改 DNS 后，旧缓存与已建立连接可能仍然有效。断开并重新连接，再新开目标请求，必要时重启目标应用；不要靠不断重装 Shadowrocket 清理缓存。局域网设备名称、打印服务或单位内部域名可能依赖本地解析，全部交给远端解析后反而失败。应为确有需要的本地名称与网络保留正确路径，并只在你信任的网络中测试内部地址，避免把敏感名称放入公开反馈。

最终验证需要同时覆盖普通域名、原先失败的域名及必要的本地服务。确认规则命中与解析结果符合预期后，再移除临时对照设置。若能稳定复现“某网络解析超时、另一网络正常”，保留这组差异提交给对应网络或服务端维护方；单独一张网页错误截图，通常无法说明故障究竟发生在解析、握手还是目标响应阶段。

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

判断耗电先看使用场景和观察时间段，而不是只看系统电池列表中的百分比。VPN 相关处理可能包含其他应用经由网络扩展产生的工作量；某项占比升高，也可能只是同一时段其他应用耗电下降。先记录是否持续传输、是否处于弱信号环境、设备是否充电，以及问题从哪次配置变化后开始。刚更新系统、恢复资料或进行云端同步时，不宜立即把短时发热归因于代理。

区分持续工作与异常重试

在网络稳定、设备温度正常的条件下，分别观察连接开启但少量使用、持续下载和关闭连接的同类时段。保持屏幕亮度、前台应用及网络尽量一致，才能进行有意义的对照。若只有大量传输时耗电增加，可能主要来自无线通信与加密处理；若几乎没有主动操作却持续发热，则需要检查后台应用、连接重试、日志写入和自动更新任务，而不是先修改协议参数。

在请求记录中寻找密集重复的失败：同一个主机持续超时、订阅反复刷新、服务器认证不断失败，都可能让设备反复建立连接。先修复最早出现的错误，后续的重试往往随之减少。不要把降低所有超时值当成节电方式，过短的等待反而可能制造更多重连。也不要频繁手动执行整组 Connectivity Test；大范围探测本身就是额外网络活动，会干扰耗电观察。

检查 On Demand 与网络切换

On Demand 需要与真实使用环境一致。Wi-Fi 信号边缘、蜂窝网络切换或网络名称条件设置不当，可能让连接反复进入启动与停止流程。先记录触发条件，再临时关闭自动触发，保持手动连接一段时间作为对照。如果耗电与频繁重连同时减少，应逐条恢复条件，找出触发循环的那一项。不要仅关闭应用界面便认为后台连接停止，应查看系统 VPN 状态。

若设备常在两个 Wi-Fi 之间移动，或休眠后重新接入网络，已有会话可能失效并重建。这种情况应先观察重新连接是否很快稳定，而不是把每次重建都判成异常。真正需要关注的是持续失败、短时间重复切换或设备在无业务时仍长期工作。可以在固定位置、单一网络中复测；固定环境正常而移动环境异常时，优先处理无线覆盖、网络切换和按需条件。

减少诊断期间的额外负担

为排错开启的详细日志、长时间流量记录和大量测试，应在取得必要信息后恢复日常设置。保存少量能复现问题的记录即可，不必持续积累全部请求。若配置还包含定时更新或其他周期任务，逐项检查频率与失败重试情况，先停用非必要项目做对照。每轮只变更一个任务，观察同类场景下温度与电池变化，避免同时停掉所有功能后无法识别真正原因。

不同协议、传输方式与网络质量会影响处理成本，但不能脱离服务端条件任意切换。首先确认所用参数有效、连接稳定，再比较已有可用服务器的表现。弱信号下反复发送、丢包后重传以及大量小请求，都可能比协议名称本身更重要。不要追求一个没有上下文的固定耗电数值；设备电池健康、屏幕使用和环境温度都会改变结果，应以同设备前后对照为主。

如果关闭 Shadowrocket 后相同场景仍然异常，应继续检查系统电池记录、后台同步和网络信号，而不是反复重新导入订阅。若异常仅随某份配置出现，保留原文件并用最小测试配置复现，重点比较自动任务、连接触发与失败重试。修复后至少覆盖一次静置和一次正常使用过程，确认没有持续重连；系统电池统计存在时间窗口，不能期待修改后一刻就完全反映变化。

反馈耗电问题时，写清设备类型、系统环境、使用网络、连接持续时间与主要操作，并附经过遮盖的失败记录。不要只提交一个电池占比截图，因为它缺少业务量和观察窗口。可以同时记下 Data 的流量增量，让接收反馈的人区分“传输了大量数据”和“少量流量却持续重试”这两种情况，从而选择不同的检查方向。

更新后异常与 iPad 专项检查

更新后出现故障，应先确认变化发生在客户端、系统、配置还是订阅，而不是把时间接近当作因果。记录最后一次正常使用时的网络与配置，再用当前环境重现。客户端更新通常不会修复已经失效的服务端授权；同样，订阅恰好更新后参数变化，也可能被误认为应用更新造成。优先保留现有文件、分组与必要截图，再考虑恢复或重装，避免失去能够定位差异的材料。

按来源恢复，不先清空所有设置

iPhone / iPad 通过 App Store 获取与更新，系统要求以 App Store 页面标注为准。iPhone / iPad 版为 App Store $2.99 一次性付费，Mac（Apple 芯片与 Intel）、Windows、安卓、Linux 版免费，其他平台安装包由本站下载页提供并走本站 /dl/ 路径。客户端一次性买断 ≠ 线路套餐；重新获取客户端不会自动恢复服务商已经撤销的订阅授权。

核对 iPhone / iPad 应用时，应确认开发者 Shadow Launch Technology Limited、官方图标和应用 ID 932747118。换机或重装后，使用原购买账号查找已购项目，具体操作见已购恢复说明。恢复应用后仍需检查订阅、服务器和 Config 是否完整；系统备份不应被当作当前配置已全部恢复的证明，密码、私钥及授权信息也不宜仅依赖单一设备保存。

更新后先做三个最小检查：系统基础网络是否正常、VPN 配置是否仍获授权、一个已有服务器能否在简化配置下工作。若旧配置失败而简化配置正常，逐项恢复规则与外部资源；若全部配置都失败，回到权限、DNS 和服务端参数。先不要把所有设置重新保存一遍，因为无差别修改可能覆盖原始线索。确认应用发生退出时，记录触发动作，而不是仅写“更新后不能用”。

iPad 的 Wi-Fi、热点与多窗口场景

仅有 Wi-Fi 的 iPad 应先区分路由器问题和代理问题；可以使用自己可用的另一网络或个人热点做对照。具有蜂窝能力的机型则分别测试 Wi-Fi 与蜂窝网络。学校、单位和公共 Wi-Fi 可能需要网页认证，先关闭连接完成认证，再开启 Shadowrocket。iPhone 正常而 iPad 失败时，不应直接认定订阅有问题，两个设备可能使用不同 DNS、不同 Config 或不同系统 VPN 配置。

分屏或多窗口操作容易让“当前查看的配置”和“当前生效的配置”混淆。返回 Shadowrocket 确认选中的服务器、Global Routing 与 Config，再重新打开目标应用的请求。不要仅依据两个设备上相同的显示名称比较；名称相同的条目仍可能具有不同端口、TLS 或传输字段。逐项核对实际参数，比把整个设备设置抹掉后重新尝试更容易定位，也能保留正常应用的网络状态。

使用外接键盘粘贴订阅或服务器信息时，注意开头结尾空格、智能标点与换行；通过跨设备剪贴板传递时，还要确认复制的是最新内容。Scan QR Code 导入后应查看解析出的条目类型，不要因为扫码成功就省略字段核对。iPad 息屏后恢复使用但页面停留在旧状态时，先新发起一个请求，再判断连接是否失效；旧页面与长连接不能代表恢复后的实际网络状态。

恢复日常配置与问题记录闭环

如果必须重新安装，先保存可以安全恢复的 Config 与服务器信息，并确认能够从你的服务商处重新取得订阅链接。导出内容可能包含敏感参数，应放在受控位置，不要通过公开文件分享。电脑与安卓重新获取后如遇系统拦截，按下载页安装放行说明处理；Mac 的“仍要打开”、Windows 的“更多信息”以及安卓安装权限只解决启动问题，完成后仍要重新验证连接与规则。

排查结束后，恢复用于日常使用的 Global Routing、On Demand 和必要规则，撤销临时 DNS 与测试条目。验证至少包括原来失败的操作、一个普通网络请求，以及息屏或网络切换后的新请求。最后记录故障范围、根因、实际改动和复测结果；若仍未解决，带着这些可复现信息继续反馈，而不是只描述设备型号。首次配置遗漏的步骤可回到快速上手教程逐项核对。