Shadowrocket 订阅导入与首次连接

步骤 1 / 准备可连接条目

Add Server 与 Subscribe：导入已有信息

打开 Shadowrocket，先停留在 Home。这里用于查看服务器列表、选择当前服务器和控制连接。首次使用时，列表中可能还没有可选条目；此时先不要打开连接开关。确认手中的资料是订阅链接，还是某一个服务器的独立参数，两者使用的入口相近，但填写方式不同。

已有订阅链接：选择 Subscribe

在 Home 点右上角加号进入 Add Server，打开 Type 并选择 Subscribe。将自己的完整订阅链接粘贴到 URL，核对开头、路径和末尾参数，再保存。链接中的认证参数也是地址的一部分；少复制一个字符、把换行带进去，或者把说明文字一起粘贴，都可能导致获取失败。备注可用自己能辨认的名称，避免直接把完整链接当作名称。

保存后回到 Home，等待订阅内容获取完成，检查是否出现对应分组和服务器条目。看到订阅名称不代表已经成功取得服务器列表；应继续展开或查看该分组，确认里面确实存在可选择的条目。若内容仍为空，先处理订阅获取问题，不要反复建立同名订阅。已有条目时，点选其中一个服务器作为接下来的测试对象。

订阅链接通常带有访问凭据，应只保存在自己需要使用的设备与可信备份中。向他人说明故障时，描述错误现象即可，不要发送完整链接。订阅更新、多订阅整理与删除后的影响在服务器管理手册中单独说明，本页先完成一次导入，不调整自动更新策略。

已有单个服务器信息：按协议填写

若资料由服务器地址、端口和认证信息组成，同样从 Add Server 开始，在 Type 选择资料明确标注的协议，然后逐项填写。不要因为名称相近就更换协议，也不要将网页地址整段填入服务器地址字段。地址与端口需要分别核对；密码、用户标识以及协议要求的其他选项，应与自己的原始资料保持一致。

不同协议展示的字段不同。例如某些连接还需要核对 TLS、Server Name 或传输设置，这些不是可以凭感觉补齐的选项。原始资料没有提供必要参数时，应先核实资料，而不是连续尝试多个组合。填写完成后保存，返回 Home 查看条目名称并选中它；需要修改时重新进入该条目的编辑页面，尽量不要重复添加多份相同记录。

如果已有兼容的二维码，可使用 Scan QR Code 读取，但识别成功后仍要检查生成的服务器字段。截图、二维码和分享链接都可能包含认证信息，不适合作为公开排查材料。完成本步骤的判断标准是：Home 中存在一个来源明确、参数已核对且已选中的服务器，而不是仅仅保存了一个订阅名称。

步骤 2 / 确定流量处理方式

Global Routing：选择合适姿态

服务器已选中后，在 Home 打开 Global Routing。这里决定流量按什么方式处理，不负责补全服务器参数。首次使用应先明确当前选择，再测试网页；否则即使访问成功，也可能不知道请求是通过所选服务器还是直接完成的。三种姿态分别是配置(Config)、代理(Proxy)、直连(Direct)，不要把它们与底部的页面入口混为一谈。

配置(Config)：按当前配置处理

配置(Config)依据当前生效配置中的规则决定流量去向。需要使用分流时，先到 Config 确认选中的是自己准备使用、且理解来源与用途的配置，再回到 Home 选择 Config。仅导入订阅不代表同时导入了符合预期的规则；订阅中的服务器列表和 Config 中的配置文件承担不同任务。

规则有匹配顺序，也可能把部分请求设为 DIRECT，因此在 Config 下某个网页能打开，并不能单独证明代理链路正常。首次连接后应结合请求记录检查实际策略。若尚未准备好规则配置，可先用下一种姿态隔离规则影响，确认服务器本身可用，再回到配置问题。

代理(Proxy)：先检查所选服务器

代理(Proxy)适合在首次排查时临时检查所选服务器的代理访问路径，减少规则选择带来的干扰。它仍依赖正确的服务器参数、可用的本地网络与服务端状态，并不保证所有应用的所有请求都会得到相同结果。测试期间记住原来的选择，验证完成后再恢复日常使用的 Config，避免把临时排查设置长期保留。

直连(Direct)：用作本地网络对照

直连(Direct)让流量直接访问，不以所选服务器作为代理出口。它适合与代理访问作对照，判断本地网络是否本来就能访问目标。不要选了 Direct 后，仅凭开关已打开就认定服务器连接成功。完成选择后返回 Home，再确认一次服务器选中状态，随后进行系统授权和连接。

步骤 3 / 建立设备连接

打开连接开关，完成系统授权

回到 Home，检查当前服务器和 Global Routing 与前两步一致，再打开顶部连接开关。首次建立连接时，系统可能提示添加 VPN 配置；这是让设备允许客户端建立网络隧道的授权步骤。阅读提示中的应用名称，确认本次操作来自刚打开的 Shadowrocket，然后按系统要求允许，并使用设备要求的验证方式完成确认。

授权完成后回到 Home，观察开关是否保持开启，以及页面是否显示已连接状态。系统的 VPN 标识可作为辅助信息，但不同设备的展示位置并不完全相同；不要为了寻找某个固定位置的图标而反复操作。更重要的是客户端连接状态是否稳定，以及下一步的实际访问能否完成。

