在 iPhone 或 iPad 上挑选代理客户端，不能只看应用名称或某一项功能，还要确认自己已有的配置能否导入、日常需要怎样分流，以及是否愿意花时间维护规则。对比时，建议把注意力放在实际工作流：从 App Store 获取应用、导入现有服务器资料、选择路由方式，再用请求记录核对结果。以下内容聚焦 Shadowrocket 的购买与使用判断，不虚构其他应用的价格、功能或兼容情况。
本文从购买成本、协议资料、规则维护、日常操作和学习投入等角度，整理选择 iOS 代理工具时可实际核对的项目，并说明 Shadowrocket 的使用边界。适合已经有自己的订阅、准备购买或调整客户端的用户；读完后可按清单检查现有配置，而不是仅凭功能名称作决定。
一、先看需求：你希望客户端替你处理什么
选客户端之前，先列出实际需求。有人只需要导入已有的服务器条目并手动选择，有人需要按域名或 IP 规则分流，也有人希望按 Wi-Fi 或蜂窝网络状态自动连接。需求不同，最重要的评估项也不同：只需基础连接时，配置流程是否清晰更关键；需要复杂分流时，则应重点检查规则表达能力、配置维护方式和故障诊断入口。
Shadowrocket 是面向 Apple 平台的付费客户端，可在 iPhone、iPad 等设备上使用。应用本身不等于线路服务：购买客户端不会附带服务器、订阅或网络套餐。用户需要已有自己的配置，并自行确认其格式、有效状态及使用条件。购买前应在 App Store 产品页核对应用名称、开发者 Shadow Launch Technology Limited 和应用 ID 932747118；具体价格与适用范围以当前商店页面为准。
还应把一次性客户端购买与持续性的线路费用分开考虑。若已经有自己的订阅，先确认它提供的是服务器订阅地址、单条分享链接还是远程配置；这些材料进入 Shadowrocket 的位置并不相同。不要因为某个客户端的功能列表很长，就默认自己的服务端资料一定能直接导入。
二、费用、协议与资料兼容：先核实关键事实
价格会因 App Store 店面、账户地区及商店当前标示而不同，比较时应以购买按钮附近显示的信息为准，不宜引用过期截图或第三方报价。还要将“客户端费用”和“订阅服务费用”分开记账：前者用于获取应用，后者属于用户与自己的服务提供方之间的安排，两者不是同一笔购买，也不能互相替代。
Shadowrocket 支持多种常见代理协议和导入形式，实际能否使用仍取决于服务器端参数与客户端条目是否一致。常见协议名称包括 Shadowsocks、VMess、VLESS 和 Trojan。仅看到协议名称还不够，Address、Port、认证信息、传输方式、TLS 参数等字段也要对应。二维码或剪贴板只是传递文本的方式，不会自动修正缺失或错误的参数。
| 核对项目 | 实际检查内容 | 避免的误判 |
|---|---|---|
| 商店身份 | 应用名称、开发者、应用 ID 与当前页面价格 | 把相似名称或旧价格当作当前信息 |
| 材料类型 | 服务器订阅、单条分享链接或远程配置 | 把所有 HTTPS 地址都当作服务器订阅 |
| 协议参数 | 协议类型、主机、端口、认证与传输选项 | 只凭端口号推断协议，或用常见值补缺 |
| 路由需求 | 规则分流、全局代理、直接连接或自动连接 | 把全局姿态的结果当成规则配置的效果 |
如果材料来自自己的服务商，应以该服务商为 Shadowrocket 提供的格式说明为准。导入成功只说明文本被识别，不代表服务器可达、凭据有效或规则已经生效。出现问题时，记录错误提示和发生步骤即可；分享截图前先遮住订阅地址、token、密码与 UUID。
三、路由与规则：比较实际工作方式
Shadowrocket 的 Global Routing 会影响流量如何处理。Config 使用当前配置中的规则进行分流；Proxy 将流量置于全局代理姿态；Direct 则用于直接连接。测试一条规则是否生效时，要先确认当前路由姿态是 Config，并确认 Home 中选中了预期配置。若处于 Proxy 或 Direct，观察到的结果不能直接证明 Config 规则写对或写错。
根据当前配置中的规则处理请求，适合需要按域名、IP 或其他规则条件分流的日常场景。应同时维护规则顺序与 FINAL 兜底策略。
适合：规则分流、国内外流量采用不同策略
使用全局代理姿态，不应把它当作逐条验证 Config 规则的方式。排查后应恢复预期路由设置。
适合：临时检查全局代理路径
使用直接连接姿态，可用于核对直连时的基础网络表现；它不会代替配置中的规则策略。
适合：临时检查直连路径
复杂规则带来灵活性，也意味着后续要承担维护成本。规则需要关注匹配范围、排列顺序和兜底项；宽泛规则可能先于例外规则命中，配置更新也可能覆盖本地调整。若只需要少量固定条目，维护庞大规则集未必有收益。开始使用前可先保存一份可恢复的配置副本，再用一条范围明确的规则验证请求记录。
结论：把规则维护成本纳入选择
如果日常目标是精细分流，应优先确认自己能否理解并维护规则；如果不需要精细分流，就不要仅为“功能可能用得上”而引入额外复杂度。
四、动手验证：用一轮小测试判断是否合适
购买或迁移之前，先整理自己的材料类型与必要字段；开始设置后，一次只验证一个环节。这样可以区分是导入格式、服务器参数、路由姿态还是规则顺序导致问题，避免重复添加相同条目或同时改动多个选项。
-
核对商店页
从 App Store 产品页核对 Shadowrocket、开发者 Shadow Launch Technology Limited、应用 ID
932747118及当前价格。系统要求与购买适用范围以页面实际标注为准。 -
辨认配置材料
区分服务器订阅、单条协议分享链接和远程配置。服务器订阅通常从 Home →「+」→ Add Server → Type → Subscribe 添加；远程配置则在 Config 中管理。
-
导入并核字段
保存后检查列表是否出现预期条目；对单台服务器，核对协议、Address、Port、认证信息和传输参数。不要把订阅 URL 填入单台服务器的 Address。
-
确认路由姿态
回到 Home 检查 Global Routing。测试配置规则时选择 Config，并确认当前启用的是预期配置；临时切到 Proxy 或 Direct 后，测试完成再恢复原设置。
-
记录测试结果
对一个目标请求进行测试，查看请求记录中的目标、策略及命中情况。记录失败提示、网络类型和更改项，不要同时改订阅、规则和协议参数。
如果迁移时旧客户端仍保存着配置，不要立刻删除原记录。先确认新应用中的条目数量、名称和关键字段，再单独测试连接与规则。订阅链接可能包含访问凭据，应只在自己的设备中使用；需要向服务商咨询时，提供脱敏后的错误信息，不发送完整链接。
首次使用的学习成本主要来自界面对象的区分：Home 管理服务器条目，Config 管理配置文件，Global Routing 决定路由姿态，规则负责匹配请求。把这几件事分开理解，比一次性调整大量设置更有效。遇到故障时先回到最小可验证状态，也更容易判断问题出在哪个环节。
五、常见问题
下面的问题集中在购买、导入与规则验证时容易混淆的边界。具体界面可能随应用更新而调整，操作时应以设备上实际显示的项目为准。
购买客户端后会自动包含订阅吗？
不会。Shadowrocket 客户端购买与线路订阅是两件事。用户需要已有自己的配置，并分别核对 App Store 的客户端价格与服务提供方对订阅的说明。
订阅地址应该加到 Config 吗？
先辨认它返回的内容。服务器订阅通常从 Home →「+」→ Add Server → Type → Subscribe 添加；远程配置才在 Config 中管理。HTTPS 前缀本身不能说明材料类型。
为什么规则写了却看不出效果？
先检查 Home 是否启用了目标配置，再确认 Global Routing 为 Config。随后核对规则顺序、匹配范围和 FINAL 位置，并用请求记录检查实际命中策略。
迁移时可以直接删除旧配置吗？
建议先保留旧配置作为对照，核验新应用中的条目和关键参数，再逐项测试。确认新配置可用并且可恢复后，再按自己的整理计划处理旧记录。
如果已经确定 Shadowrocket 符合自己的需求，可前往正版核验页查看 App Store 获取入口与购买核对信息。若仍在评估，先用上面的工作流清单检查现有材料、规则需求和维护意愿，再作决定。