Shadowrocket 使用教程

01Add Server / Subscribe：导入已有信息

先分清手里的信息是什么，再选择入口。订阅链接用于取得并更新一组服务器；单个服务器的分享链接用于导入一个条目；地址、端口和认证信息则需要手动填写。不要仅凭链接以 https:// 开头就认定它是订阅，账户管理网页、说明网页与订阅地址不是同一种内容。链接用途不清楚时，先核对原有服务说明。

已有订阅链接：使用 Subscribe

打开 Shadowrocket，进入 Home，点击右上角的添加按钮，打开 Add Server。进入 Type，选择 Subscribe，返回填写页面后，把完整的订阅链接粘贴到 URL。如需区分多个订阅，可在 Remarks 中使用自己能辨认的名称，然后保存。订阅地址往往带有个人访问凭据，不要把它发到公开讨论区，也不要为了展示操作过程而公开完整链接。

保存后等待订阅请求完成，再返回 Home 查看是否出现相应分组与服务器条目。能看到订阅名称但没有服务器时，不能直接进入连接步骤：先确认请求是否成功、链接是否仍然有效，以及返回内容是否确实是应用支持的订阅数据。不要把显示订阅名称等同于已经成功取得全部服务器。

这里需要区分 Subscribe 与 Config。前者用于导入和更新服务器信息，后者用于管理影响规则等行为的配置文件。首次上手不必先导入陌生配置；已有订阅也不代表已经获得符合自己需求的规则配置。服务器列表出现后，先完成本页的连接验证，再按需要整理配置。

已有服务器参数：使用 Add Server 手填

如果持有的是单个服务器的参数，在 Add Server 的 Type 中选择实际协议，例如 Shadowsocks、VMess、VLESS 或 Trojan，再按已有信息填写对应字段。通常需要核对 Address 与 Port，认证部分则随协议变化，可能是 Password 或 UUID。不要把一种协议的字段套到另一种协议上，也不要根据端口号码猜测协议。

当已有参数包含 TLS、传输方式、Host、Path 或其他附加项时，应与原信息逐项对应。服务器地址与 TLS 中使用的名称可能承担不同作用，不能为了“看起来一致”而自行替换。信息不完整时，停在这一步核对原始资料，比保存一个猜测出来的条目更容易定位问题。

已有分享链接或二维码：导入后仍要核对

已有二维码时可使用 Scan QR Code，并在系统询问时按需允许相机权限；已有分享链接时，可复制完整内容，再使用应用提供的剪贴板导入入口。扫码识别或链接解析成功，只表示信息能够被读取，不表示服务器当前可连接。保存后仍要打开条目检查协议与地址，避免导入了过期信息或选错条目。

本步完成标志：Home 中已有明确的服务器条目，并已选中本次要使用的一个。此时先不要连续导入更多内容；下一步确认 Global Routing。订阅更新、多个分组与备份的详细方法见节点管理手册的 Subscribe 章节。

02Global Routing：选择连接姿态

服务器决定连接到哪里，Global Routing 决定连接如何分配。回到 Home，点击 Global Routing，先查看当前选择，再按本次目的调整。入门时先认识三种姿态：配置(Config)、代理(Proxy)、直连(Direct)。它们是路由选择，不是三个不同的服务器，也不会改变已有订阅的有效状态。

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

配置(Config)适用于需要规则分流的情形。应用根据当前启用配置中的规则决定使用 PROXY、DIRECT 或 REJECT 等策略，因此并非所有连接都会经过所选服务器。进入 Config 时，要区分“列表中存在的文件”与“当前实际启用的文件”；只导入文件但未启用，不能据此判断规则已经生效。

如果选择 Config 后某些网页可以打开、另一些打不开，先记录差异，不要立即认定订阅无效。规则通常自上而下匹配，命中后使用对应策略，前面没有命中时再由 FINAL 兜底。具体域名落到 DIRECT 还是 PROXY，需要结合当前规则查看，而不是仅凭连接开关的状态判断。

代理(Proxy)：用于检查代理路径

代理(Proxy)可以作为首次验证所选服务器的简化对照。在这个模式下检查通常由应用接管的代理流量，能减少普通规则分流对判断的干扰。如果日常准备使用 Config，可以先用 Proxy 验证基础连接，再切回 Config 对比同一网页。Proxy 不是修复服务器参数的开关，也不意味着任何应用的所有网络行为都一定按同一种方式处理。

直连(Direct)：用于直接连接对照

直连(Direct)用于直接连接，不应拿它来验证代理服务器是否可用。当 Direct 能打开某网页，而 Proxy 不能打开时，说明两条访问路径的表现不同，需要继续检查所选服务器及相关设置；反过来，也不能因为 Direct 失败就认定整个设备失去网络。请始终用同一个测试目标进行对比。

本步完成标志：能说清本次选的是哪种模式，以及为什么选择它。首次确认服务器时可先用 Proxy；已有明确规则需求时使用 Config。选择后返回 Home，继续完成连接授权。规则与设置项的进一步说明见功能说明。

03Home：打开连接开关并授权

在 Home 再检查一次：所选条目是刚才导入的服务器，Global Routing 也是刚才确定的模式，然后打开页面顶部的连接开关。首次启用时，系统可能提示 Shadowrocket 希望添加 VPN 配置。这是把网络配置交给系统管理的授权步骤，不是订阅付款提示，也不表示服务器已经通过可用性检测。

