Shadowrocket 排查手册

01 / CONNECTION

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

适用现象是点击 Home 的连接开关后立刻回到关闭状态、系统授权提示反复出现，或始终看不到预期的连接状态。此时先不要更换节点：开关能否建立连接，与远端服务器能否响应是两件事。先确认设备本身可以通过当前 Wi-Fi 或蜂窝网络访问普通网页，再关闭 Shadowrocket 的开关，从最基础的系统授权开始排查。若设备已无法连接任何网络，应先处理设备网络，而不是在应用内反复切换策略。

核对首次授权与系统状态

首次开启时，系统可能要求允许添加 VPN 配置。按系统提示完成确认，然后返回 Home 再尝试一次。如果提示曾被取消，检查设备系统设置中与 VPN 有关的配置状态，再回到应用重新触发授权；系统设置的菜单位置可能随设备界面变化，不必依赖某一条固定路径。看到系统层面的连接标识，仅说明配置已启用，并不代表节点已经可用，因此下一步仍需要实际打开网页验证。

如果点击开关完全没有系统反应，先退出应用并重新打开，再检查系统是否存在需要处理的授权提示。重启设备后重试，可帮助区分临时系统状态与持续性的配置问题。每次测试前记录开关是“无法保持开启”，还是“已经开启但网页打不开”；后一种现象应转到下一章，继续检查路由和节点，不应反复撤销已完成的授权。

隔离连接配置的影响

确认系统授权之后，在 Home 核对当前选中的确实是用户已有、信息完整的服务器或订阅条目。误选空白条目、已删除的引用或过期配置时，界面可能允许操作开关，却无法得到可用连接。若近期导入过多个配置，暂时只保留本次要测试的选择，记下原有配置名称后再调整；不要一边改 Global Routing，一边重新导入订阅，否则无法判断是哪项改动生效。

还要检查 On Demand 是否设置了当前网络的触发条件。例如规则要求在某个 Wi-Fi 环境断开，而当前恰好处在该网络，手动操作可能与自动条件相互覆盖。可先暂时停止 On Demand 的自动触发，再手动开启并观察状态；验证结束后按原记录恢复。若设备由单位或学校统一管理，系统对 VPN 配置的限制也可能影响操作，应向设备管理方核对允许范围，而不是反复添加相同配置。

02 / ROUTING

连接后无法上网：拆开网络、节点与规则

适用现象是开关可以保持开启，但浏览器或其他应用加载失败。排查时先把“设备到当前网络”“设备到所选服务器”“请求如何按规则处理”分开。关闭连接后用相同网络打开一个平时可访问的页面：若此时仍失败，应先检查 Wi-Fi 或蜂窝网络本身。若关闭连接后正常、开启后失败，再进入应用核对服务器与 Global Routing。测试页面应保持一致，避免因网站自身状态不同得出错误结论。

用 Global Routing 缩小范围

Global Routing 的 Config、Proxy、Direct 是不同的路由姿态。Config 按配置中的规则决定处理方式；Proxy 让请求优先经过所选代理；Direct 直接连接。先记下原有选项，短时间切换进行对照，测试后恢复。Direct 可以访问而 Proxy 不能，重点检查所选服务器及其参数；Proxy 可以访问而 Config 不能，重点检查规则顺序、策略名称和 FINAL；三种姿态都失败，则优先检查设备网络、系统连接状态及测试目标。对照只用于定位原因，不代表应该长期保持在测试姿态。

核对选中项及失败范围

回到 Home 查看选中的服务器是否属于预期的订阅或手动配置。订阅更新后，旧条目的名称、排序或可用性可能变化；只看列表中“有很多条目”，不能证明当前选中项仍可连接。选另一条用户已有且此前正常的服务器重复同一项测试：仅一条失败时应检查该条的地址、端口和服务端状态；所有条目失败时，再检查共同使用的网络、配置文件与 DNS。不要根据一个延迟数字判断所有网页都会成功加载。

如果只有一个网站打不开，先分别记录其域名、发生时间和 Global Routing 的结果。Config 与 Proxy 结果不同，通常值得查对应的 DOMAIN、DOMAIN-SUFFIX 或 FINAL；浏览器正常而某个应用失败，则应观察该应用请求的域名是否与预想一致。无法确定目标域名时，先用应用内可用的诊断信息定位，再改一条规则复测。完整的首次连接顺序见使用说明；常见现象的简短答案见问答。