如果先前取消了授权，返回客户端再次发起连接，并按系统提示处理。如果系统仍未出现预期提示，可到设备 Settings 中检查 VPN 相关配置与管理限制。设备受管理时，应按管理要求处理，不要随意删除不认识的配置。没有完成系统授权时，先解决授权问题，不必急着更换服务器协议。

若开关刚打开就自行关闭，记下是否出现错误提示，检查服务器是否仍被选中、必要字段是否完整，以及设备是否存在另一条正在使用的 VPN 连接。此时不需要连续快速开关；先关闭连接，核对一项后再尝试。快速重复连接容易使排查记录混乱，也无法说明究竟是哪次修改产生了结果。

首次验证期间保持当前网络不变，先不启用 On Demand，以免网络条件触发的自动行为干扰观察。需要按条件自动连接时，等手动连接与访问都正常后再设置。完成本步骤仅代表设备已尝试建立隧道，仍须通过下面的实际请求确认是否能正常使用。

步骤 4 / 检查真实访问

Connectivity Test 与网页验证

保持连接开启，在 Home 使用 Connectivity Test，观察所选服务器是否返回测试结果。测试适合快速筛查明显不可达的条目，但测试目标和浏览器实际访问的目标并不一定相同。有数值只说明该次测试取得了响应，不能直接等同于所有网页正常，也不能据此判断日常访问速度。

接着打开浏览器，重新加载一个自己熟悉且能够判断内容是否更新的网页，再换一个正常使用的页面作对照。优先发起新的请求，不要只看已经打开的标签页，因为旧页面可能来自缓存。若正在验证某个指定目标，应使用同一个目标比较修改前后的结果，避免把不同网站的响应差异误认为设置变化。

返回 Shadowrocket 查看 Data 中的请求或流量记录，结合访问发生的时间查找对应请求。如果当前版本提供相应详情，可检查目标、命中规则和所用策略。Config 下出现 DIRECT 不一定是错误：若规则本来要求该目标直连，这正是分流结果。反过来，如果预期通过代理却记录为 DIRECT，应先核对当前配置和规则，而非立即重建订阅。

为了确认服务器路径，可在记下原设置后，临时切换到 Proxy，再对同一目标发起一次新请求。若 Proxy 可访问、Config 不可访问，优先检查规则与配置；如果两者都失败，再回到服务器参数、DNS 和本地网络。测试结束后恢复原来的 Global Routing，不要同时保留几项临时修改。

可以把一次合格验证归纳为三件事：Home 的连接状态保持稳定，实际网页的新请求能够完成，请求记录与所选姿态相符。三者比单独的开关状态更有参考意义。需要结束使用时返回 Home 关闭连接；之后如果要换到另一种网络，重新进行简短验证，不把之前的成功结果直接套用到新的网络环境。

步骤 5 / 按现象缩小范围

常见失败点：每次只改一项

遇到失败时，先判断停在了哪一步：订阅无法获取、服务器无法测试、连接无法保持，还是网页无法访问。它们对应的检查位置不同。先记录当前网络、所选服务器、Global Routing 和错误提示，再按下面的顺序检查；不要把重新安装应用作为第一步，因为它不能修复失效的服务器资料，还可能丢失现有设置。

订阅保存成功，但列表为空

回到订阅编辑位置，检查 URL 是否完整，尤其是末尾认证参数是否被截断。确认自己的订阅仍有效，并检查当前网络能否完成订阅获取。订阅访问和服务器连接是两个不同阶段：已有旧服务器条目可以测试，并不代表订阅更新也一定成功。先查看更新结果，再决定是否需要修改链接，不要把完整订阅粘贴到公开讨论区求证。

Connectivity Test 失败或连接立即断开

先确认本地网络可以正常使用，再核对所选条目的地址、端口、协议与认证字段。有 TLS 或传输选项时，逐项与原始资料对照，特别留意复制时附带的空格。如果自己已有其他服务器，可在保持 Global Routing 不变的情况下只切换服务器作对照。只有一个条目失败时，先围绕该条目检查；所有条目均失败时，再检查共同的网络条件与系统授权。

测试有结果，网页仍打不开

这时重点区分 DNS 解析与实际连接。若记录中出现解析失败，先检查当前配置是否指定了无法访问的 DNS，或是否存在不符合当前网络条件的设置。不要为了试错一次添加多个 DNS 地址，也不要直接覆盖整份配置。若临时 Proxy 下同一网页可访问，而 Config 下失败，应进一步检查该目标命中的规则、策略及相关解析设置。

换网络后才出现异常

从 Wi-Fi 切换到蜂窝网络后，本地网络路径和可用条件可能变化。先保持同一服务器与同一姿态，重新连接并测试同一目标，记录两种网络下的差别。若回到原网络恢复正常，这一对照比连续修改协议更有价值。若设置了 On Demand，还应检查切换网络时是否触发了自动连接或断开，避免把自动行为误认为手动开关失效。

保留结果，再继续深入检查

每次修改后重复同一测试；没有改善就恢复原值，再进入下一项。需要进一步分析时，可整理错误文字、发生步骤和已验证的条件，但应遮去订阅链接、密码及认证参数。常见现象的解释见疑难解答；订阅更新、服务器整理和备份操作见服务器管理手册。本页流程完成后，再逐步增加规则、自动更新与 On Demand 设置，能让后续问题更容易定位。