Shadowrocket
使用教程

打开 Shadowrocket，进入 Home，找到 Add Server。操作前先确认拿到的是订阅地址、单条服务器分享信息，还是完整配置文件：订阅用于维护一组服务器条目；单台服务器参数用于创建一个连接；配置文件则可能包含规则与其他设置。三者用途不同，不要把整份配置内容当作 Host，也不要把网页说明地址误填成订阅地址。

已有订阅：选择 Subscribe

在 Add Server 中点 Type，选择 Subscribe，再把自己的完整订阅链接粘贴到对应地址输入栏，检查后保存。地址中的路径、参数和大小写都应按原始资料保留；尤其留意复制时混入的空格、换行或中文标点。订阅地址可能包含访问凭据，不要把它发到公开留言、截图或公开日志里。

保存后返回 Home，等待订阅内容获取完成。查看对应分组中是否出现服务器条目；如果仅看到订阅分组而没有可选条目，应先检查订阅更新结果，不能直接把“保存成功”理解为“已经获取到服务器”。以后更新订阅前，留意自己对条目所作的本地修改；远端内容重新获取后，条目与参数可能随之变化。

已有服务器信息：按 Type 填写字段

如果持有的是单台服务器参数，在 Add Server 的 Type 中选择与原始资料相符的协议，再填写 Host、Port 和所需的认证字段。官方截图展示了包含 Password、Method 的一种表单；不同 Type 所需字段不同，不是每种协议都填写相同内容。Host 通常是服务器域名或地址，不应自行添加网页路径；Port 按原始数字填写，Password、Method 等按资料逐项核对。

如所选 Type 还需要 TLS、传输方式或其他参数，也应沿用已有资料，不能仅凭名称猜测。遇到 WireGuard 等字段结构不同的协议，不要照着截图强行套用 Password、Method。若自己的资料是二维码，可使用 Scan QR Code；Import from Cloud JSON 只适用于对应格式的已有内容，不是粘贴任意链接的通用入口。

保存后回到 Home，在 SERVER 或相应订阅分组中找到新条目，点选准备使用的那一个。此时先不要连续导入大量重复条目，也不要同时改动所有参数。保留一条来源清楚、字段可核对的配置，便于接下来验证连接。如果导入结果与预期不符，应先解决资料类型或字段问题，再进入路由模式设置。

添加服务器后，回到 Home，点 Global Routing。这里的三种常用姿态是配置(Config)、代理(Proxy)、直连(Direct)。先明确本次测试的目的，再选择模式；不要把“已选中服务器”与“所有请求都经过该服务器”当作同一件事。模式会改变请求的处理方式，也是后续排错时需要记录的关键设置。

Config：按照当前配置中的规则处理

日常需要规则分流时，选择配置(Config)，再进入 Config 页面确认正在使用的配置文件。配置文件列表与文件编辑页不是同一个层级：先确定当前使用的文件，再打开它查看内容；编辑了另一份文件，不一定会影响当前连接。官方截图展示的是配置文件编辑页，能看到 General、Rule、Hosts、URL Rewrite、HTTPS Decryption 等分段以及 Add Rule。

入门阶段先关注 Rule 对应的规则内容。规则通常自上而下匹配，命中后采用该条策略；FINAL 用于前面的规则都未命中时收尾。PROXY、DIRECT、REJECT 分别表示代理处理、直接连接和拒绝请求。配置文件可以包含更多选项，但“能看到很多设置”不意味着每项都需要修改，尤其不要为了首次连接测试去开启与目标无关的处理功能。

# 独立教学示例，理解后再合并到自己的配置
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,DIRECT

上面的示例让 example.com 及其子域名走 PROXY，让所列本地网段走 DIRECT，其余请求落到 FINAL,DIRECT。它仅用于说明匹配顺序，不是建议直接替换整份现用配置。示例域名不是连接服务器，PROXY 也不会自动创建服务器条目。修改前先备份现用文件，避免覆盖原有规则。

Proxy 与 Direct：用于理解差异和对照测试

代理(Proxy)让路由处理以代理为主，适合暂时排除普通分流规则对测试结果的干扰；但不应据此认定所有系统流量都必然经过代理。直连(Direct)让请求以直接连接方式处理，不能用它来证明所选代理服务器正常。若 Proxy 能访问而 Config 不能，优先检查当前配置与命中规则；若两者都失败，则继续检查服务器参数和网络条件。

完成模式选择后，记下当前使用的是哪份配置、哪一个服务器、哪种 Global Routing 姿态。后续测试只改变一个条件，才容易判断原因。规则类型、优先级和配置分段的深入说明见规则与配置参考；本页先保持最少调整，继续完成连接。

完成前两步后回到 Home，再检查一次当前选中的服务器条目和 Global Routing。订阅中有多个条目时，导入完成不一定意味着已经选择了预期服务器；点选后确认选择状态，再操作顶部连接开关。不要一边更换服务器、一边编辑规则并反复开关，否则很难确定哪一步造成了变化。