03 / SERVER

节点超时：区分测试失败与实际不可用

适用现象是服务器列表出现超时、Connectivity Test 没有得到预期结果，或选中服务器后页面长时间无响应。测试结果反映的是特定时刻、特定网络下的一次检测，不等于所有应用的实际访问结果。先确认当前网络本身可用，再在同一网络、同一位置重复一次测试；如果测试目标和日常使用目标不同，两个结果也可能不同。不要仅凭一次超时就删除整组订阅。

先检查输入信息

手动添加的服务器应逐项核对协议类型、服务器地址、端口和所需的认证信息。地址中多一个空格、端口位数录错、协议与服务端设置不一致，都可能表现为超时。Shadowsocks、VMess、VLESS、Trojan、WireGuard 等使用的参数并不相同；应以用户自己持有的服务器信息逐字段核对，而不是把一条连接的参数套给另一种协议。通过 Scan QR Code 导入时，同样需要检查导入后的条目是否符合原始信息，扫码成功只表示内容已被识别。

如果条目来自已有订阅，先核对上一次更新是否成功，再确认当前选中的是更新后的有效条目。一次订阅更新可能改变服务器地址或条目顺序，旧的手动副本却仍留在列表里。为避免混淆，可记录名称、分组和来源，只测试其中一个明确的条目。涉及密码或令牌时，不要将完整信息贴到公开讨论区；排查所需的是字段是否一致，而不是公开字段的实际取值。

通过交叉测试找共同原因

保持服务器不变，在 Wi-Fi 与蜂窝网络之间做一次对照；再保持网络不变，测试另一条用户已有的服务器。若只有一条服务器在两种网络下都超时，优先核对那条配置和服务端状态。若同一批服务器仅在某一个网络下失败，先检查该网络的接入条件、认证页面与 DNS。若全部服务器在不同网络下都失败，再回到系统连接状态、订阅内容和共同配置检查。交叉测试每次只改变一个条件，才能留下可复核的结论。

延迟测试能帮助发现明显无响应的条目，但数值小不必然表示网页加载快。连接建立之后仍有域名解析、规则匹配、目标站点响应等步骤。若测试有结果而网页持续打不开，转到路由排查与DNS 排查；若测试长期超时且输入信息无误，需要由用户向自己已有信息的提供方核对服务端状态。节点选择时如何理解测试结果，也可阅读延迟、地区与协议类型。

04 / SUBSCRIBE

订阅导入与更新失败：按链接、网络、内容排查

本章仅讨论用户已经持有的订阅链接。导入失败、更新提示失败、更新后列表没有变化，是三种需要分别判断的现象。先确认操作对象是 Subscribe 类型的订阅，而不是一条单独服务器信息或配置文件；它们在应用内承担不同用途。复制链接时检查首尾空格、遗漏字符与意外换行，特别是从消息中分段复制的地址。链接中的凭据属于用户自己的敏感信息，不应放入公开截图或求助文字。

判断链接是否仍能取得内容

在导入前先确认设备网络可用；网络本身不通，订阅获取自然无法完成。若此前可更新而现在失败，检查用户持有的原始链接是否被替换、凭据是否发生变化，再向该信息的提供方核对有效性。不要通过不断新建同名 Subscribe 条目来“重试”：这样会留下多个来源相似的分组，后续无法确认选中的是哪一份。保留原条目，记录失败提示，再进行一次手动更新更便于比较。

链接可访问不等于内容一定能被解析。若更新有响应，但列表为空或条目内容明显异常，可能是返回的格式与导入方式不匹配，也可能是返回了错误提示而非服务器数据。应确认复制的是订阅入口，不是介绍页面或登录页面的地址；也不要把网站页面地址直接填入 Subscribe。若使用 Import from Cloud JSON 或配置导入，应按内容类型选择相应入口，而不是统一当作订阅链接处理。

处理更新前后列表不一致

手动更新后查看条目是否归入预期分组，再检查实际选中的服务器。更新可能改变名称和排序，列表里出现新条目却仍选着旧手动条目时，连接表现不会自动变好。若曾设置打开应用时自动更新，先以手动更新测试一次：手动成功而自动更新表现不稳定，可留意打开应用当时的网络是否已连通，以及短时间内是否切换过 Wi-Fi 与蜂窝网络。自动更新是获取内容的时机安排，不会修复无效链接或无法解析的数据。

