官方手册 / 首次连接

Shadowrocket 使用教程

已有订阅导入 → Global Routing 选择 → 连接授权 → 效果验证 → 失败点排查。先完成一次可复现的连接，再调整规则与自动连接设置。

  • 操作范围 Home / Config / Data
  • 先验证手动连接
  • 每次只改一项设置

STEP 01 / 导入已有内容

Add Server：添加服务器或 Subscribe

先判断手里的资料是什么，再选择入口。订阅链接是用来获取一组服务器信息的地址，不是某一台服务器的地址；单台服务器资料则通常包含协议、地址、端口以及认证参数。两者不要混填。打开 Shadowrocket，进入 Home（主页），点击右上角添加入口，进入 Add Server（添加服务器）。以下两条路径选择符合自己资料的一条即可，不需要重复添加。

已有订阅链接：选择 Subscribe

在 Add Server 的 Type（类型）中选择 Subscribe（订阅），把自己的完整订阅链接填入 URL，并填写便于辨认的备注。粘贴后先查看开头、结尾是否完整，是否夹入换行、空格或聊天文字，再保存。链接中的查询参数可能承担身份验证作用，不要为了缩短地址而自行删去。这里填写的是已有订阅的获取地址，不要填成服务介绍页面或账户登录页面。

保存后返回 Home，等待内容获取完成，检查对应分组下是否出现服务器条目。看到订阅名称并不等于已经取回内容，应继续确认分组能展开、内部有可选服务器。若导入后列表为空，先保留提示信息，检查链接有效性与当前基础网络，不要立即反复新建相同订阅。后续更新是在原有订阅上刷新内容，通常不必为每次更新重新添加一份。

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

仍从 Add Server 进入，在 Type 中选择资料指定的协议，再逐项填写服务器地址、端口和对应认证字段。例如 Shadowsocks、VMess、VLESS、Trojan 的字段并不完全相同，应以自己的服务器参数为准。地址栏只填写资料要求的主机名或地址，不要把完整订阅链接塞进去。不要凭名称猜协议，也不要把其他条目的参数拼接成一条新记录。

如果资料还包含 TLS、服务器名称或传输相关选项，应一并核对；仅有地址和端口未必足够。通过 Scan QR Code（扫描二维码）导入已有连接资料时，也应在保存后检查解析出的类型和地址，而不是只看扫码是否成功。二维码只是一种输入方式，并不替代参数核对。没有对应字段的明确资料时，先确认原始说明，不要随意改变加密或认证选项。

本步完成的标准是：Home 中有一条来源清楚、参数完整且能够选中的服务器记录。先记住它的备注与所属分组；下一步会选择 Global Routing（全局路由），决定连接后的流量怎样处理。暂时不启用 On Demand（按需连接），以免自动触发行为干扰首次手动测试。

STEP 02 / 确认流量去向

Global Routing：配置、代理与直连

服务器已添加，并不代表所有访问都会走向它。回到 Home，点击 Global Routing，查看当前姿态。三个选项分别是配置(Config)、代理(Proxy)、直连(Direct)。先知道自己要验证什么，再选择对应项；不要把“连接开关已打开”和“全部流量都使用所选服务器”当成同一件事。

姿态含义首次检查重点
配置(Config)按当前启用配置中的规则与策略处理请求。检查 Config 中启用的文件及规则去向。
代理(Proxy)将流量交由代理路径处理，用于对照服务器连接情况。确认当前选中的服务器或相关策略。
直连(Direct)按直连路径处理流量。适合检查基础网络，不能据此证明服务器可用。

日常按规则使用：先核对 Config

准备使用配置(Config)时，进入 Config（配置）页面，确认当前启用的是哪一份配置，并查看其中的规则与策略。导入 Subscribe 与启用 Config 是两件事：订阅主要用于更新服务器列表，配置则决定匹配条件与处理去向。已有服务器出现在 Home 中，不意味着它会自动替换配置中的所有策略引用。对于自己不理解的配置，先核对来源与内容，再应用。

例如，DOMAIN-SUFFIX,example.com,PROXY 表示域名后缀匹配到 example.com 时采用 PROXY 所指的代理处理方式；IP-CIDR,192.168.0.0/16,DIRECT 则把对应地址段交给 DIRECT。这些只是规则语法示例，不需要为了完成入门教程照抄到当前配置。规则按匹配顺序工作，某条请求提前匹配后，后面的规则不一定会参与处理。

