Shadowrocket
故障排查大全

01 / 连接建立

开关打不开

先确认故障发生在建立系统连接之前，还是连接建立后立即退出。前一种常见表现是系统授权没有完成、配置没有保存或设备受到管理限制；后一种则需要查看错误信息与连接记录。不要把所有开关问题归结为服务器故障：远端不可达通常影响请求，未必会阻止本地连接启动。记录点击后的表现，比连续反复点击更有判断价值。

先完成系统授权

在 iPhone 或 iPad 上首次启用时，系统会要求允许添加 VPN 配置。确认提示来自当前操作，再按系统流程授权；如果取消了提示，返回 Shadowrocket 重新尝试，并完成设备身份验证。随后到系统设置的 VPN 管理位置检查是否已经出现相应配置。不同系统版本的设置层级可能变化，可以直接在设置内搜索 VPN，不必依赖固定菜单位置。

如果设备由学校或组织管理，添加网络配置可能受管理策略限制。此时应查看设备管理说明，向管理员确认是否允许使用相应功能，而不是反复删除配置。系统限制、家长控制和组织配置不属于服务器参数问题。对于仍有其他网络连接配置的设备，先正常断开正在使用的连接，再启动 Shadowrocket，避免把两个服务的状态混为一谈。

检查本地配置与冲突

回到 Home，确认已有可选服务器，且不是只添加了备注而遗漏必要参数。再到 Config 确认当前启用的文件确实存在，并检查最近是否改过文件内容。配置语法错误、引用了不存在的策略名称或导入文件不完整，都可能导致启动阶段报错。优先恢复修改前的副本；没有副本时，保留原文件，再用内容较少的配置验证，不要直接清空全部资料。

如果开关短暂打开又关闭，先读取错误原文，再判断是配置加载失败、系统服务启动失败，还是外部连接条件触发了断开。暂时停用 On Demand，以手动启动的方式复测，能减少自动条件带来的干扰。测试结束后再恢复原有条件。不要一边开启自动连接，一边删除系统配置，否则配置可能重新出现，让人误以为删除操作没有生效。

重建系统连接配置应排在备份之后。先关闭连接，确认订阅、手动服务器和 Config 已有可恢复副本，再从系统设置中移除明确属于 Shadowrocket 的旧连接配置。重新打开客户端，按提示授权并测试。只处理已经辨认清楚的项目，不删除组织管理资料，也不把还原全部网络设置当作第一步，因为后者可能同时移除已保存的网络信息。

电脑与安卓的启动分支

若问题其实是应用无法打开，应先按安装放行说明处理，而不是进入连接排查。Mac 先核对 Apple 芯片与 Intel 安装包是否匹配；提示无法验证开发者时，在隐私与安全性中确认来源后选择仍要打开。Windows 遇到 SmartScreen，可在核对本站下载来源后进入更多信息，再选择仍要运行，不要关闭整个系统防护。

安卓安装阶段需要按系统提示允许当前下载工具安装未知应用，完成后可收回该权限；这与连接时的 VPN 授权是两个步骤。Linux 若应用尚未启动，先检查安装格式、执行权限与桌面环境报错。各平台安装包均由下载页通过本站 /dl/shadowrocket/ 提供，不要用不明文件替换现有程序。

02 / 请求路径

连接后无法上网

先做断开连接的基线测试。关闭 Shadowrocket，用浏览器打开一个平时可直接访问的网页；如果仍然失败，先处理 Wi-Fi 登录认证、移动数据权限或路由器连接。公共网络有时需要在认证页面完成确认，未完成时其他请求也会失败。只有基础网络可用，后续比较 Config、Proxy 与 Direct 才有意义，否则会把底层断网误判为规则问题。

用三种姿态缩小范围

保持同一个网络、同一台设备、同一个服务器与同一个目标，依次比较 Global Routing 的三种姿态。每次切换后重新发起请求，必要时完全关闭目标应用再打开，避免沿用既有连接。测试只用于定位差异，不应把某个姿态视为所有情况下的长期解决办法。尤其是目标本来就不能直接访问时，Direct 失败本身不能证明基础网络有故障。

