Shadowrocket 使用教程
已有配置 → 选择模式 → 连接验证
本页只走通首次使用的必要路径。先让一条已有服务器配置完成连接，再处理规则细节与自动连接条件，避免同时修改多项设置。
下面以 iPhone 与 iPad 的操作路径说明。截图用于辨认页面和字段，不代表你的列表应当与图中一致。协议不同，Add Server 中需要填写的字段也会变化，应以当前所选 Type 和自己的配置资料为准。
- 先确认 配置完整
- 再检查 连接状态
- 每次只改 一个条件
Add Server：添加服务器或导入订阅
先根据手头资料选择一种添加方式，不必把同一份资料重复导入。
打开 Shadowrocket，进入 Home。在 SERVER 区域找到 Add Server，或使用页面中的添加入口。首先查看 Type：它决定后续字段的含义。拿到单条服务器参数时，按资料指定的协议选择；拿到订阅链接时，使用 Subscribe 类型。不要仅凭地址的外观猜测协议，也不要把订阅链接拆开填进 Host 和 Port。
手动填写服务器参数
进入 Add Server 后，先选择与资料一致的 Type，再填写 Host、Port 以及该类型要求的其他项目。Host 通常是服务器域名或地址，Port 是端口；Password、Method 等字段只在相应协议下按需填写。不同协议的认证方式并不相同，不能用一个协议的填写习惯套用到另一个协议。对于 TLS、传输方式等附加项目，只按已有资料设置，不要为了尝试连接而随意切换。
检查复制内容中是否混入空格、换行或中文标点，尤其注意端口数字与认证信息是否完整。可以填写一个便于自己辨认的备注，保存后返回 Home，确认 SERVER 中出现对应条目。备注有助于区分配置，但修改备注不会改变服务器的连接参数。
导入已有订阅链接
在 Add Server 的 Type 中选择 Subscribe，将自己的完整订阅链接填入相应的 URL 字段，再保存并等待获取结果。订阅链接可能包含识别服务权限的信息，应从原始资料完整复制，不要截掉问号后面的内容，也不要把聊天中的说明文字一起粘贴进去。订阅记录保存成功与服务器列表获取成功不是同一个结果，返回 Home 后还要检查 SERVER 是否确实出现了可选条目。
如果你持有的是二维码，可按资料形式使用 Scan QR Code；Import from Cloud JSON 则对应特定格式的导入入口，并不等同于所有订阅链接都能使用。应根据资料实际格式选择入口，无法确认格式时先向自己的服务商核对。不要在多个入口之间反复导入同一份内容，这会让后续选择与排查变得混乱。
列表仍为空时，先核对链接是否完整、当前网络能否获取该链接、已有服务状态是否正常。暂时不要进入规则编辑，因为规则不会补出尚未导入的服务器。列表出现后，先保留当前记录，下一步选择 Global Routing。更多导入问题见常见问题中的订阅与节点导入说明。
本步完成标志：Home 的 SERVER 中已有能辨认的服务器条目，而不只是保存了一条订阅记录。
Global Routing：选择连接姿态
三姿态决定连接如何选择策略，不会替代服务器资料或修复错误参数。
回到 Home，点开 Global Routing。这里的三姿态写作配置(Config)/代理(Proxy)/直连(Direct)。先明确本次操作目的：是验证所选服务器是否可用，还是按照已有规则进行日常分流。选择后返回 Home，再查看 Global Routing 当前显示的值，避免以为已经切换，实际仍停留在原来的姿态。
Config：按当前配置规则判断
配置(Config)会依据当前配置中的规则决定连接使用的策略。订阅中的服务器列表与 Config 中的配置文件承担不同职责：前者提供可选连接信息，后者描述如何判断流量。导入订阅后，不能仅凭列表出现就认定分流规则也已经准备好。使用 Config 前，应进入 Config 确认当前使用的配置，并查看 Rule 中的规则及顺序。
右侧官方截图展示配置编辑页中的 General、Rule、Hosts、URL Rewrite、HTTPS Decryption 和 Add Rule。首次连接不需要逐项修改这些分段；尤其不要因为看到某个高级项目就直接开启或编辑。先使用自己已理解、来源明确的配置，把规则调整留到连接验证之后。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,DIRECT仅用于理解规则语法：按域名后缀或地址段匹配，FINAL 处理未命中的情况，不是要求整段替换你的配置。
Proxy 与 Direct：分清测试目的
代理(Proxy)以代理路径处理连接，适合在首次排查时减少规则匹配带来的变量。它仍然依赖可用的服务器配置；如果 Host、认证信息或服务状态有问题，切换 Proxy 并不会自动修复。测试通过后，如果日常目标是按规则分流，再切回 Config 并重新验证实际访问。
直连(Direct)使用直接连接路径，适合确认基础网络访问是否正常。它不是代理服务器可用性的证明：Direct 下能打开一个页面，只说明这次直接访问成功，不能据此断定已选服务器正常。对于首次验证已有服务器的情况，可以先用 Proxy 完成后续连接和测试，再回到 Config 检查分流。
规则需要更细的匹配顺序、策略引用或 DNS 配合时，转到完整手册继续阅读。本教程先保持一个明确的测试姿态，不在首次连接时叠加多个设置变化。
本步完成标志：能在 Home 确认当前姿态，并知道接下来是在验证服务器路径还是规则分流。
Home：选定服务器并打开连接
先选 SERVER，再打开顶部开关，最后检查状态是否保持。
回到 Home，在 SERVER 中找到本次要验证的服务器，点选条目左侧的圆点，将它设为当前默认服务器。要区分“选中服务器”和“打开详情编辑”：本次只需要明确使用哪一条，不必重新填写资料。列表中如果有多个相似备注，先确认它们对应的订阅分组或服务器信息，避免测试了另一条配置。
再次查看 Global Routing 是否与上一步的测试目的相符，然后打开 Home 顶部连接开关。未连接时可看到 Not Connected。首次建立连接时，系统可能要求允许添加 VPN 配置；核对提示中的应用名称与本次操作一致，再按系统流程确认，可能还需要设备验证。这里授予的是建立系统 VPN 配置的权限，不是填写服务器认证信息的页面。
如果取消了这次权限提示，连接流程可能无法继续。返回 Shadowrocket 后重新发起连接，按实际出现的系统提示处理即可。设备若受组织管理或系统限制，应先核对设备允许的配置范围，不要反复修改服务器密码来处理权限问题。
确认权限后返回 Home，观察顶部连接状态是否从 Not Connected 变为已连接，并确认开关没有立即回落。系统显示的 VPN 状态可以作为隧道已建立的辅助信息，但不能替代实际访问验证。出现已连接只表示连接流程已建立，不等于所有目标地址都能正常访问，也不等于 Config 中每条规则都符合预期。
iPad 上同样先核对当前服务器与 Global Routing，再处理系统权限。即使在另一台设备上已经使用过 Shadowrocket，本机仍应分别确认权限与配置资料。下一步保持当前服务器和姿态不变，进行 Connectivity Test 和实际访问，以便把结果对应到同一组条件。
本步完成标志：选中的服务器明确，连接开关能够保持，Home 不再停留在 Not Connected。
Connectivity Test：验证是否生效
把测试结果、实际访问与当前姿态一起看，单项成功不能代替完整验证。
在 Home 点击 Connectivity Test，等待本次测试完成，查看所选服务器对应的结果。测试可用于观察当前测试条件下的连通情况；有结果不代表所有应用、域名或连接方式都一定成功，超时也不能单独证明服务器资料错误。测试方法、当前网络及目标的响应情况都可能影响结果，应与实际访问交叉核对。
接着打开浏览器，访问一个自己熟悉且有权访问的页面，观察是否能完整加载，而不是只看已有缓存的标题或图片。保持服务器、Global Routing 和网络环境不变，必要时刷新页面重试。若同时切换网络、修改 DNS 和更换服务器，就难以判断是哪一项带来了变化。
然后进入 Data，观察本次使用前后流量是否发生相应变化。Data 适合辅助理解使用情况，不应把累计数字直接当作某个页面已经走代理的证据。尤其在 Config 下，部分请求可能使用 DIRECT，另一些请求使用 PROXY；页面能够打开，仍需结合规则判断它是否使用了你期望的路径。
如果刚才暂用 Proxy 验证服务器，确认实际访问正常后，再切回配置(Config)进行第二次验证。相同服务器在 Proxy 下可用、切回 Config 后异常，应优先检查当前配置与 Rule，而不是立即重新导入订阅。反过来，Direct 下能访问也不能用来证明代理路径正常，需要分别判断。
完成验证后记住这组可用条件：所选服务器、当前姿态、使用的配置以及网络环境。后续出现问题时，先与这组条件比较，比连续点击开关更容易定位变化。需要了解更细的流量解释或规则判断时，查看完整手册中的连接与 Data 说明。
本步完成标志：实际访问符合预期，并能解释当前使用的是 Proxy、Direct，还是 Config 中的规则策略。
Settings：按失败位置排查
先找到失败发生在哪一步，再决定要检查哪个页面。
遇到异常时，先记下现象：列表为空、开关无法保持、测试超时，还是只有某个页面失败。它们对应不同环节，不宜用同一种处理方式。下面按从前到后的顺序检查，每完成一项就按原条件重试，保留尚未修改的资料，避免失去对照。
列表为空：返回导入环节
先确认设备的基础网络可用，再核对 Subscribe 中的完整 URL 与获取结果。链接被截断、已有服务状态变化、订阅内容无法解析，都可能让列表为空。向自己的服务商确认时，只需说明导入结果和发生位置，不要公开完整订阅链接。此时修改 Global Routing 或 Rule 没有针对性，因为尚未获得可选服务器。
开关无法保持：先看权限与当前选择
确认 SERVER 中已有明确选中的服务器，系统添加 VPN 配置的流程已经完成，同时核对是否存在设备管理限制或其他已启用的 VPN 连接。根据系统提示处理当前连接状态后再尝试，不要直接删除全部配置。若只在更换网络后出现问题，先回到原网络复测，判断是否与网络环境有关。
能连接但访问失败：区分参数与规则
重新核对 Type、Host、Port、认证信息和资料要求的附加参数，逐项比较，不要凭记忆填写。再检查 Global Routing：如原先使用 Config，可暂用 Proxy 进行对照；只有 Config 异常时，优先查看当前配置、规则顺序和目标对应的策略。只有部分域名失败时，也应把 DNS 与规则匹配纳入检查，而不是反复切换所有选项。
测试结果与访问不一致：查看诊断条件
进入 Settings，查看 Test Method 当前选择的测试方式。不同测试方式观察的条件不同，不能将一个测试结果直接推广到全部访问。需要进一步定位时使用 Diagnostics，并按其中实际提供的项目检查。保存或转述诊断信息前，应隐藏自己的订阅链接、认证资料和不希望公开的访问记录。
首次排查期间，先保持手动连接。On Demand 用于按条件触发连接，适合在手动连接已经稳定后再设置；如果开关表现与手动操作不一致，应同时核对它是否已启用。Settings 中的 Proxy、TCP、UDP 等项目也不需要为了尝试连通而全部改动，优先保留已有配置，只处理与现象直接相关的设置。
排查结束后，把测试期间临时改变的姿态恢复为日常需要的选择，再做一次实际访问验证。仍未解决时，前往常见问题按现象继续查找；规则、DNS 与长期维护的系统说明放在完整手册。说明问题时写清失败步骤、当前姿态与已经验证过的条件，比只写“连不上”更有助于定位。
本步完成标志：已把问题缩小到导入、权限、服务器参数或规则中的一个环节，并有可重复的复测条件。
