选择 iPhone 上的代理工具，不能只看界面是否熟悉或配置文件能否导入。一次性购买成本、自己已有配置的兼容性、规则维护方式、日常操作门槛和耗电表现，都需要放在实际使用场景里判断。Shadowrocket（小火箭）是 iOS/iPadOS 上的付费客户端；客户端购买费用不包含线路服务，本文以用户已有自己的服务资料为前提，不提供或推荐节点与订阅。
本文不把“功能多”直接等同于“更适合”，而是从购买、配置迁移、规则与脚本需求、上手成本和续航五方面，整理一套可在自己的 iPhone 上执行的判断方法。若考虑改用 Shadowrocket，先备份资料、核对协议与配置语法，再用同一网络和测试任务验证；结果不合预期时，可保留原有工作流程，不必一次性迁移全部设置。
一、先把比较问题拆成可验证的条件
“哪个好”没有脱离使用条件的统一答案。有人只需要导入自己的服务资料、选择服务器并连接；有人维护多组规则、脚本和重写项目；也有人最在意一次性购买后是否能恢复应用。把这些需求分开，才能避免单凭功能清单或他人截图作决定。
先写下最近一周真正做过的操作：是否编辑规则，是否依赖脚本处理特定请求，是否经常切换策略，是否需要多个配置文件，以及是否遇到订阅更新后手动修改被覆盖。记录的是实际使用频率，而不是“以后可能会用”的功能。若长期没有编辑脚本或重写内容，脚本功能数量未必是决定因素；若日常依赖自定义逻辑，则兼容性和调试成本应排在前面。
价格判断也要区分应用与服务。Shadowrocket 的应用通过 App Store 获取，购买资格、价格和设备兼容性以 App Store 页面标注为准；一次性买断指客户端购买，不等于线路套餐，也不保证已有服务资料持续有效。核对产品时可确认应用名称、开发者 Shadow Launch Technology Limited 与应用 ID 932747118，不要仅凭图标辨认。
二、购买成本：看长期使用需求，不只看首次付款
购买前先确认自己是否真的需要另一款客户端。若现有配置稳定、日常任务都能完成，换工具会增加学习和维护成本；如果目前的操作流程难以处理、现有资料格式不兼容，或希望将规则和服务条目分开整理，再评估购买是否能解决具体问题。为一个尚未出现的需求付费，未必比先把现有配置理顺更划算。
还要把“购买应用”和“恢复数据”分开考虑。通过 App Store 获取应用，不会自动保证个人服务密码、订阅链接、自定义规则或配置文件已经备份。换机或重装前，先确认资料存放位置，并对包含密码、密钥、令牌的内容做好私密保存。不要把完整订阅链接放进公开截图或求助帖。
购买核对
- 获取入口
- App Store
- 应用名称
- Shadowrocket
- 开发者
- Shadow Launch Technology Limited
- 应用 ID
932747118
购买前核对商店产品信息；价格与兼容性以 App Store 页面标注为准。
迁移核对
- 服务器资料
- 地址、端口、认证与协议
- 订阅资料
- 自己的订阅链接及更新方式
- 配置文件
- Config 中的文件与自定义改动
- 敏感内容
- 密码、密钥与访问令牌
应用重新安装与个人资料恢复是两件事，先备份再迁移。
若已购买后更换设备，可使用当初购买的 Apple 账号在 App Store 查找已购项目。找不到记录时，先核对用于 Media & Purchases 的账号和购买记录，再检查产品页面所示的设备要求。不要因为换机就假设必须再次购买，也不要把应用购买资格当作服务资料的备份。
三、规则、配置与脚本：迁移前先检查兼容范围
配置迁移不是把文件放进新应用就结束。不同客户端对配置格式、策略名称、规则类型、脚本接口和重写语法的支持可能不同；即使文件可以导入，也不代表每个字段都按原意生效。尤其是依赖脚本或自定义策略的配置，应先找出关键功能，再逐项验证，而不是只看导入时有没有报错。
Shadowrocket 中，Home 用于检查已有服务器条目和连接状态，Config 用于管理配置文件，Home → Global Routing 用于选择路由方式。按配置规则分流时，需确认 Global Routing 使用 Config，并检查当前实际选中的文件。文件出现在 Config 列表里不等于已经启用；连接开关打开也不证明规则按预期命中。
| 检查项目 | 迁移前记录 | 在 Shadowrocket 中验证 |
|---|---|---|
| 协议与服务器字段 | 自己的资料所列协议、地址、端口与认证参数 | 在 Home 对照对应条目的类型和字段；不确定时不要擅自改协议。 |
| 规则顺序 | 重要的 DOMAIN、DOMAIN-SUFFIX、IP-CIDR、GEOIP 与兜底策略 | 在 Config 检查规则是否存在、顺序是否合理，以及 FINAL 的实际去向。 |
| 脚本与重写 | 逐条列出依赖的脚本触发条件、目标请求与重写用途 | 先单独验证关键任务；不能仅因配置导入成功，就认定脚本功能完整兼容。 |
| 策略与分组 | 自定义策略名、策略组及规则引用关系 | 核对规则指向的策略是否存在，并通过实际请求观察最终处理方式。 |
| 域名与 DNS | 记录特殊域名、解析设置及需要直连的本地服务 | 固定网络逐个测试，区分解析失败、规则误命中与服务器连接问题。 |
规则示例只能说明语法，不应覆盖整份现有配置。比如 DOMAIN-SUFFIX,example.com,PROXY 可表达对示例域及其子域的匹配意图，FINAL,DIRECT 则将未命中前置规则的请求交给 DIRECT。实际策略名称必须与自己的配置一致；若 FINAL 指向其他策略，需按该配置的定义理解。
结论：先验证关键任务，再迁移全部配置
把每天最依赖的规则、脚本或重写列为必测项。只要其中一项结果不同，就先定位语法、策略或触发条件差异，不要同时替换订阅、DNS 和规则文件。
四、上手门槛：先选合适的路由姿态
对于只需要连接和基础分流的用户，优先学会确认 Home 中的服务器、Config 中的配置，以及 Global Routing 当前模式，通常比一开始改写复杂规则更有效。需要细粒度控制时，再逐步了解规则的匹配范围和顺序。每增加一层自定义设置，就增加一项需要备份、解释和排错的内容。
按当前配置中的规则处理请求，适合需要区分直连与代理目标的日常分流。使用前确认配置已选中，且规则末尾有符合需求的兜底策略。
适合：已有规则、希望按域名或地址分流。
用于代理路由的模式对照，可协助判断某个目标在代理路径下是否可访问；它不能证明 Config 中的规则顺序正确。
适合：临时对照代理路径或排查规则结果。
用于直连路径对照。若目标在 Direct 下不可访问，不应立即据此判断代理服务器或配置文件故障。
适合：确认当前网络的直接访问表现。
初次配置时，可以先保留一份未改动的配置副本，再启用待测配置。每次只修改一个条件，例如只调整一条 DOMAIN 规则，随后使用同一设备、同一网络、同一目标网页复测。若切换 Global Routing 后问题消失，记录差异并恢复预期模式，再检查对应规则，而不是把临时测试模式当成最终配置。
-
备份原文件
进入 Config，确认当前使用的配置文件，并保留原文件或可恢复副本。记录自己手动修改过的规则，避免订阅更新后无法辨认差异。
-
导入待测配置
在 Config 导入自己的配置文件，检查文件是否完整显示。先不要删除原配置，也不要同时替换服务器资料与规则。
-
确认当前选择
回到 Config 核对实际选中的配置文件，再到 Home → Global Routing 选择 Config。不要只凭文件名或连接开关判断设置已经生效。
-
验证必需功能
先测试一条直连规则、一条代理规则，以及日常依赖的脚本或重写任务。遇到差异时记录目标、规则和结果，再逐项调整。
五、续航与最终决定：用可复现的测试取代猜测
续航没有一个适用于所有人的固定答案。设备型号、电池状态、系统版本、网络信号、屏幕使用时间、后台活动与连接时长都会影响结果。不能只凭某次电量下降就认定客户端耗电较多，也不宜把不同日期、不同网络下的记录直接比较。
可以做一轮简易对照：在同一台 iPhone、相同电量区间和相近信号条件下，分别使用各自需要的日常配置；保持屏幕亮度、测试时长、常用应用和目标任务尽量一致。记录开始与结束电量、Wi-Fi 或蜂窝网络、连接模式和实际使用内容。若其中一次遇到信号变差、系统更新或大量视频播放，应把该轮标为异常，不据此下结论。
- 先看后台条件：核对 Settings → Battery 中对应时段的使用情况，并留意同一时段是否有高强度前台任务。
- 再固定网络：Wi-Fi 与蜂窝网络分别记录；信号弱时设备可能增加无线通信功耗。
- 保持配置可比：不要一边比较一边更换规则、DNS、服务器与连接模式。
- 重复观察：单次短测只能作为线索；多次相近条件下出现同类差异，才值得进一步排查。
配置文件能导入，就代表功能都兼容吗？
不代表。先检查配置段、规则策略名称与脚本、重写依赖，再用实际目标逐项测试。重要功能结果不一致时，保留原配置并单独处理差异。
我只用基础连接，需要学习所有规则吗？
不需要一次学完。先会在 Home 选择已有服务器、在 Config 确认配置、在 Home → Global Routing 核对模式；只有分流结果不符合需求时，再追查相关规则。
测试时电量掉得更快，能说明客户端更耗电吗？
单次测试不足以判断。固定设备、网络、使用时长和任务后重复观察，并查看 Settings → Battery 的对应记录；信号和前台应用都可能影响结果。
迁移后网页打不开，应该先改 DNS 吗？
先区分连接、模式与规则：核对 Home 的选中服务器、Home → Global Routing 的当前选项，再用同一网页做直连或代理对照。每轮只改一项，避免同时改 DNS 和规则。
如果主要需求是简单连接，且现有流程稳定，先保留已验证的做法通常更省心；如果希望使用 Shadowrocket，就先用一份副本验证核心功能，确认规则、脚本和日常操作均符合预期后，再决定是否逐步迁移。购买决策、配置兼容与线路可用性是三个不同问题，分别核对比追求一个抽象的“最好”更有实际价值。