Shadowrocket 使用说明
添加已有配置 → 选择 Global Routing → 连接与验证
以 iPhone 与 iPad 为操作对象,按五个步骤完成一次可检查的连接。先保持设置简单,再逐项调整规则与按需连接。
配图为 App Store 官方截图,用于辨认页面与字段;具体显示以设备上的实际界面为准。下面的两种添加方式任选其一,不必重复录入同一份信息。
Add Server:添加服务器或导入订阅
添加成功的判断标准是:返回 Home 后,SERVER 分组内出现可选条目。看到条目只说明信息已保存,并不表示认证正确或已经连接。先辨认手中的资料属于完整订阅地址,还是单台服务器的协议与参数,再选择对应入口。
已有服务器信息:按字段填写
在 Home 点击 Add Server,进入添加页面。先打开 Type,选择资料中明确标注的协议类型。Type 决定后续字段,不能仅凭服务器名称或地址猜测。截图中的 Host、Port、Password、Method 是该页面所示类型的字段;切换到其他 Type 后,应按实际显示填写对应参数。
Host 通常填写已有资料中的域名或 IP 地址,不要把整段订阅链接放入这里;Port 填写对应端口,注意复制时不要夹带空格。Password 和 Method 必须与已有资料一致,不能因某个选项看起来常见就自行替换。若资料还包含其他认证或传输参数,同样逐项核对,缺失时应向自己的服务商确认,而不是反复尝试随机值。
页面底部的 Scan QR Code 可用于读取自己已有的兼容二维码。系统询问相机权限时,按实际扫码需要决定是否允许。扫码结果仍需要核对 Type 与服务器字段;二维码被读出不等于其中的参数仍然有效。Import from Cloud JSON 是另一种导入入口,不等同于 Subscribe;仅有普通订阅地址时,不必进入该入口。
已有订阅链接:使用 Subscribe
从 Add Server 的 Type 中选择 Subscribe,在相应的地址字段粘贴自己的完整订阅链接,填写便于辨认的备注并保存。保留地址原有路径与查询参数,不要只复制域名,也不要把浏览器页面标题当作地址。订阅链接可能带有个人凭据,应视同密码保管。
保存后等待内容读取,再返回 Home 检查订阅分组与服务器条目。若分组出现但内部没有服务器,先检查地址是否完整、当前网络能否读取,以及服务是否仍有效;不要直接重复新建多个相同分组。订阅通常用于管理一组服务器信息,Config 则管理配置文件与规则,两者不是同一项操作。
完成本步后,保留一个准备测试的条目即可。遇到不熟悉的协议或字段,先查阅术语表;需要进一步整理多组配置时,再阅读完整使用手册。
Global Routing:选择配置、代理或直连
服务器添加完成后,回到 Home 点击 Global Routing。这里决定流量如何处理,而 SERVER 中所选条目提供代理连接所需的信息。选中了服务器,却保持直连(Direct),并不能用来验证这台服务器的代理连接是否正常;两项设置需要一起检查。
三种姿态分别用于什么情况
- 配置(Config):按当前配置文件的规则处理流量。不同目标可能命中不同策略,因此并非每次访问都会使用所选服务器。
- 代理(Proxy):以代理方式处理流量,适合在排查时减少配置规则的影响;仍需已有服务器参数正确、服务可用。
- 直连(Direct):以直接连接方式处理流量,可用于与原有网络访问情况进行对照,不用于检验代理服务器是否可用。
若已有明确用途的配置文件,通常先确认其规则,再选择配置(Config)。如果只是想检查刚添加的服务器是否能够建立可用连接,可以临时选择代理(Proxy)进行对照,完成后再恢复原先需要的姿态。不要把临时排查时的选择当作所有场景都适用的固定设置。
使用 Config 前确认当前配置
进入 Config,确认当前选用的配置文件,再查看其内容。官方截图展示了 General、Rule、Hosts、URL Rewrite、HTTPS Decryption 等分段,以及 Add Rule 入口。本次入门操作重点只在 Rule:了解目标访问将按什么策略处理,不需要为了首次连接启用其他分段中的功能。
Rule 中的规则从上到下匹配,命中后使用相应策略。DIRECT 表示直接连接,PROXY 表示代理处理,REJECT 表示拒绝;FINAL 用于处理此前未命中的流量。下面仅是便于阅读的语法示例,不是完整配置文件,也不要求直接覆盖现有内容:
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT
此例中,匹配 example.com 及其子域名的请求使用 PROXY,其余未命中的流量由 FINAL 交给 DIRECT。实际结果仍取决于完整规则顺序和当前配置。编辑前先保留原配置,避免删除已有必要设置。规则编写与匹配细节较多,可转到完整使用手册继续阅读,本页先完成连接闭环。
Home:选择条目并打开连接
回到 Home,先在 SERVER 分组中选中准备使用的服务器,再核对 Global Routing。首次操作建议只测试一个条目,暂时不要同时调整 On Demand、测试方式与多份配置,这样出现异常时才容易判断是哪一项造成变化。
在 Home 顶部找到连接开关。官方截图中的 Not Connected 表示尚未建立连接;确认服务器与姿态后,打开旁边的开关。首次建立连接时,系统可能询问是否允许添加 VPN 配置。该提示用于让 Shadowrocket 建立处理设备网络流量所需的系统配置,并不是要求重新购买应用或填写订阅密码。
确认提示来自当前操作后,按系统界面完成允许与身份认证,再返回 Shadowrocket。设备是否要求密码或其他认证方式,以系统实际提示为准。不要把设备解锁密码填写到 Add Server 的 Password 中:系统认证与服务器认证是两套不同的信息。
如果之前取消了系统提示,回到应用重新发起连接,并留意是否再次出现授权界面。若设备受组织管理,或已有其他 VPN 连接正在使用,应先核对设备自身的使用限制和当前连接状态,不要反复删除不明用途的系统配置。记录所见提示,通常比连续开关更有助于定位问题。
完成授权后观察 Home 顶部状态是否从 Not Connected 发生变化,并确认开关没有马上回落。建立系统 VPN 连接只是验证链条的第一部分:服务器认证、目标可达性和规则处理仍需下一步检查。状态变化后先保持当前设置,进入验证步骤,不要立刻批量修改条目。
需要结束这次手动测试时,可回到 Home 关闭连接开关。如果随后又自动连接,再到 Settings 检查 On Demand 是否启用及其触发条件;不要把自动重连直接判断为开关失效。
Connectivity Test:验证是否生效
判断连接是否可用,应同时看测试、实际访问与流量变化,而不是只看开关。先在 Home 使用 Connectivity Test,等待测试完成并记录结果。测试失败时先保留当前服务器与姿态,下一步按顺序排查;测试成功也还需要确认目标应用的实际访问情况。
先理解测试结果的范围
Connectivity Test 反映的是所用测试方法及其目标在当时的表现。一个延迟数字不能证明所有网页都能打开,也不能直接换算成文件传输速度。不同 Test Method 的结果不适合直接混在一起比较;若只是检查本次修改是否有效,应保持测试方式一致,再比较修改前后的现象。
接着打开平时使用、当前网络条件下允许访问的网页或应用,重新发起一次实际请求。不要只观察已经缓存的页面:旧内容能显示,不一定代表新请求已经完成。首次验证可选一个明确目标,确认能否加载新的内容,再扩大测试范围。
把访问结果与当前姿态对应起来
如果使用配置(Config),先确认测试目标应命中哪条规则。目标命中 DIRECT 时,即使网页正常打开,也不能据此认定代理服务器可用;目标命中 REJECT 时,失败则可能是配置的预期行为。需要区分规则与服务器问题时,可暂时改为代理(Proxy),在同一网络、同一服务器下重复请求,然后恢复原来的设置。
还可以打开 Data 观察流量变化,作为请求确有发生的辅助证据。设备上的后台任务也可能产生流量,因此总量增加不能单独证明某个网页走了预期策略。将操作时间、访问目标和流量变化一起看,比只看累计数字更可靠。
最后记下本次有效组合:所选服务器、Global Routing 姿态、当前配置和测试网络。完成一次成功验证后,再逐项增加所需设置。若只有某个目标失败,不必立即推翻所有配置,应先检查该目标的规则与可达性;若所有访问都失败,则进入下一步,从基础网络开始排查。
Settings:按失败位置逐项排查
排查时每次只改变一个条件,并在修改后重复相同的验证动作。先判断问题发生在哪一层:订阅读不出来、开关无法保持、测试失败,还是只有某个网页失败。这些现象的检查顺序不同,不宜用反复重装代替定位。
订阅为空或服务器信息不完整
先关闭当前连接,确认设备原有网络可以正常使用,再核对订阅地址的完整性。地址读取失败与服务器连接失败是两件事:前者可能还没有获得可用条目,后者则是在已有条目基础上连接异常。对于手动添加的条目,重新打开详情,核对 Type、Host、Port 与认证参数,尤其注意复制产生的空格、换行和缺失内容。服务状态与使用条件向自己的服务商核实。
开关回落或实际请求全部失败
检查系统 VPN 配置授权是否完成,观察是否有明确错误提示,再确认当前选中的服务器没有选错。对照已有资料检查认证信息,不要为排查而随意降低安全相关设置。若需要比较 Wi-Fi 与蜂窝网络,应在两种网络下使用同一条目和同一姿态,并确认测试操作符合当前网络的使用要求;切换网络后结果不同,只能说明网络路径值得继续检查,不能直接归因于某个参数。
测试结果与实际访问不一致
进入 Settings,找到 Test Method,先记录原来的选择。测试方法不同,检测对象与结果含义也可能不同,应结合实际请求判断,而不是为了出现更小数字不断更换方法。若代理(Proxy)下访问正常、配置(Config)下失败,优先回到 Config 检查 Rule 的匹配顺序、目标策略与 FINAL,不必立即重新填写服务器密码。
关闭后自动连接,或需要进一步诊断
在 Settings 检查 On Demand。如果已有按需连接条件,网络变化或相关请求可能再次触发连接。为进行一次明确的手动测试,可先记录现有条件,再暂时停止按需连接,测试结束后按原用途恢复。不要同时修改多条自动化条件,否则很难判断哪条规则生效。
需要更多线索时,可查看 Settings 中的 Diagnostics。记录失败发生的时间、当时网络、所选服务器、Global Routing 和错误文字。诊断记录可能包含域名、地址或认证相关信息,向他人说明问题前先检查并遮盖敏感内容;不要公开发送整段订阅地址、密码或二维码。
Settings 还可见 Proxy、TCP、UDP 等项目,本次入门无需逐项改动。确认需要解决的具体问题后再调整对应设置。更细的配置维护、Data 观察与排查流程见完整使用手册;术语含义见术语表。