暂时用 Proxy 做对照，结束后恢复

如果目的是先判断已有服务器能否连接，可以临时使用代理(Proxy)，减少规则选择对测试结论的干扰。测试前记录原来的姿态，确认 Home 中选中了准备测试的服务器；测试结束再切回配置(Config)。直连(Direct)适合对照设备本身能否访问原本可达的目标，它不是检测远端服务器是否正常的替代方法。

本步结束时，应能说清楚“当前用哪一种姿态、哪一份配置或哪一台服务器”。如果还不能确定，先不要同时修改 DNS 与 On Demand。规则优先级、策略引用等较长内容可转到规则分流设置说明，此处先保持路径明确，进入连接步骤。

STEP 03 / 建立手动连接

Home：打开开关与允许 VPN 配置

返回 Home，再确认一遍服务器选中状态与 Global Routing。服务器名称相似时，要连同分组和协议一起辨认，避免实际选中的是另一条记录。准备好后打开顶部连接开关，观察应用显示的连接状态。首次连接可能先出现系统授权提示，在完成授权前，不要把开关短暂变化当成服务器错误。

首次出现添加 VPN 配置提示

系统请求添加 VPN 配置，是为了允许 Shadowrocket 建立用于处理设备网络流量的系统连接。确认刚才确实由自己在 Shadowrocket 中发起连接后，按系统提示允许，并完成设备要求的验证。这个过程与添加服务器是不同层级：系统授权决定应用能否建立连接，服务器参数决定后续通信能否成功。

允许后返回 Shadowrocket，查看连接是否继续。如果之前选择取消，应用尚未取得所需授权，应重新发起连接并按提示处理，而不是反复更换服务器密码。系统设置中的 VPN 项可以用于查看相关配置状态；不同系统版本的设置路径可能有差异，可使用系统设置搜索定位 VPN。不要把删除系统配置作为第一项排查操作，以免增加恢复步骤。

区分连接状态与实际访问结果

开关保持开启或系统显示 VPN 状态，说明系统连接已建立，但这还不是最终验收。所选服务器可能不可达，某个目标可能解析失败，当前规则也可能让目标使用直连。因此连接后应留在当前设置上继续验证，不要仅凭状态标识就结束操作，也不要在结果尚未明确时连续切换多个模式。

首次手动测试期间，暂时停止其他正在管理 VPN 连接的配置，并保持同一种网络环境。如果设备上已有 On Demand 条件自动触发，先记录这些条件，再暂停自动连接行为。否则手动关闭后又自动开启，容易被误认为开关失效。不要仅为了让测试“看起来成功”而删除自己不清楚用途的系统设置。

此时建议记录三个最基本的状态：当前是 Wi-Fi 还是蜂窝网络、Home 选中了哪条服务器、Global Routing 是哪种姿态。这样进入下一步时，即使访问失败，也能把问题限定在明确的测试条件内。连接稳定后再逐步加入自动化设置，比同时调整多个选项更容易判断原因。

STEP 04 / 分层验证

Connectivity Test 与实际访问检查

验证时分开看三件事：系统连接是否建立、所选服务器在当前测试方式下是否可达、实际目标是否按预期访问。任何一个结果都不能替代另外两个。先在 Home 使用 Connectivity Test（连通性测试），留意所用测试方式与对应条目的结果，再用日常应用或浏览器打开自己要访问的目标。

先读测试结果，再测真实请求

Connectivity Test 的结果受测试方式、测试目标、当前网络和服务器处理方式影响。有数字表示这一次测试获得了对应结果，并不保证所有网页或应用都能正常工作；超时也应结合测试目标判断，不要直接推断全部通信都已失败。比较两条已有服务器时，应保持相同测试方式与网络，否则两个数字缺少可比性。

实际访问时，先选择一个自己熟悉、原本就能正常打开的页面作为基础对照，再测试真正需要使用的目标。若只有某个应用失败，尝试用浏览器访问同一服务的页面，以区分应用自身状态与连接问题。保持测试对象一致，不要每次换一个页面，也不要仅凭已经打开的旧页面判断新连接是否成功；缓存内容可能并未产生新的网络请求。

