Shadowrocket 订阅导入与首次连接
按“导入 → 选择路由 → 连接 → 验证 → 排查”的顺序操作。先完成一次可复现的连接，再调整规则与自动连接设置。
操作前提：已从 App Store 安装 Shadowrocket，并已有自己的订阅链接或服务器信息。本站不提供、不销售、不推荐节点或订阅。客户端一次性买断 ≠ 线路套餐，购买应用不等于获得连接服务。
尚未安装时，先阅读App Store 正版获取说明，核对开发者 Shadow Launch Technology Limited 与应用 ID 932747118。系统要求以 App Store 页面标注为准。
以下以 iPhone 与 iPad 上的操作流程为主，界面词保留英文。先读与你持有的信息对应的导入分支，不需要同时执行两种添加方式。按钮位置可能随界面布局变化，请按名称辨认。
Add Server：添加服务器或导入订阅
先辨认手里的资料。订阅通常是一条完整链接，读取后可以产生多个服务器条目；单个服务器信息则包含协议、地址、端口与认证参数。两者不是同一种输入，不能把订阅链接填入服务器地址栏，也不要仅凭链接看起来像网址就直接在浏览器公开打开。订阅链接可能包含个人访问凭据，应与密码一样妥善保存。
已有订阅链接：选择 Subscribe
打开 Shadowrocket 的 Home，点击右上角添加按钮进入 Add Server。在 Type 中选择 Subscribe，再将自己已有的完整订阅链接填入 URL。可填写一个方便辨认的名称，避免后续多个订阅混在一起。粘贴后先检查开头和结尾有没有空格、换行，确认链接没有被聊天软件截断，也没有把说明文字一并复制进去。
保存后返回 Home，等待订阅读取结果。若只出现订阅名称而没有可选择的服务器条目，打开该订阅的操作入口执行更新，并留意返回的错误提示。成功的判断不是“保存按钮能按下”，而是订阅下已经出现实际服务器。此时先选择其中一个，不要在尚未确认导入结果时连续重复添加同一链接。
更新订阅需要当前网络能够取得订阅内容。读取失败不一定意味着链接已失效，也可能是基础网络、域名解析或返回格式有问题。先保留原链接，记下报错，再到失败点排查逐项检查。订阅中条目的名称只用于辨认，不能单凭名称判断实际可用性。
已有单个服务器信息：按协议填写
同样从 Home 进入 Add Server，在 Type 中选择与你已有资料一致的协议，例如 Shadowsocks、VMess、VLESS 或 Trojan。随后逐项填写服务器地址、端口和对应的认证信息。不同协议需要的字段不同，密码与 UUID 不能互相替代；不要因为某个字段看起来相似，就把另一种协议的资料套进去。
如果已有资料明确列出了 TLS、Server Name、传输类型、Host 或 Path 等参数，需要一并核对。服务器地址与用于 TLS 校验的名称可能不同，应遵循原始资料，而不是自行改成相同值。填写地址时也应区分“主机名”和“完整网址”：字段只要求主机名时，不要额外加上路径。保存后返回 Home，确认条目存在，再点选该条目。
持有自己服务器的二维码时，可以从 Home 的扫码入口使用 Scan QR Code。扫描完成后仍应检查协议与关键参数，不要把“扫描成功”当成“连接已验证”。iPad 若因窗口布局而使入口位置不同，仍按 Add Server、Type、Subscribe 等名称寻找即可。
本步完成标志：Home 中至少有一个实际服务器条目，并且已经选中。接下来决定请求采用什么路由方式，而不是立刻修改大量 Settings 项。
Global Routing：配置、代理与直连
在 Home 点击 Global Routing，选择本次连接采用的姿态。三种写法分别是配置(Config)/代理(Proxy)/直连(Direct)。这个选择决定请求如何被处理，但不会替你补齐服务器参数，也不会修复已失效的认证信息。首次操作时，应把“服务器能否连接”和“规则是否符合预期”分开验证。
配置(Config)：依据当前配置匹配规则
Config 依据当前使用的配置决定请求走哪种策略。进入 Config 页面，确认要使用的配置已经选中，再回到 Home 选择 Global Routing 中的 Config。导入服务器订阅与选择规则配置是两件事：订阅里出现了多个服务器，不代表当前配置已经按你的预期分流。首次使用已有配置时，至少确认它的来源、用途与策略引用。
规则常见策略包括 DIRECT、PROXY 与 REJECT。选择 Config 后，部分请求直接连接可能正是规则的结果，不能据此断定连接失效。如果不确定某个域名为何采用当前策略，先到验证步骤查看对应请求，再核对规则顺序。规则按顺序匹配的详细说明见新手到进阶手册，本页先完成基础连接闭环。
代理(Proxy)：用于检查所选服务器路径
需要先确认已有服务器是否可用时，可以临时选择 Proxy，以减少规则分流对测试结论的干扰。它让进入客户端处理范围的请求按代理方式处理，但不应被理解为设备所有活动都必然采用完全相同的路径。测试时仍要使用明确的目标，并查看实际请求结果。确认服务器可用后，可切回 Config，再检查日常规则。
直连(Direct)：用于基础网络对照
Direct 让相应请求直接连接目标，不通过所选代理服务器。它适合用于对照基础网络是否正常，却不能证明服务器已经连通。如果选择 Direct 后网页能打开，只能说明这次直接访问成功。希望检验所选服务器时，应回到 Proxy 或有明确代理规则的 Config，然后重新进行实际访问测试。
完成选择后，记住当前姿态和服务器名称。后面若测试失败，只改一个条件再重试，才能判断是服务器问题还是规则问题；不要在同一轮里同时切换服务器、修改 DNS 并更换配置。
Home：打开开关与 VPN 配置授权
回到 Home，再确认一次选中的服务器与 Global Routing 姿态，然后打开顶部连接开关。第一次建立连接时，系统可能提示允许 Shadowrocket 添加 VPN 配置。这是让客户端建立系统网络连接配置的授权步骤，与订阅是否有效是两个不同环节。先确认提示由刚才的主动操作触发，再按系统提示完成确认与设备认证。
授权后返回 Shadowrocket，检查开关与连接状态。如果先前选择了取消，连接通常无法继续，重新打开连接开关并按提示处理即可。若没有再次出现提示，可以进入设备 Settings 的 VPN 相关设置检查现有配置；不同系统版本的设置层级可能不同，请按设备实际界面查找，不必为寻找某个固定路径反复删除配置。
连接建立后，系统中的 VPN 标识可以作为状态参考，但它只说明相关网络配置正在运行，不说明服务器认证、DNS 和目标页面访问都已正常。有时客户端可以保持连接状态，实际目标请求却失败，因此还需要完成下一步。也不要只因状态变化较慢就连续快速切换开关，应等待本次连接结果明确后再决定是否重试。
如果设备同时启用了其他 VPN 连接，或存在单位、学校管理的网络配置，可能影响本次连接。先确认当前实际启用的是哪一个连接，并遵守设备管理要求。不要随意移除用途不明的管理配置。首次测试时也建议暂不设置 On Demand，避免手动断开后又被自动连接条件触发，让观察结果变得混乱。
本步完成标志：系统授权已处理，Shadowrocket 显示连接正在运行。下一步用真实访问验证，不以开关位置代替测试结果。
Connectivity Test 与实际访问检查
先在 Home 使用 Connectivity Test 对已有服务器进行初步检查。测试结果用于观察对应测试方式下的可达情况，不能替代完整的页面访问。显示一个响应时间，不代表所有域名、所有协议与所有目标都可以访问；出现超时，也需要结合测试方式和实际使用情况判断，不能仅凭一次结果删除全部条目。
接着打开浏览器，访问一个自己有权访问、且能够辨认正常内容的页面。保持同一服务器和同一路由姿态，尝试刷新并打开页面里的另一个链接，确认不是只看到了缓存内容。若只有某个目标失败，再选择另一个明确的目标做对照。应先区分“所有访问都失败”和“仅一个网站失败”，两者的排查方向不同。
在 Data 中核对本次请求
返回 Shadowrocket，在 Data 中查看当前可用的流量与请求记录。先按刚才的访问时间和目标域名定位请求，再结合记录里实际提供的策略、错误或连接信息判断。若正在使用 Config，重点检查该请求是按预期走 PROXY、DIRECT，还是被 REJECT。只看总流量增加不足以证明目标页面已经成功，因为后台应用也可能产生请求。
如果记录没有提供足够细节，不要凭空推断命中规则。可先用 Proxy 做服务器路径的对照测试，再切回 Config 复测同一目标。Proxy 可访问、Config 不符合预期时，应优先检查当前配置、规则顺序与策略引用，而不是重新填写全部服务器信息。两种姿态都失败时，则继续检查服务器参数、基础网络与解析环节。
需要对照直接访问时，可短暂切换为 Direct 或停止本次连接，测试相同目标，再恢复之前的选择。对照测试本身会改变网络路径，应只访问适合直接连接的目标，并在操作前确认自己的访问要求。结果应记录为“哪一个目标、哪一种姿态、是否成功”，而不是只写笼统的“网络不通”。
完成首次验证后，再切换一次 Wi-Fi 或蜂窝网络复测，有助于发现只在某一网络下出现的问题。若当前设备不具备蜂窝网络条件，跳过此项即可。日常使用前确认恢复到所需的 Config 或其他姿态；订阅更新后服务器名称或条目发生变化，也应重新检查所选服务器与策略引用。
订阅失败、连接失败与网页打不开
排查时先保留当前设置与错误提示，按下面的顺序定位。每完成一项，只修改与该项直接相关的内容，再用相同目标复测。直接重装会让原来的服务器选择、配置与授权状态发生变化，反而难以判断真正原因，不宜作为第一步。
订阅保存成功，但没有服务器条目
返回 Add Server 对应的订阅编辑入口，确认 Type 为 Subscribe，URL 是完整的已有链接。检查是否复制了页面标题、遗漏了链接尾部参数，或混入空格与换行。然后检查基础网络能否正常访问，再执行一次订阅更新并记录报错。若返回的是登录网页或说明页面，而不是客户端可读取的订阅内容，需要向你已有服务的管理方核对链接用途与格式。
不要把完整订阅链接贴到公开讨论区，也不要为了试错随意删除其中的参数。部分参数用于识别个人订阅资格，改动后即使网址仍能打开，也未必返回正确内容。如果已有服务资料说明链接已更换，应更新原订阅记录，避免多个旧记录导致后续误选。
服务器已出现，但无法建立有效访问
先确认实际选中的是预期服务器，再核对协议、端口、认证信息与 TLS 等参数。不要通过关闭证书校验来掩盖名称或证书问题，应先检查 Server Name、服务器地址与设备时间是否正确。随后临时使用 Proxy 对同一目标测试：若仍失败，优先处理服务器可达性与参数；若 Proxy 正常而 Config 异常，再检查配置与规则。
连接开关无法保持，或系统授权未完成
查看系统 VPN 设置里当前的连接状态，确认添加配置的授权已经完成，并留意是否有其他连接正在切换。若设备受管理，应先核对管理限制。若手动断开后又自动连接，检查是否已设置 On Demand 触发条件；这与“开关失灵”不是同一问题。调整前先记下原条件，避免把日常需要的自动连接行为一并改变。
Connectivity Test 有响应，网页仍打不开
先比较不同目标的实际访问结果，再查看 Data 中是否有与失败目标对应的记录。可能的环节包括域名解析、规则选择、服务器到目标的连接以及目标自身响应。没有足够证据时，不要直接把问题归为 DNS。确有解析错误时，先确认当前配置采用的 DNS 设置，避免同时更换多个解析地址，使结果无法对照。
如果只在某个 Wi-Fi 下失败，先确认该网络是否需要完成正常的接入认证；若切换到另一个可用网络后恢复，应继续检查原网络条件。若只有单个应用失败，可先用浏览器访问同一服务的可用页面作对照，区分应用会话、目标服务与客户端连接问题，不要立刻修改所有规则。
保留最小排查记录，再做后续调整
记录设备类型、当前网络、Global Routing 姿态、所选服务器的自定义名称、失败目标与错误现象即可。需要分享诊断记录时，先移除完整订阅链接、密码、UUID、个人地址与其他认证内容；单独遮住名称并不代表凭据已经移除。修改完成后重新走一遍“选择服务器 → 连接 → 访问目标 → 查看记录”，确认结果可以重复。
入门完成标准：已有资料已导入，能解释当前 Global Routing 的选择，连接授权完成，并通过真实访问确认结果。随后再阅读新手到进阶完整手册，了解 Config 规则、On Demand、Data 与日常维护；具体能力范围可查阅功能介绍。
日常更新应用仍通过 App Store 完成。更新应用、更新订阅与更换规则配置是三种不同操作，分别完成后再验证，便于在出现变化时准确定位原因。