有多个已有订阅时，先按来源分清分组，暂时只更新其中一个，再比较条目名称和数量的变化。重复条目可能来自多次导入，也可能由不同订阅返回同一服务器；删除前核对来源，避免误删仍在使用的配置。相关操作见订阅更新失败的排查与多个订阅的整理方法。若只是一条手动服务器失效，不需要为排查它而刷新所有订阅。

05 / PERFORMANCE

访问速度慢：明确慢在哪一步

“速度慢”至少包含三种不同表现：网页开始加载前等待很久、页面打开后持续传输缓慢、只有个别应用或网站慢。先记录是哪一种，再确定发生在 Wi-Fi、蜂窝网络，还是两者都有。使用同一设备、同一测试页面，在关闭连接与开启连接时各测试一次；如果设备当前网络本身拥堵，单独调整 Shadowrocket 无法解决基础网络问题。测试应避开页面内容频繁变化的目标，否则两次结果缺乏可比性。

识别连接建立与内容加载

点击链接后长时间没有任何内容，可能涉及 DNS 解析、连接建立或服务器响应；页面已显示却在加载图片时变慢，则更适合观察持续传输和目标站点状态。使用 Connectivity Test 查看所选条目的基本响应，再用实际访问复测。测试数值只描述检测过程，不代表视频、图片或大文件的完整体验。若只有某个域名慢，记录其在 Config、Proxy、Direct 下的差异，避免因全局切换掩盖原本正常的其他请求。

对于用户已有的多个服务器，保持网络和目标页面不变，每次只更换服务器进行比较。地区距离、服务器负载、协议配置以及目标站点的响应都可能影响结果；不能仅凭名称中的地区字样或一次延迟测试判定性能。若所有服务器在同一 Wi-Fi 下都变慢，而蜂窝网络较稳定，应优先调查该 Wi-Fi 的实际吞吐、信号与接入状态。若仅一条持续慢，再核对这条服务器的信息与服务端状态。

检查规则带来的路径差异

Global Routing 处于 Config 时，请求按规则决定路径。一个过宽的 DOMAIN-SUFFIX 规则可能把原本需要 Direct 的请求交给 PROXY；相反，也可能让原本打算经过所选服务器的目标走 Direct。先找出慢的具体域名，查看它命中的前一条有效规则，再在不影响其他规则的前提下做小范围修正。不要直接把所有规则删除后凭单次速度测试下结论，那会改变大量不相关请求的处理方式。

若仅在应用切到后台一段时间后首次访问较慢，需把恢复连接所花的时间与持续传输速度分开观察。On Demand 条件、网络从 Wi-Fi 切到蜂窝、设备从休眠恢复，都可能使首次请求与后续请求表现不同。连续测试两次并记录差异：只有第一次慢，更应查看连接触发与网络切换；每次都慢，再比较服务器和 DNS。更多选择思路见节点延迟与实际体验。

06 / DNS & RULES

DNS 与规则异常：从域名到最终策略

典型现象是某个域名无法打开、通过不同网络得到不同结果，或 Config 下失败但 Proxy 下正常。DNS 负责把域名解析为地址，规则负责决定请求如何处理；两者相关，却不是同一个设置。先核对输入的域名是否正确，并用一个此前稳定可访问的页面对照。若仅特定域名异常，记录完整域名、当前网络、Global Routing 与命中的规则；若所有域名都异常，应先按前面的网络和节点章节排除共同问题。

理解从上到下的匹配

配置规则按从上到下的顺序检查，命中后按对应策略处理，后面的规则不再接管这次匹配。DOMAIN 针对完整域名，DOMAIN-SUFFIX 针对域名后缀，DOMAIN-KEYWORD 按关键字匹配；IP-CIDR、IP-CIDR6 与 GEOIP 面向地址相关条件。FINAL 负责此前没有命中规则的请求，通常放在规则段最后。具体配置还需核对策略名称是否在当前配置中存在，不要直接把示例复制进与之不一致的策略组。

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