如果 Proxy 可以访问而 Config 不行，先找目标域名在 Rule 中命中了什么，不要立即修改服务器。常见情况是上方存在范围较大的 DIRECT 或 REJECT 规则，覆盖了后面更精确的条目。规则通常自上而下匹配，精确例外应放在宽泛规则之前。修改前确认当前启用的 Config，避免编辑了另一个未启用文件，随后误以为规则变化没有效果。

核对策略与匹配顺序

下面是说明匹配顺序的规则片段，不是完整配置文件，也不负责创建服务器。示例域名仅用于解释语法，应根据实际目标与已有配置调整。不要为了测试直接覆盖整个文件，尤其不要丢掉原有策略组和其他必要设置。最终使用的策略还受当前配置结构影响，检查规则时应同时确认相应策略确实存在，并指向可用服务器。

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

DOMAIN-SUFFIX 匹配域名后缀，IP-CIDR 匹配地址范围，GEOIP 依据地址归属判断，FINAL 处理前面没有命中的请求。它们观察的对象不同，不能仅凭规则名称推断某次请求一定会命中。目标应用可能同时连接登录域名、资源域名与内容分发域名；只处理首页域名，未必覆盖登录或图片请求。应从失败请求本身确认目标，再决定补充规则的范围。

如果所有姿态都失败，但关闭连接后能正常访问，应检查连接内使用的 DNS、系统连接冲突以及 Config 的通用设置。先恢复到最近可用副本，并停止其他同时接管网络的服务再复测。不要一次修改 DNS、路由和服务器三项，否则即使恢复正常也无法判断原因。有关域名解析的独立验证，见DNS 问题一章。

区分全局与单个应用

浏览器正常而某个应用失败，通常需要单独观察该应用的登录、媒体或实时通信请求。先检查应用是否允许使用当前网络，再彻底退出后重开。若只有登录失败，应注意设备时间、系统证书错误和账号状态；若只有局域网设备无法访问，检查是否有规则把本地地址错误送往远端，不要直接把整个配置改为 Direct 来掩盖问题。

验证修复时，至少重复最初失败的动作，而不是只看连接图标。能打开网页首页，不代表图片、登录与文件传输都恢复；同样，一次成功也可能只是缓存命中。记录最终有效的配置改动，并撤销排查中无关的临时设置。规则类型的进一步说明可查阅DOMAIN-SUFFIX、GEOIP 与 FINAL 详解。

03 / 远端连接

节点超时

超时首先说明某次测试没有在等待期限内完成，不直接说明失败发生在哪一层。DNS 解析、连接服务器端口、协议握手与访问测试目标都可能消耗等待时间。先记下错误出现在 Connectivity Test，还是实际应用请求中；再比较同一服务器在不同网络下的表现。只看到一个超时字样就重新导入全部订阅，往往会破坏原本有用的对照条件。

先核对地址与协议字段

打开对应服务器的编辑信息，与用户已有服务提供的原始参数逐项核对。服务器地址不要带网页路径、空格或多余协议前缀，端口应与服务端设置一致。二维码与分享链接可能包含额外字段，手动抄写时尤其容易漏项。备注只是本地名称，两个备注相同的条目也可能指向不同地址；排查时应比较实际参数，而不是只看显示名称。

协议类型必须与服务端一致，不能为了让测试通过而随意互换。Shadowsocks 的加密方式和密码、VMess 或 VLESS 的身份字段、Trojan 的密码与 TLS 条件，各自承担不同作用。WireGuard 还涉及密钥、地址和对端设置，Hysteria2 则需要留意认证及传输条件。字段缺失应向已有服务的维护方核实，不应从其他条目中拼凑一组看似完整的参数。

再做网络交叉测试

保持服务器参数不变，分别在可用的 Wi-Fi 与移动网络测试。如果只有某个网络失败，应先考虑该网络的认证状态、端口可达性和传输条件，而不是立即认定账号失效。若同一网络中用户已有的其他服务器正常，范围就更接近单个远端服务；若所有服务器都失败，则应回到基础网络、系统授权和 DNS 分支继续确认。

