Shadowrocket 使用教程

打开 Shadowrocket，进入 Home。首次使用时，SERVER 分组可能还没有记录。点右上角添加入口，打开 Add Server。接下来只选一种导入方式：已有订阅链接就按订阅流程操作；已有单台服务器的完整字段，就手动填写。订阅地址与服务器地址不是同一种资料，不要把两者填进同一个字段。

已有订阅链接：选择 Subscribe

在 Add Server 中点 Type，选择 Subscribe，再把自己的完整订阅地址填入 URL 对应的输入栏。为这条订阅填写便于辨认的名称，检查复制时是否多出空格、换行或引号，然后保存。订阅地址常带有访问凭据，应按私密信息保管，不要把它发到公开讨论区，也不要用截图展示完整链接。

保存后返回 Home，等待订阅内容读取完成。成功读取时，会出现该订阅对应的服务器记录。检查名称是否符合预期，并选择其中一条作为后续测试对象。如果只留下订阅分组而没有服务器，先不要打开连接；确认链接能够读取、服务状态有效，再尝试更新。订阅用于维护服务器列表，不等于已经选好了用于分流的 Config。

已有服务器字段：按 Type 逐项填写

手动添加时，先在 Type 选择资料对应的协议，再填写 Host、Port 以及该协议需要的认证字段。截图展示了 Password、Method 等字段，但不同 Type 的表单并不相同。例如使用 UUID 的配置不能套用密码字段的填写方法；涉及 TLS、传输方式或服务器名称时，也要与原始资料逐项对应，不凭经验补值。

Host 填服务器域名或地址，不附加网页路径；Port 按资料填写。Password、UUID 等认证内容注意大小写及首尾空格。只有资料明确要求时才修改其他选项。若拿到的是二维码，可在 Add Server 使用 Scan QR Code 读取，并在保存前复核识别出的字段。Import from Cloud JSON 属于另一种配置来源，不应把普通订阅地址随意填入。

本步核对点：返回 Home 后能看到服务器记录，且选中的条目来自你刚导入的资料。若不清楚 Type、Subscribe 与 Config 的区别，先查名词解释。确认记录完整后，下一步再选择 Global Routing，而不是直接改动多个连接设置。

导入服务器后，回到 Home，点 Global Routing。这里决定连接开启后如何处理流量，与 SERVER 中选择哪台服务器是两个不同的问题。三种姿态分别是配置(Config) / 代理(Proxy) / 直连(Direct)。测试时记下当前选择，后面的访问结果才能与模式对应。

配置(Config)：按配置文件的规则处理

日常需要按域名或地址分流时，使用配置(Config)。进入 Config 页面，确认已有并选中了准备使用的配置文件。打开配置文件后，可以检查 General、Rule、Hosts 等分段；Rule 中的规则决定请求命中后采用什么策略。仅把配置文件导入列表，并不能证明它已经成为当前使用的配置，应返回列表核对选中状态。

如果没有准备好的 Config，不要认为订阅导入时会自动生成适合所有场景的规则。先明确已有配置的来源与用途；首次诊断服务器可用性时，可以暂时使用代理(Proxy)做对照，验证后再回到配置(Config)。不要为了完成教程而直接覆盖已有文件，也不需要在首次连接时开启 HTTPS Decryption 或添加 URL Rewrite。

代理(Proxy)与直连(Direct)：用于区分处理路径

代理(Proxy)让由客户端处理的流量采用代理路径，适合排查服务器本身是否可用。它不意味着每个应用的所有请求都能被统一验证，也不替代服务端能力检查。直连(Direct)则采用直接访问路径；选择它时，网页能打开不能证明所选服务器已经生效。需要比较时，在同一网络、同一测试页面下只切换这一项，记录结果差异。

理解规则时，先看匹配条件，再看末尾策略。下面是规则语法示例，不是可直接覆盖当前 Config 的完整配置。PROXY 的实际目标还需与配置中的策略定义及当前服务器选择一致。

DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

规则通常按顺序检查，前面的命中会影响后续规则是否参与判断；FINAL 用于未命中前序规则时的处理。因此同一个服务器，在不同 Config 下可能出现不同网站的访问结果。首次上手先保留少量、明确的验证目标，不急着扩大规则范围。更细的规则问题可转到问题诊断。

本步核对点：知道当前使用哪种 Global Routing 姿态；若选配置(Config)，还应知道当前选中的配置文件。记录这两项后，再执行连接授权。