在 Data 中核对连接记录

进入 Data（数据）查看当前可见的请求或连接信息，围绕刚才的目标寻找对应记录。需要确认的是请求是否出现、目标域名或地址是否符合预期，以及记录中可见的策略或处理去向。具体可见字段以应用内为准；若当前未记录足够信息，就重新发起一次明确的新请求，而不是从历史记录中随意选一条作结论。

使用配置(Config)时，重点核对匹配结果与预期规则是否一致。如果目标本应直连，却命中了代理策略，应检查启用配置及规则顺序；如果本应走代理，却命中了 DIRECT，应先找出命中的那条规则。不要只把 FINAL 改成另一个去向，因为请求可能早已被更靠前的规则处理，修改兜底项未必影响它。

验证通过的标准是：连接状态正常、实际目标能产生新请求并得到预期结果、可见的处理去向与当前路由选择一致。若测试时临时用了代理(Proxy)，切回配置(Config)后还应对同一目标再测一次。之后才适合根据自己的使用习惯配置 On Demand；具体条件与优先级见On Demand 设置说明。

STEP 05 / 单变量排查

连接失败：从基础网络查到规则

失败时先记下现象，再决定检查哪一层。“订阅取不回来”“开关无法保持”“测试超时”“只有一个目标打不开”是不同的问题，不宜用同一种处理方法。保留当前配置与错误提示，每次只改变一个条件，并使用相同目标复测。以下按从外到内的顺序检查，可以减少重复操作。

第一层：基础网络与订阅内容

先关闭当前连接，确认设备能够访问平时可达的页面。Wi-Fi 如果需要完成网络登录，应先完成登录；蜂窝网络则先检查网络服务与应用使用权限。如果基础网络本身不可用，应先处理它。切换 Wi-Fi 与蜂窝网络可以用作对照，但应分别记录结果，不要把切换前后的测试混在一起比较。

如果问题出在 Subscribe 更新，核对地址是否完整、已有订阅是否仍有效，以及当前网络能否获取该地址。订阅更新成功，只说明取回了列表，不保证其中每一条服务器都正常；更新失败也不必然让已保存的记录立即失效。先检查具体提示，再核对自己的订阅资料。不要在公开求助内容中展示含身份参数的完整链接。

第二层：服务器参数与系统授权

列表中已有条目却测试失败时，逐项核对协议、服务器地址、端口和认证字段。对于有 TLS 或传输选项的记录，也要检查相关参数是否与原始资料一致。设备日期和时间异常可能影响安全连接，应同时确认系统时间正常。若同一订阅里有其他自己已有的服务器，可选一条做相同条件的对照，但不要据此改写原记录中的未知参数。

如果开关刚开启就关闭，或一直停留在授权阶段，先看系统是否允许添加 VPN 配置，以及是否有其他连接管理设置介入。仅当已经明确系统配置被删除或需要重建时，再按应用提示重新建立。不要把系统授权失败和远端认证失败混为一谈；前者通常发生在连接建立之前，后者需要继续检查实际连接资料与错误记录。

第三层：路由、规则与 DNS

若代理(Proxy)下目标正常，配置(Config)下失败，优先核对当前配置、规则命中与策略引用；若直连(Direct)正常而代理路径失败，则继续看所选服务器和远端通信。这样的对照能缩小检查范围，但不是对故障原因的最终判定。每次切换后都要重新发起请求，避免旧连接仍被复用而影响观察。

只有部分域名无法访问时，再结合 Data 中的信息检查 DNS 与目标相关记录。不要同时替换 DNS、关闭认证检查、修改规则和切换服务器，否则即使暂时恢复，也无法知道哪一项起作用。DNS 工作方式与更细的失败提示解释可继续阅读常见问题；商店账号、已购恢复与购买核验则见App Store 获取指南，不需要在连接排查时重新处理购买流程。

至此，首次使用形成了完整闭环：已有资料成功导入、路由选择明确、系统授权完成、真实请求得到验证。后续调整仍沿用同一方法：先记录原状态，单独修改一项，再检查同一目标。需要继续配置时，可前往设置说明查看对应项目，不必重新执行全部入门步骤。