Connectivity Test 的结果只代表所选测试方法与目标。端口连接成功，并不保证协议认证成功；测试网页响应正常，也不保证另一个目标网站能正常访问。测试失败但实际应用正常时，可能是测试目标不可达或测试方法不适合当前服务。先用明确的实际请求复核，不要仅为让列表中的测试结果好看而反复更改已有服务器。

服务端名称与连接地址可以不同，但两者都必须符合原始配置。使用 IP 连接时，TLS 仍可能需要指定正确的服务端名称，直接把域名替换为 IP 可能引出证书不匹配。设备日期和时间错误也会影响证书有效性判断。遇到证书相关错误，应先校正时间并核对名称，不把跳过验证作为常规修复手段。

判断需要谁继续处理

如果同一条记录在多个可用网络下持续失败，而其他已有记录正常，向原有服务的维护方确认地址、端口、认证状态与服务运行情况。提交经过遮盖的错误原文和复现条件即可，不要公开完整分享链接或订阅地址。若远端近期更换了参数，应更新对应条目；更新后确认实际选中的也是新条目，避免列表中旧记录仍被继续使用。

当网页能打开但大文件或特定应用持续中断时，不要简单归类为节点超时。此类症状还可能与传输路径、UDP 支持或分包条件有关，应在稳定网络下用同一种操作比较。高级网络参数应以服务端要求为依据，先备份再单项调整。没有明确证据时，不建议同时改动传输方式与多项底层参数，否则会增加新的不兼容因素。

04 / 内容获取

Subscribe 更新失败

订阅失败应拆成三件事：地址能否获取、返回内容能否解析、导入结果是否被正确使用。三者的处理方式不同。更新按钮报错时，先保留原有可用条目，不要立刻删除订阅。已有服务器能够连接，只能证明那条连接仍有效，不能保证订阅接口也可访问；反过来，订阅更新成功，也不保证其中每一个服务器当前都能建立连接。

检查地址与访问条件

从用户已有服务提供的管理页面重新复制完整订阅地址，确认没有复制到网页标题、说明文字或被截断的链接。链接中的查询参数可能承载访问凭据，遗漏一段就可能失效。复制后留意开头结尾的空格以及换行，不要为了让地址显得简短而手动删除参数。订阅地址属于敏感连接信息，不应贴到公开评论或截图中。

比较更新时的网络路径。若断开连接能够更新，而连接后失败，可能是当前请求路径或 DNS 条件不适合访问订阅接口；若情况相反，可先通过用户已有的可用连接完成更新。测试时只改变连接状态，保留同一个订阅地址，才能说明差异来自路径。频繁重复点击不会修复地址错误，还可能触发接口的访问频率限制。

如果出现身份验证、权限或访问频率相关的错误，应回到原有服务页面确认链接状态与访问限制。网页能打开不等于订阅接口有权限，管理页面与订阅入口可能采用不同的认证方式。浏览器验证只能辅助判断是否能收到响应，不应把返回页面转发给他人。若页面要求登录，复制网页地址到 Subscribe 通常不能替代真正的订阅地址。

区分获取成功与解析成功

收到内容后仍然导入失败，要检查返回内容是否为客户端支持的订阅数据，而不是登录页面、错误说明或完整配置文件。某些接口在失效时仍返回一段可显示的网页，因此仅凭浏览器有文字不能判断格式正确。应对照错误原文，确认问题属于内容格式、空结果还是字段缺失，再向已有服务的维护方描述，不要自行猜测编码方式。

Subscribe 管理的服务器列表与 Config 管理的规则配置不是同一类内容。把完整规则文件当作服务器订阅导入，或把服务器分享信息当作配置文件启用，都可能出现解析失败。先确认手中资料的用途，再选择相应入口。导入完成后，检查条目是否出现在预期分组、数量是否明显异常，以及原来手动添加的记录是否仍然保留。

