Shadowrocket 使用说明

选择 Global Routing 姿态

服务器记录决定代理连接使用哪些参数，Global Routing 则决定请求如何选择路径。这两项需要分别确认：列表里选中了服务器，不等于所有请求都会经过该服务器。回到 Home，点击 Global Routing，查看当前选项，并按本次测试目标选择配置(Config)、代理(Proxy)或直连(Direct)。修改后返回 Home，再看一次模式名称，避免只进入菜单却没有完成选择。

配置(Config)：按当前配置处理请求

日常按规则分流时使用配置(Config)。它读取当前启用的配置，依照规则的匹配顺序决定请求是交给代理、直接连接还是执行其他动作。因此，选中 Config 前，应进入 Config 确认当前使用的是哪份配置，而不是仅确认列表里“存在一份文件”。刚导入的文件与正在启用的文件可能不同，改错文件不会改变当前连接行为。

如果你已有自己的配置，先保留备份再启用，不要把网上零散规则直接堆到末尾。像 DOMAIN-SUFFIX、GEOIP、FINAL 这样的规则关键字具有不同匹配范围，前面的规则可能已经处理了请求，后面的规则便不会继续匹配。此页只要求确认启用关系与基本路径；具体语法与概念可进入术语手册阅读。

代理(Proxy)与直连(Direct)：用于明确路径对照

代理(Proxy)适合临时检查所选代理路径是否可用，不依靠普通规则逐条决定去向。它不意味着服务器一定可达，也不保证每一种应用行为都会按同样方式工作。直连(Direct)用于让请求走直接连接路径，适合比较本地网络结果；选择 Direct 后，不能把“应用开关已打开”理解成“请求正在使用代理”。

初次排查时，可先使用 Proxy 对照一个明确目标；确认代理路径可用后，再切回 Config 验证分流。不要把临时排查模式长期当作已经完成的规则设置。每次模式切换后，用同一个页面重新测试并记录差异，这样下一步出现问题时，才能区分是服务器本身不可用，还是规则选择了不同路径。

打开开关连接并完成系统授权

确认 Home 中选中了预期服务器，Global Routing 也符合本次目标后，打开 Home 顶部的连接开关。首次连接时，iPhone / iPad 可能显示添加 VPN 配置的系统提示。确认提示由 Shadowrocket 发起，再允许添加，并按照系统要求使用设备密码或身份验证完成操作。系统授权属于建立连接所需的权限，不是购买确认，也不会为已有服务器补齐缺失字段。

授权完成后回到 Shadowrocket，检查开关是否保持开启。如果开关立即关闭、持续停留在连接中，或再次出现权限提示，先停止反复点击。查看提示文本，确认上一次系统授权是否真正完成；若之前取消过，重新发起连接并完成授权即可。不要在不清楚用途的情况下删除设备上的配置，尤其是由工作或学校管理的设备，应先确认其管理限制。

连接测试期间，先停止其他可能占用系统 VPN 连接的服务，再单独启用 Shadowrocket，减少相互切换造成的干扰。若系统设置显示连接状态与应用不同步，可以先在应用内关闭连接，等待状态恢复，再重新打开。每次操作之间留出状态切换时间，连续快速拨动开关通常只会让失败发生的位置更难辨认。

系统的 VPN 标识只能说明相应网络连接已建立，不能单独证明目标网页已通过预期规则。不同设备布局下，状态标识的位置与显示方式可能不同，不必为了寻找一个图标而反复重连。接下来应使用应用测试与实际请求交叉确认，而不是只看开关颜色。

首次验证时暂时不要额外调整 On Demand。它用于依据条件触发连接，不负责修正服务器地址、认证信息或规则错误。先把手动开启、手动关闭这一条流程验证清楚，再根据自己的网络使用习惯设置自动触发条件。这样若之后出现自动连接问题，也能直接与已验证的手动流程比较。

用 Connectivity Test 与实际请求验证

保持连接开启，在 Home 使用 Connectivity Test 检查所选服务器的基本可达性。测试结果可以帮助发现明显失败，但测试方法、测试目标与真实应用的访问方式并不完全相同。因此，出现测试结果不代表所有网站都能打开，测试失败也需要结合实际请求判断，不能直接据此删除整组订阅。

