Official Manual · Troubleshooting

Shadowrocket
故障排查大全

先确定故障发生在哪一层，再修改设置。本页是按症状查阅的官方手册；首次配置请先完成使用说明中的快速上手主线，再回到对应章节处理异常。这里以用户已有自己的订阅或服务器信息为前提，不提供、不销售、不推荐节点或订阅。

客户端一次性买断 ≠ 线路套餐。应用购买、服务器服务、配置文件是三个独立事项。购买与重装问题请查App Store 正版获取说明；短问答见疑难解答。系统要求以 App Store 页面标注为准。

Routing

开关已开启，但网页或应用无法访问

先确认基础网络，再比较 Global Routing。系统显示 VPN 已连接，只能说明本机连接状态，不能证明每个请求都已完成解析、认证和传输。找一个平时可正常访问的页面作为固定测试对象，记录是所有页面失败，还是只有一个域名或一个应用失败。两种范围对应不同排查方向，不要直接归结为服务器失效。

建立基础网络对照

正常断开 Shadowrocket，在相同网络中打开测试页面。若仍然失败，先检查 Wi-Fi 是否需要网页认证、蜂窝数据是否可用、当前应用是否有联网权限。公共 Wi-Fi 即使显示已连接，也可能尚未完成接入确认。先完成该网络自己的接入步骤，再回到应用测试；客户端配置不能替代基础网络的登录或授权。

若断开后恢复，再开启 Shadowrocket，对同一页面重复一次。不要同时切网络和换服务器，否则对照失去意义。只在某个应用失败时，先确认它使用的目标域名、是否有自己的网络限制，以及失败是否发生在登录、内容加载或后台刷新阶段。浏览器可用并不代表该应用所有请求使用了相同路径。

比较 Global Routing 三种姿态

如果 Proxy 可用、Config 不可用，优先检查当前配置是否选对、命中策略是否指向预期服务器，以及是否有 REJECT 规则。若 Direct 可用、Proxy 不可用，继续检查服务器参数或服务器到目标的路径。这个比较只是缩小范围，不是完整证明：DNS、配置中的其他处理及目标服务状态也会影响结果，必须结合请求记录判断。

检查规则顺序，而不是只找关键词

进入 Config 确认当前实际使用的文件，不要只检查列表里名称相似的另一份文件。规则通常按排列顺序判断，命中后使用相应策略；宽泛规则放在具体规则前面，可能使后者没有机会匹配。下面片段仅解释顺序，example.com 是语法示例域名，不代表用户需要访问的服务，也不是可直接替换全部配置的方案。

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

该片段先检查 example.com 后缀，再进行 GEOIP 判断，最后由 FINAL 兜底。PROXY 与 DIRECT 的含义不同；实际配置若使用自定义策略名称，还要确认名称存在且引用正确。不要因为看到 FINAL 就认为所有请求都会到达它，前面的规则可能已经命中。对 IP 类规则还要考虑域名解析发生在哪一步，不能仅凭网页名称推断最终命中项。

区分规则问题与目标服务问题

使用可用的连接记录或诊断信息，核对失败请求的域名、策略与错误类型。若单一域名在不同路径下都返回相同业务错误，问题可能来自目标服务、账号会话或区域性服务条件，而不是隧道建立失败。若仅 Config 下失败且记录指向不预期的策略，优先修正那条规则，不要把整个配置改成长期 Proxy 来掩盖错误。

修改前保存原文件，只调整能解释当前症状的一项，再访问同一目标。验证后回到日常所需的 Config 姿态，观察其他常用页面是否受到影响。涉及配置段落可查.conf 结构说明；如果路由结果符合预期但仍显示解析失败，转到DNS 章节，不继续增加重复规则。

Subscribe

Subscribe 更新失败、导入为空或内容不符