1. 保留旧订阅与当前可用服务器，记录此次更新的错误原文。
2. 重新复制完整地址，在同一网络下只尝试一次，确认错误是否一致。
3. 根据获取、认证、解析三个阶段，选择对应分支继续处理。
4. 成功后核对分组与实际参数，重新选择需要使用的服务器并完成请求测试。

处理更新后的列表变化

更新后出现重名条目时，先查看所属订阅和实际地址，不要按备注批量删除。不同订阅可能使用相同命名规则，手动记录也可能与订阅记录同名。清理前确认当前选中项来自哪里，以及 Config 中的策略是否仍引用有效对象。某条记录被服务端移除后，旧的选择状态不一定还能用于新连接，需要重新明确选择可用条目。

如果更新成功却仍使用旧参数，先核对是否操作了正确的订阅项目，再确认当前选中的服务器是不是另一个手动副本。不要用反复导入同一个链接来覆盖判断，这会增加重复来源。更稳妥的方法是保留可识别的来源说明，按一个订阅逐项更新，再对照改变的地址或字段。任何删除动作都应放在验证新记录能够使用之后。

订阅和线路使用条件由用户已有服务决定，客户端本身不替代这些条件。客户端一次性买断 ≠ 线路套餐。本站不提供、不销售、不推荐节点或订阅，只说明已有资料的导入与排错。需要重新了解正确导入顺序时，返回快速上手教程；概念与操作上的短问题可在常见问题中查阅。

05 / 性能对照

连接速度慢

先把“慢”描述成可复现的现象：网页首次打开等待较久、图片逐张加载、文件传输持续缓慢，还是视频间歇停顿。它们涉及的阶段并不一样。首次打开慢而后续正常，优先考虑解析与连接建立；长时间传输都慢，则需要比较基础网络、远端出口和目标服务。不要只凭一次 Connectivity Test 的结果推断所有使用场景的速度。

建立公平的比较条件

在同一台设备、同一位置和相近时间，用相同目标进行比较。先关闭其他大流量任务，暂停系统更新与云端同步，避免把后台占用算到当前请求上。然后记录关闭连接时的表现，再比较用户已有服务器之间的差异。目标文件、应用操作和网络类型都应保持一致，否则一次快一次慢可能只是内容分发节点或缓存状态不同。

Wi-Fi 信号显示良好也不一定代表链路稳定。距离、同频干扰、路由器负载和上行占用都会影响实际表现。可在路由器附近复测，再用移动网络做一次对照；如果切换网络后同一服务器明显恢复，应优先检查本地网络。测试时留意移动数据用量，不必反复下载大文件，能复现原问题的最小操作通常已经足够。

多条已有服务器的比较也要保持方法一致。连接建立时间短，不代表持续传输能力一定更好；一个目标响应快，也不说明所有目标都一样。先选择两条参数明确、可以正常连接的已有记录，逐个完成相同操作。若所有记录只在一个目标上缓慢，而其他请求正常，应把目标服务本身和相应请求路径列为主要检查方向。

判断是规则还是传输问题

比较 Config 与 Proxy，观察缓慢是否只在按规则处理时出现。若 Proxy 正常而 Config 缓慢，检查目标请求是否误走 Direct、是否引用了与预期不同的策略，以及相关资源域名是否采用了不同路径。一个页面可能同时发起多个域名请求，主文档正常而图片慢，不能直接得出整个服务器慢的结论，应先定位真正拖延的资源。

若所有请求首次打开都慢，后续又正常，可结合连接记录查看时间主要消耗在解析、握手还是等待目标响应。不要同时更换 DNS 与服务器来试图提速；先固定服务器，只比较解析条件，再恢复原状比较另一项。某个调整在一个目标上有效，不代表适合整个配置，应保留对照结果，并避免累积来源不明的“优化参数”。

实时通信、部分游戏或其他使用 UDP 的应用，与普通网页的需求可能不同。网页能够打开，并不能证明相关传输也已通过。先确认用户已有服务是否支持对应传输，再检查客户端条目与 Config 的相关条件。不要把协议名称当成速度保证，也不要随意改变 MTU 等底层设置；这类调整需要明确症状与可重复测试支撑。

