步骤一：Add Server 与 Subscribe 导入

打开 Shadowrocket 后，先进入 Home。这一页用于查看已有服务器、选择当前条目和控制连接。首次使用时，先判断手头资料属于哪一种：一条用于更新服务器列表的订阅 URL，或一组包含协议、地址、端口和认证字段的服务器信息。两种资料的填写位置不同，不要把订阅 URL 当成服务器地址，也不要把普通网页地址直接填入 Subscribe。

已有订阅：选择 Subscribe，填写完整 URL

在 Home 点击右上角添加按钮，打开 Add Server，进入 Type 选择 Subscribe。返回填写页后，把从自己的服务商处获取的订阅链接完整粘贴到 URL 字段。备注用于帮助辨认来源，可以填写自己能识别的名称。保存前检查开头与结尾是否完整，尤其不要遗漏问号后的参数，也不要带入聊天消息中的空格、换行或说明文字。

以下地址只展示 URL 的形态，不可用来导入实际服务器。真实订阅 URL 往往包含访问凭据，应按密码对待，不要放进公开截图、聊天群或故障说明中。

https://example.com/sub?token=xxxx

保存后回到 Home，等待订阅读取完成，再检查对应分组下是否出现服务器条目。保存了订阅记录，不等于已经成功获取列表。如果分组仍为空，先检查 URL 是否指向订阅内容、订阅是否有效，以及本地网络是否能够访问该地址。已有分组需要刷新时，在该分组的操作入口执行更新，再核对列表变化；不要连续新建同一个订阅，以免出现重复分组而难以判断当前使用哪一份。

已有服务器信息：按协议逐项填写

如果手头是单个服务器的参数，在 Add Server 的 Type 中选择实际协议，再填写相应字段。Shadowsocks、VMess、VLESS、Trojan 等协议的认证方式并不相同，应以自己的原始资料为准，不能因为某个字段留空就随意补值。服务器地址字段通常只填写主机名或 IP，端口单独填写；密码、UUID、加密方法、传输方式和 TLS 相关参数都需要与服务端对应。

遇到 SNI、Host 或传输路径等字段时，应逐项核对提供的信息。它们不一定与连接地址相同，不能机械地把同一个域名复制到所有位置。不要为了消除错误而随意降低证书检查要求。填写完成后保存，返回 Home 确认条目已经出现，再点选准备使用的服务器。若只拿到一条服务器分享链接，可使用应用识别该链接的导入入口；二维码资料则可通过 Scan QR Code 读取，导入后仍需核对字段。

到这一步，应当能在 Home 识别订阅分组与其中的服务器，或看到手动保存的独立条目。暂时不要批量改名、合并分组或配置自动切换，先保留一条参数明确的服务器用于后续验证。协议字段的含义可查阅概念速查；订阅负责获取和更新服务器资料，Config 负责连接策略，两者不是同一份内容。

步骤二：选择 Global Routing 姿态

服务器保存完成后，在 Home 打开 Global Routing。这里决定连接如何处理，不能只看当前选中的服务器就判断所有请求的去向。三种姿态分别为配置(Config)/代理(Proxy)/直连(Direct)。先确认这项选择，再打开连接，后续测试才有明确的判断依据。

配置(Config)：根据当前活动配置中的规则选择策略。不同请求可能分别命中 PROXY、DIRECT 或 REJECT，选中服务器不表示每个请求都经过该服务器。
代理(Proxy)：用于把请求交给当前代理策略处理，适合临时检查所选服务器是否能够完成实际访问；它不能替代针对规则命中的验证。
直连(Direct)：请求直接连接。此时即使连接开关处于开启状态，也不能据此认定请求正在经过所选服务器。

如果准备按规则使用，先切到 Config 页面，查看当前有哪些配置文件，并确认哪一份处于活动状态。仅把配置文件加入列表还不够，必须确认实际选中了它。打开配置检查规则时，先辨认其用途和来源；不要为了完成首次连接而导入无法理解的整份配置。配置中的策略引用也需要与现有服务器或策略设置对应，否则规则写对了，处理结果仍可能不符合预期。

对于刚导入的服务器，可以先记下原来的 Global Routing 选择，再临时使用代理(Proxy)进行一次基础连通验证。完成后若需要规则分流，应恢复配置(Config)，重新测试目标请求。这样的顺序把“服务器能否使用”与“规则是否按预期处理”分开，有助于避免同时排查两类问题。

本页不展开完整规则写法。理解为“Global Routing 决定处理姿态，Config 中的规则在相应姿态下参与判断”即可。需要设置 DOMAIN-SUFFIX、IP-CIDR 或 FINAL 时，阅读规则手册，先掌握自上而下匹配的顺序，再修改配置。调整前保留原配置，避免第一次测试就同时变动服务器、规则和 DNS。

步骤三：在 Home 打开连接开关

返回 Home，核对当前选中的服务器与刚才确定的 Global Routing。订阅列表里可能有多个名称相似的条目，先点选本次要测试的那一条，再打开页面上的连接开关。如果使用了由配置定义的策略选择，还要确认策略实际指向的目标，而不是仅凭列表里的名称判断。

第一次连接时，iPhone 或 iPad 可能显示添加 VPN 配置的系统授权提示。这是应用通过系统网络能力建立连接所需的确认步骤，不是订阅账户登录页。核对提示对应 Shadowrocket 后，按系统要求允许，并在需要时完成设备身份验证。授权由系统界面处理，不要把设备解锁密码填写到服务器密码或订阅 URL 字段中。