这段片段只演示语法与顺序：example.com 是示例域名，PROXY、DIRECT 是策略词，不代表适合每位用户的访问需求。若把一条宽泛的 DOMAIN-KEYWORD 放在更精确的 DOMAIN 前面，后者可能永远没有机会生效；若把 FINAL 提前，后续规则也无法承担预期作用。改动前保存当前配置，并一次只移动或修改一条规则。有关优先级与兜底的完整例子见规则匹配顺序与 FINAL。

区分解析失败与路径错误

浏览器提示找不到域名时，先比较关闭连接与开启连接的结果，再比较 Config、Proxy、Direct。如果不同姿态对同一域名结果不同，检查 DNS 设置与规则如何共同影响该域名；如果同一网络下其他域名都正常，不宜先重置全部配置。DNS 设置应按用户当前网络和已有配置要求核对：是否存在已不再适用的自定义地址、是否在不同网络之间表现不一致、是否为特定域名配置了例外。不要把“修改 DNS”当作所有超时的通用答案。

使用 IP-CIDR 或 GEOIP 判断时，还要注意规则能否获得相应的地址信息；仅凭域名表面文字无法推断最终会命中哪条地址规则。若出现“规则看起来正确，但目标仍走了另一条策略”，检查是否先被 DOMAIN 类规则命中，以及更早位置是否已有宽泛匹配。定位完成后恢复临时测试用的 Global Routing，重新以 Config 测试目标和一个不相关的网站，确认修复没有扩大影响。DNS 术语可继续查概念速查。

07 / POWER

耗电异常：记录触发条件与后台活动

适用现象是使用 Shadowrocket 的一段时间内，设备续航表现明显不同于平时。耗电受屏幕亮度、蜂窝信号、后台应用、网络频繁切换等多种因素影响，不能仅凭连接图标一直显示就归因于某一个设置。先到设备的电池使用信息中查看同一时间段内各应用和活动的占比，并记录网络类型、是否移动中、是否长期保持连接。对照应选相近的使用时长和场景，而非把高强度视频使用与待机状态直接比较。

检查反复连接与自动触发

如果耗电变化恰好发生在频繁切换 Wi-Fi 与蜂窝网络时，查看 On Demand 是否对 Wi-Fi、Cellular 或 Domain 设置了相互重叠的条件。反复连接、断开与重连，会使网络活动增多。先记录原有条件，暂时停止自动触发，改为手动连接进行一段可比较的观察；如果现象消失，再逐条恢复条件，找出是哪一条在当前环境中频繁执行。On Demand 解决的是“何时连接”，不应被当作改善所有续航问题的总开关。

若连接反复中断，同时出现节点超时，应先排查网络信号和服务器信息。网络质量差时，反复请求也会增加活动量；单纯更换 Global Routing 不一定处理根因。可固定在一个稳定的 Wi-Fi 环境，用同一条已有服务器测试，再与移动中的表现对照。若仅某个位置或某段移动路线出现问题，记录网络切换发生的时刻，比凭主观印象比较电量百分比更可靠。

检查使用方式与复测结果

查看是否有应用持续进行后台同步、媒体传输或大量数据请求；Shadowrocket 处理这些请求时产生的活动，与应用本身空闲时不同。可先暂停明确的大流量任务，在相近时间段重新观察设备电池信息。不要为测试同时更改 DNS、订阅与全部规则：即使耗电下降，也无法确认原因。需要比较时，按“原设置记录、单项调整、相同场景复测、决定是否恢复”的顺序进行。

如果设备异常发热或电量快速下降，即使关闭 Shadowrocket 的连接仍持续，问题可能不局限于当前代理配置，应优先检查设备系统与其他正在运行的应用。若关闭连接后恢复正常，则保留连接条件、网络类型和测试时间的记录，再查频繁重连、On Demand 条件及持续传输。排查的目标是识别可重复的触发条件，不是根据一次待机结果断言某个协议或某条规则必然省电。

08 / CHANGES

更新后异常：核对变化的是应用、配置还是网络

“更新后不能用”先要明确更新了什么：App Store 中的 Shadowrocket、设备系统、已有订阅内容，或自己维护的 Config 文件，都可能改变排查方向。先写下最后一次正常使用的场景，以及异常出现前做过的操作；不要因为时间接近就认定某个更新一定是原因。应用获取与更新以 App Store 为入口，兼容性和系统要求以 App Store 页面标注为准。若需要核对商店中的开发者与应用 ID，可查正版核验说明。

