OFFICIAL MANUAL / FIRST CONNECTION

Shadowrocket 使用说明：订阅导入与首次连接

按导入、路由、连接、验证、排查的顺序操作。先完成一次可验证的连接，再调整规则与自动连接设置。

  • iPhone / iPad
  • 已有订阅或服务器信息
  • 五步操作

STEP 01 / IMPORT

Add Server：添加服务器或导入订阅

打开 Shadowrocket，进入 Home。先判断手中信息属于哪一种：一条用于更新服务器列表的订阅链接，还是单个服务器的地址、端口与认证信息。两者填写方式不同，不要仅根据链接长短判断类型；如果不清楚，先核对服务商给出的用途说明。首次操作时暂时保持连接开关关闭，先把信息保存完整。

已有订阅链接：选择 Subscribe

在 Home 点击右上角的添加入口，进入 Add Server。打开 Type 选择列表，选择 Subscribe，再把完整订阅链接粘贴到 URL 字段。备注可以填写自己能辨认的名称。粘贴后检查开头与结尾是否完整，尤其注意复制时是否带入空格、换行或聊天文字，不要手动删改链接中的参数。

确认后使用页面上的保存操作返回 Home，等待订阅内容读取完成。成功的可观察结果不是只出现一个订阅名称，而是订阅下已经列出可选择的服务器。如果只有分组却没有服务器，先检查是否有读取错误提示，再执行一次该订阅的更新操作。不要通过反复新增同一链接来代替更新，否则后续很难分清正在测试的是哪一组内容。

订阅链接通常包含访问凭据，应按账号信息保管。不要把完整链接粘贴到公开讨论区，也不要为了测试而提交给不明网页。应用里的订阅更新，是向该链接请求当前服务器列表；它与 App Store 更新 Shadowrocket 是两件事。后续列表发生变化时，应更新原有订阅，并再次确认选中的服务器仍然存在。

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

如果拿到的是单个服务器参数，在 Add Server 中先选择服务商明确给出的协议类型，再逐项填写服务器地址、端口以及该协议所需的认证字段。例如 Shadowsocks 与 VLESS 的认证字段并不相同，不能因为地址一致就互换 Type。涉及 TLS、传输方式或服务器名称的字段，也应按原始信息填写，不要凭经验开启或关闭。

如果已有用于导入单个服务器的二维码，可通过 Scan QR Code 读取，并在保存前检查识别出来的 Type 与服务器地址。二维码只是信息载体，不保证参数一定有效；识别失败时应回到原始信息核对，不要通过猜测端口或认证值来补全内容。协议字段的含义可查阅名词解释。

保存后返回 Home，点选准备使用的服务器，确认当前选择指向预期条目。此时只完成了“信息已进入客户端”，还没有证明服务器能连接。下一步先确定请求如何路由，再打开连接开关，避免在尚不清楚模式时直接判断导入是否成功。

Input
已有订阅链接，或完整服务器参数。
Result
Home 中出现可选择的服务器，并已选中一个条目。
Next
打开 Global Routing，确认本次测试采用的姿态。

STEP 02 / GLOBAL ROUTING

Global Routing：选择配置、代理或直连

回到 Home，点击 Global Routing 查看当前姿态。这里决定请求如何处理，不是选择服务器地区，也不是订阅更新开关。先记住当前选择，后续测试时才能判断差异来自服务器，还是来自路由设置。三种姿态分别写作配置(Config)、代理(Proxy)、直连(Direct)。

Config
配置(Config)：根据当前配置文件中的规则与策略处理请求，可能分别走 PROXY、DIRECT 或 REJECT。
Proxy
代理(Proxy)：用于让受客户端处理的请求走代理路径，适合作为首次连接的对照测试。
Direct
直连(Direct)：用于直接连接，不应把该姿态下的正常访问当成代理路径已验证可用。

STEP 03 / CONNECT

Home：打开连接开关并完成授权

在 Home 再次检查当前服务器与 Global Routing，随后打开顶部连接开关。首次连接时，系统可能要求允许 Shadowrocket 添加 VPN 配置。该提示表示应用要建立用于处理网络流量的系统连接配置，不表示系统已经核验了你填入的远端服务器。阅读提示，确认是刚刚主动触发的操作后，按系统要求允许并完成认证。

授权后返回 Shadowrocket，观察开关与连接状态是否保持开启。不同设备显示连接标识的位置可能不同，因此不要只凭状态栏上是否看见某个图标作判断。应用仍可能遇到认证失败、连接超时或服务器不可达；系统连接已建立，与远端代理路径可用，是需要分别验证的两个结果。

如果之前取消过授权，重新回到 Home 尝试开启，并观察系统是否再次提示。若开关立即回到关闭状态，先阅读应用提示，再检查系统 Settings 中相关 VPN 配置的状态，以及设备是否存在限制。使用受管理的设备时，应遵循设备管理要求，不要为了完成教程随意删除已有的管理配置。

连接保持开启后，暂时不切换多个服务器，也不同时更改 Global Routing。先进入下一步取得一次测试结果。若需要停止测试，回到 Home 手动关闭开关，并确认应用显示已断开；如果连接会自动重新建立，再检查是否设置了 On Demand 或其他自动连接条件。

STEP 04 / VERIFY

Connectivity Test：验证连接与规则结果

连接开启后，在 Home 使用 Connectivity Test 对已有服务器进行测试。等待本轮测试结束，先看当前选中服务器是否返回结果。测试数字只反映特定测试方式与当时网络条件下的一次表现，不等于网页加载速度，也不代表持续可用性。测试超时值得检查，但也不能仅凭一次超时就断定所有业务请求都会失败。