用最小改动恢复

如果服务端给出了特定传输参数，应与当前记录逐项比对，而不是参考另一条不同服务的设置。对于 TLS 或其他握手耗时明显的情况，先检查设备时间、服务器名称和网络稳定性。忽略证书检查不能作为性能调整办法。若目标应用在网络切换后一直缓慢，可退出应用重新建立连接，排除旧连接仍依赖切换前路径的情况。

长时间传输过程中出现周期性停顿，还要观察设备是否进入省电状态、后台是否受限，以及无线网络是否发生切换。电脑处于系统代理路径时，也应确认目标应用实际采用了该路径，不能只看客户端处于运行状态。测试结论应写成“在某网络、某目标、某姿态下恢复”，而不是笼统认定某项设置在所有设备上都更快。

06 / 域名解析

DNS 问题

DNS 排查的目标是确认域名有没有得到可用地址，以及请求是否采用了预期的解析路径。域名打不开并不必然是 DNS 故障，后续连接、TLS 与规则同样可能导致失败。先看错误发生在解析阶段还是连接阶段，再比较系统网络与连接内的行为。只更换一个看起来常见的 DNS 地址，不能证明原因，也可能使原本可用的局域网名称失效。

区分服务器域名与目标域名

需要解析的对象至少有两类：代理服务器自身的域名，以及浏览器或应用正在访问的目标域名。前者失败可能导致所有代理请求无法建立，后者失败则可能只影响部分网站。先确认错误指向哪一个名称，不要看到目标网页失败就修改服务器地址。检查拼写时保留完整域名，避免把订阅地址中的路径误当成服务器名称。

在可用基础网络下先验证服务器域名能否解析，再检查连接内目标域名的结果。如果服务器地址采用 IP，也仍可能涉及 TLS 名称校验，因此不能简单以 IP 替换域名来绕过所有问题。直接访问网站 IP 也不是通用测试方法：许多网站依赖正确的主机名称与证书，访问 IP 失败可能完全正常，不能据此断定网络不可达。

下面的 General 片段展示使用系统 DNS 的配置写法，仅用于说明基线，不是适合所有网络的完整配置。修改前应检查当前文件是否已有同名设置，避免追加相互冲突的定义。保留原副本后，只调整需要比较的一项，再重建请求。实际网络若要求特定解析方式，应按该网络与用户已有服务的说明操作。

[General]
bypass-system = true
dns-server = system

结合规则检查解析结果

以域名为对象的规则和以地址为对象的规则，需要的判断条件不同。DOMAIN、DOMAIN-SUFFIX 与 DOMAIN-KEYWORD 观察名称，IP-CIDR、IP-CIDR6 与 GEOIP 观察地址。不要把所有失败都归结为规则顺序，也不要因为存在一条域名规则就认定解析无关。应查看实际请求记录，确认最终目标、命中规则和采用的策略，再决定检查哪一层。

如果只有某个 Wi-Fi 下的内部名称或本地设备不可用，先考虑该网络是否依赖自己的 DNS。将所有解析改到外部路径，可能无法识别本地名称。对于打印机、存储设备等局域网资源，应同时确认地址范围、网络隔离和相应 DIRECT 规则。能发现设备但无法连接服务，也可能是端口或设备权限问题，不应只继续修改 DNS。

IPv4 与 IPv6 的可用性不一致时，解析可能正常返回地址，但后续某条路径不可达。先比较问题是否只出现在特定网络、特定目标或特定地址类型，不要在没有证据时全局关闭一类地址。网络切换、路由器设置和远端服务都可能影响结果。排查应保留系统默认状态作为对照，再根据明确的失败分支做有限调整。

处理缓存与重复验证

修改设置后，浏览器、目标应用、系统与远端都可能仍持有旧结果。先结束旧请求，关闭并重开目标应用，必要时断开后重连，再观察新的记录。只刷新一次页面可能沿用已有连接，无法说明新 DNS 设置是否生效。也不要用反复重启设备替代判断：重启可能暂时清理状态，但不能解释是哪一个设置导致问题。

