OFFICIAL MANUAL / GETTING STARTED
Shadowrocket 使用教程：导入与连接
先导入已有资料，再选择路由方式；连接后，用实际请求确认是否生效。本页按首次操作的顺序编排，适用于 iPhone 与 iPad。
首次操作建议按顺序阅读；已经能连接但访问异常时，可直接跳到验证与排查。界面词保留英文，具体位置与可用选项以当前应用内显示为准。
STEP 01 / ADD SERVER
添加服务器或导入已有订阅
先判断手里的资料属于哪一种：一条会返回服务器列表的订阅链接，还是一个服务器的完整连接参数。两者使用同一个添加入口，但填写方式不同。订阅链接不是普通网站主页，也不是账号管理页面；如果无法判断，先向原资料提供方确认用途，不要靠反复更改地址尝试。
已有订阅链接：选择 Subscribe
打开 Shadowrocket，进入 Home，点击右上角的加号进入 Add Server。点击类型选择项，选择 Subscribe，将已有订阅链接完整粘贴到 URL。如需备注，使用便于自己辨认的名称；备注只帮助区分来源，不会改变服务器的连接方式。
粘贴后先检查地址的开头、末尾和中间是否完整。聊天消息的换行、复制时带入的空格，或遗漏查询参数，都可能导致读取失败。订阅链接中的认证部分往往属于访问凭据，应保留原样，不要擅自删减，也不要把完整地址发到公开讨论区。确认后使用页面的保存控件，返回 Home 等待订阅读取。
成功读取后，检查 SERVER 列表是否出现了订阅内的服务器条目，而不只是一个订阅名称。如果只看到来源记录、没有可选服务器，先检查订阅的更新结果和错误提示。不要在资料尚未读入时继续打开连接开关；路由设置不能补足缺失的服务器资料。
已有单个服务器资料：按对应类型填写
如果已有服务器分享链接，可先复制完整链接，再按应用内出现的导入提示确认条目；已有二维码时，可使用 Scan QR Code 读取。识别后仍要检查类型与地址，不应仅凭导入成功就认为参数正确。二维码包含的认证资料同样需要保密。
手动填写时，在 Add Server 选择与资料一致的类型，例如 Shadowsocks、VMess 或 Trojan，再逐项录入地址、端口与认证信息。不同协议需要的字段不同；加密方式、传输方式、TLS 相关参数应与原资料保持一致，不要把某一种协议的填写方法套到另一种协议上。
保存后回到 Home，在 SERVER 中选中准备使用的服务器。先用一项已核对的资料完成整个流程，后续再整理名称与分组。此时完成的是“把资料放进客户端”，尚未完成连接；下一步需要决定这些资料如何被请求使用。
STEP 02 / GLOBAL ROUTING
选择 Global Routing 三种姿态
回到 Home，点击 Global Routing，按用途选择配置(Config)/代理(Proxy)/直连(Direct)。这里决定客户端如何处理请求，不是选择另一台服务器。修改后返回 Home 核对显示的当前模式，再进行下一步，避免把“服务器已选中”和“路由已选好”混为一谈。
配置(Config)：按当前配置处理请求
需要按规则区分请求时使用 Config。先进入应用的 Config 页面，确认所需配置文件存在，并已被选中使用。仅在列表里看到文件不代表它就是当前配置；应以应用内的选中状态为准。文件中的规则、策略及相关设置，才是此模式下判断请求路径的依据。
例如，规则可能使用 DOMAIN-SUFFIX 匹配域名后缀，使用 IP-CIDR 匹配地址范围，并以 FINAL 处理前面未匹配的请求。初次上手不必立即编辑这些内容，但要知道：同一台服务器能用，不代表所有规则都按预期工作。配置中引用的策略也必须有效，不能只检查规则关键字。
代理(Proxy)：先核对代理路径
需要单独检查当前代理路径时，可临时选择 Proxy，确认 SERVER 中选中了待测服务器，再连接和访问同一个测试目标。这有助于把“服务器连接是否正常”与“规则是否命中预期策略”分开检查。该模式下也不应据此推断每个应用、每一种流量都一定经过同样的处理。
如果 Proxy 能完成目标访问，换回 Config 后却失败，优先检查当前配置、匹配顺序和最终策略，而不是立即删除服务器。完成诊断后记得恢复自己需要的模式；临时排查设置不应在未确认用途时一直保留。
直连(Direct)：检查直接连接的表现
Direct 使用直接连接路径，不通过已选代理服务器转发相应请求。它适合帮助观察原始网络的访问情况，不适合作为“代理已成功”的证据。选择此模式后即使系统显示 VPN 状态，也不能据此认为请求使用了代理服务器；系统连接状态与请求采取的策略属于不同层面。
准备继续时，核对两项：当前 Global Routing 是否符合目的；若选择 Config，配置是否已选中。规则语法和配置文件各段的详细说明放在完整官方手册，本页先完成一条可验证的连接流程。
STEP 03 / VPN PERMISSION
打开开关，完成 VPN 配置授权
现在返回 Home。打开连接开关前，再看一遍 SERVER 中的选择和 Global Routing 的当前值。如果页面显示 Not Connected，表示客户端当前尚未建立相应连接；此时点击连接开关，按接下来的应用提示和系统提示操作。
首次出现添加 VPN 配置提示时
首次连接可能触发系统添加 VPN 配置的提示。阅读提示中的应用名称与权限说明，确认正在操作 Shadowrocket 后，再按系统要求允许，并完成设备认证。这里授权的是应用创建所需系统 VPN 配置，不会替你生成服务器、修正订阅地址，也不代表资料已经通过可用性验证。
授权完成后回到 Shadowrocket，查看连接开关和状态是否发生变化。如果系统提示被拒绝，回到应用再次尝试连接，按实际出现的提示处理；必要时到系统设置的 VPN 相关位置检查是否有对应配置。不要为了排查而删除设备上所有 VPN 配置，尤其是另有工作或管理用途的配置。
区分系统连接状态与服务器可用性
系统出现 VPN 标识、开关保持打开，说明相关系统连接处于活动状态，但远端服务器认证、域名解析和目标访问仍可能失败。反过来，开关立即关闭或提示配置错误时，应先处理授权、当前配置和应用显示的错误，不要跳到浏览器反复刷新，把多个问题混在一起。
第一次验证建议保留手动连接方式，先不要同时调整 On Demand 等自动连接选项。自动触发条件会影响连接何时恢复，不适合在基础链路还未确认时一并修改。等到下一步完成后，再根据实际使用需求了解这些设置。
离开应用去测试访问时，保留当前服务器与路由选择。若准备更换关键参数，先断开，再修改、保存并重新连接，以便明确后一次测试使用的是哪组设置。接下来需要检查的不是“开关有没有打开”，而是“目标请求是否真正完成”。
STEP 04 / CONNECTIVITY TEST
用检测与实际请求验证是否生效
验证分成三个层次：客户端或服务器的测试结果、系统连接状态、实际目标的访问结果。三者需要一起看。一个测试成功不能代替所有应用的访问验证；一个目标失败，也不足以说明全部连接资料都不可用。
先看 Connectivity Test，再访问实际目标
在 Home 找到 Connectivity Test，按当前界面提供的控件执行检测，并确认检测针对的是当前需要检查的对象。若应用提供不同测试方式，应在前后比较时使用相同方式；不同测试条件下的结果不宜直接比较。
测试有响应后，打开浏览器或实际要使用的应用，访问一个明确的目标页面，执行一次新的加载。不要只看先前已经打开的内容，因为页面可能来自缓存。先选一个目标完成验证，再测试其他用途；同时打开许多页面会让请求记录难以对应，也不利于判断哪次改动产生了影响。
在 Data 中对应请求与策略
返回 Shadowrocket，进入 Data，查看与刚才操作时间和目标相对应的请求记录。记录详情若提供匹配规则、策略或连接信息，可据此判断请求使用了哪条路径。使用 Config 时，重点核对命中的规则与预期是否一致，而不是仅凭总流量发生变化作结论。
例如，某个请求本应使用代理，但对应记录显示 DIRECT，就应检查规则匹配和顺序；如果策略符合预期却连接失败，再检查该策略实际引用的服务器及相关参数。需要注意，记录中出现请求只说明客户端观察到了这次活动，不必然表示远端已返回完整内容。
形成一次可以重复的验证
确认目标能够完成实际操作，例如页面重新加载、应用正常取得所需内容，再把本次模式、服务器选择和测试目标记下来。无需保存订阅完整地址或认证资料。以后发生异常时，按相同条件重测，结果才具有可比性。
如果 Connectivity Test 成功但实际访问失败，继续下一节，按目标解析、规则与服务器参数逐项排查。若实际访问正常而某项检测失败，也先核对测试方式与检测目标，不要只为让所有检测结果一致而更改已经正常的配置。
STEP 05 / CHECK ONE CHANGE AT A TIME
按失败现象定位，逐项修改
排查从最早失败的环节开始。先记录当前现象，再只改一个条件，随后重复同一次验证。一次同时更新订阅、更换服务器、编辑规则和切换网络，即使恢复访问，也很难知道真正的原因；下一次遇到问题仍会缺少判断依据。
订阅没有读入，或更新后条目异常
先断开连接，确认原始网络能够正常访问日常可用的页面，再检查订阅地址是否完整、是否仍有效，以及应用显示的更新错误。若订阅需要认证或原服务信息已变化，应向你已有的服务商核对。不要自行修改地址中的认证内容，也不要因为读取失败就尝试来源不明的资料。
更新前可以记下原先选中的条目名称；更新后若该条目被移除或重命名，需要重新选择当前列表中的有效服务器。订阅更新主要改变服务器资料，不等于当前 Config 中的规则和策略引用也已经同步调整。
开关无法保持打开，或系统配置报错
先读取应用的错误提示，确认首次 VPN 配置授权已完成，再检查系统 VPN 相关设置中的对应项目。如果同时启用了其他会影响系统 VPN 的配置，应先核对当前活动连接，减少并行条件后重试。涉及设备管理限制时，应遵循设备的管理要求，不要随意移除管理配置。
需要重建 Shadowrocket 的系统 VPN 配置时，先保留应用中的服务器与配置资料，并只处理对应项目。系统 VPN 配置与应用内服务器列表不是同一份内容；不能把“删除系统连接项目”当成服务器参数修复办法。
已经连接，但目标无法访问
先确认当前不是为诊断而保留的 Direct，再检查所选服务器。手动录入的条目应逐项比对类型、端口、认证与传输参数，特别注意复制时漏掉的字段。不要通过随意关闭 TLS 验证来替代参数核对；证书相关错误应结合原始资料和应用提示查找原因。
随后比较同一目标在 Proxy 与 Config 下的表现。前者正常、后者异常时，优先检查配置文件是否选中、规则先后顺序以及策略引用；两者都失败时，再回到服务器、原始网络和目标本身。比较完成后，恢复日常需要的模式。
只有部分目标失败，或切换网络后异常
部分目标异常时，使用 Data 对应实际失败的请求，核对域名解析、规则命中和连接错误。不要仅凭页面主域名就断定整页采用同一路径，一个页面还可能请求其他域名。先定位失败的那一项，再决定是否需要调整规则。
如果问题只在某个 Wi-Fi 或移动数据网络出现，保持服务器和配置不变，仅切换网络复测。网络切换后可手动断开并重新连接，观察错误是否重现。这个比较用于缩小范围，不代表某一网络一定有问题，也不构成对服务器可用性的长期保证。
完成以上流程后，应能区分资料导入、系统连接与实际请求这三个环节。下一步如需理解 On Demand、配置文件各段和日常维护，继续阅读新手到进阶官方手册；需要重新核对基础操作时，回到本教程的添加与导入步骤即可。