官方手册 · 首次连接

Shadowrocket 使用教程

已有订阅导入、Global Routing 选择与连接验证。按五个步骤完成首次核对，再调整规则细节。

操作前提：已安装应用，并有自己的连接信息
本教程假定你已从 App Store 安装 Shadowrocket，且已有自己的订阅链接或服务器信息。本站不提供、不销售、不推荐节点或订阅。客户端一次性买断 ≠ 线路套餐；应用购买与连接信息的准备是两件事。

尚未安装时，先阅读App Store 正版核验与购买说明。iPhone 与 iPad 的系统要求以 App Store 页面标注为准。以下保留英文界面词，实际显示位置可能随界面布局调整，请以对应名称辨认。

先确认输入信息
再选择流量策略
最后核对实际请求

01 / INPUT

添加服务器或导入订阅

先查看手头的信息属于哪一类：单个服务器参数、单个服务器分享内容，还是用于更新一组服务器的订阅链接。这三种输入不能只凭外观互换。订阅通常是一个地址，客户端需要请求它才能取得列表；服务器参数则直接描述连接目标。开始前保留原始信息，不要先删掉地址中的参数，也不要把配置文件地址当作服务器地址填写。

Add Server：手动填写已有信息

打开 Shadowrocket 的 Home，在 SERVER 区域找到 Add Server，进入添加页面。先选择 Type，再按该协议填写字段。右侧官方截图展示的是包含 Host、Port、Password、Method 的表单；它并不代表每种 Type 都需要相同字段。以 Shadowsocks 为例，应逐项对应已有的地址、端口、密码与 Method；选择其他协议后，则按当前表单及原始资料核对，不能照搬截图中的字段组合。

Host 填服务器地址或域名，不要把包含整段路径的订阅链接塞进这个字段；Port 填端口数值，并检查复制时是否带入空格。密码、标识信息及加密选项要完整保留，尤其注意大小写。填写后使用页面的保存操作，返回 Home，确认 SERVER 中出现刚添加的条目。列表里出现名称，只说明信息已保存，还不能证明服务器可以连接。

Scan QR Code 与 Subscribe：按内容类型导入

如果已有二维码，在 Add Server 中使用 Scan QR Code；系统请求相机权限时，按需要授权。扫描后先查看识别出来的 Type 和服务器字段，再保存。二维码只是承载信息的方式，不保证其中一定是单个服务器，也不保证其中的地址仍有效。若结果不符合预期，应回到原始信息核对，而不是反复保存产生重复条目。

如果已有订阅链接，使用与内容类型对应的 Subscribe 入口。Config 页中的 Subscribe 用于相应的远程配置订阅；用于生成 SERVER 列表的服务器订阅，则应在添加入口中按订阅类型导入。不要因为两者都以网址开头就混用。粘贴时保留完整查询参数，去掉首尾空白，并确认没有把说明文字一起复制进去。导入后返回 Home 检查服务器列表；导入配置后则去 Config 检查文件是否已保存。

剪贴板识别到分享内容时，同样先确认类型再接受导入。Import from Cloud JSON 面向对应格式的数据，并不是任意订阅链接的通用入口。完成这一阶段后，只保留本次准备测试的明确条目，先不要同时调整大量服务器或规则。更详细的入口区别见订阅导入四种入口说明。

Shadowrocket 的 Add Server 页面，显示 Type、Host、Port、Password、Method，以及 Scan QR Code 和 Import from Cloud JSON 入口 — Add Server：先选 Type，再核对对应字段。截图中的字段不适用于所有协议。

02 / ROUTING

选择 Global Routing

服务器保存后，下一步不是立刻修改规则，而是先决定流量怎样选择策略。返回 Home，打开 Global Routing，查看当前选中的姿态。这里的三个选项是配置(Config)、代理(Proxy)、直连(Direct)。它们决定流量的总体处理方式，与 SERVER 中选中了哪个服务器不是同一个设置：前者决定怎样分配请求，后者提供可用的连接目标。

配置(Config)：按当前规则处理

需要指定网站走代理、其余请求直连时，选择配置(Config)，并到 Config 确认当前使用的配置文件。打开该文件，可以看到 General、Rule、Hosts、URL Rewrite 等分段；先检查 Rule，不要顺手开启与首次连接无关的功能。规则通常按自上而下的顺序检查，先命中的条目决定策略，因此相同域名相关的规则放在哪里会影响结果。

