Shadowrocket 使用教程：从添加信息到检查连接

打开 Shadowrocket，先在 Home 查找 Add Server。如果手里是单台服务器的参数，进入 Add Server 后，先按资料中的协议选择 Type，再逐项填写 Host、Port，以及该 Type 对应的认证信息。右侧官方截图展示了 Add Server 中的 Type、Host、Port、Password、Method 等字段；这些字段不是每种协议都要填写，出现哪些项目取决于所选 Type。不要把服务器地址连同端口一起塞进 Host，也不要把链接文本当作 Password。

录入之前，把已有资料分开看：服务器域名或地址对应 Host，端口数字对应 Port，密码、密钥或其他认证参数应填在相应字段。若资料包含 TLS、SNI 等附加参数，也应按对应 Type 的字段核对，不要凭猜测补值。输入完成后保存，返回 Home，确认刚添加的条目确实进入列表。列表里有名称，只代表信息已保存，并不代表服务器已经连通；下一步仍要选择条目并测试。

如果手里是自己的订阅链接，则在添加流程中找到 Subscribe，粘贴完整链接并保存，随后按界面提供的更新操作取得列表。粘贴时尤其要检查链接开头、末尾和查询参数是否完整；从消息中复制时，多出的空格或换行也可能影响解析。更新后先看列表是否出现预期条目，再选定要使用的一项。订阅列表为空时，不必立刻切换 Global Routing：先核对链接是否完整、订阅本身是否可访问以及最近一次更新是否成功。

扫码适用于你已经持有对应二维码的情况：Add Server 页面中可见 Scan QR Code，按系统提示授予相机权限后核对识别出的内容，再保存。页面中还可能看到 Import from Cloud JSON；它对应的是另一种配置导入方式，不应把普通订阅链接填到不匹配的入口。无论采用手填、Subscribe 还是扫码，结束这一步的判断标准都相同：Home 列表中出现你能辨认的条目，且关键字段与已有资料一致。更细的整理、更新与删除方式见服务器管理手册。

有了可选择的条目，再回到 Home 找 Global Routing。这里决定请求采用哪种处理姿态，和“服务器信息有没有填对”是两个问题。教程中按中文含义区分三项：配置(Config)、代理(Proxy)、直连(Direct)。界面中的 Config、Proxy、Direct 请按英文原词识别；切换后留意 Home 显示的当前选择，避免以为已经切换、实际仍停在先前姿态。

希望按配置文件的规则分别处理请求时，选择 Config。规则通常逐条匹配，命中后执行对应策略；例如某条 DOMAIN-SUFFIX 规则使用 PROXY，另一条使用 DIRECT。未命中的请求还要看配置中的后续规则或最终策略，因此“选择 Config”本身不等于所有请求都会走同一服务器。打开 Config 页面时，可对照截图识别 General、Rule、Hosts 等分段；要检查分流，重点看 Rule 与所用配置是否对应，而不是仅看规则名称。

Proxy 适合暂时检查所选服务器能否处理请求：它让更多请求经过当前代理路径，但不应将这种测试结果直接推断为 Config 规则正确。Direct 则用于确认直连路径的表现；在 Direct 下看到某个页面可以打开，不能据此证明服务器可用。排查时可以先明确自己的目标，再选择姿态：要日常按规则处理，就回到 Config；要隔离规则影响，可短暂用 Proxy 对照；要观察不经过当前代理路径的结果，则用 Direct 对照。测试后记得恢复原本需要的姿态。

初次操作不必急着改写规则。先使用自己已有的 Config，确认它是否包含所需的规则，并留意规则的先后顺序。只有当连接已经建立、测试也有结果，却发现特定请求处理方式与预期不同，才需要进一步查看 Rule 中的 DOMAIN-SUFFIX、IP-CIDR 等匹配条件与 PROXY、DIRECT、REJECT 策略。规则写法与优先次序涉及较多细节，可在完成本教程后再查阅设置说明和疑难解答。

