官方手册 · 首次配置
Shadowrocket 使用教程
从已有连接信息开始,按添加、模式、连接、验证和排错五步完成首次配置。iPhone 与 iPad 的操作顺序相同,具体界面以应用当前显示为准。
首次操作建议先保持当前 Wi-Fi 或 Cellular 网络稳定,准备好服务商给出的完整资料,再按顺序执行。订阅链接往往带有账户凭据,不要贴到公开评论、截图或聊天群中。已有配置需要修改时,先保留可回退的副本;本页的目标是确认一条完整访问链路,不必同时调整所有高级设置。
01 · Add Server:添加服务器或导入订阅
打开 Shadowrocket 后先停留在 Home。下方的 SERVER 分组用于查看服务器条目,点击 Add Server 进入添加页面。接下来根据手中的资料选择一种方式:一条用于获取服务器列表的订阅链接,使用 Subscribe;一组明确的协议、地址、端口与认证信息,则按实际协议手动填写。两种资料的用途不同,不要把订阅地址直接当作服务器的 Host。
已有订阅链接:选择 Subscribe
进入 Add Server 后点击 Type,在类型列表中选择 Subscribe,再将完整订阅链接填入对应的 URL 字段。粘贴后检查开头、结尾与查询参数是否完整,避免把说明文字、空格或换行一起带入。备注可使用便于自己辨认的名称,随后保存并返回 Home。客户端会尝试读取订阅内容;成功后应能在对应分组看到导入的服务器,而不只是一个备注名称。
如果保存后没有出现服务器,先检查是否存在更新失败提示,再尝试对该订阅执行更新。订阅内容后续发生变化时,也需要通过更新重新获取;仅重新打开连接开关并不等于更新了订阅。不要连续重复添加同一地址,否则容易形成多组重复条目,之后也难以判断正在使用哪一组资料。
已有服务器信息:按 Type 逐项填写
手动添加时,先选择服务商注明的 Type,再填写 Host 与 Port,以及该协议要求的认证和传输字段。截图展示的 Password、Method 并不是所有协议都通用:如果资料是 Trojan,就按 Trojan 的字段填写;如果是 Shadowsocks,才核对相应的 Method 与密码。字段名称相近也不表示内容可以互换,不确定的参数应向自己的服务商核实,而不是凭名称猜选。
Host 通常填写资料中的域名或地址,不要自行加上网页路径;Port 填写服务端实际使用的端口。涉及 TLS、服务器名称或其他传输选项时,保持与服务端资料一致,不要为了通过测试随意降低验证要求。若已有二维码,可使用 Scan QR Code 识别后逐项复核;Import from Cloud JSON 仅用于已有且格式对应的资料,不能代替普通订阅导入。
保存完成后回到 SERVER 分组,点击准备使用的服务器,使其成为当前选择。此时先不要急着连接:有了条目只说明信息已经录入,接下来还要决定访问请求采用哪一种 Global Routing。
02 · Global Routing:选择访问姿态
回到 Home,点击 Global Routing 查看可选模式。本教程先区分三种基础姿态:配置(Config)、代理(Proxy)、直连(Direct)。它们决定请求如何选择路径,不会替你补全服务器资料,也不会自动修复失效的订阅。改变模式后,应回到 Home 核对当前显示的选择,再进行连接测试。
配置(Config):按配置文件匹配规则
日常需要规则分流时选择 Config,但前提是已经有一份合适的配置并将其选为当前配置。点击底部 Config 进入配置文件页面,确认当前使用的文件;需要检查内容时进入对应文件的编辑页面,查看 General、Rule、Hosts 等分段。截图展示的是配置编辑界面,而不是 Home 中的模式选择列表,二者的职责应分开理解。
Rule 中的条目按顺序判断,前面的规则匹配后,后面的兜底规则通常不再决定该请求。以下片段仅用于理解顺序:apple.com 及其子域名选择 DIRECT,其他未匹配请求落到 PROXY。它不是完整配置文件,也不表示适合所有人的访问需求;修改前请先保存副本,并确认自己的配置确实使用这些策略。
[Rule]
DOMAIN-SUFFIX,apple.com,DIRECT
FINAL,PROXY
编辑页面中的 Add Rule 用于增加规则。初次操作不建议一次插入大量条目,也不需要为了连接而修改 HTTPS Decryption。先核对目标域名是否被前面的 DOMAIN、DOMAIN-SUFFIX 或其他规则匹配,再看最终策略。配置语法、策略组与匹配优先级的详细说明见规则与配置参考大全。
代理(Proxy)与直连(Direct):用于明确路径或对照测试
Proxy 用于让受客户端处理的请求走代理路径,适合在排查时暂时减少规则因素;它仍然要求当前服务器能够正常工作。Direct 选择直接连接目标,不应拿它来判断代理服务器是否可用。切换到 Direct 后某个网站能够打开,只能说明直连路径下该目标可访问,不能据此认定代理配置正确。
首次建立基线时,可暂时选择 Proxy 验证已有服务器;确认工作后再切回 Config 检查分流。若本来就有明确的可用配置,也可以直接使用 Config。每次对照测试后恢复原来的模式,避免后续把测试状态当作日常配置。遇到陌生的字段或策略名,可先查阅名词解释,不必在这一步展开所有高级选项。
03 · Home:打开开关并确认连接
完成服务器选择和 Global Routing 设置后,回到 Home。打开开关前再检查一次:SERVER 中选中的是刚才准备测试的服务器;Global Routing 是计划使用的 Config 或 Proxy;如果使用 Config,当前配置文件也已经确认。这样可以避免订阅刚更新后仍在测试旧条目,或误把 Direct 状态下的访问结果当作代理结果。
点击 Home 顶部的连接开关。首次建立连接时,系统可能要求允许添加 VPN 配置,这是客户端接管相关网络请求所需的系统授权。阅读弹窗内容,确认由当前操作触发后继续,并按系统要求完成设备验证。若选择取消,返回应用后连接可能仍未建立,此时应重新触发连接并完成授权,而不是反复修改服务器密码。
授权完成后返回 Shadowrocket,观察顶部是否仍显示 Not Connected,以及开关是否保持开启。系统 VPN 状态与应用连接状态可以帮助确认网络配置已经启用,但开关开启不等于目标网站一定能够访问。服务器认证、目标地址、DNS 和当前规则仍可能影响实际结果,下一步需要单独验证。
如果开关打开后立即恢复关闭,先检查系统授权是否完成,记录应用出现的提示,再看是否有其他正在启用的 VPN 配置影响当前连接。先处理授权和连接状态问题,不要同时更改 Global Routing、服务器协议与 DNS,否则很难知道是哪一项影响了结果。也不要在尚未确认连接状态时连续快速开关,以免把状态变化与实际访问混在一起。
iPad 上可能出现更宽的列表或分栏布局,但仍按 Home、服务器选择、Global Routing、连接开关的顺序核对。设备上显示的 VPN 状态标识可能因系统界面而异,应以应用状态和后续实际请求验证为准。暂时停止使用时,可以回到 Home 关闭连接;若之后出现自动重新连接的情况,再按第五步检查 On Demand 条件。
04 · Connectivity Test:确认测试与实际访问
连接保持开启后,先在 Home 点击 Connectivity Test,按当前界面提供的方式执行测试。测试结果主要反映所选测试方法下的连通情况,不代表所有目标、所有协议流量都能得到相同结果。某一种测试失败,也不能单凭这一项认定整条连接不可用;应把它与实际访问、应用记录以及当前网络状况一起判断。
接着打开浏览器,访问一个自己明确需要验证的目标页面,执行一次新的加载。不要只看已经缓存的旧页面,也不要只凭页面上的某个地区文字判断路径。若需要确认出口地址,应使用自己信任且能显示当前请求出口的服务,并注意:Config 可能让不同目标使用不同策略,因此一次查询结果不能代表设备上的每个请求。
返回 Shadowrocket,查看 Data 中当前可用的连接或请求记录,寻找刚刚访问的目标。若记录提供匹配规则、策略或服务器信息,逐项核对它是否符合预期。目标请求命中 DIRECT,通常意味着它按规则直接连接;命中 PROXY 后仍失败,则还需要核对当前服务器及目标本身。记录内容随界面而异,先依据实际显示的信息判断,不要把“没有注意到记录”直接等同于“没有任何请求”。
当 Config 下失败而原因不明时,可临时切换到 Proxy,对同一个目标重新发起请求。如果 Proxy 能访问而 Config 不能,优先检查规则匹配、策略引用及配置中的 DNS 设置;如果两者都失败,再检查服务器、协议参数和当前网络。比较时保持目标、服务器与本地网络不变,一次只调整模式,测试结论才有参考价值。
如果只有某个应用表现异常,先完全结束该应用的当前请求,再重新打开进行对照。若只在 Wi-Fi 下失败、换到 Cellular 后恢复,应继续排查本地网络而不是马上重建全部配置。切换网络可能产生流量费用,也可能触发已有的 On Demand 条件,测试前先确认相关设置。
05 · Settings:按失败环节逐项排查
遇到问题时,先确定它停在哪一步:订阅尚未导入、连接开关无法保持、服务器测试失败,还是只有部分目标不能访问。不同阶段对应不同检查项。打开 Settings 可以查看 Test Method、On Demand 与 Diagnostics 等入口,但不必把每个选项都改一遍;先记录现象,再做最小范围的调整。
订阅没有生成条目或更新失败
先回到订阅设置核对完整 URL,检查是否复制了管理页面地址、遗漏查询参数或带入多余字符。再确认当前网络能请求该地址,以及自己的订阅是否仍有效。订阅地址能够在浏览器显示内容,也不保证返回格式适合当前导入方式;若出现登录页面、错误说明或空内容,应向自己的服务商确认地址及格式。保留仍可用的旧资料,不要在尚未确认新内容有效时清空全部服务器。
服务器已出现,但连接或测试失败
手动条目优先核对 Type、Host、Port 与认证字段,尤其留意密码前后的空格、Method 是否对应,以及传输和 TLS 参数是否一致。订阅条目先更新,再选择已有资料中另一条已知可用的服务器对照。若所有条目只在同一网络下失败,检查本地网络限制或临时异常;若仅一条失败,更应先核实该服务器的状态和参数。
Settings 中的 Test Method 会影响连通性测试采用的方式。某些服务不响应某一种探测,所以测试超时需要结合实际访问判断。不要把测试结果直接当作完整的速度结论,也不要为了消除测试提示同时改动 TCP、UDP 等选项;协议或传输细节应依据已有服务器的真实配置调整。
连接成功,但部分请求路径不符合预期
先检查 Global Routing 是否仍处于测试用的 Proxy 或 Direct,再确认 Config 中选中的文件。随后按第四步寻找目标请求的记录,查看是否被前置规则命中。涉及域名解析时,先确认问题是否能在相同网络与相同目标上重复出现,再检查 General 中的相关设置。规则修改后需要重新发起请求,旧连接可能不能立即体现新策略。
如果手动关闭连接后又自动开启,查看 On Demand 中已有的触发条件,确认是否由 Wi-Fi、Cellular 或其他条件重新发起连接。排查时可暂时停用对应条件,完成对照后恢复原设置。需要进一步定位时进入 Diagnostics,按现象收集必要的诊断信息;分享前先检查是否包含订阅凭据、服务器认证信息或个人访问记录。
最后保留一份简短记录:当前网络、所用服务器、Global Routing、发生失败的目标、已做过的单项修改及结果。这样再次排查时可以从明确的状态继续,而不是重复尝试。更多常见现象见问答与故障说明;需要逐条理解规则时,再阅读配置大全。本页操作到这里,应已能区分“资料没有导入”“连接没有建立”和“请求没有走预期路径”这三类问题。