下面仅演示规则结构，不是可直接套用到所有环境的完整配置。example.com 是教学域名，使用前应替换为你确实需要处理的目标；PROXY 还必须在当前配置中有对应的可用策略。第一行处理该域名及其子域名，最后一行给未命中的请求指定 DIRECT。编辑前先备份现有配置，使用 Add Rule 时也要核对插入位置，而不只是检查关键字拼写。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

代理(Proxy)与直连(Direct)：用于明确处理方向

代理(Proxy)将适用流量交给代理策略，适合在核对已选服务器是否能承载请求时作临时对照；直连(Direct)让适用流量直接连接，不应把它当成代理已经生效的证据。进行对照时记录原来的选项，只改变 Global Routing，再访问同一个目标。测试结束后恢复准备长期使用的姿态，避免忘记切回而误以为规则失效。

首次操作只需把“模式”和“服务器”分清，不必马上写一份复杂配置。若已有可信且符合自身用途的配置，先使用它并检查选中状态；若要继续学习 DOMAIN、GEOIP、IP-CIDR 与 FINAL 的边界，转到规则手册。本步骤结束时，应能说清当前选择了哪一种姿态，以及 Config 下正在使用哪份文件。

Shadowrocket 的 Config 配置文件编辑页面，包含 General、Rule、Hosts、URL Rewrite、HTTPS Decryption 分段和 Add Rule 入口 — Config：这里展示配置文件内容；Global Routing 的选择入口在 Home。首次使用重点核对 Rule。

03 / CONNECT

选择服务器并授权连接

模式确认后回到 Home，在 SERVER 列表中选择本次要用的服务器。若列表来自订阅，先确认选中的是有完整参数的实际条目，而不是只看到了分组标题。首次验证尽量固定一个服务器；连接过程中频繁更换条目，会使后续很难分辨问题来自服务器、规则还是当前网络。

核对 Home 上的 Global Routing 与上一步一致，再操作顶部连接开关。尚未连接时可能看到 Not Connected；连接状态应以当前页面显示为准。首次建立连接时，系统会请求添加 VPN 配置。这是 Shadowrocket 接管设备网络流量所需的系统授权，不是让你在表单中补填订阅密码。确认弹窗中的应用来源后允许，并按系统要求完成设备身份验证。

如果此前拒绝了授权，回到应用重新发起连接，按系统提示检查相关 VPN 设置。不要在弹窗中反复取消后只凭开关位置判断成功。授权完成后返回 Home，观察连接状态是否保持；若刚打开就恢复未连接，先停在这里排查，不必继续通过增加规则来修复。已经建立连接则继续下一步，用实际请求验证转发结果。

需要特别区分两层事实：VPN 配置被系统接受，表示设备允许客户端处理相应流量；远端服务器能否完成连接，还取决于地址、端口、凭据、协议参数和当前网络。即使开关保持开启，也可能只有直连请求正常，代理请求失败。因此不应把系统出现 VPN 标识等同于所有目标都已按预期访问。

初次操作期间，先保持 On Demand 等自动连接条件不变，手动完成一次连接与断开的闭环。也应避免让其他 VPN 配置同时争用连接状态。需要断开时返回 Home 关闭顶部开关，再核对状态已变化。这样可以确认你知道当前由哪份配置处理请求，也为下一步做连接前后的对照留下清晰起点。

本步完成标准
Home 中已选定服务器，Global Routing 符合预期，系统授权完成，连接状态能够保持。此时继续验证请求，不把“开关已打开”当作最终结论。

Shadowrocket 的 Home 页面，顶部为 Not Connected 开关，下面显示 Global Routing 的 Config、Connectivity Test、SERVER 分组与 Add Server — Home：在同一页核对服务器、Global Routing 与连接状态，再进入 Connectivity Test。

04 / CHECK

使用 Connectivity Test 验证

连接保持后，在 Home 使用 Connectivity Test。测试前确认当前选择的仍是刚才的服务器，并注意 Settings 中的 Test Method：不同测试方法观察的层面不同。某项测试有结果，最多证明这项测试在当时条件下得到了响应，不代表所有网站、所有协议或所有规则都正常；某项测试失败，也不能直接推出全部实际请求都会失败。