若同一域名只在一台设备失败，先对照设备时间、系统网络设置与当前 Config，而不是立刻改整个路由器。若同一网络的多台设备都出现相同失败，应优先检查网络提供的解析条件。记录结果时应包含网络类型、目标名称、错误阶段及使用的姿态，但不必暴露完整订阅和认证信息。涉及内部名称的记录也应先做适当遮盖。

07 / 后台运行

耗电与后台异常

先区分耗电统计中的占比与设备实际消耗。某个应用占比提高，可能只是其他应用使用减少，并不必然代表它消耗突然增加。应在相近亮度、信号、使用时长和网络条件下比较，同时留意设备温度、后台任务与系统更新。连接承担了其他应用的网络请求时，相关活动也可能出现在统计中，不能只看一项百分比就认定客户端异常。

查找持续重连与后台请求

连接不稳定时反复建立会话，可能增加无线通信和处理开销。先观察是否出现频繁断开、网络切换或认证失败，再用一个稳定网络做对照。若同一服务器在固定网络下仍不断重连，应先处理远端连接问题；此时减少测试频率只能降低额外活动，不能修复导致重连的根本原因。设备处于弱信号区域也应单独记录。

On Demand 可能在满足条件时自动建立连接，因此手动关闭后又出现连接，不一定是开关失效。检查是否设置了与当前网络相关的条件，以及是否存在多个相互重叠的自动规则。排查时先记录原条件，再暂时停用自动连接，用手动方式比较。确认规律后只恢复需要的条件，不要一边要求持续自动连接，一边把每次重建都视为异常。

检查是否有应用持续上传照片、同步文件、刷新消息或下载离线内容。后台请求来自其他应用时，即使用户没有打开浏览器，连接仍可能保持活跃。可以暂时暂停这些任务，在相同网络下观察待机表现，再逐个恢复。不要同时关闭大量系统功能后宣布问题已解决，那样无法知道真正影响来自哪一项，也容易影响日常通知和同步。

减少排查工具自身的干扰

Connectivity Test、持续刷新和详细日志本身也会带来额外请求与写入。排查完成后，停止不再需要的重复测试，并按应用实际提供的选项恢复常规记录级别。若需要保留日志，限定复现窗口，先清楚记录开始和结束动作，再收集必要片段。长时间累积的记录既增加查阅难度，也可能包含不应公开的访问目标与连接信息。

判断耗电时尽量使用一段能够覆盖相似操作的观察时间，而不是刚打开连接就比较瞬时变化。充电、设备发热和系统后台整理都会干扰结论。可以先完成正常使用的对照，再观察待机状态；如果只有高负载传输时耗电增加，应结合实际传输量理解。如果在几乎没有请求时仍持续异常，再重点查重连、后台任务与诊断活动。

安卓的电池管理可能在后台限制应用运行，表现为锁屏后一段时间连接中断，解锁后又恢复。先查看系统是否限制了 Shadowrocket 的后台活动，再按设备实际需要调整相关设置，不必一开始就放宽全部应用。不同系统的选项名称可能不同，应依据当前设备说明。调整后比较通知、待机与连接连续性，避免只验证前台网页。

分别处理温度与休眠

电脑从睡眠中唤醒后网络可能尚未恢复，连接也可能短暂重建。先等系统网络就绪，再重新发起原请求，观察问题是否只与唤醒有关。若每次睡眠后都必须重开应用，应记录休眠前后的网络类型和错误，检查是否更换了网络接口。不要通过长期禁止设备睡眠来掩盖问题，这会改变能耗基线，并不等于修复连接恢复流程。

设备明显发热时，先停止高负载传输并让设备恢复正常温度，再做性能判断。温度管理会影响处理速度，慢与耗电可能是同一负载的不同表现。若关闭连接后仍持续发热，应检查系统和其他应用活动，而不是继续修改规则。电池健康、充电环境与无线信号也会改变结果，需要与客户端设置分开考虑。

