Shadowrocket 快速上手 订阅导入与首次连接

打开 Shadowrocket，进入 Home，在服务器区域找到 Add Server 并进入。添加页中的 Type 决定需要填写哪些字段；不要把订阅地址直接填进单台服务器的 Host，也不要仅凭地址外观猜协议。先查看你的服务商给出的说明：它提供的是可更新的订阅链接，还是一台服务器的完整连接参数。两种方式都能形成 Home 中的条目，但后续更新和核对的方法不同。

已有订阅链接：使用 Subscribe

在 Add Server 中点开 Type，选择 Subscribe，将从你的服务商处获取的完整订阅链接粘贴到 URL。如果页面提供备注字段，可填写便于辨认来源的名称。粘贴后检查开头和末尾，避免混入聊天消息里的说明文字、空格或换行，也不要自行删掉地址中的查询参数；这些参数可能是服务商用于识别订阅的必要信息。

确认后保存，返回 Home，等待订阅内容读取完成，再查看对应分组内是否出现服务器条目。保存了订阅条目，不等于已经读取到可用服务器。如果分组为空或出现读取错误，先检查链接是否完整、订阅是否仍有效，以及当前网络能否访问订阅地址。不要连续重复添加同一条链接；先保留一份，按服务商说明重新读取，避免列表里出现重复分组。

已有单台服务器参数：按 Type 逐项填写

如果收到的是服务器地址、端口、密码及协议信息，在 Type 中选择实际协议，再填写 Host、Port 和该类型要求的认证字段。截图展示了包含 Password 与 Method 的添加页，但不同 Type 的字段并不相同。Shadowsocks、VMess、VLESS、Trojan、WireGuard 等类型需要的信息应以服务商提供的参数和应用当前页面为准，不能把某一种类型的字段照搬到另一种类型。

填写时重点检查地址是否多了空格、端口是否抄错、密码是否保留大小写；需要额外传输或安全参数时，也应完整核对。遇到不清楚的字段，先向你的服务商确认含义，再保存。凭空补一个参数可能让条目看起来完整，却无法完成连接。

已有二维码：使用 Scan QR Code

如果已有服务器二维码，可使用 Scan QR Code，并在系统提示时允许所需的相机访问。识别完成后仍要核对 Type、地址与端口，再保存；二维码能被识别只说明内容可被解析，并不能证明服务器当前可用。Import from Cloud JSON 是另一种导入入口，不应当作普通订阅链接的替代填法；仅在你已有对应格式且清楚用途时使用。

这一阶段的完成标志是：Home 中已经能找到准备使用的服务器，并能打开其详情核对来源。先不要急着更改 DNS 或其他 Settings。下一步先确定请求将按哪种 Global Routing 方式处理。

回到 Home，点开 Global Routing。首次使用先分清三个姿态：配置(Config)/代理(Proxy)/直连(Direct)。这里的选择不会替你补齐服务器参数，也不会使失效的订阅恢复有效。切换之前记住当前选项，测试后才容易恢复，避免后续把模式变化误认为服务器变化。

配置(Config)：按当前配置文件匹配规则

选择配置(Config)时，请求依据当前启用的配置文件处理。进入底部 Config，核对实际启用的是哪份文件，再查看其中的 Rule。规则可以把不同请求交给 PROXY、DIRECT 或 REJECT 等策略，因此同一次连接中，多个网站的处理路径可能不同。看到 VPN 状态，并不意味着所有请求都使用了当前服务器。

官方截图展示的是配置文件编辑页，可见 General、Rule、Hosts、URL Rewrite、HTTPS Decryption 与 Add Rule。它用于帮助辨认位置，并不是要求首次使用时逐项开启。先保留你已有配置的结构，尤其不要为完成一次连接测试就更改 HTTPS Decryption；它不属于本教程的首次连接步骤。

代理(Proxy)：用于缩小首次验证范围

如果你尚未准备好规则文件，或需要先确认已选服务器能否处理请求，可以临时选择代理(Proxy)进行验证。此时针对由 Shadowrocket 处理的请求，使用代理方式检查，更容易将“服务器连接是否可用”和“某条规则是否命中”分开判断。它不是成功保证，也不应理解为对设备上所有流量路径的绝对承诺；实际结果仍需下一步连接和请求测试确认。

直连(Direct)：不用于证明服务器可用

选择直连(Direct)时，相关请求按直连方式处理。此时网页正常打开，不能证明已添加的服务器能连接；同样，选中某台服务器后一直停留在 Direct，也不能靠网页可访问来完成服务器验证。若只是做对照测试，完成后应恢复原来的模式，避免忘记切回。

需要规则分流时，通常回到配置(Config)，并确认当前文件的策略符合你的用途。初次连接不必立即编写长规则表；先把模式、文件和当前服务器三者对应起来。关于 DNS、On Demand 与其他设置的进一步说明，请阅读Settings 设置手册。本页继续完成连接，不展开完整配置维护。