先保留现有可用条目，再检查订阅获取和内容解析。Subscribe 更新至少涉及地址访问、身份校验、返回内容以及客户端识别几个环节。提示更新失败时，原有服务器可能仍能使用；不要立刻删除整个分组。客户端连接可用与订阅更新可用不是同一件事，订阅地址可能位于不同主机，也可能需要不同的访问条件。

确认地址仍有效且完整

从用户已有的信息来源重新核对订阅地址，注意复制时是否遗漏查询部分，是否带入句号、空格或换行。地址中的身份信息可能决定返回内容，不能为了让链接看起来整齐而删掉。若之前重新生成过订阅地址，旧地址可能已经失效；应使用当前有效资料，而不是在旧地址上随机修改字符。

订阅地址应按凭据处理。不要把它贴进公开问答、截图或共享文档，也不要发送给不必要的接收方。需要反馈时描述主机访问错误和状态信息即可；若地址已经公开，应通过原有服务的管理方式更换相关凭据。浏览器地址栏和系统分享预览也可能显示完整内容，排查前先考虑是否会造成额外留存。

分开检查访问失败与内容错误

更新时若出现连接超时、解析失败或证书错误，先按网络和 DNS 章节检查订阅主机。若出现明确的身份或访问权限错误，回到原有资料确认订阅是否仍有效。网络能访问某个网页，不等于能访问订阅主机；订阅主机能建立连接，也不等于会返回客户端需要的内容。

返回内容可能是登录网页、错误说明或其他格式，而不是服务器列表。若更新完成却没有条目，先确认原有服务提供的格式是否适用于 Shadowrocket，并核对响应是否为空。不要通过修改协议类型把网页文本当作服务器信息导入。地址重定向、账户状态变化或格式调整，都可能使同一个入口返回不同内容。

明确 Subscribe 与 Config 的分工

服务器订阅主要用于提供或更新服务器条目；Config 中的配置文件用于规则及相关设置。两者有联系，但不能互相替代。导入了服务器列表，不代表已经建立正确的分流规则；载入 .conf 文件，也不代表身份凭据有效。若用户资料同时包含两种地址，应按各自用途操作，而不是把配置地址放进 Subscribe 后反复尝试。

更新后条目名称或数量变化，先与原有服务的当前信息对照。服务器可能被重命名或替换，旧的选中项也可能不再存在；检查 Home 当前实际选择的是哪条记录。自定义策略若引用固定名称，也需要核对是否仍能找到目标。不要仅凭列表看起来更短就认定解析错误，应先确认来源返回的内容。

检查更新请求使用的路径

若普通网页正常、只有 Subscribe 更新失败，观察更新时是否处于连接状态，以及订阅主机的访问路径。不同设置和配置可能影响该请求如何出站。先正常断开连接，在基础网络中尝试一次；再恢复原连接条件对照一次。每次保留相同地址，不同时切换网络、替换地址和修改规则。

若只有一种路径可获取内容，修复应针对订阅主机的访问条件，而不是改动所有服务器参数。若两种路径都返回相同权限错误，则更可能需要核对来源账户或地址有效性。对于重定向和证书问题，保留错误原文交由原有信息提供方确认，不自行降低校验要求来掩盖失败。

更新后的恢复检查

一次成功更新后，重新选中预期条目，核对 Global Routing 和配置中的策略引用，再完成实际访问测试。订阅刷新成功只是列表更新成功，后续认证仍可能失败。若列表问题已解决而连接超时，转到服务器章节；导入操作位置不清楚时查使用说明，不要继续用删除分组来代替定位。

DNS

DNS 解析失败、域名打不开或返回异常地址

先区分名称解析与后续连接。网页访问通常先把域名转换为地址，再建立传输和应用会话；任一步失败都可能表现为页面打不开。Connectivity Test 能完成而网页失败，并不能直接证明 DNS 有问题。只有错误文字、请求记录或可重复的对照指向解析阶段时，才进入 DNS 设置排查，避免用更换解析服务器掩盖认证或规则错误。