随后打开浏览器，访问一个你平时使用、且能明确判断是否加载完成的页面。先看页面主体能否出现，再尝试站内跳转或重新载入，避免只看到缓存内容就认定连接成功。若测试目标本身正在维护，换一个已知可用的目标复测；不要使用来历不明的检测网页，也不要向检测服务提交订阅链接或服务器凭据。

需要验证规则分流时，切回 Config，确认当前启用的配置，再发起一次新的请求。结合应用中可查看的请求记录，核对目标域名、命中的规则以及实际处理去向。预期直连的请求应与 DIRECT 处理一致，预期代理的请求应与当前配置中的代理动作一致。若规则引用了策略，还要核对策略最终选择，而不是只看规则名称。

可以按照“关闭连接时的本地结果、Proxy 下的结果、Config 下的结果”做简单对照。每次只改变一个条件，保持同一设备、同一网络和同一测试目标。若 Proxy 正常而 Config 失败，优先看规则与配置；若两者都失败，先检查服务器参数与网络，而不是继续增加规则。对照完成后，恢复你日常需要的模式。

最后验证一次关闭与重开：先关闭连接，确认本地网络仍正常，再重新启用并重复实际访问。如果只有首次打开正常、切换网络后失败，记录发生问题的是 Wi-Fi 还是蜂窝网络。速度与稳定性需要结合使用场景判断，Connectivity Test 的单次结果不能直接换算成下载速度，更不应作为长期稳定性的结论。

按失败位置排查，不同时改动多项

排查顺序从本地网络开始，而不是从重装应用开始。关闭 Shadowrocket 连接，确认设备本身能够正常联网；如果 Wi-Fi 尚未完成网络认证，先完成认证页面，再重新连接。如果本地连接已经失败，修改服务器密码、规则或 DNS 通常不能解决根因。允许使用蜂窝网络时，可切换一次网络做对照，但要留意自己的流量使用情况。

导入失败：检查内容与更新结果

若 Subscribe 保存后没有服务器，重新检查链接是否被截断、是否混入空格，以及服务状态是否允许更新。已有分组中的旧条目仍然显示，不代表本次更新成功；应查看更新提示并确认内容是否符合预期。若链接返回的是登录页面或错误文本，先处理链接访问条件。向你的服务提供方反馈时，描述错误与发生时间，不要在公开位置附上完整私人 URL。

连接失败：先对照字段，再看网络

若某一服务器失败，打开其记录，对照已有信息检查协议、地址、端口、密码或其他认证字段。涉及 TLS 时，还要核对服务器要求的相关名称与传输选项，不能把所有可选项都打开作为尝试。若同一订阅内多个条目同时失败，先比较不同本地网络的结果，再判断是否需要向已有服务提供方反馈；不要仅因为单次测试失败就反复删除与重新添加。

开关已开但页面失败：区分规则与 DNS

先确认 Global Routing 不是 Direct，再比较 Proxy 与 Config 的表现。仅 Config 失败时，查看当前配置是否启用正确、目标是否被更早的规则处理、所引用策略是否可用。若表现为域名无法解析，应检查当前 DNS 设置与网络条件，而不是随意填入多个地址。调整前保存原值，每次只改一项；恢复后能否复现，也是判断修改是否有效的重要依据。

如果浏览器正常而某个应用失败，还需考虑该应用自身的缓存、连接复用、服务状态与访问要求。先完全结束并重新打开目标应用，再发起新的请求，不要直接推断为整个连接失效。相反，如果所有目标都失败，应回到服务器、系统授权和本地网络三个基础条件检查，避免在单个应用设置里绕圈。

保留可复现的信息后继续深入

有效的排查记录应包括：使用 Wi-Fi 还是蜂窝网络、当前 Global Routing、失败发生在导入还是实际访问、是否所有服务器都相同，以及最近改动了哪一项。分享记录前遮盖订阅认证内容、密码和可识别个人的信息。涉及错误提示的进一步说明见疑难解答；需要整理多组订阅、安排更新与备份时，转到订阅指南继续操作。

完成这五步后，应能明确说出当前选中了哪个服务器、采用哪种模式、系统连接是否建立，以及实际请求是否符合预期。以后修改配置或更新订阅，也按相同顺序复测即可。先保存一份已验证可用的配置，再开展更细的规则调整，比同时更换多项设置更容易保留稳定的参考状态。