先看测试结果
在 Home 点击 Connectivity Test,等待结果。测试方式会影响结果含义;可在 Settings 的 Test Method 中核对采用的方法。能显示测试数值,只能说明该测试条件下得到了响应,不能据此推断所有协议、所有目标或所有应用都正常。
如果结果失败,先保留当前服务器与模式,记录失败发生在哪个网络环境。不要仅凭一次超时就删除整份配置,也不要只按数值大小判断某条连接一定更适合实际使用。测试方法的差异见Ping 与测试设置。
订阅导入 → Global Routing → 连接授权 → 生效验证。先走通一次完整流程,再调整规则与 Settings。
以下操作面向 iPhone 与 iPad。截图展示对应界面,实际字段可能随所选协议而变化;填写依据始终是你已有的配置资料。
选择一种导入方式即可,不需要把同一份信息重复添加。
打开 Shadowrocket,停留在 Home,点击 SERVER 分组附近的 Add Server,进入添加页面。在 Type 中选择 Subscribe,再把你已有的完整订阅链接填入对应的 URL 字段。订阅链接是用于获取服务器条目的地址,不是普通的服务说明网页;应从你的服务商处核对原始链接,不要把浏览器地址栏里任意一个页面地址当作订阅。
粘贴后从头到尾检查一次:链接前后是否带空格、是否多复制了引号或中文说明、换行是否把内容截断。订阅链接可能包含用于访问配置的凭据,应仅保存在你信任的设备中,不要放进公开截图、聊天群或排错记录。确认填写完成后保存,返回 Home,检查订阅对应的分组是否出现,以及分组内是否已有服务器条目。
如果只看到订阅名称,却没有可选服务器,先不要打开连接开关。这通常说明“保存订阅地址”和“成功取得并解析内容”还没有同时完成。检查当前网络能否访问该地址,并核对订阅是否仍有效、返回内容是否符合要求,再执行更新。反复新建相同订阅只会增加重复条目,不能修正一个本身无法获取的地址。
如果拿到的是单个服务器的信息,同样从 Add Server 进入,先选择与资料一致的 Type,再填写 Host、Port 以及该协议要求的身份验证字段。以截图中的字段为例,Password 与 Method 必须与服务器端一致;换成其他协议后,界面会显示不同字段,不要沿用上一种协议的填写习惯。Host 一般填写服务器域名或 IP 地址,不能擅自附加网页路径。
端口、加密方式、Password、UUID、TLS 与 SNI 等参数各有用途,只填写当前 Type 所要求的项目。缺少某项时,应回到原始资料核对,而不是猜测一个常见值。若你已有二维码,可使用 Scan QR Code 读取,再检查识别出的 Type 与参数是否完整。Import from Cloud JSON 适用于相应格式的资料,不是任意订阅链接的通用入口。
保存后返回 Home,确认新条目位于预期的 SERVER 分组,点击选中准备使用的服务器。名称只帮助辨认,不证明连接有效;此时完成的是“信息已加入并可选中”。下一步先确定这些信息将如何被使用,再开始连接。对协议字段不熟悉时,可查阅协议术语表,不必在首次配置时同时学习所有协议。
模式决定请求怎样处理,服务器条目决定代理连接使用什么参数。
回到 Home,点击 Global Routing,查看当前选择。三种姿态分别是配置(Config)/代理(Proxy)/直连(Direct)。不要把 Global Routing 中的 Config 与底部用于管理配置文件的 Config 页面混为一谈:前者选择路由模式,后者用于检查配置文件内容。选对服务器并不意味着已经选对处理请求的方式,这两处都需要确认。
若你已有明确可用的配置文件,准备按域名或 IP 分流,可选择配置(Config)。随后进入 Config 页面,确认正在使用的文件是你预期的那一份,再查看其中的 Rule。配置文件与订阅不是同一类内容:订阅主要提供服务器条目,配置文件还可能包含规则、DNS 及其他处理设置。订阅更新成功,不代表规则也已自动切换到你希望的文件。
截图中的 General、Rule、Hosts、URL Rewrite、HTTPS Decryption 是配置编辑页面的不同分段。首次连接只需确认当前文件与 Rule 的用途,不必为了“完成配置”逐项改动。Add Rule 用于增加规则,但规则会受排列顺序和策略名称影响;尚未理解这些关系时,不要把网上找到的多段内容直接拼接进去,也不需要为普通连接验证启用 HTTPS Decryption。
如果当前目标只是验证刚添加的服务器,可以暂选代理(Proxy),让后续测试先聚焦在服务器连接路径上;确认可用后,再返回配置(Config)检查分流。若保持直连(Direct),网页能打开也不能证明所选代理已经工作。完成选择后,回到 Home,再看一次 Global Routing 显示的值。规则的具体写法与命中顺序放在规则关键字与策略中,配置文件管理则见Config 设置详解。
先确认选中项,再打开开关;首次授权属于系统配置流程。
现在回到 Home。连接之前做两项复核:SERVER 中选中的是否为准备测试的条目,Global Routing 是否仍为上一步确定的模式。如果刚才更新过订阅,条目名称或分组可能发生变化,应重新检查选中项,而不是沿用更新前的印象。首次验证建议保持一个确定的服务器,避免边测试边连续切换,导致结果无法对应到具体参数。
点击 Home 顶部连接开关。尚未连接时,页面顶部可见 Not Connected。首次使用时,系统可能提示允许 Shadowrocket 添加 VPN 配置;这是应用建立系统网络扩展连接所需的授权步骤。确认提示来自刚刚进行的操作,再按系统流程允许,并完成设备要求的验证。这里验证的是设备授权,不是在要求填写服务器的 Password。
授权后返回 Shadowrocket,观察开关与状态是否保持连接。如果开关立即恢复,先确认系统授权是否完成,再进入后文的连接层排查;不要在没有任何反馈依据时反复删除订阅。若已出现系统 VPN 状态标识,也应继续做下一步测试:该标识表示系统连接状态,不代表每个服务器都可达,更不代表所有网页都已按预期策略处理。
连接期间需要修改服务器参数或配置文件时,先明确当前改动属于哪一层。为了便于比较,可以先断开、修改并保存,再重新连接,用同一个目标进行验证。完成使用后可通过 Home 顶部开关断开;如果发现连接会再次自动建立,检查是否启用了 On Demand,相关行为见On Demand 设置说明。不要把按需连接触发误认为开关操作没有保存。
测试结果、实际访问与规则路径需要分别确认。
在 Home 点击 Connectivity Test,等待结果。测试方式会影响结果含义;可在 Settings 的 Test Method 中核对采用的方法。能显示测试数值,只能说明该测试条件下得到了响应,不能据此推断所有协议、所有目标或所有应用都正常。
如果结果失败,先保留当前服务器与模式,记录失败发生在哪个网络环境。不要仅凭一次超时就删除整份配置,也不要只按数值大小判断某条连接一定更适合实际使用。测试方法的差异见Ping 与测试设置。
打开你实际需要使用的网页或应用,重新发起一次请求,观察是否完成加载。尽量使用新请求而不是只看已缓存的页面;必要时刷新或重新打开目标页面。一次成功只代表该目标当前可用,不能代替对其他请求的检查。
随后回到应用,结合当前模式、配置与可用的连接记录判断路径。配置(Config)下,某个请求可能命中直连策略;代理(Proxy)下的成功结果,也不能直接证明配置(Config)中的规则写法正确。
验证应形成一条能解释的链路:当前选中服务器是什么、Global Routing 采用哪种模式、测试是否响应、实际目标是否可用、该请求预期应由哪条策略处理。如果只确认了其中一项,先补齐其余信息,而不是立即调整 DNS 或添加更多规则。需要检查记录时,仅保留排错所需的域名、时间和错误类型;分享前移除订阅链接、服务器凭据及其他个人信息。
在配置(Config)下出现“部分目标正常、部分失败”,可临时切到代理(Proxy)对同一目标重试。若结果随模式变化,应优先检查配置文件与命中策略;若两种模式都失败,继续检查服务器、当前网络与目标本身。这是缩小范围的对照方法,不是永久修改建议。测试结束后恢复原先需要的模式,避免把临时排错状态当作日常设置。
每次只改一项,用同一目标复测;不要同时更换服务器、规则和 DNS。
回到 Add Server 对应的订阅设置,核对 Type 是否为 Subscribe,以及 URL 是否完整。确认订阅仍处于可用状态,返回的是可解析的配置内容,而不是登录页、提示页或错误信息。若原始链接已变更,应使用你现有服务提供方给出的有效信息更新。此阶段的问题发生在取得服务器资料之前,调整 Global Routing 或 DNS 通常不是第一步。
打开所选条目的编辑页面,将 Type、Host、Port 与原始资料逐项对照,再检查认证与传输层字段。尤其留意复制时遗漏字符、选错协议、端口填入了其他用途的端口,以及 TLS 或 SNI 与资料不一致。不要通过随意开启 Allow Insecure 来替代证书与主机名检查;出现相关错误时,应先确认服务器提供的信息和设备时间是否正确。
如果同一条目在当前网络下始终失败,可在你有权使用的另一种网络环境中复测,并保持其余参数不变。这样可以区分“仅在某个网络出现”和“所有测试环境都出现”,但结果本身仍不足以断言具体原因。需要进一步确认服务器状态时,向你已有服务的提供方反馈必要的错误信息,不必附上完整凭据。
若连接开关一打开就关闭,先确认系统 VPN 配置授权是否完成,再检查系统中是否存在正在使用的其他 VPN 连接。若是主动断开后又连接,转到 Settings 查看 On Demand。排错时可以暂时停用已配置的按需触发,手动控制连接;记下原设置,测试结束后再恢复。相关选项的条件与触发逻辑可继续阅读On Demand 参考。
先按上一步的方法对比配置(Config)与代理(Proxy)。若只有配置(Config)异常,回到 Config 确认当前文件、Rule 顺序和策略引用。较宽泛的规则放在前面,可能先于后面的精确规则命中;FINAL 则用于前序规则未命中的请求。不要仅因为新增了一条规则,就假定请求一定会使用它。
如果表现为域名解析错误,再检查当前配置中的 DNS 设置及其可达性。DNS 影响域名如何得到地址,代理服务器参数影响连接如何建立,两者不能相互替代。不要同时粘贴多组来源不明的 DNS 设置;保留原值,每次改动后用同一域名复测。更完整的配置关系见DNS 设置详解。
在 Settings 中查看 Diagnostics 相关诊断入口,并结合 Test Method 确认测试前提。记录当前模式、是否已连接、出现问题的目标与大致操作顺序,比只描述“不能用”更有助于定位。截图中 Today Widget、Proxy、TCP、UDP 等属于不同设置范围,不应为了排除某个故障而全部改动。只在明确某个设置与现象有关时,再进入相应章节核对含义。
到这里,应能分清问题停在“资料未导入”“服务器无法连接”“系统连接未建立”还是“特定请求的规则或解析异常”。如果仍不能确定,保留可重复的最小操作流程,前往常见问题按现象继续查找。首次上手只需完成一条可验证的连接路径;Widget、iCloud 同步与更细的参数调整可在基本流程稳定后,再按Settings 设置详解逐项处理。