官方手册 · 首次设置
Shadowrocket 快速上手
按添加信息、选择姿态、连接、验证、排错的顺序操作。本篇面向 iPhone 与 iPad 的首次使用，重点是走通一次完整连接流程；规则原理与复杂故障另有专页说明。
以下截图来自官方 App Store 素材，用于识别页面与字段。实际可见项目会随所选 Type 与应用界面调整；填写值始终以自己的原始连接资料为准。
步骤一 · Add Server / Subscribe
添加服务器或导入订阅
打开 Shadowrocket 后先停留在 Home，找到下方 SERVER 分组。这里用于选择实际连接的服务器；刚安装且尚未导入时，没有可选条目并不表示应用异常。进入 Add Server，根据手里的资料选择一种添加方式即可，不必同时做手动填写和订阅导入。
已有单个服务器信息
在 Add Server 中先点 Type，选择资料指定的协议，再填写该协议需要的字段。截图展示的是包含 Host、Port、Password、Method 的一种表单；切换 Type 后，字段可能变化，因此不能把这一张表单当成所有协议的统一填写模板。Shadowsocks、VMess、VLESS、Trojan 等协议的参数不可互换，名称相近也不能据此猜测。
Host 填服务器地址，Port 填对应端口，Password 等认证字段按原始信息填写；需要 Method 时也必须逐项一致。复制后留意首尾空格、换行和输入法替换的符号。若资料还包含 TLS、服务器名称或其他传输参数，应按资料继续补齐，不要因为常见字段已经填完就直接略过。保存后回到 Home，确认条目出现在 SERVER 中，再点选计划使用的条目。
如果已有二维码，可以使用 Add Server 页中的 Scan QR Code 读取自己的信息，识别后仍需核对 Type 与地址。Import from Cloud JSON 用于相应的结构化资料，并不等同于普通订阅入口；只有资料明确采用这种格式时再使用。字段含义不清楚时，可先查术语手册，不要通过反复更改协议类型碰运气。
已有订阅链接
再次进入 Add Server，在 Type 中选择 Subscribe，将自己的完整订阅链接填入相应地址字段，按页面提供的保存操作完成添加。订阅链接常包含认证信息，复制时应包含完整路径与查询参数，不要仅复制网站域名，也不要额外加上中文引号或说明文字。订阅链接属于敏感资料，不应贴到公开截图或排错记录中。
返回 Home 后检查对应分组及服务器条目是否出现；如果只保存了订阅记录但尚未取回内容，再对该订阅执行更新并等待结果。导入订阅与选择服务器是连续的两步：列表出现后仍要选中一个条目，随后才能进入下一步。若导入失败，先保留错误提示并检查链接，而不是立即修改 Global Routing；路由姿态不能修复格式错误或失效的订阅地址。
步骤二 · Global Routing / Config
选择 Global Routing 姿态
服务器添加完成后，回到 Home，点开 Global Routing。它决定请求采用哪种处理方式，与“选择哪个服务器”不是同一个设置。首次使用应先明确本次要验证代理链路，还是直接使用已有分流规则，再选择对应姿态；不要把顶部开关打开当成全部请求都经过服务器的证明。
配置(Config)：按当前规则处理
配置(Config)使用当前选中配置文件中的规则判断请求去向。需要按网站区分 PROXY 与 DIRECT 时，使用这一姿态，并进入 Config 页核对实际启用的文件。截图中的 General、Rule、Hosts、URL Rewrite、HTTPS Decryption 分段分别组织不同类型的配置；首次连接不需要为了“设置完整”而逐段修改，更不必启用与当前目标无关的功能。
尤其要区分服务器订阅与配置文件：前者通常更新服务器列表，后者描述连接与分流行为，导入前者不代表已切换后者。在 Config 页打开文件查看内容后，还应确认它确实被选中使用。需要编辑时先保存可恢复的副本，再通过 Rule 或 Add Rule 检查目标网站对应的条件、策略和顺序。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT这段示例表示 example.com 及其子域名匹配 PROXY，其余请求由 FINAL,DIRECT 兜底；example.com 只是示例域名，不是服务器或订阅地址。规则自上而下匹配，较早命中的宽泛条件可能使后面的规则没有机会生效。第一次上手先理解这个关系即可，完整语法可继续阅读配置文件分段说明。
代理(Proxy)与直连(Direct)
代理(Proxy)适合在首次排查时减少规则差异，观察当前服务器的代理路径能否完成实际访问；它并不保证每个系统请求都具有完全相同的路径。直连(Direct)用于直接连接目标，可作为基础网络的对照，但不能用于证明服务器可用。两者都不会自动补齐错误的认证参数。
如果已有明确的配置文件，选择配置(Config)并按既定规则验证；如果暂时无法判断是规则问题还是服务器问题，可以临时用代理(Proxy)作对照，测试完成后再恢复原来的姿态。三者的适用范围见代理模式说明，直连细节见Direct 说明。确认姿态后，下一步才是打开连接开关。
步骤三 · Home / VPN 配置授权
打开开关并完成授权
回到 Home，依次检查 SERVER 中当前选中的条目和 Global Routing 的姿态。若刚更新过订阅，先确认原先选中的条目仍然存在，且没有误选到同名的另一条记录。连接使用的是当前选择，而不是刚才最后打开查看详情的服务器。
找到顶部 Not Connected 旁的开关并打开。首次连接时，系统可能提示允许 Shadowrocket 添加 VPN 配置。核对提示中的应用名称后选择允许，并根据系统要求完成设备验证。这是让应用在设备上建立相应网络连接配置的授权，与订阅有效期或服务器认证不是同一件事。
完成授权后返回 Shadowrocket，观察 Home 顶部状态是否从 Not Connected 转为已连接状态，开关是否保持打开。系统确认窗口出现后应先处理完毕，再继续操作；不要在授权尚未结束时反复点按开关。如果此前拒绝授权，先重新发起连接并按系统提示处理，必要时到系统设置检查 VPN 配置状态，而不是重新导入同一批服务器。
iPad 的页面空间与系统提示布局可能不同，但检查顺序仍是“选中服务器 → Global Routing → 顶部开关 → 系统授权”。如果设备受到组织管理，系统策略可能限制 VPN 配置的添加，应按设备管理要求处理。系统要求与兼容性以 App Store 页面标注为准，不应仅凭截图判断设备是否适用。
连接后先保持网络环境不变，暂时不要同时切换 Wi-Fi、服务器和配置文件。如果状态很快回到 Not Connected，记下它发生在授权之前还是之后；这个区别能帮助后续定位系统配置问题与连接参数问题。需要更详细的 Home 区块解释时，可阅读首次打开与 Home 页说明。
步骤四 · Connectivity Test / 实际访问
验证连接与规则是否生效
连接状态稳定后，在 Home 点 Connectivity Test，观察当前服务器的测试结果。测试出现响应说明相应测试方法下存在可达性，但不能据此推断所有网站、所有协议或所有请求都正常。测试值也不是下载速度；不要只比较数值大小而忽略实际访问结果。
随后切到浏览器，打开一个自己明确知道正常、且与本次验证目标相关的网页。优先重新加载页面或发起新的请求，不要只看连接前已显示的缓存内容。检查页面能否加载文字与必要资源，再操作一次站内链接；仅有页面标题出现，并不能说明整个页面的请求都成功。
按所选姿态进行对照
代理(Proxy)下先检查实际访问是否能完成；如果测试有响应而网页持续失败，后续应考虑 DNS、目标访问与传输参数，而不是直接得出“服务器完全正常”的结论。直连(Direct)下的成功只能说明直接访问路径可用，不应作为代理链路验证结果。
配置(Config)下，应分别选择一个预期命中 PROXY 的网站和一个预期命中 DIRECT 的网站，并核对当前文件中的相应规则。单凭两类网页都能打开，并不能确定它们的路由方向；需要结合规则顺序与应用内可查看的请求记录判断实际命中结果。若规则使用域名条件，也要留意网页可能同时请求其他资源域名，主域名命中不代表全部资源采用相同策略。
首次验证建议保持目标简单：先让一条明确的连接路径可用，再逐步恢复复杂分流。若要对比其他服务器，每次只换一个条目，并重新发起请求；若要对比姿态，则保留相同服务器与网络环境。这样才能知道变化来自哪里，也避免把网络切换后的偶然成功误认为某项设置的效果。
完成后记录最终使用的服务器、Global Routing 姿态和当前 Config 文件名称即可，不要记录或传播密码、完整订阅链接等敏感信息。如果基础连接与预期访问均正常，上手流程到这里已经完成；只有出现具体症状时，才需要进入下面的排错步骤。
步骤五 · Settings / Diagnostics
检查常见失败点
先确定失败发生在哪个阶段：没有导入条目、服务器测试失败、开关无法保持，还是已连接但网页无法使用。沿着这条顺序检查，比一次修改多个高级设置更容易找到原因。下面仅处理首次上手最常见的分支；持续故障请转到疑难手册按症状排查。
导入后没有服务器
先回看添加时的 Type 是否为 Subscribe，链接是否完整，更新是否给出错误。普通网页地址、账户页面与订阅地址不是同一种资料。不要自行删掉查询参数，也不要把含认证信息的地址贴到公开页面求证。如果链接无法取回或返回内容无法识别，应向自己的服务商确认原始资料及其适用格式；重复保存相同的错误地址不会改变结果。
测试失败或连接中断
手动添加时逐项复核 Type、Host、Port、认证字段与所需传输参数；订阅导入时先确认内容已成功更新。随后检查当前基础网络是否可用，并在相同环境中测试自己的其他已有条目。如果多个条目同时失败，应同时考虑当前网络条件，不宜立即断定每条服务器都失效。
在 Settings 中查看 Test Method，确认正在使用哪一种测试方法。测试方法改变后，结果含义也会改变，前后的数值不能直接比较。对 UDP 等传输相关问题，不应把 Settings 中的 TCP 或 UDP 项目随意切换作为通用修复；先明确服务器协议要求，再按对应文档检查。
开关异常或网页打不开
开关无法打开时先检查系统 VPN 授权是否完成，是否存在其他正在使用的 VPN 配置，以及设备管理限制。开关能保持但网页失败时，再检查 Global Routing 与当前 Config；若代理(Proxy)可用而配置(Config)不可用，优先查看规则、当前文件与 DNS 设置，而不是重新填写全部服务器信息。连接相关流程见连接问题排查。
如果 Connectivity Test 有响应但域名访问失败，可以先对照DNS 解析失败说明，不要看到 dns-server 就随意替换成不熟悉的地址。解析与连接是不同环节，修改前应保存原值，每次只改一项并再次测试。
自动连接与诊断记录
手动断开后又出现连接时，到 Settings 检查 On Demand 是否已配置触发条件。首次上手宜先确认手动连接稳定，再配置自动行为；已有 On Demand 规则时，先记录原设置，再暂时停用触发条件作对照。Wi-Fi 与蜂窝网络切换也应单独验证，避免把网络变化与自动触发混在一起。
需要进一步分析时，可查看 Settings 中的 Diagnostics。保留错误发生时的步骤、网络类型与错误文本，比只描述“不能用”更有帮助。分享记录之前应遮盖服务器地址、认证字段和订阅内容。排错完成后，恢复原先需要的 Global Routing 与 On Demand 设置，并再做一次实际访问验证，形成完整闭环。
