第一步：Add Server 添加或 Subscribe 导入
先判断手中的资料是哪一种。订阅链接用于获取一组服务器条目，通常可以由原服务方更新；单个服务器信息则包含协议、地址、端口和认证字段。两者不必重复添加，按自己实际持有的资料选择一种方式即可。开始前确认原始资料完整，尤其不要把网页介绍地址当作订阅链接，也不要把配置文件地址与服务器订阅地址混用。
已有订阅链接：选择 Subscribe
打开 Shadowrocket，进入 Home，点击添加按钮进入 Add Server。在类型选择中找到 Subscribe，将已有的完整订阅链接填入 URL，并为这组内容填写便于辨认的名称，再保存。返回 Home 后等待获取结果，检查订阅分组下是否出现服务器条目。如果只看到订阅名称，尚未出现条目，应先确认获取是否完成，而不是立即打开连接开关。
复制链接时保留问号之后的参数，不要添加引号、空格或换行。某些链接带有个人访问凭据，应只在自己的设备中使用，不要将完整链接放进公开截图或问题描述。保存后若出现错误，先回到编辑页对照原始链接；重复创建同一订阅不会修复地址错误，反而容易让后续选择混淆。订阅内容需要更新时，对已有订阅执行更新，再检查结果是否发生变化。
已有服务器信息：按实际协议填写
如果拿到的是独立服务器资料，在 Add Server 中选择与资料一致的协议类型，再填写地址、端口和对应认证字段。例如 Shadowsocks、VMess、VLESS、Trojan 的认证信息并不相同，不能仅凭地址相似就套用另一种协议。带有 TLS 或其他传输参数的资料，还需要核对相关字段；这些字段应来自原始资料，不通过猜测补齐。
服务器地址只填对应字段要求的主机名或地址，端口填入端口字段。用户名、密码、UUID、TLS 名称等各有用途，不应互相替代。若资料以二维码提供，可使用 Scan QR Code 读取；导入后仍应打开条目核对类型和关键字段，确认内容完整再保存。二维码与订阅链接同样可能包含凭据，不宜公开展示。
添加完成后回到 Home，在 SERVER 列表中选中本次要使用的条目。这里要区分“条目已经保存”和“条目已经选中”：列表里存在多个服务器时，后续连接应使用明确选中的那一个。先记住这个条目的名称，下一步切换 Global Routing 和验证结果时保持同一个服务器，避免同时变动多个条件。
第二步：选择 Global Routing 姿态
完成添加并选中服务器后，在 Home 打开 Global Routing。它决定请求总体采用哪一种处理方式，不负责替用户补齐服务器信息。首次连接尤其需要核对这里：服务器填对了，但请求按另一种姿态处理，实际表现仍可能与预期不同。本教程将三种姿态写为配置(Config) / 代理(Proxy) / 直连(Direct)，设备上以英文界面词识别。
| 姿态 | 请求处理方式 | 首次使用时的用途 |
|---|---|---|
| 配置(Config) | 按当前生效的配置文件和规则确定策略。 | 验证已有配置的分流结果。 |
| 代理(Proxy) | 以代理方式处理请求；系统及应用特定例外仍需结合实际设置判断。 | 先验证所选服务器的代理路径。 |
| 直连(Direct) | 直接连接目标，不以所选服务器的代理转发结果作为验证依据。 | 对照本地网络的直接访问情况。 |
如果手中只有服务器订阅，还没有准备好规则配置，可以先选择代理(Proxy)做一次受控测试。这能暂时减少规则选择带来的变量，但不意味着所有应用、所有系统请求都会得到完全相同的处理。测试时仍应选定明确的目标页面，并结合实际访问和连接记录判断，不能仅凭姿态名称推断某次请求已经经过服务器。
准备使用配置(Config)时，先进入 Config，确认当前实际生效的是哪份配置文件。Global Routing 中的 Config 是路由姿态，底部的 Config 页面是配置文件管理入口，两者有关联，但不是同一个操作。导入服务器订阅也不等于已经切换了规则配置；发现分流不符合预期时，应核对生效文件，而不是反复添加服务器。
规则通常按顺序匹配，命中后使用对应策略。先把这点作为排查原则即可，本页不要求首次连接前编辑完整规则。需要理解 PROXY、DIRECT、REJECT 与 FINAL 时，再到规则与配置参考逐项核对。选定姿态后返回 Home，确认服务器仍是刚才选中的条目，再进入开关连接步骤。
第三步：打开开关并完成系统授权
现在检查三个条件：Home 中有可用的服务器条目、已经选中本次使用的条目、Global Routing 是刚才确定的姿态。确认后打开 Home 的连接开关。首次在这台设备上建立连接时，系统可能显示添加 VPN 配置的授权提示；这是创建系统网络连接配置的步骤，与 Subscribe 获取服务器列表不是同一件事。
阅读系统提示，确认它由刚才在 Shadowrocket 中的操作触发，再选择允许，并按系统要求完成设备验证。系统授权通过后返回应用，查看连接开关与状态是否保持在已连接状态。如果之前取消过提示，应重新发起连接并处理授权；连续点击开关不能替代尚未完成的系统确认。
若开关打开后很快恢复关闭，先留意应用或系统显示的错误信息。此时更应检查配置是否成功建立、是否有其他网络连接配置正在接管，以及设备管理策略是否限制了相关操作。不要在尚未记录现象前删除所有配置；先正常关闭其他正在使用的连接，再回到 Shadowrocket 单独测试，可以减少状态相互切换造成的干扰。
系统显示 VPN 连接，只能说明相关网络连接配置处于工作状态，不能单独证明远端服务器认证成功，也不能证明每个网页都可访问。完成这一步后还需要验证目标请求。尤其是使用配置(Config)时，部分目标按规则走 DIRECT 是可能的结果，不能把它与“开关没有生效”直接画等号。
首次排查期间先保持手动开关连接，暂不同时调整 On Demand。按需连接会根据条件影响连接的建立或恢复，如果尚未理解这些条件，容易误以为关闭后又出现连接是操作失败。先完成下一步的稳定验证，再按实际使用场景阅读On Demand 功能说明。需要结束本次测试时，回到 Home 关闭连接开关，并确认状态已变化。
第四步：Connectivity Test 与实际访问验证
连接建立后，先执行 Connectivity Test，记录是否返回结果以及失败提示，再打开 Safari 访问一个已知可用的页面。测试与实际访问是两项检查：前者反映测试方式与测试目标下的结果，后者涉及目标域名解析、连接、TLS 和页面资源加载。测试有数值，不代表所有目标均可访问；单次超时，也不足以判断所有请求都无法完成。
先建立可重复的对照
选择一个明确的页面，记下使用的网络、服务器和 Global Routing。等待页面完成加载，再刷新一次或打开另一个已知可用的页面，确认结果能够重复。测试期间不要同时更新订阅、切换服务器和修改 DNS，否则结果变化后难以定位原因。若需要比较 Wi-Fi 与蜂窝网络，应先完成当前网络的记录，再只切换网络条件重新测试。
如果代理(Proxy)下访问正常，而配置(Config)下同一个目标异常，保持服务器不变，优先检查当前配置与规则命中。反过来，两种姿态下均无法完成实际访问时，应继续核对服务器信息、远端可用性和本地网络，而不是先重写整份规则。直连(Direct)可用于对照本地访问，但它的成功不能证明代理路径可用。
按请求核对结果，而不是只看总状态
需要确认某个目标使用了什么策略时，打开应用内的连接记录，按目标域名或地址查找本次请求，并查看可见的策略、规则或错误信息。不同版本的记录入口与展示字段可能有所调整，以实际界面为准。先发起一次明确的新请求，再查看相应记录，比从大量历史记录中猜测更容易对照。
观察到 DIRECT 时，先判断是否符合当前规则；观察到 REJECT 时，先查看是否由预期的拦截规则命中；使用 PROXY 时，再继续核对所选服务器与连接结果。页面可能同时请求多个域名，因此主页面打开与图片、登录或其他资源加载并不总是同一个结果。遇到局部失败，应记录失败资源对应的域名，而不是把整站一概判为不可用。
验证通过后，再将 Global Routing 调整为日常需要的姿态。若使用配置(Config)，保留已经验证过的服务器与配置文件，后续每次只修改一项。此时首次连接流程已完成；仍有异常时，按下一节从最靠近问题发生的位置开始排查。
第五步：按失败发生的位置排查
先说明“在哪一步失败”，再处理对应设置。订阅没有获取到内容、连接开关无法保持、测试返回超时、网页只加载一部分，是四种不同现象。把它们都归为“连不上”，容易反复改动已经正确的字段。以下顺序从本地网络开始，逐步缩小范围；每完成一项，都用同一个目标重新测试。
订阅导入失败或列表没有条目
先检查设备是否已接入可访问网络；如果当前连接使网络状态难以判断，可以正常关闭 Shadowrocket 后对照基础访问。然后检查订阅链接是否完整、是否仍在有效期内，以及返回内容是否是可识别的订阅数据。网页能打开，只能说明该网页可访问，不等于订阅地址一定返回了正确内容。
确认链接来自自己的原始资料，不包含复制时附带的说明文字。如果服务方更换过链接，应更新对应订阅的 URL，而不是在旧地址上反复刷新。更新后核对分组下的实际条目，再选中服务器；如果获取过程已经失败，后续切换 Global Routing 通常不能修复这一步的问题。
服务器已添加，但认证或测试失败
打开当前选中的条目，对照协议类型、地址、端口、认证字段以及 TLS 和传输设置。尤其留意密码末尾的空格、UUID 是否完整、TLS 名称是否填入正确位置。仅修改显示名称不会改变连接参数，重新命名条目也不能解决认证错误。
若同一份已有资料中另有明确可用的条目，可以只切换服务器做对照，并保持其他设置不变。如果多个条目均失败，再检查本地网络变化和原服务方提供的状态信息。不要为了通过测试随意关闭证书校验；应先核对设备时间、目标名称和原始 TLS 配置是否一致。
已连接且测试有结果，但网页打不开
这时先区分域名解析失败、连接超时与规则拒绝。查看当前配置中的 DNS 设置是否是自己原本准备使用的内容，再结合连接记录定位具体域名。单个域名打不开而其他页面正常时，不应立即判断整个连接失效；若多个域名都无法解析，则优先检查 DNS 路径与当前网络条件。
不要一次写入多个来历不明的 DNS 地址。先记录原值，恢复到自己已知可用的设置，重新发起请求，再比较结果。若代理(Proxy)正常而配置(Config)异常，检查是否有规则将该目标送往 DIRECT 或 REJECT，以及 FINAL 是否承担了预期的兜底策略。详细设置与症状分类见DNS 与连接疑难解答。
修改后更难判断：回到最后一次可用状态
保留原始订阅信息和可用配置的副本，撤回刚才的单项改动，再重复测试。订阅更新可能改变服务器列表，配置切换可能改变策略，网络切换也可能影响解析；按发生顺序核对，比直接重装应用更有助于定位。确需重新获取应用时，应按App Store 已购恢复说明操作，不把重新安装当作通用的网络修复步骤。
一次完整的首次连接验证，应能确认四件事：服务器信息已经正确保存并选中，路由姿态符合本次用途，系统连接已经建立，实际目标请求得到了可解释的结果。完成这些检查后，再逐步添加按需连接或更细的分流设置，后续遇到变化也能沿同一顺序复查。