官方手册 · 首次连接
Shadowrocket 使用教程订阅导入与连接验证
先导入已有信息，再选择 Global Routing，最后验证实际请求。以下步骤适用于 iPhone 与 iPad；首次操作按顺序阅读，遇到问题再跳到对应阶段。
- 导入已有信息
- 选择连接方式
- 验证实际请求
STEP 01 / IMPORT
Add Server 与 Subscribe 导入
打开 Shadowrocket 后，先停留在 Home，暂时不要打开顶部连接开关。准备好从你的服务商处获取的原始信息，再根据内容选择导入方式：一条会返回服务器列表的订阅链接，使用 Subscribe；一组明确列出协议、地址和认证参数的信息，使用对应的服务器 Type。两种方式的输入内容不同，把订阅链接填进 Host 通常不能建立连接。
已有订阅链接
在 Home 点击 Add Server，进入添加页面后打开 Type，选择 Subscribe。在该类型对应的 URL 输入位置粘贴完整订阅链接，按页面提供的保存操作完成添加，再返回 Home 等待内容读取。如果输入框已经有文字，应先清空再粘贴，避免两段地址连在一起。链接可能包含身份凭据，复制时保留完整参数，同时检查开头和结尾是否夹入空格、换行或聊天文字。
返回 Home 后，查看 SERVER 中是否出现订阅返回的项目。列表已经存在时，先选中其中一个准备使用的服务器，不必立即反复更新订阅。若保存后仍为空，先核对链接是否有效、订阅是否允许读取，以及当前网络能否访问订阅地址。订阅内容的有效状态由你的服务商确认；仅仅保存了一个订阅名称，并不表示服务器已经成功导入。
已有单个服务器信息
再次进入 Add Server，根据服务商给出的协议选择 Type，再填写 Host 与 Port。认证字段随协议变化：例如 Shadowsocks 需要核对 Password 与 Method，其他协议则应按其要求核对相应参数，不能把不同协议的字段互相套用。官方截图展示的是其中一种填写界面，并不代表所有 Type 都有相同字段。Host 通常填写服务器域名或 IP，不要自行附加网页路径。
如果已有二维码，可使用 Scan QR Code 导入后逐项复核；Import from Cloud JSON 是另一种输入途径，只有信息来源明确提供相应内容时才使用。保存后回到 Home，确认选中的确实是刚导入的项目。到这里完成的是“把连接信息放进客户端”，接下来还需要决定请求采用哪一种路由方式。
STEP 02 / ROUTING
选择 Global Routing 姿态
导入完成后回到 Home，点击 Global Routing 查看当前选择。这里的三种姿态写作配置(Config)/代理(Proxy)/直连(Direct)。它们决定请求如何选择连接路径，不是三种服务器协议；修改这里也不会修复错误的密码、失效的订阅或无法访问的服务器地址。
| 姿态 | 操作前需要理解的含义 |
|---|---|
| 配置(Config) | 按当前启用的配置与规则选择策略，适合已有明确分流需求的使用场景。 |
| 代理(Proxy) | 以代理路径为主要处理方式，可用于核对选中服务器的实际连接情况；系统与配置中的特殊处理仍需一并考虑。 |
| 直连(Direct) | 使用直接连接路径，可用于建立当前网络的访问基线，不用于验证代理服务器是否正常。 |
如果已有可信来源提供的配置文件，进入 Config 页面，先确认准备启用的是哪一份配置，再检查其中的 Rule 与策略安排。订阅与配置文件承担不同任务：订阅主要提供服务器信息，配置文件描述如何处理请求。导入 Subscribe 后，不应据此推断一套符合需求的分流规则也已经自动准备好。
官方截图展示了 Config 编辑页中的 General、Rule、Hosts、URL Rewrite、HTTPS Decryption 和 Add Rule。首次连接不需要把每个分段都改一遍，也不需要启用 HTTPS Decryption。先保留能够理解的配置，尤其不要为了“连上”而同时调整多项与连接无关的设置。若只想定位服务器能否正常工作，可以暂用代理(Proxy)核对，再返回配置(Config)检查分流差异。
在 Rule 中，请求通常自上而下匹配，首条命中后使用对应策略；FINAL 用于处理未命中前序规则的请求。比如下方片段把示例域名交给 PROXY，其余请求交给 DIRECT。它仅用于解释匹配关系，不是建议覆盖现有配置的完整文件，也不代表适合所有使用场景。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT如果配置引用了策略组，还需要确认组内选择指向有效服务器。规则命中 PROXY 并不能证明服务器本身可用。规则优先级、DNS 与各分段语法可继续阅读配置大全；本教程先保持一个清楚、可复现的模式，然后进入连接步骤。
STEP 03 / CONNECT
在 Home 打开连接开关
确认导入项目和 Global Routing 后，返回 Home。在 SERVER 中选中本次准备使用的服务器，再打开顶部连接开关。官方截图中的 Not Connected 表示拍摄时尚未连接，这不是某个服务器的名称。操作时应关注顶部连接状态，以及列表中当前选中的项目，避免导入了新信息却仍在使用原先的选择。
首次建立连接时，系统可能显示添加 VPN 配置的确认提示。这是允许客户端通过系统网络扩展处理流量的授权步骤，不是要求重新购买应用。阅读提示中的应用信息，按系统要求确认并完成设备身份验证，然后返回 Shadowrocket 查看状态。若之前已经授权，后续连接不一定再次出现同样的提示。
如果选择取消授权，连接开关可能回到关闭状态。此时先重新执行连接并按提示完成确认，不要通过改服务器密码来解决授权问题。若设备由组织管理，系统限制也可能影响 VPN 配置的添加，需要按设备管理规则处理。系统设置中的 VPN 配置与应用里的服务器条目属于不同层次，删除前者不能代替修正后者。
当 Home 显示连接已建立后，先保持当前服务器与模式不变，再进行下一步测试。连接状态主要说明本地处理请求的通道已启动，不等于所有远端请求已经成功，也不代表配置里的每条规则都符合预期。服务器认证、DNS 解析和目标站点响应仍可能在后续访问阶段出现问题。
结束本次使用时，可回到 Home 关闭顶部开关。如果关闭后又自动连接，先查看 Settings 中是否配置了 On Demand，而不是连续切换开关。排错期间保持手动操作路径清楚，待基本连接确认正常后，再根据需求设置自动连接条件。
STEP 04 / VERIFY
用 Connectivity Test 验证结果
保持刚才选中的服务器，先在 Home 使用 Connectivity Test，并等待测试结束。测试结果应结合 Settings 中的 Test Method 理解：不同方法检查的环节不同，有些只能反映某种网络探测是否得到响应，不能把一个返回时间直接解释为所有网站的实际访问速度。测试失败也需要结合访问结果判断，而不是立即认定服务器所有功能都失效。
接着打开浏览器，访问一个平时熟悉、当前应能正常响应的网站。尽量使用明确的新请求，必要时重新加载页面，避免只看到浏览器已有的缓存内容。先观察页面能否打开，再观察是否持续加载失败、只有部分资源缺失，或者首次访问很慢。把现象记下来，比只记录“能用”或“不能用”更有助于定位问题。
若当前使用配置(Config)，还要分别核对一个预期走 DIRECT 的请求与一个预期走代理的请求。某个网站能够打开，可能恰好命中了 DIRECT，不能据此认定代理路径正常；相反，代理(Proxy)下能访问、配置(Config)下失败，通常值得进一步查看规则和策略组。对照时只切换 Global Routing，保持服务器与测试目标一致，测试完恢复原本准备使用的模式。
需要了解流量变化时可以查看 Data，但统计读数只适合辅助确认是否产生了流量，不是对某条规则正确性的最终证明。一次测试也不能代表所有目标、所有时段或所有协议都正常。完成基础验证的标准是：连接开关状态稳定、预期目标能够实际访问、当前模式与预期路径一致。若三项中有一项不符合，继续按下方失败阶段排查。
STEP 05 / DIAGNOSE
常见失败点与 Settings 检查
排错先定位停止在哪一步，再修改对应设置。不要一次重建订阅、切换协议、替换 DNS 和重写规则；这样即使恢复，也无法知道是哪一项起作用。建议先保存必要的配置记录，保持一个已知测试目标，在每次改动后重复同一组验证。
没有成功导入项目
如果 Home 中没有预期服务器，先回到 Add Server 核对 Type 与输入内容。Subscribe 使用的是订阅地址，不是服务商网页的登录地址；链接中的完整参数也不能随意删减。若读取结果为空、提示认证失败或内容无法解析，应从你的服务商处确认链接状态和返回格式。此时连接开关还不是重点，因为可用的服务器信息尚未准备完成。
有项目，但测试或认证失败
手动添加的信息应逐项核对 Host、Port、Password，以及对应协议的 Method、TLS 或其他必要选项。字段必须以服务商给出的信息为准，不凭经验猜测。设备日期与时间异常也可能影响依赖证书时间的连接。涉及 TLS 时，应核对服务端名称和证书信息，不要把关闭证书校验作为通用修复步骤。
进入 Settings 查看 Test Method，确认测试方式与要判断的问题相符。若某种探测失败但实际访问正常，先保留这个差异，不要只为获得一个测试读数而反复修改连接参数。反过来，测试有响应而页面打不开，也应继续查看 DNS、路由和目标响应，不能就此结束排查。
开关无法保持，或会自动重新连接
开关立即回落时，优先检查系统 VPN 授权是否完成、是否存在设备管理限制，以及应用当前显示的错误信息。如果手动关闭后又连接，检查 Settings 中的 On Demand 条件。排错期间可暂时关闭已启用的自动连接条件，再重复一次手动连接；测试结束后按原有需求恢复，不要把自动连接行为和服务器认证混为一谈。
已连接，但只有部分请求失败
先对照代理(Proxy)与配置(Config)的结果。差异明显时，回到 Config 查看命中的规则、策略组选择与 FINAL 兜底。域名无法解析而直接连接地址有响应时，需要进一步核对 DNS；但仅凭一个访问失败页面不能确定一定是 DNS 问题。TCP 与 UDP 也可能受不同环节影响，应结合目标应用和服务商提供的能力说明判断，避免在 Settings 中无目的地逐项切换。
需要更多线索时，在 Settings 找到 Diagnostics，围绕刚刚发生的错误收集诊断信息。分享诊断前检查内容，遮盖订阅地址、认证参数及可识别个人使用情况的信息，仅保留排错必要部分。复杂规则、DNS 与配置分段的原理请转到配置大全继续阅读；想重新走一遍最小操作路径，可回到本教程的导入步骤，逐步复核而不是从头改掉全部设置。