接着打开浏览器，访问一个你预期会走代理的目标，再访问一个预期直连的目标。两次都应发起新的请求，不要只观察已经打开的页面，因为缓存内容可能掩盖当前连接变化。若使用配置(Config)，检查目标的实际请求是否匹配预期规则、最终策略是否为 PROXY 或 DIRECT；若暂时使用代理(Proxy)，则先确认通过所选代理策略的请求能完成。

可以把下面三项作为最小验收记录。记录只需写本次实际观察到的结果，不需要填入整段凭据，也不需要收集一长串测试数字。三项结论互相补充，不能用其中一项替代其余两项。

检查项	操作	确认内容
连接状态	返回 Home 查看开关与状态	系统授权后连接能够保持
实际请求	访问预期走代理的目标	新请求可完成，而非仅显示缓存
规则结果	查看相应请求记录	命中规则与最终策略符合预期

如果页面能打开但策略不对，优先回查 Global Routing 与 Rule 顺序，而不是立即换服务器。比如一条更靠前的宽泛规则已经命中，后面的精确规则就不会再决定该请求。反过来，如果策略已经是 PROXY 但连接失败，则应检查所用策略对应的服务器与协议参数，避免把连接问题误写成域名规则问题。

完成后断开再连接一次，并重复同一个目标的验证，确认结果不是偶然来自旧连接。切换网络环境时也应重新核对，尤其是订阅更新或服务器参数发生变化之后。若要检查更复杂的域名解析、策略引用与规则优先级，继续阅读规则与配置参考；这份入门教程只要求先建立一条能够复现的验证路径。

05 / REVIEW

常见失败点与检查顺序

出现问题时，先确定失败发生在导入、建立连接还是发出实际请求的阶段。打开 Settings，可以看到 Test Method、On Demand、Diagnostics 以及 Proxy、TCP、UDP 等相关入口。这些设置各有用途，不是一组需要同时打开的“修复开关”。先保留原配置，一次只改变一项，复测同一个目标后再决定是否保留修改。

订阅失败：先检查地址与返回内容

若更新失败或导入后没有服务器，先回到原始资料核对链接是否完整，是否带入换行、空格或聊天文字。链接中的查询参数可能用于识别订阅，随意删掉后可能无法获取内容。再确认当前网络能否访问该订阅地址，以及它返回的是客户端支持的数据，而不是登录页、错误说明或网页正文。配置订阅与服务器订阅入口用错时，也可能出现“已经保存但列表没有变化”的情况。

不要为了试错反复删除仍可用的旧条目。先记录失败提示，再向你现有连接信息的提供方确认地址状态、内容格式与使用条件。订阅链接往往包含个人访问凭据，不应贴到公开讨论中，也不要把完整地址写入故障截图。处理好导入问题后，回到第一步检查保存结果，而不是直接跳到修改 DNS。

开关回落或请求失败：分开查系统与服务器

连接开关无法保持时，检查 VPN 授权是否完成、是否有其他 VPN 配置正在影响当前连接，并查看应用给出的错误信息。开关能保持但请求失败时，再核对 Host、Port、Type 及相应凭据。部分协议还需要额外的传输或 TLS 参数，必须与已有资料一致；仅仅地址和端口相同，不能证明这份配置完整。先用同一服务器、同一网络重试，避免同时换网络和参数。

若某个域名失败而其他目标正常，检查对应规则与解析结果。不要先用一条覆盖范围很大的规则掩盖问题，也不要在无法解释原因时开启 HTTPS Decryption。首次连接通常不需要处理加密流量解密；误改相关设置会引入新的变量，让简单的服务器连接问题变得更难定位。

测试失败但能访问：核对 Test Method

Connectivity Test 与浏览器访问不一定使用完全相同的请求方式。实际访问正常而测试失败时，先看 Test Method 与测试条件，不要只凭一个测试结果删除服务器。若网页正常但某类应用请求失败，则继续区分 TCP、UDP、域名解析和服务端能力，不应把一种请求成功推断为其他类型都被支持。

需要进一步定位时使用 Diagnostics，并在分享前删去服务器地址、订阅参数、账户信息等敏感内容。On Demand 用于按条件触发连接，不负责修复无效凭据；先确认手动连接与验证都正常，再根据使用场景配置自动行为。对 Settings 中各入口仍有疑问，可查看功能与设置说明。

把一次可用的结果保存下来
当导入、连接和验证全部通过后，保留当前配置的备份，记下 Global Routing 与所用服务器。以后修改规则时，以这份可复现的状态为对照；规则结构与备份注意事项继续查阅规则手册。