1. Add Server：添加与导入
打开 Shadowrocket，进入 Home。先查看 SERVER 列表：如果列表中已经有你准备使用的服务器，不必重复添加，可以直接核对信息并选择默认服务器。如果列表为空，或已有条目并非本次要使用的连接，点页面右上方的添加入口，进入 Add Server。接下来按手中信息的类型选择一种导入方式，不要把订阅链接当作服务器地址填写。
已有订阅链接：选择 Subscribe
在 Add Server 中打开 Type，选择 Subscribe，再把从你的服务商处获取的订阅链接粘贴到 URL。链接需要完整保留，尤其是末尾参数；复制时避免带入说明文字、换行或首尾空格。备注只用于辨认这组订阅，可以写容易识别的名称。核对后保存，返回 Home，等待订阅请求完成，再查看对应分组是否出现服务器条目。
保存订阅入口和成功获取服务器列表不是同一件事。若只看到订阅名称，没有可选择的服务器，先查看更新是否报错，而不是继续打开连接开关。重新从原始来源复制链接，并确认订阅仍然有效；重复创建同一订阅通常不能解决地址错误。后续需要更新时，对该订阅使用更新操作，完成后再次检查列表，不要只凭操作按钮已点过就认定更新成功。
已有单台信息：核对协议与字段
如果拿到的是单台服务器参数，在 Add Server 的 Type 中选择与资料完全一致的协议，再填写服务器地址、端口和对应的认证信息。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 的字段并不相同，不能只更换协议名称而沿用其他字段。加密方式、传输方式、TLS 与服务器名称等选项，均应按原始资料核对，不确定时向你的服务商确认。
已有可识别的分享内容或二维码时，可以使用客户端提供的导入入口；二维码可通过 Scan QR Code 读取。导入后仍应打开条目核对协议和服务器地址，确认它与资料一致。扫码只是输入方式，并不证明参数有效。不要为了凑齐字段自行填写猜测值，也不要把本应作为认证信息的内容放到备注或地址栏。
回到 SERVER：选择默认服务器
保存后返回 Home，在 SERVER 列表中点选本次要使用的服务器，确认该条目出现默认选择标记，即 DOT。备注相近的条目可能属于不同分组，选择时同时核对所属订阅与协议。默认服务器决定需要代理的请求使用哪个连接入口；列表中存在条目，并不等于它已经成为当前默认。到这里先不要修改多组参数，下一步只确定 Global Routing 的处理方式。
2. Global Routing：选择路由姿态
在 Home 点 Global Routing，选择当前需要的处理方式。三种姿态分别是配置(Config)、代理(Proxy)、直连(Direct)。它们控制请求如何处理，不负责补齐服务器资料，也不会让失效的订阅恢复。首次上手时，先把“服务器是否可用”和“规则是否正确”分开验证，通常更容易定位问题。
代理(Proxy)：先检查服务器连通性
代理(Proxy)让由客户端接管的请求按代理方式处理，适合在首次连接时临时检查默认服务器是否可用。选定后返回 Home，再看一次默认服务器标记。这个模式不是某种额外加速开关，也不能保证设备上的每一种流量都经过同一路径；系统流量与应用行为仍可能存在差异。此时不必先编辑规则，先完成连接与实际访问测试。
配置(Config)：按当前配置处理请求
配置(Config)按照当前配置中的规则与策略处理请求。需要使用这一姿态时，先进入 Config，确认准备使用的配置已经设为当前配置，而不是只保存在列表中。配置文件和服务器订阅有不同作用：前者描述路由、DNS 等行为，后者通常用于维护服务器列表。成功导入订阅不会自动证明当前配置的规则适合你的使用目标。
如果已经有可用配置，先保持原样，连接成功后再逐项调整。规则按顺序匹配，较前的条件可能先决定请求去向；即使默认服务器正常，匹配 DIRECT 的请求也不会按代理策略处理。本文不展开规则编辑，涉及 DOMAIN-SUFFIX、IP-CIDR、FINAL 的完整说明请查看配置文件章节，避免首次连接时同时修改 DNS、规则和服务器参数。
直连(Direct)：确认直接访问路径
直连(Direct)按直连方式处理请求，不使用所选代理服务器承载这些请求。它可以用于对照当前网络的直接访问情况，但不能用来验证服务器的代理连接是否成功。选择 Direct 后看到连接状态或页面正常打开，不能据此判断代理服务器可用。若目标是首次检查已有服务器，应切回 Proxy，或确认 Config 中对应请求确实命中代理策略。
完成选择后，记住当前模式以及选择理由。测试期间不要连续来回切换三种姿态，否则同一个页面的两次结果可能来自不同路径。下一步只打开连接开关；如果后来需要改模式，修改后重新连接并再次验证，不沿用前一次测试结论。
3. Home：打开连接开关
回到 Home，按顺序检查两处：SERVER 中的默认服务器是否正确，Global Routing 是否是刚选定的姿态。订阅包含多台服务器时，先固定一台进行测试，不要在连接过程中同时切换条目。确认后打开页面上方的连接开关。未连接时可看到 Not Connected；连接过程中等待状态更新，不要快速重复开关，以免混淆系统授权与实际连接过程。
首次授权：允许添加 VPN 配置
第一次建立连接时，系统可能请求添加 VPN 配置。这个请求用于让 Shadowrocket 通过系统提供的网络能力处理流量，仅涉及系统权限，不表示服务器已经连接成功。核对请求由 Shadowrocket 发起后，选择允许，并按设备提示完成身份验证。系统权限弹窗的文字可能随系统语言变化，本教程保留客户端内的英文界面词，不把系统弹窗当成固定不变的客户端页面。
如果之前取消了授权，连接开关可能无法正常保持开启。回到客户端重新发起连接，留意是否再次出现系统请求。设备受管理或受到系统限制时，可能无法添加或启用 VPN 配置，应先确认设备允许该操作，不要靠重复导入服务器解决权限问题。授权完成后返回 Home，再查看连接开关与状态，而不是停留在系统设置页面判断结果。
连接状态：先确认，再离开页面
连接开关保持开启、客户端显示连接状态，说明系统网络连接已建立到相应阶段，但还需要测试实际请求。VPN 状态标识也不能单独证明服务器认证、DNS 解析和目标访问全部正常。若开关立即回落，或客户端显示连接错误，先记录错误文字与当前协议，再进入末尾的排查步骤。不要在错误尚未确认时就开启 On Demand，以免自动重连让观察过程变得复杂。
首次手动连接成功后，再考虑 Settings 中的 On Demand。按需连接条件解决的是何时触发连接，不是怎样修复一个不可用服务器。也应避免同时让多个 VPN 配置接管当前连接；先确认当前活动配置属于 Shadowrocket，再继续验证。现在保持默认服务器和模式不变，进入 Connectivity Test 与实际访问检查。
4. Connectivity Test：验证生效
在 Home 点 Connectivity Test，观察当前条目的测试结果。它用于辅助判断连通性，不是完整的网络质量报告。不同测试方式可能检查不同目标或阶段，因此某项测试有结果，不代表所有页面都能访问；测试超时也需要结合实际请求判断。先确认你读到的是当前默认服务器的结果，而不是此前测试其他条目留下的显示。
把测试结果与实际访问放在一起看
完成测试后，打开你预期使用的一个页面，或执行一次明确的应用请求。选择平时能够辨认结果的目标，观察是否加载完成，而不只是看连接图标。需要对照连接前后的差异时，保持相同网络、相同目标和相同操作，分别测试；一次只改变客户端连接状态。页面缓存可能让旧内容继续显示，必要时刷新并发起新的请求，不用已加载页面代替验证。
如果当前使用 Proxy，实际访问失败时优先检查服务器、DNS 与当前网络。如果当前使用 Config，则还需要确认请求应该命中哪条规则。目标能打开不等于它走了代理：规则可能指定 DIRECT。反过来，一个目标失败也不能立即说明所有服务器失效，目标本身、认证状态和应用内连接方式都可能影响结果。
Data：辅助确认请求路径
回到客户端，查看 Data 中可用的流量或请求记录。结合目标域名、发生时间与策略信息判断刚才的请求是否被记录，以及是否按预期处理。记录中的 DIRECT、PROXY 等信息应与当前模式和配置一起理解，不能只看总流量有变化。部分请求可能使用已有连接，或不以你预期的域名形式出现；没有看到某个名称时，先重新发起请求，再检查相关记录。
验证成功应至少包含三个结果：Home 的连接状态稳定，选定服务器能够完成相关测试，预期页面或应用请求正常完成。需要规则分流时，再补充确认该请求的策略符合配置。网络图标、测试数值和流量计数分别反映不同层面，不把任何一个单独当作最终结论，也不根据一次测试就频繁替换所有参数。
完成验证后保留这套可用组合：当前服务器、Global Routing 姿态和当前配置。以后调整设置时，以它作为对照，每次修改后重复同样的验证动作。若要进一步理解路由记录与 DNS 的关系，可以继续阅读Settings 常用项说明；如果结果不一致，按下一步顺序排查。
5. 首次失败：按顺序检查
先区分失败发生在哪一步：没有服务器条目、连接开关不能保持开启、Connectivity Test 超时，还是连接后只有部分请求失败。这四种情况的检查入口不同。保留错误文字，记录当前网络、默认服务器与 Global Routing。每次只改变一个条件，测试后再决定下一步；同时更新订阅、换服务器、改模式和改 DNS，会让有效线索丢失。
列表为空：先检查导入结果
若 SERVER 没有可选条目，回到订阅入口确认 URL 完整，检查本次更新是否成功。订阅地址可能包含认证参数，缺少末尾内容就可能无法获取列表。先用当前网络完成一次更新，区分请求失败与返回内容无法识别；有明确错误时按错误处理。订阅有效期、访问权限和返回格式应向你的服务商核对，不用不断建立同名订阅来代替检查。
无法连接：检查选择、权限和协议参数
如果已有条目但连接失败，先确认默认标记，再检查 VPN 配置权限。之后打开服务器条目，逐项对照原始信息：地址、端口、协议、认证信息，以及该协议需要的传输和 TLS 参数。端口能够响应不等于认证信息正确；协议选择正确也不等于其附加字段匹配。不要为了通过测试随意关闭证书验证或改写服务器名称，应以正确参数恢复连接。
同时检查设备日期与时间是否准确。系统时间偏差可能影响证书与认证过程，尤其是启用 TLS 的连接。确认时间后重新连接并测试。若同一订阅中有另一台已知可用服务器，可只切换默认服务器做对照，保持其他设置不动；一台失败、另一台正常时，优先检查失败条目的信息与服务状态。
已连接但访问失败：隔离规则与网络因素
在 Config 下失败时，可以临时切到 Proxy，用相同服务器和相同目标重新测试。如果 Proxy 正常而 Config 异常，优先回到当前配置检查规则命中、策略引用与 DNS 设置；这不是要求长期使用 Proxy，而是把问题缩小到配置层。若两种姿态都失败，先核对服务器参数与当前网络，再考虑配置细节，不急着重写整份规则。
必要时在设备允许的情况下，对照 Wi-Fi 与蜂窝网络。只切换网络，保留同一服务器、模式和目标；结果不同说明网络环境可能参与了问题，但不能直接证明是哪一个环节。某些 Wi-Fi 需要先完成网络登录，未完成时订阅更新和服务器连接都可能失败。确认普通页面能够直接访问，再重新测试客户端。
保留可用状态，再处理进阶设置
如果只有某个应用或目标失败，先检查该目标的请求记录，不要删除全部服务器或重置所有设置。若问题在订阅更新后出现，重新确认默认服务器仍指向有效条目；更新可能改变列表内容，旧名称相同也不一定代表参数完全相同。配置更新后出现异常，则优先对照备份，确认当前 Config 是否仍是原来的可用配置。
需要继续排查时，整理不含敏感信息的现象说明：失败步骤、错误文字、所用协议、Global Routing 姿态，以及不同网络下是否一致。涉及密码、密钥或完整订阅地址的内容不要公开。常见原因与对应处理见疑难解答；日常更新、备份与长期维护见使用手册的维护章节。