Shadowrocket 使用教程
导入、连接与验证
以 iPhone / iPad 界面为例，沿着五个操作环节完成首次使用。先让一条已有服务器信息正确工作，再检查规则；不必在开始时逐项修改所有设置。
- 01 添加
- 02 选模式
- 03 连接
- 04 验证
- 05 排错
截图来自 App Store 官方素材，用于辨认页面与字段。实际排列可能随客户端调整，请以当前应用显示为准；不要照抄截图中的服务器资料。
Add Server：添加服务器或导入订阅
打开 Shadowrocket，先到 Home。尚未添加资料时，SERVER 分组中没有可选择的服务器属于正常情况。点击 Add Server 进入添加页面，再按手中资料选择导入方式：订阅链接、单条分享信息、二维码和手动字段并不是同一种输入，不要把一整条订阅链接填进 Host。
使用已有订阅链接
进入 Add Server 后点击 Type，选择 Subscribe，在相应的 URL 输入位置粘贴完整订阅链接。粘贴前后检查是否带入换行、空格或聊天消息中的说明文字，尤其不要遗漏链接末尾的参数。填写便于自己辨认的名称后保存，等待客户端获取并解析内容，再回到 Home 检查 SERVER 中是否出现条目。
保存成功只代表输入已被保存，不代表订阅一定已下载成功。如果条目没有出现，先检查当前网络能否访问订阅地址，以及链接是否仍有效；不要连续建立多个相同订阅来尝试修复。订阅返回的内容必须是客户端能够解析的连接资料，网页提示、登录页面或错误文本不能直接当作服务器列表。
使用单条服务器信息或二维码
手动添加时，先在 Type 选择与资料一致的协议，再填写 Host、Port 及该协议需要的其他字段。例如 Shadowsocks 需要核对 Password 与 Method；其他协议可能显示不同的身份或传输设置。字段不确定时应回到原始资料核对，不能凭名称猜测，也不要把某一协议的密码填进另一协议的身份字段。
若已有二维码，可在添加页使用 Scan QR Code，按系统提示授予相机权限，识别后仍需检查 Type 与服务器字段。Import from Cloud JSON 是另一种导入入口，不等于 Subscribe，也不适合随意粘贴普通订阅链接。完成一种添加方式即可，不必把所有入口都操作一遍。
最后回到 Home，在 SERVER 中点选一个确实拥有使用权限的条目，确认选中状态。列表中出现很多名称并不等于它们全部可用；先保留一个明确的测试对象，下一步再选择请求如何处理。
Global Routing：选择三种姿态
服务器已经选好后，回到 Home 点击 Global Routing。这里决定请求采用哪一类处理方式，而不是切换服务器协议。三种姿态分别是配置(Config)、代理(Proxy)、直连(Direct)。先明确本次测试目的，再选择对应项，避免一边排错一边反复切换却没有记录。
配置(Config)按当前配置文件中的规则决定请求去向，适合需要规则分流的使用方式。使用前打开 Config，确认已有并启用了适用的配置文件。订阅导入通常用于取得服务器条目，不应据此认定完整的规则配置也已准备好；服务器列表与配置文件需要分别检查。
代理(Proxy)用于按该模式经所选代理处理请求，可作为短时对照测试：若同一目标在 Proxy 下可访问、在 Config 下不能访问，优先检查规则与策略。它不是修复错误凭据的方法，也不能保证所有应用行为都相同。完成对照后，应恢复自己原本需要的模式。
直连(Direct)用于直接连接，不以“已打开开关”来判断请求一定经过所选服务器。若原本想测试代理连接却选择了 Direct，浏览器能打开普通网页也不足以说明服务器可用。模式、所选条目和实际命中策略是三个需要同时确认的条件。
首次使用先理解一段规则
Config 页面中可以查看 General、Rule 等分段；本次只需理解 Rule 的匹配顺序，不必修改 HTTPS Decryption 等无关设置。下面是教学片段，不是可直接替代完整配置的成品：
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY第一行让匹配 example.com 及其子域名的请求使用 PROXY；后续 GEOIP 规则匹配时使用 DIRECT；仍未命中前序规则的请求交给 FINAL。规则从上到下检查，命中后采用该行策略，FINAL 因此放在最后。实际的 PROXY 还需有可用的代理选择，规则文字本身不会创建服务器。
本步完成标准是：能够说清当前选了哪种模式，以及使用 Config 时启用了哪个配置。规则类型、REJECT 与配置段的完整说明请看配置大全，这里先保持设置稳定，继续进行首次连接。
Home：打开顶部连接开关
回到 Home，按顺序检查两件事：SERVER 中已有选中的服务器，Global Routing 显示刚才确定的模式。随后打开页面顶部、初始显示 Not Connected 附近的开关。先完成这一步，再观察浏览器，不要把添加成功与连接成功混为一谈。
首次连接时，iPhone / iPad 可能弹出添加 VPN 配置的系统提示。阅读提示，确认这是刚刚由 Shadowrocket 发起的操作，再选择允许，并按系统要求使用设备密码或身份验证。系统授权用于建立本机网络连接配置，不是在购买额外线路，也不需要把订阅密码填写进系统身份验证窗口。
如果此前选择了取消，开关没有保持开启，并不一定是服务器失效。再次打开开关，观察是否重新出现授权提示；必要时到系统设置中搜索 VPN，检查已有连接配置与当前状态。排查时暂停其他正在使用的 VPN 连接，避免另一项连接接管流量；不要在没有记录的情况下批量删除设备上的配置。
授权完成后返回 Home，等待顶部状态变化。开关打开后又立即关闭时，先停留在当前页面记录提示文字，再检查系统授权和服务器字段。此时连续切换十几个条目只会增加变量，不利于区分是配置问题还是某一条连接资料的问题。
设备出现 VPN 状态标识，说明系统连接状态发生了变化，但不证明所有请求都走 PROXY，也不证明订阅中的每个服务器都可访问。Global Routing 仍可能是 Direct，Config 也可能让部分请求使用 DIRECT。保持应用连接开启，下一步用测试与实际访问共同验证，而不是仅凭一个状态标识作结论。
本步完成后，暂时不要开启 On Demand。先把手动连接、断开与重新连接验证清楚，再考虑按需自动连接，便于以后区分手动操作和自动触发行为。
验证：测试、访问与规则记录
步骤 04 · 把“已连接”与“按预期处理请求”分开确认。
先做 Connectivity Test，再做实际访问
连接保持开启时，在 Home 使用 Connectivity Test。测试反映的是当前测试方法和测试目标下的可达性，不代表每个网站、每个应用或所有传输方式都正常。测试有响应时，继续打开浏览器访问一个自己知道应当可用的页面；测试超时时，也先记录结果，不要立即得出整个订阅都失效的结论。
实际访问时尽量使用新打开的页面并重新加载，避免浏览器缓存让结果看似没有变化。先测试一个目标，再测试另一个用途不同的目标，不要一次打开大量页面。若某个目标失败而其他目标正常，需要继续判断目标本身、域名解析或规则是否存在差异，而不是立刻重装客户端。
检查请求是否命中预期策略
需要验证分流时，打开客户端的请求记录或 Data 中可用的记录视图，找到刚刚发出的请求，核对目标域名、命中规则及策略。想验证 PROXY，就应看到相应请求使用 PROXY；如果记录显示 DIRECT，先回到 Global Routing 与当前配置检查原因。界面没有展示足够信息时，可在下一步使用 Diagnostics 收集对应诊断线索。
用相同目标做一次短时对照更有价值：保持服务器不变，仅将 Config 切换到 Proxy 再访问。如果结果改变，说明应优先检查配置分流；如果两种模式都失败，则继续核对服务器、网络和目标。对照完成后恢复原模式，并记下结果，避免把临时测试模式长期保留。
最后关闭连接，再重新开启并重复一次访问。这样可以确认成功不是由先前缓存或临时状态造成。确认手动连接稳定后，才进入日常使用；自动连接、复杂规则与更多设置可稍后逐项增加。
Settings：按失败环节排查
遇到问题先定位停止在哪一步，再进入 Settings 查看相关设置。这里的 Test Method 影响测试方式，Diagnostics 用于诊断；它们不能替代正确的服务器字段。先记录现象、当前网络、Global Routing 和所选条目，修改一个条件后重试，才能知道是哪项变化起了作用。
导入后没有出现服务器
回到 Subscribe 检查链接是否完整，是否复制成了网页地址，是否带入空白字符，订阅是否仍在有效期内。若客户端提示获取失败，先确认当前网络可访问该地址；若提示解析失败，核对返回内容格式。必要时向原资料提供方确认链接状态，而不是把链接公开贴到讨论区。订阅链接可能包含访问凭据，应按密码同样保护。
开关无法保持开启
先查看系统 VPN 配置授权是否完成，再核对 Type、Host、Port 与协议所需字段。留意错误发生在授权之前、刚连接时还是等待一段时间之后。若另一项 VPN 正在运行，先暂停后重试；若设备由单位或学校管理，系统策略也可能限制更改，应遵循设备管理要求，不要反复删除管理设置。
显示已连接，但页面打不开
确认 Global Routing 不是误选 Direct，再用 Connectivity Test 与实际页面做交叉检查。保持配置不变，换到自己可用的另一种网络测试，例如在 Wi-Fi 与蜂窝网络间切换；若表现不同，记录对应网络条件。只有部分域名失败时，检查 DNS 与命中规则；两种模式均失败时，优先核对服务器状态、凭据和目标可达性。
访问正常，但分流不符合预期
回到 Config 确认启用的是刚刚检查的文件。检查较宽泛的规则是否放在具体规则之前，FINAL 是否在末尾，以及规则中的策略是否符合目的。不要为了修复一条匹配而同时更改 DNS、协议、服务器和所有规则；先用一个域名复现，再根据请求记录调整对应规则。
准备求助时，可整理错误提示、复现步骤与已尝试的对照结果。截图或诊断记录分享前，要遮挡订阅链接、密码、身份字段和服务器访问凭据；记录中也可能包含访问域名，应先检查再提交。更细的订阅、网络和账号问题可按类别查阅常见问题，规则语法则转到配置大全。
完成首次连接后，保留一份能够正常工作的配置记录。以后更新订阅、调整规则或启用 On Demand 时，仍按“改一项、测一次、记录结果”的顺序进行，失败后即可回到上一份已验证的设置，而不必从安装开始重做。
