Shadowrocket入门指南与连接验证
按“导入资料 → 选择路由 → 打开连接 → 验证结果 → 定位失败点”的顺序操作。本页以 iPhone、iPad 为对象，先完成一次可复现的连接，再调整日常配置。
截图为 App Store 官方素材，用于辨认界面位置。具体字段会随所选 Type 与应用界面变化；操作时以设备上的英文界面词和实际提示为准。
STEP 01 / IMPORT
Add Server / Subscribe：导入已有资料
打开 Shadowrocket 的 Home，先辨认下方的 SERVER 分组与 Add Server。这里需要区分两类资料：订阅链接是用于获取、更新一组服务器条目的地址；单个服务器信息则包含连接某台服务器所需的协议与参数。两者的填写位置不同，不要把订阅地址直接当作 Host，也不要把普通说明网页当作订阅地址导入。
已有订阅链接：使用 Subscribe
在 Home 点按 Add Server，进入添加页面后点按 Type，选择 Subscribe。将自己已有的完整订阅链接填入对应的 URL 字段，再保存。粘贴前后检查链接是否被聊天工具截断、是否混入换行或首尾空格；链接中的查询参数通常属于地址的一部分，不要凭猜测删除。订阅地址可能包含访问凭据，应仅保存在自己的设备中，不要贴到公开留言或截图里。
保存并完成内容获取后，返回 Home 检查 SERVER 是否出现预期条目。如果只看到订阅记录却没有服务器，先查看是否有更新错误，不要继续反复打开连接开关。订阅获取失败发生在“取回资料”这一环节，与后续服务器能否连接是两个问题。先确认地址有效、当前网络能访问该地址，再使用订阅条目对应的更新操作重试。
已有服务器参数：按 Type 逐项填写
如果拿到的是单个服务器信息，仍从 Add Server 进入，但 Type 要与资料中的协议一致。随后填写 Host、Port，以及该 Type 所要求的认证和传输字段。官方截图展示的是一类参数表单，并不代表每一种 Type 都使用 Password、Method 这组字段；不要为了与截图相同而修改协议。Host 通常填写资料给出的主机名或地址，Port 填写对应端口，大小写敏感的认证内容应完整保留。
已有适用二维码时，可以使用 Scan QR Code 导入，再打开生成的条目逐项核对。Import from Cloud JSON 仅适用于匹配格式的已有资料，不是任意订阅链接的通用入口。无论采用哪种方式，保存后都应回到 Home，确认条目名称与参数对应，并选中本次准备测试的服务器。名称只是识别标签，不能代替对实际参数的核对。
STEP 02 / ROUTING
Global Routing：选择配置、代理或直连
资料导入后，回到 Home 点按 Global Routing。这里的选择决定请求采用哪一种处理姿态，而不是更换服务器。三个选项应分别理解为配置(Config)、代理(Proxy)、直连(Direct)。首次使用不应只记住某个选项“应该打开”，而应先确认本次验证想排除什么因素，再选择对应模式。
| 姿态 | 处理含义 | 入门使用方式 |
|---|---|---|
| 配置(Config) | 按当前配置中的规则决定请求去向。 | 已确认当前规则配置有效时，用于日常分流。 |
| 代理(Proxy) | 以代理姿态处理由客户端接管的请求。 | 临时对照测试，减少规则选择对结果的影响。 |
| 直连(Direct) | 以直连姿态处理请求，不以所选代理服务器作为通常出口。 | 检查目标服务在当前网络下的直连表现。 |
准备使用配置(Config)时，进入 Config，先确认正在使用的是哪份配置，再查看其中的 Rule。Config 页面中的文件选择与编辑内容，比文件名称本身更能说明实际行为：同名文件也可能包含不同规则。截图中的 General、Rule、Hosts、URL Rewrite、HTTPS Decryption 是配置编辑分段；本次入门只需要确认当前配置与 Rule，不必逐项开启或修改其他分段。
规则通常按从上到下的顺序匹配，命中后使用该条规则指定的策略。下面两行仅用于识别格式，不是一份可直接替换现有文件的完整配置。第一行将示例域名及其子域名交给 PROXY，最后一行是未命中前面规则时的兜底处理；实际结果仍取决于整份配置及其策略定义。
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT如果暂时不清楚现有规则的来源与作用，可以先记录原来的选择，再临时切到代理(Proxy)进行一次连接对照。若同一服务器在 Proxy 下可以访问，而在 Config 下某个目标失败，优先检查规则命中与目标策略，而不是立即删除服务器。直连(Direct)也不是“自动选择最快服务器”；它适合做直连基线，不能用来证明代理出口有效。
不要为完成第一次连接而随意点按 Add Rule，也不需要开启 HTTPS Decryption。先保留已有配置，完成后续验证，再按明确需求修改规则。各项能力的使用边界可继续阅读功能介绍；需要重做本次操作时，可返回Global Routing 选择步骤逐项对照。
STEP 03 / CONNECT
Home：打开开关并完成 VPN 配置授权
完成模式选择后回到 Home，按顺序再看三处：SERVER 中当前选中的服务器、Global Routing 的当前值、顶部连接状态。截图中的 Not Connected 表示尚未连接。先确认前两项正确，再打开顶部连接开关，这样出现错误时才能知道本次实际测试的是哪一组条件。
第一次连接时，系统可能提示允许 Shadowrocket 添加 VPN 配置。这是应用建立系统网络连接所需的授权流程，不是订阅导入成功的提示，也不代表远端服务器已经可用。确认提示由刚刚操作的 Shadowrocket 发起后，按系统界面允许，并按设备要求完成身份验证。授权完成后返回 Home，观察连接状态是否改变。
若此前选择了不允许，先回到应用重新发起连接，再处理系统提示；不要连续快速切换开关。如果提示没有再次出现，或连接一打开便结束，可到系统设置中的 VPN 相关页面检查是否存在对应配置，再结合应用的错误信息判断。设备受组织管理时，部分网络设置可能由管理策略限制，应先确认设备允许进行这类配置操作。
iPad 上也遵循“选服务器、看模式、开连接、完成系统授权”的顺序。屏幕尺寸或系统界面布局可能不同，但应以 Home、Global Routing 等界面词定位，不必机械寻找截图中的像素位置。系统要求及兼容性仍以 App Store 页面标注为准。
连接期间先停留片刻，观察状态能否稳定保持。如果开关随即关闭，记录出现的完整提示；如果开关保持开启，也先不要认定所有请求都已按预期处理。系统 VPN 标识说明系统网络连接处于相应状态，但并不能单独证明服务器认证、域名解析和目标服务访问均已成功。下一步需要把应用状态与实际访问结果结合起来判断。
STEP 04 / VERIFY
Connectivity Test：区分可达性与实际生效
回到 Home 使用 Connectivity Test，查看当前服务器在所选测试方式下的结果。测试有结果，说明相应探测得到了响应；测试超时，说明这次探测没有在规定时间内完成。它们都不应直接等同于“所有应用可用”或“服务器一定失效”。不同 Test Method 检查的链路环节可能不同，因此比较前后结果时，应保持测试方式一致。
接着打开 Safari，访问自己有权使用、且已知正常工作的目标页面。除了首页是否出现，还要检查页面中的必要资源能否加载，实际登录或业务操作是否正常。若页面此前已经打开，重新加载一次，避免仅凭缓存内容判断。某个页面可访问，也只说明该次请求路径有效，不能替其他域名、其他协议或其他应用作保证。
在配置(Config)下验证时，先想清楚目标应该走 PROXY 还是 DIRECT。配置允许部分请求直连是正常结果，不能因为某个服务仍采用原来的网络出口，就直接认定应用未生效。若只对一个目标有疑问，可保持同一服务器与同一网络不变，临时切到代理(Proxy)重试，记录两种姿态的差异，测试完成后恢复适合日常使用的配置。
还可以建立直连对照：记录断开连接时目标的表现，再连接后重试。对照期间不要同时切换 Wi-Fi 与蜂窝网络，也不要更换服务器，否则无法确定变化来自哪一步。为减少后台请求干扰，验证时只操作少量明确的页面。涉及登录、支付或敏感业务时，以该服务本身的提示为准，不要把网络测试结果当作账号状态判断。
- 先记录连接状态：Home 是否保持连接，是否出现明确报错。
- 再记录测试条件：所选服务器、Global Routing、Test Method，以及使用的是 Wi-Fi 还是蜂窝网络。
- 最后记录访问结果：目标是否打开、失败发生在加载还是登录阶段、切换 Config 与 Proxy 后有何差异。
本步完成标准不是看到某个延迟数字，而是连接能够稳定保持，并且预期使用的目标在相同条件下可以重复访问。如果测试有结果但访问失败，保留这项差异，进入下一步按失败位置排查；不要为了让数字变小而连续修改协议参数。
STEP 05 / CHECK
Settings：从失败位置开始排查
先将问题归到一个具体环节，再改设置。订阅没有更新出条目、Connectivity Test 超时、连接开关无法保持、只有特定服务打不开，分别对应不同检查路径。一次只改一项，重新执行同一测试；确认无改善后恢复原值，再进行下一项。这样比同时更换网络、模式和参数更容易得到可解释的结论。
资料获取失败：先查订阅，不先改路由
如果 SERVER 中没有预期条目，返回订阅记录检查地址是否完整、访问凭据是否仍有效、更新时显示了什么错误。确认订阅是否需要特定的当前网络条件，并向你已有资料的提供方核对格式与有效状态。不要把订阅地址发到公开页面，也不要用不断新建重复订阅的方式掩盖错误。获取资料成功之后，才继续测试具体服务器。
测试超时或连接失败：先查参数与当前网络
逐项核对 Type、Host、Port 与认证内容，特别留意粘贴导致的空格、端口填错、协议选择不一致。若资料包含额外传输或 TLS 参数，应与原始说明逐项对应，不要随意关闭校验。再检查设备日期、时间与时区是否合理，避免因系统时间异常影响安全连接。
进入 Settings 查看 Test Method，确认比较的是同一种探测方式。某一种探测超时而实际访问正常，不能只凭超时就删除条目；反过来，探测有响应但实际访问失败，也要继续检查认证、传输与目标路径。必要时在保持其他条件不变的前提下，分别测试 Wi-Fi 与蜂窝网络，判断差异是否与接入网络有关。
只有部分请求失败：用模式对照定位规则
同一服务器在代理(Proxy)下正常、配置(Config)下异常时，优先回到 Config 检查当前文件和 Rule。留意是否命中了 DIRECT、REJECT，或引用了与预期不同的策略。不要只在文件末尾追加一条规则就假定它会覆盖前面的命中；规则顺序本身会影响结果。暂时无法判断时，保留原配置，先记录目标域名和两种姿态的表现。
连接反复变化：检查 On Demand 与诊断信息
如果手动断开后又重新连接，或网络切换时状态反复变化，到 Settings 检查 On Demand 是否已有触发条件。测试手动连接时先记录这些条件，按需要暂时停用，再观察相同行为是否仍出现。不要在首次排查中随意修改 Proxy、TCP、UDP 等分组中的高级选项；这些选项不是连接失败时必须统一开启的清单。
需要进一步定位时，可查看 Settings 中的 Diagnostics，结合发生问题的时间保留相关信息。分享诊断内容前，应遮盖订阅链接、认证内容、个人地址与其他敏感字段，只提供复现所需的错误提示和条件。针对超时可继续阅读节点超时与连接失败检查顺序；系统授权问题可阅读添加 VPN 配置提示说明。