确认失败对象与错误阶段

记录打不开的域名，以及它是目标网页、代理服务器主机名还是订阅主机名。三者可能使用不同处理路径。若服务器主机名无法解析，隧道本身就可能建立失败；若隧道正常而目标域名失败，应检查该请求的解析和路由。不要把所有域名统一写成“DNS 不通”，否则后续测试很难对应。

尝试同一网络中的另一个常用域名，再在基础网络中对照。只有一个域名失败时，可能涉及其自身记录、缓存、Host 映射或特定规则；多个无关域名都失败时，才更应检查解析服务的可达性。直接用地址访问网站不是可靠的通用验证，因为证书、Host 和服务端虚拟主机可能仍要求正确域名。

检查当前配置中的 DNS 与 Host

先确定实际使用的 Config 文件，再检查 General 中已有的 DNS 相关配置和 Host 段。不要只在 Settings 改一个选项后就假设文件中的设置不再影响行为。不同选项的适用范围应以应用当前说明为准；将相关设置的原值记下来，明确哪项来自文件、哪项来自应用，才能恢复测试状态。

Host 中的固定映射可能使域名长期指向某个地址。若映射已经过期，替换 DNS 服务也不会改变该固定结果。先核对映射用途，再临时移除相关条目进行比较，不要清空整个 Host 段。由已有资料提供的必要映射需要保留恢复方式，尤其不能根据搜索到的地址随意覆盖。

解析服务本身也需要可达路径

DNS 服务地址不是填入后就必然可用。传统查询、加密查询和通过代理访问的查询，各自需要相应网络路径。若配置要求通过代理访问解析服务，而代理服务器主机名又依赖同一条尚未建立的路径解析，就可能形成依赖问题。处理时要明确最先需要解析的对象，不把所有查询强制塞进一个无法启动的路径。

选择解析设置时使用自己已有且了解用途的信息，先验证其在当前网络中的可达性。不要把增加很多服务器当作提高可靠性的必然办法：不同返回结果和等待顺序可能使问题更难复现。修改前保存原值，只替换一项条件；若结果改善，仍要检查日常分流和本地网络访问是否受到影响。

把 IPv4、IPv6 与缓存分开判断

域名可能同时返回 IPv4 和 IPv6 地址。解析成功但某一地址族不可达时，表现可能是等待较长后才回退，或部分资源失败。这属于地址可达性问题，不等于解析服务没有响应。先观察错误和当前网络能力，再针对性比较；不要为了一个目标长期关闭设备所有相关能力。

修改 DNS 或 Host 后，旧连接和缓存可能仍在使用之前的结果。结束当前测试请求，正常断开并重新连接，再对同一目标验证；必要时重新打开目标应用。不要连续改多次设置后立即用一个旧页面判断成败。若重连后短暂恢复又复发，记录再次失败的域名与时机，检查是否有配置切换或网络变化。

规则命中也会受到解析结果影响

DOMAIN 类规则以域名条件判断，IP-CIDR、IP-CIDR6 与 GEOIP 则涉及地址条件；具体行为还与规则参数及解析阶段有关。一个请求可能因解析到不同地址而采用不同策略。排查时先确认命中项，不要把所有 IP 类规则放到域名规则前面试图“修好 DNS”。FINAL 只负责未命中时的兜底，不负责修复错误的解析结果。

修复后至少验证目标域名、一个日常常用域名和必要的本地网络服务。若解析错误消失但访问仍失败，返回路由章节检查后续连接，不继续更改 DNS。更详细的症状区分见DNS 解析失败排查说明；反馈时提供错误原文与设置类别，隐藏内部域名和私人地址信息。

iPad

iPad 已购恢复、布局与网络专项排查

iPad 上先把购买恢复与配置迁移分开。使用自己当初购买应用时的 Apple ID，在 App Store 已购项目中重新获取应用；购买适用性和系统要求以 App Store 页面标注为准。应用可以重新获取，不代表另一台设备上的服务器、Subscribe 或 Config 会自动完整出现。若打开后列表为空，先核对资料迁移，不把它判定为购买失效。

