OFFICIAL MANUAL / FIRST CONNECTION
按导入、模式、授权、验证的顺序操作。先完成一次可重复的连接，再调整规则与自动连接设置。本篇以 iPhone 与 iPad 为主，入口名称保留界面英文原文。
Global RoutingSTEP 01 / IMPORT
先判断手中的资料是订阅地址、单个服务器参数，还是二维码。一次只采用一种入口，避免重复导入后选错记录。
打开 Shadowrocket，进入 Config 页，查找 Subscribe 相关入口。将自己已有的完整订阅链接填入对应地址栏，确认后执行导入或更新。若当前界面通过 Add Server 提供 Subscribe 类型入口，则从该入口填写同一份资料；不同界面布局下，仍应以 Subscribe 标识和实际字段为准，不要把订阅地址填入单个服务器的 Host。
复制地址时保留完整内容，尤其是问号之后的参数。聊天工具中的换行、前后空格、被截断的尾部字符，都可能让原本有效的地址无法识别。地址属于个人配置资料，不要贴到公开页面，也不要为了排错随意交给陌生人。导入完成后回到 Home，在 SERVER 分组查看是否出现记录，先确认名称与数量变化，再继续下一步。
在 Home 的 SERVER 分组点击 Add Server，先选 Type，再逐项填写 Host、Port 和相应认证字段。官方截图展示的是包含 Password、Method 的一种填写形式；选择其他 Type 后，字段可能变化，不应把截图当作所有协议通用的表单。Host 填服务器地址，Port 填对应端口，认证方式和加密参数按自己的资料逐字核对。
如果资料包含 TLS、SNI 或其他传输设置，应进入对应选项核对，不能仅填写地址和端口就认为已经完成。不要凭经验替换 Method，也不要为了让测试通过而随意改变证书校验设置。填写后保存，返回 Home 重新打开该记录检查一次，确认关键字段没有遗漏或被自动识别成其他类型。
已有二维码时可使用 Scan QR Code，并按系统提示授予所需权限；二维码必须包含可识别的配置内容。已有单条配置链接时，可在复制后按应用提供的剪贴板识别提示导入。Import from Cloud JSON 适用于相应 JSON 配置资料，不是任意订阅地址的替代入口。无法判断格式时，先核对资料说明，不要在多个入口反复尝试同一段内容。
这一阶段的完成标准是“记录已保存且参数可复核”，不是“网络已经可用”。订阅可能包含多个服务器，也可能仅提供服务器列表而不包含分流规则。下一步先决定 Global Routing 的处理方式，再从列表中选择要使用的服务器。订阅更新失败但旧记录仍在时，先保留现场，避免删除后失去对照。
STEP 02 / GLOBAL ROUTING
服务器决定代理请求使用哪个连接；Global Routing 决定请求按什么方式处理。这是两件不同的事。
回到 Home，点击 Global Routing 查看当前选择。三种姿态分别是配置(Config)、代理(Proxy)、直连(Direct)。不要只根据连接开关判断路由是否正确：即使开关已经打开，Direct 或规则中的 DIRECT 仍可能让相关请求直接访问。开始测试前记下当前模式，后续对照结果才有意义。
选择配置(Config)时，进入 Config 页确认当前生效的配置文件，再检查 Rule 分段。官方截图中的 General、Rule、Hosts、URL Rewrite、HTTPS Decryption 是配置编辑分段；它们不是首次连接必须逐一开启的项目。初次操作主要确认 Rule 内容与当前配置，不要顺手修改无关项目，也不必为了连接验证去启用 HTTPS Decryption。
规则通常自上而下匹配，命中后按对应策略处理。例如 DOMAIN-SUFFIX 根据域名后缀匹配，DIRECT 表示直接访问，PROXY 表示交给代理策略，REJECT 表示拒绝。FINAL 用于前面的规则均未命中时兜底。下面仅是语法示例，不是针对你的网络准备的完整配置；看懂即可，不需要照抄替换当前文件。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY选择代理(Proxy)，是让受当前模式处理的请求按代理路径执行，适合短暂对照服务器连接是否正常；它不代表所有网站一定能访问。选择直连(Direct)，则用于直接访问的对照，不能拿它验证服务器是否有效。进行模式切换时只更改这一项，使用相同网页重复测试，才能区分问题来自规则还是代理连接。
如果 Proxy 下访问正常、Config 下同一网页失败，应回到当前配置检查命中的规则与策略，而不是马上重新导入订阅。如果两者都失败，再向连接与服务器参数方向排查。完成对照后恢复日常所需模式。有关规则顺序、策略与 DNS 的细节，可继续查阅名词解释与排查手册，本篇先不扩展复杂配置。
STEP 03 / CONNECT
先选中要使用的记录，再操作顶部开关。首次连接需要完成系统 VPN 配置授权。
在 Home 的 SERVER 分组中，点选本次准备使用的服务器，核对选中标记落在正确记录上。订阅里出现多个相似名称时，打开详情确认地址与类型，不要只看名称猜测。随后再次查看 Global Routing，确认它与上一步的测试计划一致，再打开 Home 顶部连接开关。
未连接时可看到 Not Connected 等状态文字。首次开启时，系统可能提示 Shadowrocket 请求添加 VPN 配置。这一步是在设备上建立供应用使用的系统网络配置，不是导入订阅，也不会替你补全服务器参数。确认提示来自当前操作后选择允许，并按设备要求完成认证，然后返回应用继续查看状态。
若此前取消授权，先返回 Home 再尝试打开开关，并查看是否重新出现提示。若开关立刻回落或状态始终未变化，进入系统设置的 VPN 配置位置检查相关记录是否存在。不同系统版本的设置层级可能不同，可使用系统设置内的搜索查找 VPN；不要在没有记录原状的情况下批量删除已有配置。
iPhone 与 iPad 的系统授权逻辑相同，较宽屏幕上的列表与详情排列可能不同。判断依据仍是所选服务器、当前 Global Routing 和连接状态，不是按钮所在的屏幕位置。若设备受组织管理，部分网络权限可能受管理策略限制，应先核对设备管理要求，不要反复修改服务器信息来处理系统权限问题。
顶部状态发生变化，只说明应用与系统连接流程已经推进，不能单独证明目标网页能正常打开。也不要在开关刚打开后连续点按，让连接和断开操作交错。等待本次状态变化完成，保持当前服务器与模式不动，然后进入下一步，用 Connectivity Test 和实际访问分别验证。
STEP 04 / VALIDATE
把“开关已打开”“测试有响应”“网页可访问”分开记录，避免把其中一个结果当作全部结论。
保持刚才选定的服务器和模式，在 Home 点击 Connectivity Test，观察测试是否返回结果。测试超时是排查线索，但不直接等同于所有业务请求都会失败；测试有响应，也不等于认证、DNS、规则和目标网站都正常。测试使用的方法与目标会影响结果，因此先记录当下表现，不要据此一次性删除全部记录。
随后打开浏览器，访问自己熟悉且当前需要使用的网页。先看能否完成加载，再检查页面中的普通链接是否可以继续打开。仅看到缓存中的首页不足以验证新请求，可以重新加载页面或打开同站点的另一页。不要使用只有应用内缓存内容的画面来判断网络已经恢复。
若网页能访问但应用内某项业务失败，暂时保留当前配置，分别记录发生问题的应用、操作和网络环境。单个业务还可能受其登录状态、目标服务状态等因素影响，不要立即把所有异常归结为服务器连接。用同一网络下的重复操作确认症状是否稳定出现，再进入排错。
Config 下的某个网页访问成功，可能是命中了 DIRECT，因此不能单凭“能打开”证明代理路径生效。需要验证代理路径时，按上一步的方法暂时切到 Proxy，在同一服务器、同一网络下访问同一目标。对照结束恢复原模式，并记录两次结果是否不同。
如果你熟悉应用中的连接记录，可结合请求域名与对应策略进一步确认；只记录和当前问题相关的片段即可。规则里写了 PROXY，并不表示所有请求都会命中这一行，排在前面的规则可能已经完成匹配。遇到“测试正常但某个域名失败”，优先区分规则命中与 DNS，再检查目标本身，而不是反复开关连接。
本步骤的完成标准是：你能说明所用服务器、Global Routing 模式，以及实际访问结果。若需要在 Wi-Fi 与蜂窝网络之间对照，先完成一组记录，再切换网络重复相同流程；测试期间同时更换服务器、网络和模式，会使结果失去可比性。
STEP 05 / SETTINGS & DIAGNOSTICS
先定位失败发生在哪里，再调整对应一项。Settings 是核对工具的入口，不是需要全部改动的清单。
没有生成记录时，先检查资料类型与导入入口是否匹配，再核对链接完整性、有效状态和当前普通网络。能打开订阅地址不一定意味着返回了可识别的配置内容；返回登录页、错误提示或空内容时，都可能无法完成导入。不要把订阅中的私密参数放进公开截图，需要核对资料有效性时联系你已有服务的提供方。
返回连接步骤，确认系统 VPN 配置授权已完成，并检查其他正在运行的 VPN 连接是否影响本次操作。若系统 VPN 配置曾被删除，应用可能需要重新请求授权。先记录现有配置与提示原文，再按系统流程处理，不要将“重新安装”作为第一项操作；重装之前尤其要确认已有配置可以恢复。
进入 Settings 查看 Test Method，确认当前测试方式，再回到相同条件复测。某种测试方式不返回结果时，仍需结合实际访问判断，不要把某个测试数值当作唯一依据。若多次实际访问也失败，回到 Add Server 核对 Type、Host、Port、认证与 TLS 相关参数；逐项对照原资料，不要随机修改端口或密码。
若 Proxy 正常而 Config 失败，优先检查当前配置的 Rule 与 DNS。若切换网络后才出现异常，记录 Wi-Fi 或蜂窝网络下的差异，再检查网络可达性。Settings 中的 Proxy、TCP、UDP 等设置具有各自用途，不建议初次排错时全部调整；保持默认或原有配置，通常更容易定位真正改变了结果的那一项。
如果手动断开后又出现连接，查看 Settings 中 On Demand 的状态及现有条件。On Demand 用于按条件触发连接，首次验证阶段可先记录原值，必要时暂时关闭再做手动对照，结束后按自己的需求恢复。不要把自动触发误判为顶部开关失灵，也不要在尚未确认手动连接可用时先添加复杂条件。
需要更多线索时进入 Diagnostics，查看与你本次操作对应的诊断信息。记录失败发生的步骤、网络类型、模式、错误原文和可复现操作即可。对外提供截图或日志前，遮盖订阅地址、密码、认证字段及个人网络信息。日志能帮助缩小范围，但公开完整配置通常没有必要。
到这里仍无法定位时，按症状继续阅读连接故障排查手册；购买、授权与常见操作疑问可查FAQ；不确定字段含义时查名词解释。保留这次测试的服务器、模式和结果，进入长文排查时就不必从头重复所有步骤。