完成授权后返回 Shadowrocket，观察连接开关与状态是否保持在已连接状态。如果先前取消了授权，可再次打开连接开关并按提示处理。若设备受管理策略限制、系统未允许建立配置，或存在另一项正在使用的 VPN 连接，应先查看系统提示并确认限制来源，不要连续快速切换开关来掩盖问题。

系统显示 VPN 已连接，只说明相关连接已建立，不保证目标服务器和每个网站都可用。状态图标在不同设备上的显示位置可能不同，因此下一步仍要在应用内检查，并发起真实请求。首次验证期间建议保持手动连接，暂缓调整 On Demand，以免网络切换时的自动行为干扰观察。确定基础连接正常后，再按自己的网络使用习惯配置按需连接。

步骤四：Connectivity Test 与实际访问验证

连接开启后，先在 Home 使用 Connectivity Test，检查准备使用的服务器是否可达。测试过程中确认对象是当前条目，而不是另一个分组或旧记录。测试有结果可以帮助缩小排查范围，但测试方法与实际网页请求并不完全相同，不能把一次成功直接等同于所有访问正常，也不能只看某个延迟值决定使用体验。

接着切换到浏览器，打开一个你熟悉、内容可以正常核对的网页，主动刷新并继续打开其中一个页面。已经加载的旧页面可能来自缓存，不适合作为唯一依据。先选择少量稳定目标完成验证，不要同时打开很多应用制造额外请求。如果只有一个网站失败，先保留其他网站的测试结果，不要立即认定整条连接失效。

在配置(Config)姿态下，还需要核对请求是否走到了预期策略。回到 Shadowrocket 的 Data 查看可用的连接记录，按请求域名、发生时间以及记录中可见的策略信息进行比对。先发起一次明确的访问，再查看对应记录，比在大量后台请求中猜测更容易判断。具体记录字段以当前应用界面为准。

如果请求命中 DIRECT，那么网页打开并不能证明代理服务器可用；如果命中 REJECT，也不能单靠页面失败就断定服务器参数错误。需要验证代理本身时，可临时切到代理(Proxy)对同一目标复测，然后恢复原姿态。如果 Proxy 下正常、Config 下异常，应优先检查配置与规则，而不是反复重新导入订阅。

最后做一次可重复的检查：关闭连接时确认本地网络状况，重新开启后用同一服务器、同一模式、同一网页测试，并记录差异。不要把身份登录状态、内容地区或某个页面提示作为唯一判据，它们还可能受账户与缓存影响。能够说明“当前选了什么、请求命中了什么、实际访问结果如何”，才算完成本轮验证。

步骤五：按失败环节逐项检查

遇到连接失败时，先判断卡在哪一层：订阅没有导入、服务器测试失败、系统连接未建立，还是连接后某个请求异常。每次只改一个条件，修改后立即复测。同时更换网络、服务器与配置，会让一次成功或失败失去解释依据。下面按由近到远的顺序检查，查到原因后不必继续改动其他项。

先确认本地网络与订阅读取

先暂时关闭 Shadowrocket 连接，用浏览器确认本地网络本身可用。公共 Wi-Fi 可能需要先完成网络登录；如果切换到另一种网络后表现不同，记录这种差异，再回到同一个服务器测试。不要在本地网络尚未连通时反复刷新订阅。

若 Subscribe 保存后没有条目，重新核对 URL 是否完整、是否误用了账户页面地址，以及订阅是否仍然有效。如果已有列表但更新失败，保留当前可用资料，先查看更新错误，不要先删除整个分组。更新订阅只是重新获取服务器信息，不会自动证明其中每个服务器可达，也不等于已经切换了当前使用条目。

再核对协议参数与系统时间

当 Connectivity Test 持续失败，逐项比对 Type、地址、端口和认证字段，再检查 TLS、SNI 与传输参数。优先回到自己的原始服务器资料核对，不根据服务器名称猜测协议。订阅更新后若仍有异常，也应确认当前点选的是更新后的条目。不要尝试用随意改变端口、密码或证书选项来碰运气。

检查设备系统时间是否准确，必要时在系统设置中确认日期与时间设置。时间偏差可能影响证书有效期判断与部分认证流程。测试超时也可能来自当前网络到服务器的路径或服务器自身状态，单次结果无法确定责任位置；使用相同参数在另一可用网络复测，有助于区分问题范围。

连接已建立时检查模式与活动配置

如果开关可以保持开启，但网页不符合预期，先回到 Global Routing。确认没有停留在直连(Direct)，也没有在临时验证后忘记恢复配置(Config)。接着到 Config 核对活动文件，再看目标请求命中的策略。只有个别域名异常时，应结合规则和域名解析检查，不要立刻重置全部设置。

如果怀疑配置问题，保留原文件，用已知用途的配置或临时的代理(Proxy)姿态进行对照。对照时使用同一个服务器与目标，验证后恢复原状态。详细的配置段落、策略含义与匹配优先级见Shadowrocket 规则与配置参考；Subscribe、Config 与 Connectivity Test 的概念区别可在概念速查中核对。

记录结果，再继续调整

仍无法定位时，整理失败发生的具体步骤、当前网络类型、Global Routing 姿态、测试对象以及可见错误提示。向自己的服务商核对服务器状态时，只提供定位所需信息，并隐藏订阅 URL 中的凭据、密码及个人信息。不要把完整订阅链接复制到公开问题描述中。

完成一次稳定连接后，再逐项加入自己的规则、订阅更新习惯与 On Demand 设置。每次调整都保留可返回的配置，并用相同目标复测。以后遇到异常，按本页“导入 → 模式 → 连接 → 验证”的顺序回查，通常比直接删除所有条目重新开始更容易定位变化。

Shadowrocket 使用教程