回到 Home，在 SERVER 列表里点选要使用的服务器。若列表中有多条记录，先用一条你确认资料完整、服务状态有效的记录，不要在第一次测试时反复切换。检查 Global Routing 仍是上一步选好的姿态，再打开 Home 顶部的连接开关。截图中的 Not Connected 表示尚未建立连接，并不是服务器名称。

首次建立连接时，iPhone 或 iPad 可能显示添加 VPN 配置的系统提示。这是系统为应用配置网络连接所需的授权步骤。阅读提示，确认操作由刚才打开 Shadowrocket 开关触发，再按系统要求完成设备验证。若取消了提示，返回应用重新发起连接即可；不要因为开关未保持开启，就立即删除服务器或重置全部设置。

系统授权和服务器认证是两回事。前者允许设备使用相应的 VPN 配置，后者仍依赖 Host、Port、认证内容与服务端设置正确。完成授权后回到 Home，观察顶部连接状态是否改变、开关能否保持开启。系统的 VPN 标识因设备布局与显示位置不同而有所差异，不必把某一个状态栏图标作为唯一判断依据。

如果开关刚打开就关闭，先确认系统授权已完成，并检查是否有其他正在管理连接的 VPN 配置、设备管理限制或 On Demand 设置影响当前操作。首次手动验证期间，先记下已有 On Demand 设置，避免自动触发行为干扰判断。不要在不了解用途时移除设备上的其他配置，尤其是受管理设备中的设置。

如果开关能够保持开启，先停留在当前服务器与当前模式，不立即调整 DNS、TCP 或 UDP 选项。连接状态只说明本地连接流程已有进展，不代表网页访问一定成功。下一步用 Connectivity Test 和实际页面访问分别检查，才能判断问题停在哪个环节。

本步核对点：SERVER 中有明确选中的条目，系统授权已完成，连接开关保持开启。若每次都卡在授权或开关阶段，直接进入本页的常见失败点，先解决连接建立问题。

出现异常时，先停止连续修改设置。关闭 Shadowrocket 连接，确认设备的基础网络本身可以访问平时可用的页面；公共 Wi-Fi 如需完成网络登录，应先完成这一步。之后重新连接，按下面对应的现象继续。每次只改变一个条件，并重复第四步的同一项验证。

订阅保存了，但没有服务器记录

重新检查 URL 是否复制完整、订阅是否仍然有效，以及当前网络能否读取订阅内容。不要把普通网页地址误当成订阅链接，也不要反复把同一链接添加成多个分组。若之前已有可用列表，更新失败时先保留记录，确认原因再整理。链接权限、有效期或返回内容异常，需要根据你已有服务商提供的信息核对，客户端不能自行补齐缺失的服务器资料。

服务器测试超时，或连接后无法访问

先对照原始资料检查 Host、Port、Type 和认证字段，再看 TLS、传输方式等附加项是否一致。超时通常提示需要继续检查可达性，但不能仅凭这个结果断定密码错误。切换 Wi-Fi 与蜂窝数据做一次对照时，保留其他条件不变；若仅某种网络失败，记录差异，不立即覆盖 Config。系统化流程见服务器超时排查。

如果 Connectivity Test 有结果，而网页仍打不开，检查 Global Routing 是否误选直连(Direct)，或配置(Config)中是否把目标交给了不符合预期的策略。确认规则之后，再检查 DNS。不要一开始就同时更换解析设置与服务器，否则即使恢复访问，也无法确定是哪项修改起了作用。

设置变化后，测试结果不一致

进入 Settings，核对 Test Method；改变测试方法后，前后结果不能直接当作同一指标比较。Diagnostics 可用于进一步收集排错线索，但首次上手不需要随意改动 Proxy、TCP、UDP 等分组内的选项。若刚调整某项就出现异常，优先恢复那一项，再重复原来的测试，不必清空整个应用。

On Demand 可能根据条件触发连接，因此手动关闭后又连接的现象，需要结合它的设置判断。先完成手动连接验证，再配置自动触发条件。iPad 使用时也遵循同样顺序；窗口尺寸或横竖屏改变可能影响入口位置，但不改变订阅、服务器和 Config 各自的作用。

需要整理诊断信息时，保留错误提示、操作步骤和发生条件，移除订阅 URL、Password、UUID、真实服务器地址等敏感内容。截图也要检查是否包含这些信息。应用更新后的问题先记录当前设置，核对 App Store 的应用信息，再逐项复测，不凭单次失败认定配置已经失效。

本步核对点：能够说明失败发生在导入、授权、服务器可达性、规则还是实际访问阶段。基础问题可查问答；需要逐章检查 DNS、耗电或更新后异常时，转到问题诊断，不在上手阶段一次性调整全部高级选项。