08 / 变更恢复

更新后异常

更新之后出现问题，不一定说明应用更新是唯一原因。同一时间可能还发生了订阅内容变化、Config 更新、系统升级或网络切换。先列出最近一次正常使用到首次失败之间的变更，再决定排查顺序。不要同时删除应用、清空订阅与还原网络，这会丢掉用于比较的原始状态，也可能让一个局部问题变成需要重新配置的复杂问题。

先保留资料，再确认范围

备份当前 Config、手动服务器与必要的订阅信息，并确认副本可以在本地找到。备份文件可能含有密码、身份字段或完整订阅地址，应放在受控位置，不公开上传。然后确定问题属于应用无法启动、连接立即退出、全部请求失败，还是某个目标失败。不同范围分别对应启动、授权、连接与规则分支，不应统一用重装解决。

如果更新应用后第一次启动出现新的系统授权提示，先确认提示来源并完成必要授权，再复测。系统更新可能调整原有权限状态，连接配置仍在也不代表权限条件完全不变。对于只有某个 Config 无法加载的情况，保留原错误，尝试启用最近可用的本地副本；若副本能够运行，应重点比较配置内容，而不是继续更换服务器。

当 Subscribe 与应用都在近期更新过，先核对当前选中服务器的实际参数是否变化，再确认 Config 中的策略引用是否仍有效。旧名称被移除、分组变化或条目替换，都可能造成看起来像更新后的连接故障。用一个用户已有且参数明确的条目测试，能够减少列表变更的影响，但不要在没有备份时删除整个订阅来源。

按平台检查安装与放行

iPhone 与 iPad 的应用更新通过 App Store 完成，系统要求以 App Store 页面标注为准。重新安装前先确认备份和原购买账号；删除应用可能同时删除本地配置，商店中的已购记录并不等于配置备份。核对正版时检查官方图标、开发者 Shadow Launch Technology Limited 与应用 ID 932747118，具体步骤见正版核验。

Mac、Windows、安卓与 Linux 的新版安装包从本站下载页获取，由页面动态入口指向 /dl/shadowrocket/。Mac 先在关于本机确认 Apple 芯片或 Intel；Windows 按页面说明选择安装包；Linux 根据发行版选择相应格式。不要因为更新遇到问题就混用其他架构或不明来源的文件，这会引入独立的启动故障。

首次打开被拦截时，Mac 可在核对来源后进入隐私与安全性选择仍要打开；Windows 在 SmartScreen 的更多信息中确认后选择仍要运行；安卓按提示允许当前下载工具安装未知应用，完成后再按需要收回权限。Mac 若提示应用已损坏，先确认下载完整与来源，再参考安装页针对该提示的处理，不关闭整体安全设置。

xattr -cr /Applications/Shadowrocket.app

上面的命令仅用于已经确认来源、且应用位于该路径时处理 Mac 文件扩展属性，不是修复所有启动错误的通用命令。应关闭应用后再操作，并确认路径对应实际安装位置。Linux 的 AppImage 还需执行权限，deb 与 rpm 则应通过对应包管理流程检查依赖。安装阶段处理完成之后，再回到连接与请求测试，不把两类问题混在一起。

验证恢复并整理反馈

完成一次改动后，重新执行最初失败的动作，并与更新前的可用副本比较。若只有新增配置失败，保留差异即可；若所有配置在同一网络下失败，再检查系统网络与权限变化。不要仅凭主界面能够打开就认定恢复，仍应测试连接、解析和目标应用。修复后将临时排查文件与正式启用文件区分，避免下次误选测试副本。

反馈应包含设备系统、安装来源、问题发生阶段、错误原文与最短复现步骤。版本信息如需提供，应从当前应用实际显示处读取，不根据旧截图猜测。遮盖服务器凭据和订阅链接后，再提供必要记录。有关 Mac 与 Windows 的芯片选择及首次打开流程，可继续阅读电脑安装与系统放行说明。

09 / 设备专项

