OFFICIAL MANUAL / FIRST CONNECTION
Shadowrocket 使用教程
已有订阅导入 → Global Routing → 连接授权 → 生效验证 → 失败点检查
本页面向 iPhone 与 iPad 的首次配置。按顺序完成一次手动连接，再考虑规则调整和 On Demand；已有部分配置时，可直接跳到对应步骤。
STEP 01 / ADD SERVER
添加服务器或导入订阅
打开 Shadowrocket 后进入 Home，找到 SERVER 分组下的 Add Server。先判断手中资料的类型：一条由服务商提供、用于更新服务器列表的链接，应按订阅处理；分别列出的协议、服务器地址、端口和认证参数，应按单个服务器处理。两种资料的填写位置不同，不要把订阅链接整个粘贴进 Host。
已有订阅链接：选择 Subscribe
点按 Add Server，打开 Type 的类型选择，选择 Subscribe，再将自己的完整订阅链接粘贴到 URL。给这条订阅填写便于辨认的备注后保存。链接前后不要带空格、换行或聊天内容中的说明文字；查询参数通常也是链接的一部分，不要为了让地址简短而删除。订阅链接可能包含访问凭据，应视为私密资料，不要公开展示。
保存后返回 Home，等待订阅内容获取完成，核对是否出现对应分组及服务器条目。如果只看到了订阅名称，却没有可选择的服务器，先检查该订阅的更新结果。此时继续打开连接开关不能解决导入问题，应先确认链接完整、订阅仍然有效，以及当前网络能否访问它。服务商若重新生成了链接，应使用新的完整地址更新原记录。
已有服务器信息：按 Type 填写参数
手动添加时，先在 Type 选择资料中明确写出的协议，再逐项填写 Host、Port 以及该协议需要的认证和传输设置。截图展示的是一类服务器表单，包含 Password、Method 等字段；切换 Type 后字段会变化，不能把截图中的字段当成所有协议都必须填写的固定清单。
Host 一般填写服务器域名或地址，Port 填写对应端口，不要把带路径的完整网址混入地址字段。Password 与 Method 必须与已有资料一致，不能根据名称猜测。使用 VLESS、Trojan、WireGuard 等类型时，也应按各自资料核对参数。证书验证、服务器名称和传输路径等项目只有在资料明确要求时才调整，不要通过随意关闭验证来掩盖参数错误。
如果手中是可识别的二维码，可在 Add Server 中使用 Scan QR Code，并按系统提示授予相机权限；Import from Cloud JSON 适用于相应的配置资料，并不是任意订阅链接的通用入口。导入后仍需返回条目详情核对 Type 和地址。协议与订阅概念不清楚时，可先查阅概念速查，再继续下面的路由选择。
STEP 02 / GLOBAL ROUTING
选择路由姿态，核对 Config
服务器条目出现后，先不要急着连接。在 Home 点按 Global Routing，按当前任务选择配置(Config)/代理(Proxy)/直连(Direct)。这里决定请求如何处理，并不负责获取订阅，也不会修复错误的服务器参数。选择之后回到 Home，核对 Global Routing 显示的结果，避免以为已经切换，实际仍停留在原来的姿态。
配置(Config)：按当前文件中的规则处理
配置(Config)依据当前配置文件的规则决定请求走向。进入 Config，先确认正在使用的是哪一个文件，再打开查看相关内容。官方截图展示了 General、Rule、Hosts、URL Rewrite、HTTPS Decryption 等分段和 Add Rule 入口；首次使用不必逐项修改。先核对 Rule 中是否有自己的预期规则，以及最终未匹配请求如何处理。
规则按从上到下的顺序匹配，通常命中第一条适用规则后即采用相应策略。下面的片段只用于解释结构，不是可直接替代你现有配置的完整文件。example.com 是教学示例域名；FINAL 放在末尾，表示前面的规则都未命中时采用 DIRECT。因此，选择配置(Config)并不等于所有请求都会经过已选服务器。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,DIRECT代理(Proxy)与直连(Direct)：用于明确处理方向
代理(Proxy)让通常受该路由姿态控制的请求交给当前代理选择，可用于判断问题是否与 Config 中的分流规则有关。它不代表每一种系统流量都必然按相同方式转发，仍需结合实际请求验证。直连(Direct)则按直连方式处理，适合做同一网络下的对照检查，不能用它证明服务器已经可用。
首次排查时，可暂时选择代理(Proxy)做连接验证，验证后再切回计划使用的配置(Config)。修改配置前先保留原文件，一次只改一处；不要同时替换订阅、修改规则并更换测试方法，否则失败时难以判断是哪一步造成的。规则关键字、PROXY、DIRECT 与 REJECT 的含义见概念速查，更多设置说明见设置。
STEP 03 / HOME
选中服务器，打开连接开关
完成导入和路由选择后，返回 Home，在 SERVER 中点按准备使用的服务器，核对当前选中标记。订阅分组的名称与实际服务器条目不是同一层级；仅展开分组并不表示已经选择了其中某一条。若列表为空，应回到添加步骤检查，不要反复切换连接开关。
接着打开 Home 顶部的连接开关。未连接时可看到 Not Connected；开启后，等待应用与系统完成连接过程。首次使用可能出现添加 VPN 配置的系统提示，这是系统允许应用创建相应网络配置的授权步骤。阅读提示，确认正在操作 Shadowrocket，再按设备要求完成认证。
若此前取消了授权，回到 Home 再次尝试连接，并留意系统提示。设备受管理或存在系统限制时，授权结果可能受相应策略影响，应核对设备上的限制说明，而不是修改服务器密码碰运气。连接开关立即退回关闭状态，也应先检查授权或配置错误提示，再判断服务器是否可用。
返回 Home 后，观察顶部是否保持连接状态，并再次确认所选服务器及 Global Routing。此时只完成了建立本地连接配置这一层检查，尚不能据此判断目标页面会如何访问。系统的 VPN 标识同样不是端到端可用的证明，下一步还需要执行测试并实际访问。
iPad 的操作顺序相同：先核对条目，再选择路由姿态，最后打开连接开关。布局或系统弹窗呈现方式可能与截图不同，以设备实际界面为准。首次验证阶段先保持手动连接，不急于设置 On Demand，便于把自动触发问题与手动连接问题分开。
STEP 04 / CONNECTIVITY TEST
验证生效：测试与实际访问
保持连接后，在 Home 点按 Connectivity Test，等待当前测试完成。先看是否得到响应，再结合 Settings 中的 Test Method 理解结果。不同测试方法关注的链路环节不同，不能仅凭某个结果就判断所有协议、所有目标页面或所有应用都能正常工作。
接着打开浏览器，访问自己已知可用的页面，确认内容是否能实际加载。若测试有响应而页面失败，先检查该页面在当前 Global Routing 下应走什么路径：配置(Config)可能把它交给 DIRECT，也可能匹配 PROXY 或 REJECT。此时应查看相应请求记录与规则，而不是直接认定所选服务器不可用。
做对照时保持测试目标不变。可以先记录配置(Config)下的结果，再临时切换到代理(Proxy)重新访问同一页面；如果仅切换路由姿态就改变了结果，优先核对 Config 的规则顺序、最终策略及域名解析相关设置。完成对照后恢复原计划使用的姿态，避免把临时诊断设置长期保留。
还要区分“有流量”和“路径正确”。Data 中的流量变化只能说明有相应统计活动，不能单独证明某个域名命中了预期策略。若应用提供对应请求的连接记录，结合目标域名、策略和时间查看；分享排查材料前，应去掉服务器地址、订阅链接及认证信息。
STEP 05 / SETTINGS & DIAGNOSTICS
常见失败点，按层检查
遇到 Shadowrocket 连不上时，先确定失败发生在哪一层：订阅没有导入、开关无法保持、测试失败，还是只有特定页面无法访问。下面按从资料到请求的顺序检查。每完成一项，都用相同目标再试一次，记录变化；这样比反复删除并重新添加全部内容更容易定位原因。
导入后没有服务器：检查资料与获取过程
先返回订阅记录，核对 Type 是否为 Subscribe、URL 是否完整。链接失效、内容格式不适用或当前网络无法访问订阅地址，都可能导致更新失败。服务器列表不会因为应用已购买而自动出现；需要由用户已有的有效资料导入。若原始链接已变更，应从自己的服务商处核对，而不是从不明内容中拼接地址。
开关开启但测试失败：核对参数与测试方法
打开相应服务器的详情，逐项对照原始资料，尤其是 Type、Host、Port、认证字段以及传输设置。进入 Settings 查看 Test Method，确认正在比较的是同一种测试。测试方法变化可能使结果表现不同，但改换测试方法本身不会修复错误的服务器资料，也不能替代真实页面访问验证。
必要时使用 Settings 中的 Diagnostics 辅助收集现象，先阅读输出中与连接、解析相关的信息。不要把整段诊断内容直接公开；其中可能包含网络地址或其他私密资料。若准备切换 Wi-Fi 与蜂窝网络作对照，应保持服务器、路由姿态和测试目标不变，观察问题是否仅发生在某一种网络下。
只有部分页面失败：回到规则与解析检查
如果大部分访问正常，只有个别目标失败，先检查它是否命中 REJECT，或被交给了不符合预期的 DIRECT。规则中较宽泛的匹配放在前面，可能使后面的精确规则没有机会生效。确认 FINAL 位于规则末尾，并理解其策略。域名解析失败与代理连接失败属于不同问题，应结合请求记录区分，不要盲目替换所有 DNS 设置。
手动正常、自动异常：最后检查 On Demand
手动连接已验证后，再进入 Settings 检查 On Demand。核对当前网络与触发条件是否一致，并观察自动触发后连接开关是否按预期变化。若设置了多种条件，先简化到容易验证的一种，再逐步加入其他条件。为了隔离问题，可暂时停用 On Demand，重新完成手动连接与实际访问测试。
Settings 中还包含 Proxy、TCP、UDP 等相关设置。首次排查不建议同时改动这些项目；只有在已明确协议要求或失败范围后，再针对对应项目核对。TCP 访问正常不代表 UDP 应用一定正常，单一测试失败也不代表所有业务都会失败。保持事实描述具体，例如“同一服务器在蜂窝网络下测试失败，但 Wi-Fi 下可响应”，比笼统描述“完全不能用”更有帮助。
到这里应能把问题缩小到资料、系统授权、服务器连接、规则或网络环境中的某一层。术语含义可继续查看概念速查；需要核对购买账号、商店地区或重新安装后的已购恢复时，转到正版指南。购买与连接是两条不同的检查路径，不要因为网络请求失败就重复购买应用。
