Shadowrocket 疑难解答

Shadowrocket 支持 iPhone 与 iPad，系统要求与购买适用范围以 App Store 页面标注为准。在 iPad 上使用原购买账户进入 App Store，先查看已购项目，再核对产品详情中的兼容性。iPad 的显示空间与部分列表排布可能不同，操作时仍以 Home、Add Server、Config 和 Global Routing 等界面词定位。完成安装后核对服务器列表与当前配置，不要把应用已购误认为订阅资料已经自动迁移。

首次启用连接时，系统可能请求允许 Shadowrocket 添加 VPN 配置。这是客户端建立系统网络隧道所需的授权步骤，与购买验证或订阅更新不是同一件事。确认弹窗对应 Shadowrocket 后，按系统提示完成允许与设备身份验证；不要向他人提供设备解锁信息。若曾取消，可返回客户端重新尝试连接，并在系统 Settings 的 VPN 相关页面检查配置状态。授权完成后，仍需选择有效的服务器并核对路由模式。

先按固定界面词定位：Home 查看服务器列表与连接状态，Add Server 添加已有服务器信息，Subscribe 用于订阅类型，Config 管理配置文件，Global Routing 选择整体路由方式。系统提供的应用语言入口与可选语言，以设备 Settings 和当前应用实际显示为准；若没有可切换项，可继续对照这些英文名称操作。不要只凭按钮所在位置判断功能，不同设备布局可能变化，修改前先读清字段名称。

先准备从你的服务商处获取的订阅，或已有服务器的完整参数；再通过 Add Server 导入或填写，并回到 Home 确认列表实际出现内容。随后选择要使用的服务器，核对 Global Routing；需要规则分流时，还应确认当前启用的 Config。最后打开连接开关并完成系统授权，用实际访问结果验证。不要在资料尚未导入时反复切换开关，也不要一次改动多个高级选项，否则难以分辨失败发生在哪一步。

打开 Shadowrocket 的 App Store 产品详情，查看兼容性栏，系统要求一律以 App Store 页面标注为准。更新也通过 App Store 完成；先确认设备有足够可用空间、网络可以正常访问商店，并核对购买账户。不要仅因教程中的界面与当前设备不同就判断安装错误，界面会随设备和应用调整。更新前保留必要配置备份，更新后再核对当前 Config、服务器选择和连接状态，避免将设置变化误判为订阅失效。

先确认使用的是从你的服务商处获取的完整订阅地址，而不是账户登录页、说明页或截断的分享文字；检查复制时是否混入空格、换行和标点。再核对设备日期与时间，确认当前网络能正常访问服务商的订阅地址。若提示认证失败或内容无效，应向服务商核对地址有效期、访问权限和输出格式。不要把含认证信息的完整链接发到公开讨论区；排查时保留错误提示即可，不必公开订阅内容。

在 Add Server 先选择与服务端一致的 Type，再按该协议要求填写地址、端口及认证字段。不同协议还可能需要 TLS、传输方式、Server Name 或其他附加参数，不能只复制地址与端口就假定完整。字段取值应以已有服务器资料为准，不要根据协议名称猜测密码、加密方式或开关状态。保存后回到 Home 确认条目存在，再执行连接测试；若失败，优先逐字段对照，而不是反复更换协议类型。

在 Home 找到对应订阅分组，使用该分组提供的更新操作；具体入口以当前界面显示为准。更新前记录正在使用的条目，更新后检查是否成功完成、分组内容是否变化，以及原条目是否被更名或移除。订阅更新会读取服务商当前返回的内容，不能保证每个旧条目始终保留。若连接选择发生变化，重新选定有效条目再测试；不要为刷新而重复导入同一地址，否则容易留下多个内容相近的分组。

先展开对应分组，并检查搜索、筛选或隐藏设置是否限制了显示；再确认刚才更新的是目标订阅，而不是另一组资料。若分组确实为空，应查看更新结果，向服务商核对订阅有效期和当前返回内容。导入成功只表示导入流程完成，不代表每个条目都有效，也不保证服务商一定返回相同数量。删除分组前先保留可恢复的资料，避免在排查显示问题时丢失原地址；不建议连续重复导入来试错。

Subscribe 通常用于获取和更新服务器条目，Config 用于管理规则及相关配置；两者不能简单视为同一个更新任务。更新服务器订阅后，应单独检查当前启用的 Config 及其来源，不能据此认定规则也已同步。具体导入内容取决于资料本身的格式。修改或替换 Config 前先备份，启用后再核对 Global Routing 是否为 Config，并检查关键规则和 FINAL；只在列表里看到文件，并不等于该文件已经生效。

Global Routing 的三种姿态是配置 Config、代理 Proxy、直连 Direct。Config 按当前配置中的规则决定连接策略，适合需要规则分流的情况；Proxy 让受客户端处理的连接使用所选代理；Direct 采用直接连接。日常按实际需求选择，不把 Proxy 当作修复一切连接问题的开关。排查时可以在记录原设置后临时切换作对照；验证完成再恢复，并区分界面中的 Proxy、Direct 与规则策略关键字 PROXY、DIRECT。

先确认 Home 已选择有效服务器，再查看系统是否仍在等待 VPN 配置授权或设备身份验证。随后检查 Settings 中是否有其他正在启用的 VPN 配置、设备管理限制或组织策略；受管理设备应按管理要求处理。记录客户端显示的具体错误，再尝试关闭连接并重新打开应用。不要一开始就删除全部系统配置或重置网络；只有在确认影响范围并保存必要信息后，才考虑更大范围的系统排查。

连接状态只表明隧道已建立，不代表目标网站、服务器与 DNS 都正常。先关闭连接，确认基础网络可以访问普通网页；再启用连接，检查所选服务器及订阅是否有效。记录 Global Routing 和当前 Config，分别测试不同目标，判断是全部失败还是部分失败。必要时在 Wi-Fi 与蜂窝网络间对照。每次只更改一个变量；若只在 Config 下失败，优先检查命中的规则与 DNS，而不是立即删除整个配置。

先确认 Global Routing 为 Config，再确认目标配置文件已经启用。规则通常自上而下匹配，首个命中项决定策略，因此前面的宽泛规则可能先于后面的精确规则生效。检查 DOMAIN、DOMAIN-SUFFIX、IP-CIDR 等条件是否符合实际目标，并核对策略拼写及引用是否有效。FINAL 应放在规则末尾，处理前面未命中的连接。修改后用新发起的连接验证，已有连接可能继续沿用原处理结果；不要只凭一次访问推断整份规则失效。

先在系统电池页面比较相近时段的使用情况，同时考虑屏幕时长、信号强弱、实际传输量和网络切换。频繁重连、持续高流量、密集测试或长时间详细日志都可能增加处理负担。检查 On Demand 是否符合需要，减少不必要的重复测试；为诊断临时开启的详细记录，用完后恢复。协议名称本身不能直接决定耗电高低，应在相同网络与任务下比较；不要仅凭 VPN 状态持续显示就认定客户端异常运行。

Connectivity Test 用于辅助判断特定测试条件下的连通情况，不等同于所有网站、应用和传输方式都能正常使用。Data 中的流量记录也需要结合统计范围与重置状态解读，不能替代服务商的用量或有效期记录。测试通过但目标访问失败时，继续检查目标域名、规则命中与 DNS；测试失败而部分访问正常时，核对测试目标本身。向服务商反馈时说明网络类型、失败目标和错误现象，并遮盖订阅地址及认证字段。