核对系统提示中的应用名称，确认操作由自己刚才打开的 Shadowrocket 发起，再选择允许，并按系统要求完成设备验证。验证过程应在设备的系统界面内完成；教程和订阅导入都不需要把设备解锁凭据发给他人。授权完成后返回 Shadowrocket，观察开关是否保持开启，以及应用是否显示相应连接状态。

如果此前拒绝了添加配置，或开关打开后立即回到关闭状态，先留意系统是否还有待处理的提示。必要时到系统 Settings 中检查 VPN 配置状态，再回到应用重试。不同系统版本的设置路径可能不同，应以设备当前显示的菜单为准。不要为了尝试连接而随意删除不认识的受管理配置。

设备上若已有其他 VPN 连接，应先确认当前实际启用的是哪一项，避免在另一项仍生效时测试 Shadowrocket。首次操作也先保持 On Demand 设置不变；自动触发连接会增加观察变量，待手动连接与断开都验证清楚后再配置。

本步完成标志：系统授权已经完成，应用开关能够保持开启。此处只确认本地连接流程已启动，不把系统 VPN 标识或开关开启当成远端访问成功的证明。下一步必须用实际请求验证。

04Connectivity Test：结合实际访问验证

先在 Home 使用 Connectivity Test 检查已有服务器，再切换到 Safari，打开一个平时使用且允许访问的网页。测试结果与网页加载分别反映不同环节：前者用于辅助判断测试目标的可达情况，后者才是本次实际访问的结果。不要把一次测试成功理解为所有网站、所有协议与所有规则都正常。

观察网页是否能够完成加载、内部链接是否能继续打开，而不只是看见曾经缓存过的标题或图片。可以重新加载页面，或者打开该网站一个此前没有访问过的页面。若只凭旧页面仍能显示就下结论，浏览器缓存可能掩盖真实连接问题。

随后回到应用核对 Global Routing。若当前是 Config，应结合连接记录检查测试域名使用的策略，确认是 DIRECT、PROXY 还是 REJECT。页面成功打开不一定意味着经过代理，因为规则可能让它直接连接；页面失败也可能是该域名命中了 REJECT，而不是服务器本身断开。

需要比较模式时，保留同一个服务器与同一个测试网页，只切换 Config 和 Proxy 中的一个变量，再重新发起请求。若 Proxy 正常而 Config 异常，下一步优先检查当前启用配置的规则与 DNS 设置。若两个模式都失败，则先回到服务器和基础连接环节，不要立即重写整份配置。

Data 中的变化可以作为应用处理过流量的辅助线索，但有流量记录并不自动证明目标网页已经正常返回。更稳妥的判断是同时核对：开关状态、实际页面加载、当前模式以及相关连接记录，几项信息之间应当能相互解释。

本步完成标志：实际网页可以按预期访问，并能解释它在当前模式下使用的路径。验证后恢复准备日常使用的模式；切换网络或服务器后，如有异常，再重复这一步，不必从购买与安装重新开始。

05常见失败点：按出现位置检查

排查时每次只改一项，并记下修改前后的结果。可以记录“所选服务器、Global Routing、测试网页、是否出现系统提示、失败发生在哪一步”，但不要记录或公开完整认证信息。这样既方便自己复查，也能避免反复切换设置后忘记最初的问题。

导入后没有条目

先回到第一步确认链接类型。如果把账户网页当成订阅地址，应用即使能访问该网页，也不能从中取得正确的服务器数据。检查粘贴时是否遗漏开头、末尾或查询参数，是否带入多余空格，以及订阅当前是否有效。对于手填条目，确认已经保存，而不是只退出编辑页面。不要连续重复添加相同链接来代替检查错误提示。

开关无法保持开启

先处理系统授权与本地配置状态，确认添加 VPN 配置的步骤已经完成，并检查是否有其他连接影响当前状态。这个阶段尚未完成本地连接流程，优先调整 DNS 或规则通常不能解决问题。若设备受到管理，应按设备管理要求处理，不要尝试随意移除配置。

开关已开，但所有测试都失败

核对当前选中的服务器是否正确，再检查地址、端口、协议与认证字段是否匹配已有信息。订阅能更新与其中某台服务器能使用是两件事；Connectivity Test 失败也应结合实际请求复查。如果自己的订阅里有其他已知可用条目，可以保持相同模式与相同测试网页，仅更换服务器进行对照。条目有效性需要从自己的服务信息中确认。

Connectivity Test 正常，网页却打不开

先确认测试使用的目标与网页访问并不相同，再检查是否只在 Config 下失败。域名解析、规则命中、远端响应以及测试方式差异都可能造成这种现象。进入相关设置前先记下原值，检查 DNS 是否被自定义，配置是否对该域名作了特殊处理。不要在尚未定位问题时同时更换 DNS、服务器和整份配置，否则无法知道是哪一步起作用。

只有部分网页或部分功能失败

保留能正常访问的页面作为对照，再检查失败页面涉及的域名与命中策略。同一网页可能请求多个域名，因此主页面打开而图片或登录功能失败，仍需要查看相关请求，而不是仅检查地址栏里的一个域名。Proxy 与 Config 的对比可以帮助缩小范围，但最终仍要回到实际记录与配置内容核对。

断开后自动再次连接

检查是否已经启用了 On Demand，以及它的触发条件是否符合当前网络。如果首次使用时就设置自动连接，手动断开后的表现容易被误判为开关失灵。先恢复到能够手动观察的状态，确认连接、访问、断开这三个动作都符合预期，再单独设置按需连接。

本页用于首次操作与快速定位。遇到问题时可从上方目录直接返回对应步骤，不需要反复重装应用，也不需要在尚未确认失败环节时一次性改动所有设置。