返回 Home，确认已经选中刚才核对过的服务器条目，同时确认 Global Routing 显示的是你要测试的姿态。Home 官方截图可用于定位顶部的 Not Connected 状态与开关、Global Routing、Connectivity Test，以及下方的 SERVER 分组和 Add Server。先选条目、再开开关，有助于避免列表里虽然存在多个条目，却连接了并非本次要检查的那一个。

打开顶部开关后，如果系统首次显示 VPN 配置授权提示，请先读清提示内容，再按系统流程确认。这个授权用于允许设备建立相应的网络连接配置；未完成系统确认时，应用中的开关操作可能无法完成。完成后回到 Home，观察状态是否从 Not Connected 变化，以及开关是否保持在开启状态。系统状态与应用显示都值得看：如果开关立即退回、持续停留在连接中，或反复出现系统提示，不要直接把问题归结为规则分流。

此时仍需区分“开关打开”和“请求按预期处理”。开关只说明开始建立或已经建立连接；服务器参数、订阅内容、当前姿态及规则仍会影响后续访问。若保存了多个服务器条目，先固定其中一个做测试，不要在每次尝试时同时更换条目和 Global Routing。这样下一步出现差异时，才能知道是连接对象变了，还是路由姿态变了。

在 iPad 上也按相同逻辑寻找 Home 中的条目、Global Routing 与开关；界面排布可能随屏幕宽度变化，但这些英文词的作用不变。连接保持开启后，继续做 Connectivity Test 和实际访问验证。若这一步尚未得到稳定的连接状态，先回头检查系统授权、所选条目和已填写字段，不必提前修改 DNS 或复杂规则。

如果在第一步就看不到预期条目，先回到导入环节。手填信息应核对 Type、Host、Port 和该协议需要的认证字段，尤其留意复制时的空格、端口遗漏，以及资料与所选 Type 是否匹配。使用 Subscribe 时，检查粘贴的链接是否完整、列表是否完成更新，以及已有订阅内容本身是否包含服务器信息。列表为空属于导入或更新层面的问题；在这个阶段反复拨动 Home 开关不会补全缺失内容。更详细的订阅解析排查见订阅导入失败自查清单。

如果条目存在，但 Home 的开关无法保持开启，先确认本次选中的确实是要测试的条目，再检查系统授权是否完成。若状态能够保持连接、Connectivity Test 却没有得到预期结果，回到服务器字段与当前网络条件，按同一姿态重试；有多个条目时，只替换所选条目做对照，不要同时改写 Config。这样可以把“连接没有建立”和“连接已建立但目标不可达”分成两类处理。

如果 Connectivity Test 有结果，实际请求的处理方式却不对，优先确认 Global Routing 是否仍是预期的 Config、Proxy 或 Direct。选择 Config 时，再确认正在使用的 Config 文件、Rule 匹配条件与顺序，以及最后落到的策略。规则中的 PROXY、DIRECT、REJECT 各有不同作用；只看到某条规则存在，不代表请求一定命中它。修改规则前先确定具体目标及预期策略，每次只调整一条相关条件，保存后重新验证。

需要查看更多诊断选项时进入 Settings。右侧官方截图展示了 Test Method、On Demand、Diagnostics、Proxy、TCP、UDP 等项目。排查连接时可先查看 Diagnostics 提供的信息，再核对 Test Method 与刚才的测试方法是否一致；如果使用了 On Demand，还要留意按需连接条件是否与当前网络环境相符。不要为了一次测试同时修改 TCP、UDP、DNS 和 On Demand，否则即使结果变化，也难以知道是哪一项起作用。具体设置项的用途可查阅设置说明。

完成排查后，把临时测试用的 Global Routing 姿态恢复到日常所需状态，并重新执行一次 Home 状态检查、Connectivity Test 和实际访问验证。若问题仍在，整理出“手填还是 Subscribe、所选 Type、Home 状态、Global Routing、测试结果、是否启用 On Demand”这些信息，再按疑难解答中的对应情形逐项核对。记录现象时不要公开分享密码、密钥或完整订阅链接。