首次连接的系统提示

顶部显示 Not Connected 时，打开连接开关。首次使用可能出现系统请求添加 VPN 配置的提示；确认是自己刚刚在 Shadowrocket 内主动发起的操作，阅读提示后允许，并按系统要求完成设备验证。这个授权用于建立应用所需的网络隧道，不等于订阅获取成功，也不代表服务器已通过验证。此前若取消过授权，再次打开连接时应留意系统是否重新提示。

如果开关立即退回关闭状态，先查看有没有尚未处理的系统弹窗，再确认当前条目有效。也可到设备系统设置中的 VPN 相关位置检查配置是否存在、是否受到设备管理限制；不熟悉的其他配置不要随意删除。对受管理的设备，应遵循设备管理要求处理，不能仅靠反复打开开关解决权限问题。

连接状态与可用性分开判断

授权完成后等待状态变化，避免在建立连接的过程中连续点击。系统显示 VPN 状态、应用显示连接已开启，只能说明相应隧道状态，并不能证明每一个目标都能访问。代理认证错误、目标 DNS 解析失败或规则选择不符合预期，都可能在开关保持开启时出现。因此下一步仍需运行 Connectivity Test，并进行实际访问验证。

首次验证时保持当前网络稳定，暂时不要主动在 Wi-Fi 与蜂窝网络之间来回切换。若已有其他会建立 VPN 连接的设备功能，先确认系统当前实际使用的是哪一项，避免把连接被替换误认为服务器失效。测试结束需要关闭时，回到 Home 关闭顶部开关，并确认状态回到未连接。

如果连接能保持开启，先进入下一步检查实际请求；如果始终无法保持开启，直接跳到失败点排查，从授权与基础配置开始。此时更改大量 Rule 通常不是有效的第一步，因为连接尚未建立，尚不能判断规则分流是否符合预期。

排错前先确定失败发生在哪一层：没有导入条目、开关无法保持开启、测试与访问都失败、只有部分目标失败，还是切换网络后中断。把现象分开，比反复删除重建更容易保留线索。以下按从基础到具体的顺序检查，已经确认正常的一层不必每次重新修改。

导入失败：先回到原始资料

Subscribe 保存后没有条目时，检查链接是否完整、对应地址是否仍有效，以及当前基础网络能否访问订阅内容。订阅获取与连接服务器是两个独立过程，旧条目能连接并不意味着更新地址一定可达。手动添加后失败时，把 Type、Host、Port、认证字段与传输参数逐项对照原始资料；不要凭记忆重填，也不要靠随机切换 Method 尝试修复。

连接失败：先查授权、基础网络与参数

开关立即关闭时，先处理系统 VPN 授权或配置限制。开关保持开启但所有测试失败时，先关闭连接，检查设备本身的网络是否可用，再恢复连接复测。条件允许时可换到自己可使用的另一种网络做对照；若仅在某一网络失败，应保留这一差异，不要把原本正确的全部参数改掉。服务器认证与传输条件仍需按自己的资料确认。

部分目标失败：查模式和规则

只有个别目标异常时，先看 Global Routing，再对比 Config 与 Proxy 的结果。检查当前文件中相关 DOMAIN、DOMAIN-SUFFIX、IP-CIDR 及 FINAL 的顺序和策略，尤其留意更靠前的规则是否已提前命中。若涉及 DNS，先记录现用配置和错误现象，再检查相关设置；更换 DNS 并不是对所有失败都有效的通用步骤。

Settings：确认测试条件与自动连接行为

进入 Settings，查看 Test Method，确认测试使用的方法是否适合当前排查目标。不同方法可能得到不同结果，切换方法后应说明测试条件发生了变化，不能把两次结果直接当成同一种测量。Language 可用于核对界面语言；Today Widget 不是基础连接成功的前提，入门测试不需要先调整它。

On Demand 决定符合条件时如何触发连接，不负责替代服务器参数或 Rule。若现象是切换网络后自动连接与预期不一致，检查已有的 On Demand 条件；先用手动连接确认基础链路正常，再调整自动触发。不要为了修复一次无法连接，就同时开启所有自动行为，导致无法判断究竟是谁触发了重连。

Diagnostics 可辅助查看排查信息，分享前需检查其中是否含服务器地址、访问目标或认证相关内容。Settings 中的 Proxy、TCP、UDP 是进一步检查时的入口，不意味着它们都需要更改。涉及特定协议的选项，应结合自己的配置条件阅读，不要仅因某个选项名称出现在截图中就修改默认值。

恢复可用状态后再整理配置

每次修改后，用之前相同的目标与方法复测；没有改善就恢复原设置，再检查下一项。找到有效调整后，记录原因，清理测试时创建的重复条目，并确认 Global Routing 与 On Demand 已回到预期状态。更复杂的配置分段、规则优先级与策略写法，继续阅读规则与配置参考；如果需要重新走一遍操作链，可返回添加与导入，按本页顺序逐步核对。