先看测试
确认测试方法与结果
在 Home 点击 Connectivity Test,等待测试结束。测试方法受 Settings 中 Test Method 等设置影响;某一种测试失败,不足以直接证明所有实际请求都会失败。
官方手册 / 首次设置
按顺序完成添加、选模式、连接和验证。先建立一条能复测的连接,再调整规则与自动连接条件。
步骤 01 / 准备服务器条目
两种方式选一种即可。已有订阅链接时先导入订阅;只有单个服务器参数时再手动填写。
打开 Shadowrocket,进入 Home,点击添加入口打开 Add Server。在 Type 中选择 Subscribe,再把完整订阅链接填入对应的 URL 输入项。订阅链接通常包含用于识别账户的参数,复制时应从开头一直保留到结尾,不要附带聊天里的引号、解释文字或换行,也不要把服务商的账户管理页面当成订阅地址。
按应用内的保存或完成操作返回 Home,等待订阅内容载入。随后查看 SERVER 分组是否出现服务器条目。导入成功的判断是列表中有可供选择的服务器,而不只是输入框接受了链接。如果只有订阅名称而没有服务器,先检查更新结果与链接完整性,不要连续添加相同链接形成多个重复分组。
订阅更新用于重新取得服务商提供的列表,不是给应用恢复购买,也不保证服务器此时能够连接。已有条目时,先确认刚导入的分组和目标服务器,再继续下一步;链接解析失败或列表为空时,直接按本页第五步检查,暂时不要改动规则。
如果持有的是服务器地址、端口及认证参数,在 Add Server 先选择正确的 Type,然后按当前页面显示的字段填写。不同协议的字段并不相同,不能因为两条记录都带有密码就选成同一种类型。截图展示的是含 Host、Port、Password 与 Method 的页面,其他类型可能显示不同项目。
Host 填服务器域名或 IP,不能顺手附上网页路径;Port 填提供给你的端口数值。Password 与 Method 应逐字核对,尤其留意复制产生的首尾空格。遇到 UUID、TLS、SNI 或传输层参数时,也应遵照已有服务器信息填写,不通过猜测补齐。保存后回到 Home,确认新条目可见,给它使用便于辨认的备注。
已有二维码时,可以使用应用内的 Scan QR Code,按系统提示给予相机权限。若使用应用内提供的剪贴板导入操作,先确认剪贴板里是完整分享链接,而不是截图说明或一段网页正文。扫描或导入后仍要回到列表检查条目类型、地址与分组,不以“扫码完成”代替参数核对。
截图中的 Import from Cloud JSON 是另一种导入入口,不等同于任意订阅链接输入框。初次设置只选与手中资料相符的一种方式即可。订阅、单个分享链接与 Config 文件的区别,可在术语手册中继续查看;批量整理与更新策略见订阅与服务器管理手册。
本步完成标志:Home 的 SERVER 列表中已有目标服务器,来源与参数能够核对。接下来决定这些服务器在什么情况下被使用。
步骤 02 / 决定流量处理方式
先确认模式再打开连接。列表里选中了服务器,不代表所有流量都会使用它。
在 Home 点击 Global Routing,查看当前选项。教程中的三姿态分别是配置(Config)、代理(Proxy)、直连(Direct),界面中以英文显示。选择后回到 Home,再看一次 Global Routing 旁的当前值,避免在切换页面后误以为设置已经改变。
已有明确可用的配置文件时,选择配置(Config)。随后进入 Config,确认当前选中的文件确实是准备使用的那一份。配置中的规则会影响请求采用代理、直连还是其他策略;如果文件引用策略组,还需要核对组内实际使用的服务器。仅有订阅列表不代表已经具备适合自己需求的分流规则。
右侧官方截图是 Config 配置文件编辑页,其中可见 General、Rule、Hosts、URL Rewrite 与 HTTPS Decryption。初次连接不需要逐项修改这些分段,也不需要为了测试而添加 HTTPS Decryption 设置。先保留已知配置,理解当前 Rule 的作用后再调整;Add Rule 是添加规则的入口,不是添加服务器的入口。
如果还不能确定配置是否正确,可以暂时选择代理(Proxy),用当前所选服务器验证代理路径,减少规则匹配带来的变量。该模式不是对服务器质量的保证;服务器参数不匹配、认证失效或基础网络异常时,仍可能无法访问。验证完成后,如果日常需要按规则分流,再切回配置(Config)并复测。
直连(Direct)使流量按直连方式处理。因此,即便连接开关处于打开状态,也不能据此认为请求使用了列表中的代理服务器。它可以帮助对照基础网络表现,但不能用来验证代理服务器是否正常。切换模式前记下原来的值,测试结束后恢复,避免以后把直连结果误判为规则效果。
这里先掌握模式的区别即可。规则顺序、策略名称和匹配范围需要结合具体配置阅读,详细说明见Global Routing 功能章节。不要在不清楚规则目标的情况下,仅凭复制几个关键字替换整份配置。
本步完成标志:能说清当前选择的是 Config、Proxy 还是 Direct;选择 Config 时,知道正在使用哪份配置。下一步再开启连接。
步骤 03 / 建立连接
首次连接可能需要系统授权。授权通过后仍需检查应用状态和实际访问结果。
回到 Home,在 SERVER 列表选择准备使用的条目,并核对当前选中标记。如果列表里有多个订阅分组,留意备注相似的条目是否来自不同分组。选择配置(Config)且配置引用策略组时,还应确认策略组的实际目标;Home 中点选某个条目,不一定能覆盖配置里所有指定策略。
确认 Global Routing 后,打开页面顶部的连接开关。官方截图在未连接时显示 Not Connected,用于帮助辨认入口,不是本次操作的实时状态。点击之后应观察实际设备上的状态变化,而不是照着截图寻找完全相同的结果。
首次建立连接时,iPhone 或 iPad 可能弹出添加 VPN 配置的系统提示。这是应用建立系统级连接所需的授权步骤,不是导入服务器密码的输入框。确认当前操作由 Shadowrocket 发起,阅读提示后按系统要求允许,并完成设备密码或其他设备验证。不要把服务器密码填进设备验证界面。
如果暂时取消了授权,应用不会仅凭已有服务器条目建立完整连接。回到 Home 重新发起连接,并根据系统实际提示处理。若授权后开关立即退回,先记下提示内容,进入第五步逐项核对,不需要马上删除应用或重建全部订阅。
连接期间先保持同一种网络,不要同时切换 Wi-Fi、蜂窝网络、服务器与模式。若正在使用其他会管理设备 VPN 连接的功能,先确认当前由哪个连接配置生效,避免把配置切换造成的中断当成服务器故障。对于受管理的设备,系统策略也可能影响授权,应按设备现有管理要求处理。
看到连接状态变化后,先不要立即打开 On Demand 或修改更多设置。手动连接成功只是完成了这一步,是否能处理目标请求还需要下一步验证。使用结束时,可返回 Home 关闭开关;以后需要按条件连接,再单独了解 On Demand。
本步完成标志:系统授权已处理,连接状态能够保持,所选服务器与模式没有意外变化。接着用测试结果和实际页面共同验证。
步骤 04 / 核对实际结果
测试延迟、系统连接状态与网页能否使用,是三个不同层面的结果,需要分别核对。
先看测试
在 Home 点击 Connectivity Test,等待测试结束。测试方法受 Settings 中 Test Method 等设置影响;某一种测试失败,不足以直接证明所有实际请求都会失败。
再看访问
用 Safari 打开熟悉的页面,再打开实际需要使用的目标页面。应核对内容能否加载和继续操作,而不只看已有缓存或一次测试数值。
测试完成后,先查看目标服务器是否得到结果。数值是当前测试条件下的表现,不是速度承诺,也不代表所有网站都经过同一条路径。不同测试方法、网络和目标可能产生不同结果,因此比较服务器时尽量保持测试条件一致,不把不同时间、不同方法的数值直接混在一起排序。
接着用 Safari 打开一个平时可访问的页面,确认基础浏览行为正常,再验证本次需要使用的页面。必要时重新载入页面,避免把缓存内容当成新请求成功。页面能打开之后,还可以完成一次实际操作,例如进入页面中的另一个栏目;只显示标题或少量缓存图片,不能说明整个连接过程已经正常。
如果使用配置(Config),不同页面可能命中不同规则,一个页面成功并不能验证整份配置。需要判断某个请求的处理方式时,结合应用内可见的连接记录与当前规则核对,留意使用的是 DIRECT 还是代理策略。仅看系统 VPN 标识无法区分这两种处理方式,也不应据此断言所有请求都已使用代理。
遇到“测试有结果,但页面打不开”,保留当前服务器与模式,进入下一步检查目标访问和配置;遇到“测试失败,但实际页面可用”,先核对 Test Method,不要立刻删除可用条目。验证的目的是定位哪一层出现差异,而不是挑一个看起来正常的指示就结束检查。
本步完成标志:实际需要使用的页面可以正常操作,并且其处理方式符合当前模式与规则。测试通过后再做日常优化;没有通过时,沿下面的顺序缩小范围。
步骤 05 / 每次只调整一项
先区分基础网络、导入、服务器连接与规则问题。不要一开始就重置所有设置。
先在 Home 关闭连接,打开平时可访问的页面。如果关闭后依然无法使用,优先处理 Wi-Fi、蜂窝网络或当前网络的登录要求。基础网络恢复后再重新开启连接。这个对照能避免把所有访问失败都归因于订阅;测试期间仍应保持网络条件稳定。
如果 SERVER 里没有可用条目,回到订阅信息检查链接是否完整、是否带有多余空格,以及更新时显示了什么结果。订阅链接可能含有账户凭据,不要把完整链接贴到公开讨论中。服务状态、使用期限和账户限制需要在你的服务商处核对,重复点击更新不会自动修复账户侧问题。
手动添加的服务器则从 Type 开始逐项复核,再看 Host、Port、认证与传输参数。尤其不要只改密码却忽略协议类型。若原始资料本身缺少必要字段,应从你的服务商处获取完整信息,而不是使用别的条目参数拼接。
如果连接开关能保持,但实际访问不符合预期,可先记下当前配置与模式,再短暂切到代理(Proxy)复测同一目标。若 Proxy 下可用而 Config 下失败,重点核对当前配置、匹配规则与策略组目标;若两种模式都失败,则继续检查服务器与网络。直连(Direct)只用于直连对照,不能证明代理路径可用。
进入 Settings,查看 Test Method,确认测试结果对应哪种方法。不要为了让数值出现而随意更改 Proxy、TCP、UDP 下的多个选项;这些设置应在明确问题和参数含义后再调整。一次改动后回到 Home,用相同目标复测,确认变化确实来自这一次操作。
如果关闭后连接又重新出现,检查 On Demand 是否启用了符合当前网络条件的自动连接规则。排查阶段可先关闭按需连接,建立可控的手动测试流程,测试结束再恢复所需条件。On Demand 负责何时发起连接,并不能修复错误的服务器参数。
仍不能定位时,可查看 Diagnostics 中应用实际提供的诊断内容,记录问题发生时的网络、模式、所选条目和错误提示。对外分享前遮盖订阅 URL、密码、UUID、账户信息及可识别的访问记录。只分享与故障有关的部分,通常比一张完整设置截图更便于判断。
下一次复测从同一服务器、同一模式和同一目标开始。恢复上一项无效改动,再检查下一项,避免修改越多越难还原。常见错误的进一步说明见疑难解答;订阅更新、多分组整理、删除和备份见节点管理手册。完成这些基本步骤后,再考虑按自己的需求细化规则和自动连接条件。
本步完成标志:能够指出问题位于哪个环节,并保留可重复的测试过程。修复后返回第四步,重新核对实际访问结果。