本文以 iPhone / iPad 上的 Shadowrocket（小火箭）首次连接为操作示例，前提是已经持有自己的服务器资料或订阅。按“导入资料、选择默认服务器、授权连接、检查测试结果”的顺序操作，并区分系统 VPN 已连接、服务器可达与目标网站可用这三个不同结果。
一、连接前确认安装来源与已有资料
尚未安装时，先进入下载指南按设备获取。获取方式分为 2 档：iPhone / iPad 版在 App Store $2.99 一次性买断；Mac（Apple 芯片 / Intel）、Windows、安卓、Linux 版免费。iPhone / iPad 的开发者为 Shadow Launch Technology Limited，系统要求以 App Store 页面标注为准。不同平台的系统授权窗口可能不同，下面的 VPN 授权步骤以 iPhone / iPad 为准。
安装客户端不等于取得可用的服务器。首次连接需要用户已有的服务器地址、端口和协议认证资料，或者自己的订阅链接。本站不提供、不销售、不推荐节点或订阅。不要把订阅链接、密码或完整配置发到公开讨论区；其中的 token 往往能够用于访问个人订阅内容。
- 已有订阅：在 Home 右上角点“+”，将 Type 设为 Subscribe，填写自己的订阅地址并保存，再更新订阅内容。只有列表中出现实际服务器条目，才进入下一步。
- 已有单个服务器：在 Home 右上角点“+”，按资料选择 Type，逐项核对地址、端口及认证信息。Shadowsocks、VMess、VLESS、Trojan 等协议的字段不同，不能仅凭地址相同就互换 Type。
- 已有 Config：区分配置文件与服务器订阅。Config 可以包含路由规则和策略引用，但导入 Config 并不必然产生可用的服务器条目。
二、在 Home 选择默认服务器并打开连接
Home 中能看到服务器名称，只能说明条目已经存在。首次操作还需要明确选中实际使用的服务器，再打开连接开关。点服务器左侧圆点与进入条目编辑不是同一个操作；编辑地址后返回列表，也应再次检查默认选择。
-
检查列表
进入 Home，展开自己已有订阅对应的服务器列表，确认至少有一个实际服务器条目。若列表为空，先检查订阅地址及更新结果，不要直接反复打开连接开关。
-
选默认项
点目标服务器左侧圆点，确认选中标记落在该条目上。首次排查先固定同一个服务器，不要在每次测试前同时更换服务器与路由模式。
-
确认路由
打开 Home → Global Routing，查看当前是 Config、Proxy 还是 Direct。需要验证代理路径时不能停留在 Direct；Config 下还应确认当前配置的规则与策略引用有效。
-
开启连接
返回 Home，打开顶部连接开关。首次出现系统添加 VPN 配置提示时，核对请求来自 Shadowrocket 后允许，并按系统要求完成设备验证。
-
核对状态
等待连接状态稳定，再执行 Connectivity Test。若开关立即回到关闭状态，先处理授权或系统连接问题，不要把它直接判断为目标网站故障。
系统 VPN 状态表示本机的流量接管通道已经建立，不代表远端认证一定通过，也不代表每个请求都经过代理。选用策略组的 Config 还可能引用组内的其他服务器，因此 Home 的默认选择并不一定覆盖配置中所有策略。
三、用 Connectivity Test 分层验证
连接开启后，在 Home 执行 Connectivity Test，等待测试完成并查看实际结果。测试的意义是检查所选测试目标在当前设置下是否可达；它不是对全部网站、全部协议或所有应用的可用性保证。记录测试时的服务器名称、Global Routing 模式和当前网络，才能对比后续结果。
- 出现耗时结果：表示本次对应测试完成了响应测量。该数值不是下载速度，不能据此推断视频吞吐或长时间连接的稳定性。
- 出现超时或失败：先记录完整提示，再检查测试目标、服务器资料与当前网络。单次超时不足以证明整条线路失效。
- 测试通过但网站打不开：继续核对该网站实际匹配的规则、DNS 解析及目标站点状态，不要用一个成功测试覆盖所有请求的结论。
- 网站能打开但代理未必生效：Direct 或 Config 中的 DIRECT 规则都可能让请求直连，网页可访问本身不是代理路径成立的证据。
测试后打开一个自己实际需要访问的网站，再验证日常应用。若只有某个应用异常，先保持服务器和网络不变，检查它是否使用独立连接、是否受到规则影响。不要把 Connectivity Test 的延迟、订阅列表的延迟测试与实际下载速度当作同一个指标。
四、Global Routing 如何影响首次测试
首次连接常见的误判，是在 Direct 下看到网站可用就认为代理已正常工作，或者在 Config 下遇到单个域名失败就认为服务器不可用。需要先识别当前姿态，再解释测试结果。下面比较的是 Shadowrocket 自身的路由设置，不涉及其他产品。
Config
推荐按当前配置中的规则与策略处理请求。命中 DIRECT 的请求直连，命中代理策略的请求按相应策略发送；未匹配的请求由后续规则或 FINAL 处理，并非一律直连。
适合：已有可用配置时的日常分流与最终复测。
Proxy
让由客户端接管的请求采用代理路由，便于暂时减少分流规则对排查的影响。它不能绕过服务器认证错误，也不能修复错误的地址、端口或 TLS 设置。
适合：临时确认问题是否与 Config 的规则或策略有关。
Direct
采用直连路由，不使用代理路径。它可以用于建立当前网络的直连对照，但不能用来验证远端代理服务器是否正常。
适合：检查本地网络能否直接访问同一个测试目标。
若界面中使用 Scene，应先检查当前 Scene 对应的设置，不要把它视为与 Proxy 相同的全局代理开关。首次排查可明确选用上述单一模式进行对照，完成后恢复原有配置。切换模式只改变路由处理，不会自动补齐订阅或修正服务器认证字段。
五、连接失败时按现象缩小范围
排查时每次只改一个变量，并在更改后重复同一个测试。服务器、Global Routing、Wi-Fi 与蜂窝网络同时更换，会让成功或失败都无法归因。先判断问题发生在“开关无法保持开启”，还是“已经连接但请求失败”，再进入相应分支。
两类故障分别检查
开关立即关闭
- 确认首次系统 VPN 配置授权已完成，没有取消系统验证。
- 在系统设置中核对 VPN 配置是否存在，并确认设备管理策略没有限制连接。
- 暂时停止其他正在使用的 VPN 连接，再返回 Home 重试。
- 检查 Settings → On Demand，排查期间暂时关闭自动触发，改用手动开关观察结果。
已连接但失败
- 确认 Home 左侧圆点选中了预期服务器，并核对 Global Routing。
- 逐项核对服务器地址、端口、协议、密码或 UUID，以及资料要求的 TLS 参数。
- 更新自己的订阅，检查是否出现更新失败或服务器条目变化。
- 固定同一服务器，在 Wi-Fi 与蜂窝网络分别测试，记录是否仅一种网络失败。
先确认系统连接能保持，再判断远端可达性；不要用反复点击连接开关代替分层检查。
若 Wi-Fi 失败而蜂窝网络成功，优先核对 Wi-Fi 是否需要网页认证、是否限制相关端口，以及该网络的 DNS 条件；这只是排查方向，不是自动判定网络封锁。若两种网络均失败，再检查已有服务是否有效、服务器是否仍在订阅内，以及协议字段是否与原始资料一致。
Hysteria2、WireGuard 等协议涉及 UDP，不能只凭其他 TCP 请求成功就断言它们的传输路径正常。反过来，也不要为了测试随意把 Type 改成另一种协议：远端与本地的协议必须一致，改变名称不会改变服务器实际提供的服务。
六、连接成功后的复核与记录
完成一次 Connectivity Test 后，应恢复准备长期使用的路由模式，并再次验证实际网站。若排查期间临时使用 Proxy，恢复 Config 后还要复测；两种模式下相同域名可能采用不同路径。On Demand 则应在手动连接稳定后再配置，避免自动触发让首次排查过程难以观察。
- 恢复配置：在 Home → Global Routing 选择日常模式，检查 Config 中当前启用的配置及策略选择。
- 重复测试：再执行一次 Connectivity Test，并打开实际所需网站，确认不是只在临时模式下可用。
- 检查自动连接：需要自动触发时再进入 Settings → On Demand，按实际网络条件设置；测试期间关闭过的选项应按原先需求恢复。
- 保留排查记录：记录网络类型、服务器名称、路由模式、失败提示和发生时间。对外提供日志前遮盖订阅 token、密码、UUID 等敏感资料。
一次完整的首次连接，应同时满足系统通道保持连接、测试目标得到响应、实际业务符合预期三项条件。以后若出现异常，沿用相同的分层顺序，通常比直接删除所有配置更容易定位问题，也能保留原本可用的设置作为对照。