先测实际访问，再看规则命中

打开浏览器，访问一个平时正常使用、内容较轻的页面，等待新的请求完成。避免只看已经打开的旧页面，因为缓存内容可能在断开连接时仍能显示。随后再测试另一个独立页面，记录是全部失败、部分失败，还是仅加载较慢。不要把某个网站自身的故障直接归因于 Shadowrocket。

回到应用查看连接记录或 Data 中可用的相关信息，找到刚才请求的目标，核对实际采用的策略与路径。若记录提供匹配规则，进一步确认它是否符合预期：例如预期直连的目标命中 DIRECT，预期代理的目标使用当前服务器或配置中的对应策略。仅看到流量计数增加，不能证明某个具体请求一定走了代理。

如果刚才使用 Proxy 且实际访问正常，可切换为配置(Config)，重复访问同一组页面。对比结果时保持同一个服务器与本地网络不变。若只有 Config 下出现差异，优先检查当前配置、规则顺序及策略选择，不要立即重新导入订阅。规则可能把请求分配到与 Home 当前选择不同的策略，需要结合实际记录理解。

把验证结果分成三层

第一层是“客户端已连接”，通过开关与应用状态确认；第二层是“服务器路径可用”，结合测试与实际访问确认；第三层是“规则符合预期”，通过相同目标的匹配记录确认。这三层不能互相替代。只完成第一层时，不应直接认定订阅有效；完成第二层后，也仍需要检查配置(Config) 是否按预期分流。

如果需要对照原有网络，先记下当前路由姿态，再手动断开，重新请求相同页面，最后恢复连接重复一次。每次只改变一个条件，才能让结果有解释价值。完成后保留适合日常使用的姿态，不必为了追求更小的测试数字持续切换服务器。

Connection
开关保持开启，应用连接状态稳定。
Request
新发起的实际页面请求能够完成。
Routing
请求记录中的规则、策略和路径符合预期。

STEP 05 / TROUBLESHOOT

常见失败点：从最早未通过的步骤检查

排查时先回答“哪一步第一次没有得到预期结果”。如果 Home 还没有可用条目，就先处理导入；如果授权尚未完成，就先处理系统连接；如果能连接但部分页面失败，再进入访问与规则检查。不要一次重置配置、重导订阅并切换网络，这会消除对照条件，也可能覆盖原本正确的信息。

订阅没有内容，或导入时提示失败

重新核对完整 URL 与订阅用途，检查是否误填了服务说明网页地址，以及复制时是否遗漏参数。订阅读取需要当前网络能访问该链接；客户端能打开，不等于订阅地址一定可达。如果出现认证或内容格式错误，应保留错误文字，并从你的服务商处核对链接状态与适用格式。不要公开完整链接，也不要在无法确认原因时随意改动其中的认证参数。

单个服务器导入失败时，从 Type 开始检查，再按地址、端口、认证、TLS 与传输设置的顺序逐项对照。字段缺失与字段填错是不同情况，保存成功也不代表这些值正确。二维码识别出的内容同样需要核对；若缺少必要信息，应回到原始说明获取准确值，而不是试填常见默认值。

开关能开启，但实际请求失败

先确认当前选中的服务器仍属于已更新的列表，再用 Connectivity Test 与实际页面分别测试。若拥有多个已有服务器，可只切换服务器做一次对照，保持路由姿态不变。随后在条件允许时切换 Wi-Fi 与蜂窝网络，重复相同测试。这样可以区分问题是否随服务器变化，或是否只在某一种本地网络下出现。

如果所有测试都失败，检查服务器地址是否可解析、端口与认证信息是否匹配，并留意应用提示的错误类型。连接超时与认证失败的排查方向不同，前者需要关注网络可达性，后者需要优先核对凭据和协议。不要用单一的“连接失败”概括所有现象，也不要把重复点击开关当作修复步骤。

Proxy 正常，Config 下部分访问异常

先在 Config 确认当前使用的配置文件，再对失败目标查看匹配记录。检查它是否命中了预期规则，策略是否指向可用服务器，以及是否被分配为 DIRECT 或 REJECT。若涉及域名解析，还要区分域名没有解析成功与解析后连接失败。首次排查不建议同时更换多组 DNS 设置，先保留现状并记录证据，相关术语可查阅名词解释。

如果只有个别目标失败，而其他请求正常，应优先检查该目标、匹配规则与所用路径，不要立即删除全部配置。若只是速度慢，分别比较轻量页面与实际业务请求，并保持测试时间相近。一次延迟结果无法覆盖带宽、服务器负载、目标服务响应和本地网络质量等差异。

整理可复现信息，再继续处理

记录设备类型、本地网络、Global Routing 姿态、当前协议、失败发生在哪一步，以及应用显示的原始错误。分享记录前遮盖订阅 URL、服务器认证信息和其他个人数据，只保留定位问题必需的片段。能清楚描述“相同服务器在 Proxy 可用、Config 下某个目标失败”，通常比反复重装更有助于缩小范围。

到这里，首次使用的闭环应当是：信息能导入、服务器能选中、连接能建立、实际请求能完成、规则结果能解释。继续处理具体错误可查看常见问题；App Store 商店地区、购买与换机恢复另见获取指南。本教程保留手动连接的基础流程，后续调整 On Demand 或复杂配置时，也应沿用一次只改变一个条件的验证方法。