1. Add Server / Subscribe：添加与导入
先区分手上的资料属于哪一种：一整条用于更新服务器列表的链接，按订阅导入；一个服务器的地址、端口、协议和认证信息，按单个服务器添加。两种方式都从 Home 开始，不要把订阅链接填进服务器地址栏，也不要把仅包含服务器信息的文字当成订阅链接提交。
已有订阅链接：选择 Subscribe
打开 Shadowrocket，进入 Home，点击右上角的添加入口，进入 Add Server。在 Type 中选择 Subscribe，将完整订阅链接填入 URL，并用 Remarks 写一个便于辨认的名称，例如“个人订阅”。名称只用于本地识别，不会修复链接，也不会改变服务器本身。保存前检查链接开头、路径和查询参数是否完整，尤其不要漏掉问号后面的内容。
保存后返回 Home，等待订阅请求完成，确认对应分组内出现服务器条目。订阅名称出现但组内没有条目，不等于导入已经成功；应先检查是否仍在更新、是否提示请求失败，再回到原始资料核对链接。部分订阅地址在浏览器中显示的是文本或一串编码内容，不应只因页面没有普通网页排版就判断链接失效。
如果资料通过消息或文档传递，复制时留意行尾空格、换行、中文标点和被截断的尾部参数。订阅链接往往带有访问凭据，不要把完整地址放进公开截图、文章评论或测试记录。需要确认订阅是否有效时，应通过原有服务渠道核对状态，而不是反复创建同一份订阅。
已有单个服务器：按协议逐项填写
同样进入 Add Server，在 Type 选择资料明确指定的协议，再填写服务器地址、端口与认证字段。不同协议需要的字段不一样：密码、标识符、传输方式和 TLS 相关设置不能相互替代。先按原始信息完整填写，不要因为某个字段不熟悉，就把它留空或照其他服务器的设置补上。
服务器地址栏通常只填写提供的主机名或 IP 地址；端口放在对应端口字段，不要将完整网页地址连同路径粘贴进去。若已有可导入的服务器链接，或资料以二维码形式提供，也可使用应用对应的导入入口或 Scan QR Code；导入后仍需打开条目核对协议、地址与端口，而不是只看名称是否正确。
保存并回到 Home 后，选择准备使用的服务器，核对当前选中标记。列表里存在多个条目，并不表示它们会同时承担请求；首次测试先选定一个，记下名称，后续测试和访问都围绕同一条目进行。此时先不要开启 On Demand，避免自动连接条件干扰手动验证。
2. Global Routing：选择连接姿态
服务器导入后，下一步是决定请求如何处理。在 Home 打开 Global Routing，核对当前选择。三种姿态分别是配置(Config)/代理(Proxy)/直连(Direct)：它们改变的是路由决策方式，不会替你修正服务器密码，也不会让失效的订阅恢复有效。
配置(Config)：由当前配置决定策略
配置(Config)按照当前生效配置的规则处理请求。进入 Config，先确认实际启用的是哪一份文件，再查看它包含的规则和策略。仅导入一份服务器订阅，不能据此认定所有目标都已经有了符合预期的分流规则；服务器列表与规则配置承担的是不同任务，应分别核对。
阅读规则时关注匹配条件、顺序和最后的处理方式。DOMAIN-SUFFIX 用于域名后缀匹配，IP-CIDR 用于地址网段匹配，FINAL 表示前面的规则未匹配时采用的策略。下方只是规则语法示例，不是需要直接导入的完整配置；example.com 是示例域名，不代表实际测试目标。
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY其中 PROXY、DIRECT 是策略关键字，不是服务器名称。PROXY 表示交给代理策略处理，DIRECT 表示直接连接；如果规则或策略组另有指定，还需要继续核对其实际选择。不要只看到一行规则存在，就断定请求必然由它命中：前面的规则、当前生效文件和请求所用的域名都可能影响结果。
代理(Proxy)：用于单独核对代理链路
代理(Proxy)将适用流量交给当前代理策略。首次排查时，可以短暂使用这一姿态，将“服务器能否工作”与“规则是否按预期匹配”分开观察。它不是所有应用行为的统一证明；系统流量范围、当前网络和目标服务自身状态仍会影响访问。测试结束后，如需规则分流，记得切回配置(Config)。
直连(Direct)：核对直接访问基线
直连(Direct)用于直接连接，不能作为代理链路已经生效的证据。它适合对照当前网络能否直接访问某个目标。假如切到直连(Direct)后页面能够打开，只能说明该次直接访问可用，不能证明服务器参数正确。下一步连接前，请再看一遍 Global Routing，避免把临时测试姿态当成最终设置。
3. Home：开启连接与系统授权
回到 Home，按顺序核对当前服务器、Global Routing 和当前网络。首次操作建议保持网络不变，例如先在同一 Wi-Fi 下完成一轮测试，再单独测试蜂窝网络。不要在服务器还没选好时连续开关连接，也不要同时更换服务器、网络和规则文件，否则失败时难以判断是哪一项发生了变化。
打开 Home 顶部的连接开关。首次连接时，系统可能提示添加 VPN 配置；这是应用建立系统网络连接所需的授权步骤。阅读弹窗中的应用名称和说明，确认是本次操作触发后，再按系统提示完成确认与身份验证。授权过程在系统界面完成，不需要把设备解锁信息或 Apple 账户凭据填写到服务器条目中。
返回 Shadowrocket 后，观察开关与连接状态是否保持。若开关立即恢复关闭，先检查系统授权是否取消、是否有待处理的提示，以及是否存在其他正在使用的 VPN 配置。可在系统 Settings 中查看相关 VPN 状态，再回到应用尝试；不要为了让开关保持开启而随意删除不清楚用途的系统配置。
连接状态建立，只表示系统连接通道已经启动，并不证明选中的服务器能访问所有目标。错误的密码、端口或传输参数仍可能使实际请求失败。因此，完成授权后应立即进行下一节的测试，而不是把状态栏标识当作最终结果。iPhone 与 iPad 的状态栏呈现会受设备和系统界面影响，以应用和系统显示的连接状态交叉核对。
需要结束本轮测试时，在 Home 关闭连接开关，并确认系统连接已结束。若之后出现自动连接，再核对 On Demand 是否已经开启。首次手动流程完成前，保持自动连接条件不参与测试，能够减少“刚关闭又连接”这类现象造成的误判。
4. Connectivity Test：验证是否生效
验证分为三个层次：服务器测试是否有结果、系统连接是否建立、实际请求是否走到预期策略。三者分别回答不同问题，不能相互替代。先在 Home 使用 Connectivity Test 测试已选中的服务器，等待结果稳定后再发起实际访问；测试期间不要一边切换条目，一边把前一个结果归到后一个服务器上。
Connectivity Test 的结果取决于测试方式和测试目标。有数值只说明该项测试取得了响应，不等于所有网页和应用请求都可用；timeout 也需要结合当前测试方式和目标判断，不能仅凭一次结果就认定所有服务器都已失效。首次操作应优先关注当前选中的条目，避免把整个列表的结果混在一起比较。
随后打开浏览器，访问一个你已知当前网络通常能够正常打开的页面，再访问需要核对策略的目标。每次重新发起请求，不要只看已经加载完成的旧页面或缓存内容。记录“哪个目标、哪种网络、哪个服务器、什么 Global Routing 姿态”，比只记录“能用”或“不能用”更有助于下一步排查。
使用配置(Config)时，可结合应用 Data 中可用的连接记录，查找刚刚发起的请求，核对记录所示的目标、规则与策略。不同记录可提供的信息可能不同；看不到策略细节时，不要自行推断。重点是确认实际使用的是当前配置，并判断请求采用 DIRECT、PROXY 或其他配置中指定的策略是否符合原意。
如果代理(Proxy)下可以访问，而配置(Config)下不符合预期，先回到 Config 检查规则顺序和策略选择，不要立即改服务器认证参数。如果两种姿态下都失败，而直连(Direct)可以打开对照页面，则继续检查服务器与连接路径。这个对照只能缩小范围，仍需结合具体目标和错误记录得出结论。
5. 常见失败点：按顺序定位
排查从最早失败的一步开始。列表为空时，先处理导入；条目存在但测试失败时，先处理服务器参数；连接建立后仅部分目标异常时，再处理规则与目标访问。先保留原始配置和现有条目，每次只改一项，复测后记录结果。连续删除、重新导入与更换规则，往往会让原本单一的问题变得难以复核。
订阅保存成功，但列表为空
先回到 Subscribe 条目检查 URL 是否完整，确认复制的是订阅地址，而不是账户页面或介绍页面。查看更新是否完成，核对当前网络是否能请求该地址，再通过你原有的服务渠道确认订阅状态与内容是否有效。若更新返回错误或空内容，重复添加同一链接通常不能解决问题；应先确认错误发生在请求阶段还是内容解析阶段。
如果更新前已有可用条目，先保留当前资料，不要为了重新获取列表而批量删除。记录失败发生在手动更新后、网络切换后还是重新打开应用后，可帮助判断问题是否与更新时机有关。进一步排查见订阅更新后节点为空的自查顺序。
Connectivity Test 显示 timeout
先确认测试对象确实是当前选中的服务器，然后逐项核对地址、端口、协议、认证与传输参数。检查设备日期和时间是否正确，尤其在需要 TLS 或时间相关认证时，不正确的系统时间可能导致失败。再换一种实际网络复测一次，区分当前接入网络与服务器本身的问题；切换网络后仍要保持同一服务器和同一测试目标。
不要凭猜测不断替换端口、关闭认证或修改 TLS 设置。参数应以你已有的服务器资料为准，服务状态应通过原有服务渠道确认。需要更细的记录方法时，可阅读节点超时与连接失败排查，按顺序保存结果。
连接已建立，但网页打不开
先确认原始网络本身可以访问对照页面，排除 Wi-Fi 尚未完成网络登录、蜂窝数据不可用等基础问题。然后核对 Global Routing：如果处于直连(Direct)，不要期待请求按代理策略处理；如果处于配置(Config)，检查当前生效文件和匹配策略。只有在明确看到域名解析相关错误时，再针对 DNS 设置排查，避免同时更改服务器、规则与 DNS。
若只有单个目标失败，先用其他已知可用目标进行对照，并查看该次请求记录。目标服务自身异常、规则命中不符、服务器访问受限和认证失败可能呈现不同结果，不能统一归结为“应用未连接”。若仅某个应用异常，重新发起该应用的网络请求，并注意其已有连接或缓存可能让观察结果滞后。
切换设置后结果混乱
回到最近一次有明确记录的状态：恢复原服务器，恢复之前的 Global Routing 与配置文件，关闭本轮新增的 On Demand 条件，再从验证步骤重新测试。不要把一次临时成功当成设置已经稳定；在相同条件下重复验证，再分别检查网络切换后的表现。
排查记录只保留时间、网络类型、服务器本地名称、姿态与错误现象即可。向他人说明问题前，遮住订阅完整链接、密码、密钥和其他认证字段；分享配置片段时也应先检查是否包含这些内容。需要重新核对购买、商店获取或换机恢复流程，请转到安装指南，不要把应用获取问题与已有服务器的连接问题混为一谈。