Shadowrocket（小火箭）的连接开关、服务器选择、规则配置与订阅更新是不同环节。本文以用户已有自己的服务商与订阅为前提，按首次连接、模式选择、更新排错和换机恢复的顺序说明操作。排错时一次只改一项，记录 Connectivity Test 与实际访问结果，避免把客户端购买、系统 VPN 授权和服务可用性混为一谈。
1. 打开连接开关没反应，先检查哪里？
首次连接需要已有可用的服务器条目、明确的默认选择，以及系统允许添加 VPN 配置。Home 上的开关用于启动连接，并不会自动生成服务器。列表为空时，应先导入自己已有的订阅；列表已有内容时，先确认选中的是服务器条目，而不是只展开了订阅分组。
-
检查条目
进入 Home，确认已有服务器，且地址、端口、认证信息来自自己已有的配置。
-
选中服务器
点服务器左侧圆点，将该条目设为默认；记下名称，便于后续核对测试对象。
-
打开开关
打开 Home 的连接开关。系统首次询问是否允许添加 VPN 配置时，阅读提示并允许，按要求完成设备验证。
-
进行测试
回到 Home 使用 Connectivity Test，再访问实际需要使用的网页，分别记录结果。
如果系统授权被取消，返回应用重新发起连接；如果开关短暂开启后立即关闭，先查看系统 VPN 状态和应用错误信息。不要反复删除全部配置，因为这样会丢失判断故障发生在哪一步的依据。
2. Global Routing 的 Proxy、Direct、Config、Scene 怎么选？
Global Routing 决定连接采用哪种路由姿态，不等同于服务器列表。日常需要按规则分流时，先在 Config 中确认使用的配置文件，再到 Home → Global Routing 选择 Config。排查服务器可用性时，可以临时用 Proxy 做对照，完成后恢复原来的设置。
Config 下只有部分网站失败，而 Proxy 下相同网站可以访问时，应优先检查规则命中和策略选择，而不是直接判定服务器失效。Scene 也不是“自动找最快服务器”的同义词；没有核对场景条件与对应设置前，不宜把它作为排错基准。
3. VPN 已连接，为什么网页仍然打不开？
系统显示 VPN 已连接，只表示隧道处于运行状态，不能证明远端认证成功、DNS 解析正确或目标网站可达。Connectivity Test 的成功结果也只对应测试目标和当时的网络条件，不能代替所有业务的访问验证。
- 先查本地网络：暂时关闭连接，确认 Wi-Fi 或蜂窝本身可以联网；需要网页认证的 Wi-Fi 应先完成认证。
- 再查选择对象：回到 Home，核对默认服务器是否仍是预期条目。订阅刷新后，原条目可能已经变化。
- 做模式对照：记录当前 Global Routing，在 Proxy 下重试同一个目标；不要同时更改 DNS 与多条规则。
- 区分失败范围：所有目标失败时检查端点、认证和服务状态；只有单个域名失败时检查规则、解析及目标网站自身状态。
例如“测试有结果但某个网页一直等待”与“所有测试均超时”是两种不同现象。前者需要进一步定位目标连接，后者优先核对服务器是否仍有效。日志和截图中可能包含地址、UUID 或订阅凭据，对外提供排错材料前应遮盖这些信息。
4. 已有订阅应该从哪里添加？
订阅是用于获取服务器条目的地址，不是普通网页地址，也不是客户端购买凭证。添加时使用自己的完整订阅链接，保留路径、查询参数及大小写。通过聊天工具复制时，要特别检查是否带入了空格、换行或标点。
- 打开 Home，点右上角“+”，在 Type 中选择 Subscribe。
- 在 URL 中粘贴自己已有的订阅地址，填写便于辨认的备注，再保存。
- 回到 Home 下拉刷新，等待请求完成，检查分组内是否出现服务器。
- 选中其中一个服务器，再按首次连接流程授权、连接并测试。
导入成功与连接成功是两个检查点。出现条目说明客户端取得并识别了内容，并不代表每个服务器都能从当前网络访问。本站不提供、不销售、不推荐节点或订阅，仅说明已有配置的使用方法。
5. 订阅更新失败、超时或更新后没变化怎么办？
订阅更新先发起一次获取请求，再解析返回内容。请求超时、认证失效和返回内容不可识别，需要分别处理。先记下错误文本，再判断是网络路径问题还是订阅本身的问题；不要通过反复删除订阅来代替检查。
下拉刷新一直超时，要先开连接吗？
若订阅地址需要经由代理访问，先使用仍可连接的已有服务器打开连接，再到 Settings → Subscribe 检查 Update via Proxy，启用后回 Home 重试。没有可用服务器时，仅打开该选项并不能建立可用路径。
提示认证失败，换服务器有用吗？
先核对订阅 URL 是否完整，再到自己已有服务的管理页面确认链接是否已重置、权限是否仍有效。认证拒绝不同于网络超时，修改 Global Routing 通常不能修复失效的 token。
显示更新完成，条目为什么还是原来的？
返回的内容可能没有变化。核对订阅分组、条目数量与目标服务器参数；不要仅凭名称判断。若手动编辑了订阅生成的条目，后续刷新可能重新写入订阅中的值。
临时改用代理更新后，应记录这一设置，便于下次遇到“服务器已失效，订阅也无法刷新”时识别依赖关系。不要连续高频刷新；先确认一次请求的结果，再决定下一步。
6. 关掉开关后又自动连接，是 On Demand 吗？
On Demand 用于按网络条件触发连接行为。出现切换 Wi-Fi 后自动连接、手动断开后再次连接等现象时，先检查 Settings → On Demand，而不是立即删除系统中的 VPN 配置。规则分流决定流量去向，On Demand 决定何时触发连接，两者分属不同层次。
On Demand 排查
- 入口
- Settings → On Demand
- 检查内容
- 是否启用、网络条件及对应动作
- 对照方法
- 暂时关闭 On Demand，再手动断开
完成对照后按实际需要恢复；不要同时修改路由规则。
系统状态核对
- 系统入口
- 设置 → 通用 → VPN 与设备管理 → VPN
- 检查对象
- 当前启用的 VPN 配置与连接状态
- 观察条件
- 切换 Wi-Fi 与蜂窝后是否再次触发
系统菜单名称可能随系统界面变化，以设备实际显示为准。
如果关闭 On Demand 后不再复现，说明应回到自动连接条件中调整，而不是更换服务器认证信息。如果仍会自动连接，再检查是否存在其他系统管理设置，并保留当前状态供进一步排查。
7. Config 的规则顺序会影响哪些网站走代理吗？
会。Config 使用当前配置文件的规则判断连接，规则通常自上而下匹配，较早命中的规则会影响后续判断。DOMAIN-SUFFIX 用于域名后缀，IP-CIDR 用于地址网段，GEOIP 按 IP 地理数据库判断，FINAL 为前面未命中时的兜底。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY这段示例表示 example.com 及其子域名交给 PROXY，指定的私有地址段使用 DIRECT，随后检查 GEOIP，最后由 FINAL 兜底。它只是规则语法示例，不应直接覆盖现有完整配置；实际还要确认配置中的策略名称有效，以及 DNS 和其他设置是否符合原有用途。
no-resolve表示该 IP 规则匹配时不为此主动进行域名解析；已有目标 IP 时仍可进行网段判断。- GEOIP 判断的是地址归属，不是网页语言，也不等同于网站经营主体所在地。
- 如果将宽泛匹配放在前面，后面的更具体规则可能没有机会命中。
- 排错时先在 Config 备份当前配置，再调整单条规则，连接后检查目标流量的实际去向。
8. 服务器地址和端口都填了，为什么仍然认证失败？
地址与端口只描述服务入口。Type 决定用什么协议与该入口通信，认证字段和传输设置也必须与已有服务端配置一致。例如端口为 443 并不自动意味着 Type 应选 Trojan，也不能据此判断 TLS 是否应该开启。
| Type | 重点核对 | 常见误区 |
|---|---|---|
| Shadowsocks | 密码及加密方法 | 密码正确但加密方法与服务端不一致 |
| VMess / VLESS | UUID、传输方式、TLS 相关设置 | 仅复制 UUID，遗漏传输路径或服务端名称 |
| Trojan | 密码、TLS 与服务端名称 | 把连接地址与证书校验所需名称混为一项 |
| Hysteria2 | 认证、TLS 及当前网络的 UDP 可达性 | 只检查普通网页可达，没有检查 UDP 路径 |
| WireGuard | 密钥、隧道地址、Endpoint 等 | 将对端公钥填入自己的 Private Key |
优先重新核对原始参数，而不是尝试猜测协议或关闭证书校验。TLS 报错还可能与设备时间、证书有效性或服务端名称有关；忽略校验不能作为常规修复方法。若参数来自订阅，应先确认更新是否成功，避免在生成条目上反复手改后又被刷新覆盖。
9. 换到 iPhone 或 iPad，如何恢复已购应用和配置？
App Store 的已购记录与 Shadowrocket 内的服务器配置是两类数据。使用购买时的 Apple ID 恢复应用，不代表服务器、订阅和规则文件已经全部转移。换机前应分别检查购买记录与配置备份，并在新设备上重新验证连接。
换机流程：应用恢复与配置迁移分别处理
原设备
- 确认 App Store 中的购买账号与购买记录。
- 保留自己的订阅地址和必要的手动服务器参数。
- 备份正在使用的配置文件，记录 Global Routing 与 On Demand 设置。
- 配置备份含敏感凭据，存放在自己控制的位置。
新设备
- 用购买时的账号，在 App Store 已购项目中查找 Shadowrocket。
- 恢复应用后，确认服务器、订阅和配置是否实际存在。
- 缺少内容时从自己的备份恢复，或重新添加已有订阅。
- 首次连接重新允许 VPN 配置，并运行 Connectivity Test。
同一购买账号不等于配置自动一致；是否通用购买、兼容设备与系统要求以 App Store 页面标注为准。
若商店仍显示购买价格，先核对登录账号、商店地区与购买记录，不要急于重复购买。若原设备的服务器已经失效，将相同配置恢复到新设备也不会自动恢复服务可用性。
10. 购买客户端后，还需要单独准备什么？
Shadowrocket 是闭源商业应用，在 Apple 平台通过 App Store 发行，采用一次性买断。客户端买断 ≠ 线路套餐。购买客户端取得的是应用使用权，不会自动获得可连接的服务器、订阅或服务时长；本文操作均以用户已有自己的服务商与订阅为前提。
- 核对产品：名称为 Shadowrocket，开发者为 Shadow Launch Technology Limited，应用 ID 为
932747118。 - 核对设备：主要使用设备为 iPhone 与 iPad；Mac、Apple TV、Apple Vision 的兼容性以及系统要求，以 App Store 页面标注为准。
- 核对配置：准备自己的订阅或服务器参数，确认服务有效，再选择 Global Routing 与规则文件。
- 保留检查结果：记录默认服务器、路由模式、Connectivity Test 结果及失败目标，后续排错按同一条件复测。
新手可以采用固定检查顺序：先确认本地网络，再确认服务器选择，随后完成系统授权、运行测试，最后检查规则与自动连接。这样能够把“应用没有启动”“服务器不可达”“规则走向不符”和“订阅无法更新”分开处理，减少无关设置对判断的干扰。