Shadowrocket 使用教程
按添加、模式、连接、验证、排错的顺序操作。先完成一条可核对的连接，再调整规则或自动连接条件；本页只讲首次使用所需的设置。
阅读顺序：第一次配置从第 01 步开始；已经打开开关但访问异常，可直接从第 04 步核对。需要理解协议参数时，再转到协议手册，不必在首次连接前逐项修改高级设置。
Add Server / Subscribe
选择与你已有资料对应的入口，保存后先核对 SERVER，不急着打开连接。
打开 Shadowrocket，进入 Home，找到 Add Server。开始填写前，先分清手中的资料是哪一种：单个服务器的地址与认证参数、一个可更新的订阅链接，或包含服务器信息的二维码。三种资料的用途不同，不应把订阅链接整段填进 Host，也不应把普通网页地址当作订阅内容导入。
手动填写已有服务器信息
进入 Add Server 后，先点 Type，选择与你已有服务器信息一致的协议。类型决定后续需要填写哪些字段；截图展示的是一组具体字段，并不表示所有协议都需要同一组参数。按资料填写 Host、Port 及对应认证信息；只有所选类型要求时，才填写 Password、Method 等项目。
逐项比对时，尤其注意地址前后是否夹带空格、端口是否完整、认证内容是否区分大小写。服务器地址、用于 TLS 验证的名称及其他传输设置不一定相同，不能因为看起来相似就互相替换。资料没有要求的高级项目先保持原状；遇到不认识的字段，查看协议手册中的参数说明，不要用猜测的值补齐。
通过 Subscribe 导入已有订阅
如果已有完整订阅链接，在 Add Server 的 Type 中选择 Subscribe，将链接填入对应的 URL 字段，确认复制内容没有截断或夹入说明文字，再保存。订阅地址可能包含用于访问个人订阅的认证内容，应作为私人信息保管，不要直接粘贴到公开求助文字或截图中。
保存后返回 Home，查看对应订阅分组及其中的服务器条目。若暂时没有内容，检查订阅的更新状态，并使用订阅条目提供的更新操作重新获取一次；随后再看列表是否变化。保存成功只表示添加了记录，不代表远端内容一定能读取，也不代表返回内容一定可被解析。持续为空时应先查完整链接与订阅状态，而不是反复添加同一条记录。
使用 Scan QR Code 前先核对类型
已有二维码时，可使用 Scan QR Code，按系统提示给予本次扫描所需的相机权限。读取后检查导入的是单个服务器还是订阅，并核对协议、地址等内容。Import from Cloud JSON 是另一种数据导入入口，只在已有与该入口匹配的资料时使用；它不是所有订阅链接的通用粘贴位置。
本步完成的标志是：SERVER 中能看到与你已有信息相符的条目，且能够打开并核对字段。此时先保留一个明确的测试对象，继续设置 Global Routing。服务器条目、订阅与配置文件的区别，可在术语表中查阅。
Global Routing 三种姿态
配置(Config) / 代理(Proxy) / 直连(Direct)。先明确当前模式，再判断访问结果。
服务器资料保存好后，回到 Home，点开 Global Routing。这里决定流量采用哪种处理方式，不是选择某个服务器的替代入口。首次排查时，应记住当前选项；否则同一条服务器信息在不同模式下可能表现不同，容易把规则问题误当作服务器问题。
配置(Config)：按当前配置处理
需要规则分流时使用配置(Config)。在这一姿态下，应同时查看 Config 中当前使用的配置文件，确认其中的规则与策略符合预期。导入订阅主要解决服务器列表的管理，不等于自动获得一套适合所有用途的规则。仅看到服务器列表已经出现，还不足以判断当前配置会如何处理某个请求。
官方截图中的配置编辑页包含 General、Rule、Hosts、URL Rewrite、HTTPS Decryption 等分段。首次上手先识别 Rule 与 Add Rule 的位置即可，不必逐项编辑。尤其不要为了完成基础连接而启用与当前任务无关的处理项目。
检查规则时，先看顺序，再看命中后的策略。DOMAIN-SUFFIX 用于域名后缀匹配，GEOIP 涉及 IP 地理归属匹配，FINAL 是前序规则均未命中时的最终策略；DIRECT、PROXY、REJECT 则会影响请求的处理结果。这里的 PROXY 是规则策略关键字，应与 Global Routing 中的 Proxy 模式区分。
代理(Proxy)：用于服务器路径对照
代理(Proxy)用于让流量按代理方式处理，可在排查时作为对照。保持同一个服务器不变，临时切换到这一姿态，再尝试同一个页面。如果代理(Proxy)可以访问而配置(Config)不行，下一步应重点核对当前配置、规则命中与相关设置，而不是立即重填所有服务器参数。它不表示任何服务器都一定可用，也不能替代实际访问验证。
直连(Direct)：核对本地网络
直连(Direct)用于按直连方式处理流量，可以帮助确认当前 Wi-Fi 或蜂窝网络的基础访问是否正常。在这个姿态下，页面能够打开并不能证明已选服务器工作正常。对照结束后，返回预期使用的模式；需要规则分流就恢复配置(Config)，并记下当前 Config，再进行下一步连接。
本步只需确定“使用哪种姿态、哪份配置”。规则关键字的完整含义见术语表；不要在首次验证中同时更换模式、服务器和配置文件，否则难以判断是哪一个变化影响了结果。
Home：选择条目，打开开关
系统授权、开关状态和实际访问是三个不同的检查点。
回到 Home，先在 SERVER 分组中点选本次要使用的服务器，核对选中标记与条目名称。订阅里有多个条目时，不必逐个切换；先围绕一个资料完整的条目完成整套验证。然后再次看一眼 Global Routing，确认它仍是上一步选择的姿态。
在未连接状态下，顶部会显示 Not Connected。打开顶部连接开关后，首次使用可能出现系统添加 VPN 配置的授权提示。阅读系统提示，确认正在操作的是 Shadowrocket，再按照系统要求完成确认或设备认证。这个授权用于建立系统层面的网络连接配置，不会替你填写服务器地址，也不会补充订阅内容。
完成授权后返回应用，观察顶部开关与状态是否保持在连接状态。若此前取消了授权，应重新发起连接并查看系统提示，不必因此先删除已导入的服务器。若开关立即回落，先记录是否出现错误文字、是否刚切换网络，以及所选服务器是哪一条；这些信息比连续重复点击更有助于后续定位。
iPad 上也按同样的逻辑操作：先选条目，再看模式，最后打开连接。页面布局可能随设备与应用当前界面有所变化，以界面词和条目内容识别入口即可。首次测试期间，尽量保持当前网络不变，并避免同时开启其他会改变系统网络连接状态的配置。
需要停止本次连接时，返回 Home 关闭顶部开关，再核对状态。若稍后发现连接自动恢复，应到第 05 步检查 On Demand 条件，而不是把所有自动连接现象都判断为开关失效。
Connectivity Test 与实际访问
把“测试有结果”“页面能打开”“规则按预期处理”分别核对。
保持刚才选中的服务器与模式不变，在 Home 使用 Connectivity Test。等待结果返回后，再打开日常使用的页面，检查是否能完成加载。测试结果受测试方法、测试目标及当时网络状态影响；一个延迟数字不等于持续传输速度，也不能直接推导视频或所有应用的体验。
如果测试有结果但页面打不开，先确认测试与访问发生在同一个网络、同一个服务器和同一种模式下。有些页面还会请求其他域名，初始页面出现并不意味着全部资源都已成功加载。可再选一个平时能够正常访问的页面作对照，避免仅凭单个目标的结果判断整条连接。
在配置(Config)姿态下，还要确认请求是否走了预期策略。可结合应用中的连接记录查看请求与命中情况，再回到当前 Config 核对相关规则。若记录显示请求被 DIRECT 处理，页面可访问并不能作为所选代理服务器已生效的证据；若命中 REJECT，应先确认是否为当前配置的预期行为。
需要对照模式时，每次只改变 Global Routing 一项，保持服务器和测试页面一致。记录配置(Config)、代理(Proxy)、直连(Direct)下的差异，测试完成后恢复原先需要的姿态。不能仅凭页面外观判断访问路径，也不要为了获得某个测试数字连续更换全部设置。
当选中条目保持明确、开关状态稳定、实际访问正常，且配置(Config)下的处理路径符合预期时，本轮首次配置检查即可结束。之后再根据实际需要逐项调整规则或自动连接条件。若仍有异常，保留这组对照结果，继续按下一步缩小范围；更多现象说明见常见问题。
按失败位置逐项检查
先处理最早失败的一步。修改一项，复测一次，再决定是否继续。
列表为空：回到 Subscribe
若连 SERVER 条目都没有出现，先不要检查分流规则。打开对应订阅，核对 URL 是否完整、是否把说明文字一同复制、是否仍为当前有效链接，再确认更新操作是否完成。订阅返回的是登录网页或错误提示时，也可能无法生成服务器列表。应在自己的服务管理页面核对订阅状态，确认内容后再更新，避免连续重复导入造成混淆。
条目存在但测试失败：核对字段与测试方法
列表里有名称，不代表其中参数必然正确。重新打开该条目，按原始资料比对 Type、Host、Port 与认证信息；涉及 TLS 或其他传输字段时，一并检查是否有遗漏。随后在 Settings 查看 Test Method。不同测试方法反映的条件不同，单次超时不能独立证明所有访问都失败，应结合实际页面访问结果判断。
开关回落或自动变化：区分授权与 On Demand
开关无法保持时，先查看系统是否已经允许 VPN 配置，以及是否出现具体错误。若表现为关闭后再次自动连接，则检查 Settings 中的 On Demand 与已设置的触发条件。首次排错可暂时停用相关自动条件，观察手动连接是否稳定；排查结束后再决定是否恢复。不要在未记下原设置的情况下反复改动多个自动行为。
代理(Proxy)正常、配置(Config)异常：检查规则
这种差异应优先回到当前 Config，核对使用中的文件、规则顺序和最终策略。检查目标是否被过早匹配到 DIRECT 或 REJECT，以及 FINAL 是否符合预期。先依据连接记录定位具体请求，再修改对应规则；不要仅凭一个页面打不开就删除整份配置。
只有部分域名异常：再看 DNS 与网络差异
当同一服务器下部分页面可以打开、部分域名持续失败时，DNS 与规则都值得检查。先恢复近期改动过的相关设置，确认当前配置中是否存在专门的解析安排。切换 Wi-Fi 与蜂窝网络可以作为对照，但切换后要重新运行测试并注明网络变化。不要把地址栏改成任意 IP 作为通用验证办法，域名、TLS 验证与服务端行为可能因此一起改变。
使用 Diagnostics 时保留必要信息
Settings 中的 Diagnostics 可用于进一步查看诊断信息。记录出错步骤、模式、测试方法、错误文字及是否仅影响特定请求，通常比笼统描述“不能用”更有帮助。对外展示记录前，遮去订阅 URL、认证字段与个人连接信息；保留用于说明问题的界面词和错误内容即可。
完成排查后，恢复临时改动，重新执行“选服务器 → 核对模式 → 打开连接 → 测试与访问”的顺序。如果需要继续研究某种协议的参数，阅读协议手册；如果只是想确认某个开关或关键字的意思，查看术语表或常见问题，不必把首次配置变成一次全部设置的重写。