对照更新前的可验证状态

先测试不依赖 Shadowrocket 的设备网络，再测试 Home 开关能否保持开启，随后检查当前选中的服务器、Global Routing 和一个固定网页。若开关状态与此前不同，回到系统授权章节；若开关正常但所有服务器失败，回到网络与路由章节。这种分层判断比立即删除所有配置更稳妥，也能保留原始现场供后续核对。

如果变化的是订阅，关注服务器名称、分组、地址或选中项是否改变，而不是只看“更新成功”提示。若变化的是 Config，检查新规则是否排在旧规则之前、FINAL 是否仍位于合适位置，以及配置引用的策略名称是否存在。对于自己保存过的原配置，可以先比较具体差异，再只调整与故障目标有关的一项。不要把两个不同时间取得的配置混合粘贴：重复规则和失效引用会增加判断难度。

建立可回退的复测记录

在改设置之前记录原有选择，包括所选服务器、Global Routing、On Demand 条件及自定义 DNS。每做一项调整，就用相同网络和相同页面复测；若结果没有改善，恢复这一项后再查下一项。这样即便异常最终来自网络变化，也不会留下多处未经确认的设置修改。若问题只在某个应用中发生，还需分别测试浏览器和该应用，记录是否使用相同域名或网络环境。

App Store 可显示应用相关信息，但不要依赖他人写下的固定版本数字决定是否适用；以自己设备上的商店页面与实际界面为准。设备系统更新后若出现授权提示，按系统提示处理，再重新测试开关。若订阅更新后出现异常，则优先走链接与内容排查。始终把“更新行为”和“故障现象”分别记录，才能准确判断是哪一层发生了变化。

09 / IPAD

iPad 专项：分清界面布局与连接状态

iPad 与 iPhone 共享本手册的基本排查顺序，但屏幕布局、网络接入方式和使用场景可能不同。不要只凭 iPhone 上某个按钮的屏幕位置，在 iPad 上寻找完全相同的坐标；应以 Home、Settings、Global Routing 等界面词和当前功能为准。首先确认 iPad 本身可以通过所用网络访问普通网页，然后查看 Shadowrocket 开关、选中的服务器与路由姿态。若问题仅发生在 iPad，应优先比较两台设备的网络及配置，而不是认定某一台设备的硬件有故障。

核对网络类型和系统授权

部分 iPad 主要在 Wi-Fi 环境中使用，另一些设备也会使用蜂窝网络；实际可用网络以手中设备为准。在 iPad 上出现连接失败时，先确认 Wi-Fi 是否需要完成接入认证，或是否刚从另一网络切换过来。网络尚未连通时，Subscribe 更新、Connectivity Test 与网页访问都可能同时失败。连接授权仍由系统提示处理；若开关无法保持开启，按授权排查逐项核对，不要把订阅刷新失败误认为唯一原因。

如果 iPhone 上同一条已有服务器可用、iPad 上不可用，确保比较的是同一服务器信息，而不只是同名条目。两台设备可能分别保留了不同时间导入的订阅或手动副本；核对协议、地址、端口以及当前选中项的来源。然后在同一 Wi-Fi 下测试两台设备，尽量排除网络差异。若 iPad 使用的是另一个 Wi-Fi，先把网络差异记录清楚，再讨论配置是否一致。

检查大屏操作与自动连接条件

iPad 横竖屏切换或多窗口使用时，界面元素可能重新排列，但不改变 Global Routing 中 Config、Proxy、Direct 的含义。修改设置后回到 Home 确认选中项，再访问相同目标复测，不要因为列表位置变化就误选了另一条服务器。若仅在设备唤醒后访问失败，检查 On Demand 对当前 Wi-Fi 或 Domain 的触发条件，并比较手动开启是否正常。手动正常而自动连接不符合预期，排查重点应放在触发条件，而不是先修改所有服务器参数。

换设备后的已购获取与首次打开步骤见iPad 获取说明；系统要求与兼容性以 App Store 页面标注为准。若另一台设备与 iPad 的订阅内容不同，应分别核对各自的导入和更新结果，不能假设在一台设备上调整配置会自动改变另一台设备。最后用“同一网络、同一服务器信息、同一目标页面”进行对照；只有这些条件明确，iPad 专项的问题才能与一般的网络或服务器故障区分开。