在 Home 的 SERVER 列表里找到准备使用的条目，点选服务器前的圆点，将它设为当前项。仅打开服务器详情页查看参数，不应当作已经切换当前服务器的依据；返回 Home 后确认选择标记确实落在目标条目上。列表里有多个订阅分组时，也要核对分组来源，避免选到了旧订阅中的同名条目。

接着检查 Global Routing 是否仍是上一步选定的姿态，再打开 Home 顶部的连接开关。官方截图中顶部显示 Not Connected，用于辨认未连接时的开关位置；截图本身不代表你设备上的当前状态。连接后应以实际界面文字和系统状态为准，不需要让页面里的每个细节都与截图完全一致。

首次允许添加 VPN 配置

首次连接时，系统可能询问是否允许 Shadowrocket 添加 VPN 配置。确认提示中的应用名称后，按系统要求授权；设备可能要求通过设备密码或生物识别确认。这里使用的是设备的系统认证，不是把服务商密码填进系统授权框。允许这一步，是让应用建立所需的网络配置，不是为服务器参数或线路状态作出有效性认证。

如果之前取消了授权，回到 Home 重新尝试连接并留意系统提示。若设备受组织管理或存在相关限制，应遵循设备管理要求，不要删除来源不明的系统配置来试错。授权后返回应用，观察顶部开关是否保持开启；如果开关马上回落，先记录当时的提示，再进入后面的排查步骤。

状态改变后，先保持环境不变

连接建立后，系统可能显示 VPN 状态标识，但其具体呈现受设备与当前界面影响。连接状态说明配置已启用，不等于远端服务器与每个目标都已验证通过。因此不要看到状态标识就结束操作，也不要立即连续切换服务器、网络和模式。先保持当前组合，进入下一步执行一次 Connectivity Test，再发起实际请求。

若使用 iPad，仍按 Home 中的列表、Global Routing 和顶部开关完成相同检查；界面布局以设备显示为准。此时的记录至少应包含当前服务器、当前模式，以及连接开关是否能保持开启。三个信息明确后，即使测试失败，也能沿着相同条件复现，而不是重新从导入开始。

导入后没有条目：先检查输入与读取

回到 Home 检查导入来源。订阅分组为空时，核对 Subscribe 的 URL 是否完整，链接是否仍有效，以及读取时出现的具体错误。如果手动添加的条目能保存却无法连接，回到详情重新核对 Type 与全部必需字段。保存成功只说明应用接受了输入格式；它并不会替你确认服务商侧的状态。此类问题优先核对已有信息，不要先去改与导入无关的设置。

开关不能保持开启：先检查授权与提示

如果连接开关立即关闭，确认系统的 VPN 配置授权是否完成，并记录应用或系统给出的文字。再确认当前服务器确已选中，所需配置没有缺失。若之前更改过多个选项，先恢复明确记录过的原值，而不是凭印象继续尝试。设备管理限制与服务器不可达属于不同问题，应按提示区分；反复重装应用通常无法替代这一步核对，也可能使原有配置更难追溯。

已连接但测试失败：核对方法与当前服务器

进入 Settings，找到 Test Method，先记录当前方法，再判断它与你正在看的测试结果有何对应关系。随后回到 Home，对相同目标复测。若所有实际请求也失败，再核对服务商给出的参数、服务器状态与当前网络条件。可以用另一台自己已有的服务器做对照，但不要把“换一个测试方法后数字出现”直接当作所有请求已恢复的证明。

只有部分目标失败：回到 Config 看路径

连接能保持且部分页面正常时，优先查看 Global Routing 与当前 Config。确认出问题的目标是否命中了 DIRECT、PROXY 或 REJECT，以及是否由预期的配置文件处理。DNS 与规则都可能参与其中，但不要为了一个目标立即替换整份配置。先保留原文件，在能说明原因的前提下只做一处调整，再用同一目标复测；需要理解 DNS 与配置之间的关系时，转到设置手册继续阅读。

手动测试时状态又变化：核对 On Demand

在 Settings 中查看 On Demand。如果此前已经设置了按网络条件触发连接的行为，手动测试过程中可能出现与预期不同的连接变化。先记录已有条件；为隔离问题而临时停用时，测试结束后恢复原设置。不要在尚未理解当前条件时新建多条触发规则。本教程的目标是先验证一次明确的手动连接，按需连接的长期设置应在基础连接确认后再做。

需要进一步定位：使用 Diagnostics 并保护信息

仍然无法区分原因时，再查看 Settings 中的 Diagnostics，结合发生问题的时间、目标和现象检查可用诊断信息。记录应服务于复现，不需要把所有内容公开。订阅地址、认证字段、服务器标识和访问记录都可能包含敏感信息；发送诊断内容前先检查并遮去不必要的信息。有关 Proxy、TCP、UDP 等选项，先读懂用途再调整，不把反复切换开关当作固定解决方案。

排查到此，回到 Connectivity Test 与实际请求验证，按同一套条件再做一轮。能重复得到正常结果后，再恢复日常使用的 Global Routing 和 On Demand。若问题来自已有订阅或服务器参数，将核对后的现象交给你的服务商确认；若只是忘记操作顺序，重新从本页对应步骤继续即可，不必重复购买客户端。