iPad 专项排查

iPad 的排查仍遵循网络、服务器、配置与请求的顺序，但需要额外区分仅 Wi-Fi 机型、支持移动网络的机型，以及多任务状态下的应用行为。不要因为 iPhone 上相同备注能够连接，就直接判断 iPad 故障；两台设备可能使用不同网络、不同 Config 或不同实际参数。先对齐测试条件，再比较设备差异，才能避免把环境差异当成平台问题。

让两台设备具备可比条件

若与 iPhone 对照，应先让两台设备连接同一个可用 Wi-Fi，选择参数一致的已有服务器，确认启用的 Config 内容相同，并使用相同的 Global Routing。然后在浏览器中执行同一个请求。只对照服务器名称不够，因为同名条目可能来自不同订阅或更新批次；只对照配置文件名也不够，应核对实际规则内容与最近修改情况。

仅 Wi-Fi 的 iPad 不能直接通过关闭 Wi-Fi 来完成移动网络对照，可以在条件允许时连接另一个已知可用网络。若使用手机热点，应注意这是新的网络路径，而不是对原 Wi-Fi 的重复测试。支持移动网络的机型还应检查数据服务是否正常，以及目标应用是否允许使用相应网络。任何比较都应先确认基础网络可用，再启动连接。

分屏或其他多任务状态下，目标应用可能维持之前的会话。切换 Global Routing 后，先结束正在进行的请求，再重新打开目标页面；必要时退出目标应用重试。不要根据分屏中的旧页面仍显示内容就认定网络正常，那可能只是缓存。反过来，后台应用暂时没有刷新，也不一定是连接中断，需要用一个新的实际请求确认。

处理锁屏与网络切换

若问题只在锁屏后出现，记录解锁时系统网络是否已经恢复、客户端连接是否仍存在，以及目标应用重开后能否恢复。某些应用在后台停止活动，与系统连接是否可用是两回事。先用浏览器新建请求验证，再判断是否仅为某个应用的会话恢复问题。反复点击开关可能让尚在恢复的连接重新建立，反而打断原本可完成的恢复过程。

校园、办公或公共 Wi-Fi 可能要求定期重新认证，也可能按设备分别授权。iPhone 已完成认证，不代表 iPad 自动具备相同条件。关闭连接后尝试打开认证页面，确认网络许可状态，再重新连接 Shadowrocket。受组织管理的 iPad 还可能限制 VPN 配置或网络行为，应向管理员核实允许的使用方式，不删除无法辨认的管理资料。

若需要访问本地打印机、存储设备或其他局域网服务，检查 iPad 与目标设备是否处于允许互通的网络，再检查 Config 对本地地址的处理。局域网权限、网络隔离与规则路径都可能影响结果。先确认关闭连接时能否访问，再比较 Config 与 Direct；不要为了恢复一台本地设备而把所有请求永久改为直连，精确调整更容易维护。

购买恢复与资料迁移

iPhone / iPad 版在 App Store 为 $2.99 一次性付费，两种设备使用同一购买账号恢复已购应用；Mac、Windows、安卓与 Linux 版免费。价格与设备获取口径应分开理解，电脑端不并入移动商店购买流程。iPad 的具体系统要求以 App Store 产品页标注为准，不根据另一台设备能否安装推断。

换机或重新安装时，先确认登录的是原购买账号，再从已购项目查找应用。恢复应用并不会自动补齐所有手动配置，迁移前仍需保存用户已有的订阅信息与 Config。若应用能够恢复但列表为空，应按资料迁移问题处理，而不是再次购买。详细步骤见已购项目恢复说明，首次重新导入则按教程完成。

最后按原场景验收：连接后新建网页请求、打开原来失败的应用、锁屏后解锁复测，并在需要时验证局域网服务。记录哪一步恢复、哪些条件仍会触发问题，比一句“iPad 不能用”更容易继续定位。若只剩概念性疑问，可查看常见问题；若出现明确错误，则回到本页对应章节，沿同一条证据链继续，而不是重新清空全部设置。