已购应用仍显示价格时如何核对

查看当前用于 App Store 购买的账号是否为原购买账号，不只看系统其他服务显示的账号。再核对产品名称、开发者 Shadow Launch Technology Limited 和应用 ID 932747118。不要在尚未确认账号与产品前重复购买。相关核验入口见正版三要素说明，应用唯一获取入口是 App Store。

若当前商店中暂时无法显示已购项目，先检查网络、账号购买记录和当前店面状态，按 App Store 的实际提示处理。家人共享是否适用，以商店页和自己的家庭设置为准，不能默认另一人的购买必然可恢复。购买问题与服务器服务状态彼此独立，恢复应用后仍需使用用户已有且有效的连接资料。

横屏、分屏与窄窗口中的操作定位

iPad 横屏或分屏可能改变列表与详情的展示位置。按 Home、Config、Data、Settings 等英文界面词定位，不用“左下角第三个按钮”作为唯一依据。某个编辑面板可能仍显示上一次选择的内容，修改前核对条目名称和内部地址，保存后回到当前选中项检查，避免误改相邻的同名记录。

屏幕旋转或窗口宽度变化不会自动证明路由状态改变。如果界面看起来不同，先查看 Global Routing 当前姿态和 Config 实际选中文件。输入服务器资料时，外接键盘、自动替换或粘贴内容也可能带入空格；保存后逐项核对地址、端口和身份字段，不以输入过程没有报错作为有效性证明。

两台设备同一资料却表现不同

先保持同一 Wi-Fi、同一目标和同一服务器资料，再比较结果。不要直接拿 iPhone 的蜂窝网络与 iPad 的 Wi-Fi 做客户端对照。即使两台设备使用相同条目名称，实际密码、传输设置、选中策略和配置文件也可能不同。按字段类别核对差异，不把完整凭据发送给第三方进行比较。

若配置完全一致而只有一台失败，继续检查该设备的联网权限、其他 VPN、管理限制、系统时间与 DNS 环境。只有 Wi-Fi 的 iPad 可使用自己能够控制的另一网络做对照；借助个人热点测试时，要把热点设备的网络变化也记入结果。网络来源改变后恢复，只能说明接入环境参与了问题，不能证明某个应用设置已经修复。

休眠、唤醒与网络切换

记录异常是在长时间锁屏后、唤醒瞬间，还是切换 Wi-Fi 后发生。刚唤醒时基础网络可能尚未恢复，应用请求失败和 VPN 重连可能同时出现。先确认网络已经稳定，再手动进行一次访问。若每次唤醒都需要重新连接，检查 On Demand 条件、系统 VPN 状态和服务器会话行为，按前面的连接章节逐层定位。

不要用后台停留多久推断连接一定维持，也不要认为屏幕上的旧状态代表当前请求可用。实际访问、系统状态和错误记录应相互对照。对于只在分屏中出现的失败，确认目标应用是否有自己的会话或网络限制；切回全屏后重复相同动作，保持其他条件不变，才能判断窗口变化是否只是同时发生的事件。

配置迁移后逐项恢复并验证

从自己控制的备份恢复资料后，先检查 Subscribe 的有效性与当前服务器选择，再确认 Config 文件及策略引用。若文件引用固定名称，另一台设备上的名称差异可能造成命中错误。恢复顺序应是资料完整、连接可建立、实际请求可完成、规则符合用途，最后再恢复按需连接和附加处理，不一次启用全部复杂设置。

验证至少包含一次日常网页访问、一次需要代理路径的已有业务请求，以及一次正常断开后的基础网络检查。若只有某个阶段失败，回到对应章节，不重新做全部购买流程。账号恢复与布局细节可参阅iPad 已购与使用要点；界面定位可查英文界面词说明。