Connectivity Test
观察当前测试方式对应的可达性，不将单个结果扩大为所有请求都可用。
OFFICIAL MANUAL / GETTING STARTED
Shadowrocket 使用教程
导入配置与首次连接
按添加、模式、连接、验证、排错的顺序操作。先让一个已有配置完成实际请求，再逐步调整规则与设置。
STEP 01 / ADD SERVER
添加服务器或导入已有订阅
先判断资料属于单个服务器参数还是订阅链接。两种资料使用不同入口，不能把完整订阅链接填进 Host。
手动填写：Home → Add Server
在 Home 的 SERVER 分组找到 Add Server，进入服务器编辑页。先点 Type，选择与你已有资料一致的协议，再填写 Host、Port 及对应的认证字段。Type 会决定后续出现哪些输入项，因此应先选协议，再核对参数；不要先把所有内容填完，最后才切换 Type。
以 Shadowsocks 为例，Host 填服务器域名或 IP，Port 填端口数字，Password 和 Method 分别对应已有资料中的密码与加密方法。Host 不是网页地址，不应附带网页路径；Port 也不要连同冒号一起粘贴。若资料写的是 Trojan、VMess、VLESS 或其他协议，应切换到相应 Type 后按字段填写，不能照搬 Shadowsocks 的字段组合。
填写完成后，逐项检查首尾空格、大小写和数字，再保存并返回 Home。看到新条目只说明信息已保存，还没有证明服务器能够连接。先核对条目的协议、地址与端口，再选中准备使用的条目。协议字段含义较多时，可先查术语手册，不确定的值应向自己的服务商核实，不要凭经验补齐。
批量导入：Subscribe 与已有链接
已有订阅链接时，在 Config 页查找 Subscribe 入口，粘贴完整链接并确认导入；不同界面布局下入口位置可能有所调整，以应用内实际标签为准。保留链接原有路径和查询参数，不要删去看似多余的字符。订阅链接可能包含认证信息，只粘贴到对应输入框，不要发到公开留言或截图中。
导入后等待请求完成，再返回 Home 检查 SERVER 分组是否出现预期条目。列表为空时，先看是否有导入或网络错误，不要连续创建多个相同订阅。订阅导入用于取得服务器列表，Config 配置文件则还可能包含 Rule 等内容；列表已经出现，不等于分流规则也已经配置好，下一步仍需单独核对 Global Routing。
如果已有的是服务器二维码，可从 Scan QR Code 识别并核对识别结果；剪贴板中的受支持链接则按应用提示导入。Import from Cloud JSON 是另一种导入入口，只有资料格式与该入口要求一致时才使用。几种入口不需要全部操作，选择与你手中资料匹配的一种即可。
STEP 02 / GLOBAL ROUTING
选择 Global Routing 三姿态
回到 Home 打开 Global Routing。这里决定请求采用哪种处理方式，不是服务器协议选择器。
在 Global Routing 中选择配置(Config)、代理(Proxy)或直连(Direct)，确认后返回 Home，核对当前显示的选项。首次使用时，应先明确自己的验证目标：需要按规则区分请求，使用 Config；需要临时观察所选代理服务器能否处理请求，可用 Proxy 进行对照；只检查本地网络基础访问时，可用 Direct。三种姿态不是逐个开启的开关，只选择当前所需的一种。
| 姿态 | 处理依据 | 使用前检查 |
|---|---|---|
| 配置(Config) | 按当前配置的规则及策略处理请求 | 配置文件是否选中，策略引用是否有效 |
| 代理(Proxy) | 以代理方式处理请求，便于检查所选服务器 | 当前服务器是否正确，实际请求是否成功 |
| 直连(Direct) | 以直连方式处理请求 | 本地网络本身是否可用 |
使用 Config 前核对 Rule
进入 Config，确认准备使用的配置文件，再打开其编辑内容。官方截图中的 General、Rule、Hosts、URL Rewrite 与 HTTPS Decryption 是配置的不同分段；本次上手只需先关注 Rule，不必为了完成连接而逐一修改其他分段。截图展示的是配置编辑页，而不是 Home 中的 Global Routing 选择页，二者名称相关但操作用途不同。
在 Rule 中检查规则的顺序与目标策略。规则通常按顺序匹配，前面的规则命中后，后续规则未必继续参与该请求的处理。DOMAIN-SUFFIX 用于域名后缀匹配，GEOIP 用于按 IP 地理信息匹配，FINAL 用于前面规则未命中时的收尾处理。不要为了测试随意删除 FINAL，也不要把未知策略名称直接复制进配置。
例如 DOMAIN-SUFFIX,example.com,PROXY 是规则语法示例，不是可直接完成连接的服务器资料。实际使用前，必须确认 PROXY 能对应到当前配置中的有效策略或选择；规则里的文字不会自动创建服务器。对规则语法不熟悉时，先保留已有配置，详细匹配逻辑见Global Routing 与分流规则说明。
本步结束时，应能在 Home 明确读出当前 Global Routing。若刚才使用 Proxy 做临时对照，验证后再按原计划切回 Config，并重新核对实际请求；不要把对照测试时的姿态长期留作默认而忘记原因。
STEP 03 / CONNECT
打开 Home 顶部开关
先确认服务器与姿态，再打开连接。首次使用还需要完成系统授权，停在系统弹窗不等于连接已建立。
回到 Home，检查 SERVER 中选中的条目与你准备测试的服务器一致，再看 Global Routing 是否保持为上一步的选择。确认后打开顶部开关。未连接时可见 Not Connected；打开后观察顶部状态与系统提示，等待客户端完成连接状态转换，不要在状态尚未稳定时反复切换服务器和开关。
首次操作时，系统可能提示允许 Shadowrocket 添加 VPN 配置。确认发起操作的是刚打开的 Shadowrocket，再按系统提示允许，并使用设备要求的验证方式完成授权。该配置用于让系统把相关网络请求交给客户端处理，它本身不包含可用服务器，也不能代替订阅导入。如果拒绝或取消，本次连接可能无法继续，需要重新发起连接并完成授权。
授权完成后返回应用，查看顶部是否仍处于连接状态。若开关立即回落，先确认授权是否完成，再确认所选条目存在并且参数已保存。不要在这个阶段反复修改 DNS、Rule 或其他高级设置，否则即使之后能够连接，也难以判断究竟是哪一项变化产生了影响。
连接时留意设备上是否还有其他正在运行的 VPN 连接。需要切换时，先停止当前连接，再回到 Shadowrocket 建立本次测试连接，避免把连接被替换的现象误判为参数错误。应用回到前台后仍应重新核对状态，而不是只依赖先前出现过的系统标识。
连接状态保持开启，说明系统网络配置已经进入工作状态，但不能单凭这一点认定所有目标都能访问，也不能认定请求都走了所选服务器。接下来必须执行 Connectivity Test 和实际页面访问，分别验证测试目标与真正使用场景。
STEP 04 / CONNECTIVITY TEST
验证测试结果与实际请求
先测试，再打开实际需要访问的页面，最后核对策略。每一层只回答一个问题，结果需要结合判断。
实际页面访问
重新发起需要验证的请求，避免仅凭已缓存的页面内容判断连接成功。
Data 与请求记录
结合流量变化及可用记录，确认请求出现，并核对处理策略是否符合预期。
在 Home 点 Connectivity Test，等待测试完成，记录是成功、超时还是其他错误。测试结果与 Settings 中的 Test Method 及测试目标有关，不能把某一次超时直接等同于所有连接失败。也不要只比较结果数字的大小来决定配置是否正确；先看测试是否完成，再看实际请求能否得到响应。
保持连接开启，打开需要访问的页面或应用，重新发起一次请求。页面完整加载、登录流程完成或应用取到新内容，比只看到一个旧页面更能说明实际访问情况。若页面可能来自缓存，可刷新或使用新的浏览会话再试；验证过程中不要同时更换服务器、网络与模式，否则无法复现前后差别。
随后回到 Shadowrocket 查看 Data 中的流量变化，并在当前界面提供请求记录时，按刚才的目标域名或时间寻找对应请求。流量增加仅说明存在网络活动，不足以单独证明目标走了代理；还应核对 Global Routing、命中规则及最终策略。使用 Config 时，某些请求按规则直连可能正是预期结果。
如果 Proxy 下实际请求成功，而切回 Config 后失败，应优先检查规则、策略引用及相关解析行为，不必立刻重建整个服务器条目。反过来，所有模式下本地网络基础访问都异常时，先处理设备网络。记录“使用哪种网络、选择哪个服务器、处于哪种姿态、哪个请求失败”，进入下一步就有明确起点。
STEP 05 / DIAGNOSTICS
按失败位置逐项排查
先定位失败发生在导入、授权、连接还是访问阶段。每次只改一项，复测后再决定是否保留。
导入没有条目：核对链接与返回内容
回到 Subscribe 检查链接是否复制完整，特别是末尾参数、换行与多余空格。先确认设备网络可用，再按原入口更新一次，观察具体错误。订阅更新成功与列表内容可用并不是同一件事；若返回内容不符合入口要求，或你自己的服务已失效，应向自己的服务商核对资料。不要把链接改成猜测的地址，也不要连续导入相同内容掩盖原始错误。
开关无法保持：先查系统授权
回到 Home 重新打开连接，查看是否仍有待确认的系统弹窗。必要时进入设备的系统设置，确认 Shadowrocket 对应的 VPN 配置存在，并检查当前连接是否被其他 VPN 替换。先解决授权和连接状态，再讨论服务器响应；尚未建立系统连接时，修改 Rule 通常不能解决这一层的问题。
连接开启但请求失败：复核参数
在 SERVER 中打开当前条目的编辑页，核对 Type、Host、Port 与认证信息，确认选中的不是另一条名称相近的记录。对依赖 TLS 的协议，还需按原资料检查 SNI、证书校验及相关传输设置。设备日期与时间异常也可能影响 TLS 验证。遇到证书错误时先核实域名、时间与服务端资料，不要把降低校验要求当作常规修复步骤。
只有部分目标失败：对照模式与 DNS
先记录原来的 Global Routing，临时用 Proxy 对同一目标复测，再恢复原姿态。只有 Config 出现问题时，优先核对 Rule 的命中顺序、策略名称和当前配置是否选对。域名解析异常则检查已有 DNS 设置，先还原自己最近改过的项目，再测试。DNS 决定解析路径的一部分，不是所有连接错误的通用解决方法；相关概念可查DNS 与网络术语。
使用 Settings 留下可复现的观察结果
进入 Settings 查看 Test Method，确认两次 Connectivity Test 是否采用相同测试方式。需要进一步观察时使用 Diagnostics 中当前可用的诊断功能，保留失败发生的时间、错误文字和操作顺序。On Demand 用于按条件触发连接；首次手动验证期间，若已配置该功能，应留意它是否让连接自动变化，避免把自动行为误认成手动操作的结果。
需要向自己的服务商反馈时，描述协议类型、失败阶段、网络环境及已经做过的单项对照。发送截图或记录前，隐藏订阅链接、Password、认证参数及密钥等敏感内容。不要为排错公开完整配置；通常先提供错误文字与复现步骤，就能缩小问题范围。
完成排查后，恢复计划使用的 Global Routing，再进行一次实际请求验证。确认新设置有效后再保存必要的配置备份，并定期通过原入口更新已有订阅。应用更新通过 App Store 进行；重装应用不等于恢复服务器与规则资料。需要系统化排查时，继续阅读使用手册中的连接排查章节。
