官方手册 / 快速上手
Shadowrocket 快速上手
已有订阅导入 → Global Routing → 连接与验证
按顺序完成五步。先确认输入信息，再检查连接结果；遇到问题时，回到对应步骤核对，不必重做全部设置。
- 01 添加
- 02 路由
- 03 连接
- 04 验证
- 05 排错
步骤 01 / 输入连接信息
Add Server 添加与导入
订阅导入与手动添加任选一种，取决于你已持有的信息类型。保存后能看到条目，才进入下一步。
已有订阅链接：选择 Subscribe
打开 Shadowrocket 的 Home，在 SERVER 区域找到 Add Server，或使用页面上的添加入口。进入 Add Server 后，点开 Type 并选择 Subscribe，再把自己的完整订阅链接粘贴到 URL 字段。不同类型会展示不同字段，因此应先选择 Type，再填写内容，避免把订阅地址误填成单台服务器的 Host。
粘贴后从开头到结尾检查一次：链接必须来自你已有的服务配置，不能缺失查询参数，也不要混入说明文字、空格或换行。订阅链接中可能包含识别使用资格的凭据，应当像密码一样保管，不要贴到公开讨论或截图中。为条目填写便于辨认的名称，然后使用页面上的保存操作返回 Home；如提示更新，按提示获取订阅内容。
导入完成后，在 SERVER 检查是否出现订阅分组和服务器条目。分组名称出现并不一定表示内容已成功取得；如果列表仍为空，先核对链接是否完整、当前网络是否能访问订阅地址，以及订阅本身是否仍有效。此时先不要反复更改 Global Routing，因为订阅内容获取与连接模式是两个不同环节。
已有单台服务器信息：按 Type 填写
如果准备的是一组服务器参数，在 Add Server 的 Type 中选择与资料一致的协议，例如 Shadowsocks、VMess、VLESS、Trojan 或 WireGuard，再填写该类型要求的字段。官方截图展示了 Host、Port、Password、Method 等项目，但它们并非所有协议都会使用。Host 填服务器主机名或 IP，Port 填端口；不要把含路径的完整网页地址直接当成 Host。
认证信息、加密方式与传输参数需要逐项对应原始资料。对于涉及 TLS 的配置，服务器名称与证书相关字段同样要保持一致；不要为了让测试通过而随意降低验证要求。若资料只提供二维码，可使用 Scan QR Code，并在识别后检查 Type 与关键字段。Import from Cloud JSON 是另一种导入入口，不等同于通用订阅链接；只有已有对应格式资料时才使用。
保存后回到 Home，确认条目没有重复、协议与名称便于辨认。导入只是把连接资料存入应用，不代表已经连接，也不会自动证明服务器可用。现在保留一个准备测试的条目，下一步先确定它应按哪种路由姿态工作。
步骤 02 / 确定请求处理方式
Global Routing 三种姿态
配置(Config)、代理(Proxy)、直连(Direct)决定请求如何处理；服务器条目和 Config 配置文件不是同一件事。
回到 Home，点开 Global Routing。先根据当前目的选择姿态，而不是只看服务器是否已被选中。配置(Config)按照当前配置文件中的规则决定请求去向；代理(Proxy)让通常的请求通过所选代理服务器处理，适合隔离规则因素进行检查；直连(Direct)则不通过所选代理服务器转发。它们改变的是处理方式，不会替你补齐服务器参数。
第一次使用时，如果已有经过确认的配置文件，可选配置(Config)；如果暂时只想检查刚添加的服务器能否正常转发，可先用代理(Proxy)做一次受控测试。直连(Direct)适合确认本地网络的基础访问情况，不适合用来验证代理服务器本身。切换后返回 Home，核对 Global Routing 旁显示的名称，避免以为已切换但实际上没有选中。
使用 Config 前，先看当前配置
打开底部 Config，确认当前使用的是哪份配置，再进入其内容查看 General 与 Rule。官方截图还展示 Hosts、URL Rewrite、HTTPS Decryption 等分段；完成基础连接不需要逐一启用这些功能。尤其是涉及证书与内容处理的项目，不属于本页的首次连接流程，应该在理解作用后单独配置。
Rule 中的规则按顺序匹配。比如 DOMAIN-SUFFIX,example.com,PROXY 表示按域名后缀匹配并交给相应策略处理，FINAL,DIRECT 则将此前未命中的请求交给 DIRECT。这里的规则只是语法说明，不需要为了跟随本教程把它们添加进你的配置。实际访问是否经过代理，取决于当前文件、规则顺序和策略指向。
订阅通常用于提供服务器条目；它与包含分流规则的完整配置并不能直接画等号。如果只导入了订阅，却没有核对 Config 的内容，就不应假定所有应用都已经按期望分流。也不要同时导入多份不熟悉的规则来“补齐”设置，否则验证时很难判断是哪一项改变了结果。
本步只完成两件事：确认 Global Routing 的姿态，确认配置(Config)所依赖的文件。详细设置留到连接通过后再调整，可继续阅读Settings 设置详解；有关规则命中与导入差异的疑问可查FAQ。完成后返回 Home，准备建立连接。
步骤 03 / 建立系统连接
Home 选择服务器并连接
先选条目，再确认 Global Routing，最后打开顶部开关。系统授权与服务器认证是两件不同的事。
回到 Home，在 SERVER 中点选本次要使用的服务器。存在多个分组时，先展开正确的分组，再确认选中标记对应的是目标条目。不要只根据列表位置判断，因为更新订阅后条目顺序可能变化。接着再看一次 Global Routing：这一项应与上一步的测试目的保持一致。
打开 Home 顶部开关。未连接时，官方截图中的状态为 Not Connected。首次建立连接时，系统可能弹出添加 VPN 配置的请求，这是允许应用通过系统网络扩展处理流量的授权，不是让你填写远端服务器密码的地方。阅读系统提示，确认当前操作来自 Shadowrocket，再依照设备要求完成身份验证。若暂时取消授权，应用可能无法进入正常连接状态。
确认后返回 Shadowrocket，等待顶部状态更新。不要在状态切换过程中连续开关；如果立即回到未连接状态，先停下来查看提示，而不是把开关保持打开就当作成功。系统出现 VPN 标识，只能说明相关网络连接已经建立，不能单独证明所选服务器、域名解析或分流规则全部正常，实际访问仍要在下一步验证。
连接后先保留稳定的检查条件
首次测试时，保持当前网络不变，暂时不要同时切换 Wi-Fi、蜂窝网络和多台服务器。如果设备还配置了其他 VPN 连接，先确认当前实际启用的是本次要测试的连接，避免把不同配置的结果混在一起。网络限制、服务器状态与认证参数都可能影响结果，单靠多次重试无法区分原因。
在 iPad 上也按 Home、SERVER、Global Routing、顶部开关的顺序检查；屏幕布局不同并不改变这个流程。连接成功后，可以切换到需要测试的应用，但先不要进行大量规则修改。若之后修改了服务器参数或影响连接的设置，应按界面提示重新连接，再重新验证，避免拿旧连接的表现判断新设置。
停止使用时，可回到 Home 关闭顶部开关。如果关闭后又出现自动连接现象，先记录发生时的网络条件，之后检查 On Demand，而不是直接删除所有资料。现在进入验证步骤，把“开关已打开”和“请求按预期处理”分别确认。
步骤 04 / 分层确认结果
Connectivity Test 与实际访问
测试结果、系统连接状态、页面访问与规则命中分别回答不同问题，应按顺序核对。
先回到 Home，使用 Connectivity Test 查看条目的测试结果。测试方法会影响结果的含义：能探测到服务器端口，并不一定表示认证、TLS 或后续请求都能完成；某种测试失败，也不能直接推出全部实际访问都失败。不要把一个读数当成对整条链路的完整结论，更不要只按数值大小判断服务器是否适合当前任务。
然后打开自己需要使用且有权访问的页面，先用一个目标进行检查，等待其主要内容加载，再尝试页面内的正常操作。页面打开但图片、登录或接口请求失败时，应记录是哪一部分出错；一个页面可能使用多个域名，它们在配置(Config)下也可能匹配到不同规则。重复刷新同一个缓存页面，不足以证明连接已按新设置工作。
用三项检查区分问题所在
- 连接是否保持：切回 Home，确认开关与连接状态没有回落。若连接已断开，优先检查授权、服务器参数和网络，而不是先改 Rule。
- 所选服务器是否参与：如果当前是直连(Direct)，页面能打开不能证明代理服务器可用。切换到代理(Proxy)进行一次对照测试后，再按需要恢复配置(Config)。
- 规则是否符合预期：配置(Config)下结合当前 Rule 与相关连接记录检查目标请求。不要因为某个页面成功，就推断其他域名或所有应用都会采用相同策略。
需要进一步判断时，可以查看 Data 中的流量变化，或通过诊断记录观察请求处理情况。流量变化只是辅助线索：后台应用可能同时联网，因此有数据增长不等于刚测试的页面一定经过了目标服务器。将目标域名、测试时刻与当时的 Global Routing 一起记录，才便于复现。
如果代理(Proxy)测试成功、配置(Config)下失败，优先检查规则、策略与解析设置；如果两种姿态都失败，先转向服务器资料和网络检查。验证通过后，再恢复你计划长期使用的姿态，并进行一次简短复测。更复杂的分流问题可查连接与分流 FAQ，首次上手不必同时处理所有高级功能。
步骤 05 / 按最小改动排查
Settings 与常见失败点
每次只改一个条件，保留原值并复测。先定位失败阶段，再处理对应设置。
导入失败或服务器列表为空
回到步骤 01，重新核对订阅链接是否完整、是否选了 Subscribe，以及订阅内容能否在当前网络下取得。链接过期、返回登录页面或返回内容格式不适用，都可能使列表无法形成。不要把订阅地址当成普通服务器 Host。手动添加时，则对照原始资料检查 Type、Host、Port、认证与传输字段，尤其留意粘贴造成的空格和字符遗漏。
如需向原资料提供方询问，只描述失败阶段与提示内容，必要时提交经过遮盖的字段截图。不要把完整订阅 URL、密码或私钥发到公开位置。删除并重建条目前先确认原始资料仍可取得，否则可能丢失唯一保存的连接信息。
测试失败或连接后无法访问
先确认设备本身有基础网络连接，再检查目标条目。打开 Settings 查看 Test Method，理解当前 Connectivity Test 使用的检查方式；更换测试方法只改变测试口径，不会修复错误参数。若换一种网络后表现不同，应记录网络差异，不要同时修改服务器配置，否则无法判断问题来自哪一侧。
如果系统连接能保持，但实际页面失败，按步骤 04 对照代理(Proxy)与配置(Config)。前者成功而后者失败时，检查当前 Config 的规则指向、DNS 与相关设置。遇到证书或服务器名称相关错误，应回到资料核对 TLS 参数，不要把跳过验证作为常规修复办法。涉及 TCP、UDP 或特定传输的细节，留到确定问题范围后再逐项处理。
自动连接异常与诊断记录
在 Settings 中找到 On Demand，检查是否设置了按网络条件触发的连接行为。它与手动打开 Home 开关不是同一个控制入口；如果正在排查意外重连，可以先记录原设置，再暂时停止相关自动触发条件进行对照。Today Widget 属于便捷入口，不能代替 Home 中的状态确认。
需要更多线索时，查看 Diagnostics 及可用日志，重点保留错误类型、发生时的姿态与网络条件。日志可能包含域名、地址和连接标识，分享前应隐藏敏感内容；不要为了收集信息而长期保留不必要的详细记录。也不要同时改动 Proxy、TCP、UDP 等多项设置，它们不是通用的“连接修复”开关。
完成一项修改后，返回 Home 按需重新连接，并用同一个目标重复验证。如果仍然失败，将问题归类为“导入”“连接建立”“服务器访问”或“规则处理”，再到FAQ查对应说明。需要理解 DNS、On Demand、测试方式和日志设置时，继续阅读Settings 设置详解。当导入、姿态、连接与实际访问四项均已确认，本页的首次上手流程即已完成。
