选择 iOS 代理工具，不能只看“免费”或协议列表，还要确认获取渠道、配置方式、规则控制、隐私边界与长期维护成本。本文以 Shadowrocket 为中心，说明购买客户端与使用已有订阅的区别，并比较应用内不同路由模式适合的场景。涉及价格、兼容性与界面选项时，请以当前 App Store 商品页和设备上的实际显示为准。
选 iOS 代理工具，先看需求而不是宣传词
讨论代理工具时，常见的宣传重点包括“支持多少协议”“一键连接”“完全免费”或“省电”。这些说法单独看都不足以判断是否适合自己。实际使用至少涉及客户端本身、用户已有的连接参数或订阅、分流规则，以及 iOS 对 VPN 配置的授权。某一环节不匹配时，功能列表再长也无法解决当前问题。
Shadowrocket 是面向 Apple 平台的付费客户端，获取时应通过 App Store 核对应用名称、开发者与应用 ID。客户端购买与线路服务是两件不同的事：购买应用不包含订阅，也不会自动产生可连接的服务器。本文以用户已经拥有自己的订阅或服务端参数为前提，不提供线路或订阅推荐。
- 先确认用途：是希望按域名分流、临时让所有请求走代理，还是只需要检查某条连接？不同目标会影响规则与路由模式的选择。
- 再确认资料：手动添加需要服务端提供完整协议参数；使用订阅则需要完整有效的订阅地址。只知道服务器地址和端口，通常不足以建立连接。
- 最后看维护能力：规则、DNS、证书与传输参数需要按实际情况核对。希望长期稳定使用，就要能找到问题所在，而不是只依赖一个“连接”开关。
“免费”也不是一个足够具体的技术指标。免费应用可能有不同的功能、数据处理方式、广告或服务条款；仅凭价格无法判断安全性、稳定性或隐私保护。不要把敏感订阅链接、密码、UUID 或密钥交给来历不明的网页或工具处理，也不要根据宣传页面推断应用一定支持自己现有的参数。
价格、获取渠道与线路费用要分开核算
查看 Shadowrocket 的费用时，应以自己所在 App Store 店面的商品页为准。价格、税费及购买条件可能因店面和时间不同而变化，因此不适合把某一地区看到的金额当作所有用户的固定价格。购买前核对开发者 Shadow Launch Technology Limited、应用 ID 932747118 和商品页信息；不要仅凭名称相似就认定是同一应用。
获取入口应保持清晰：从 App Store 购买并安装。安装后首次连接时，iOS 可能询问是否允许添加 VPN 配置；确认是由自己主动发起的 Shadowrocket 操作后，再按系统提示授权。这个系统授权关系到网络隧道的建立，不代表应用已经获得订阅或连接参数。
客户端费用
- 核对位置
- App Store 商品页
- 核对信息
- 开发者、应用 ID、当前价格
- 获得内容
- 客户端使用权
购买客户端不包含用户自己的订阅或服务。
订阅与参数
- 核对位置
- 用户自己的服务商资料
- 核对信息
- 订阅 URL 或完整协议参数
- 获得内容
- 由服务提供方说明
客户端购买不会自动生成服务器、密码或订阅地址。
如果自己的目标只是评估一次性客户端成本，应将 App Store 当前标价单独记录；如果还要使用订阅，则另行核对已有服务的费用、期限和更新条件。不要把两类费用混成“客户端套餐”，也不要因为客户端已经购买，就推断连接服务也已开通。
需要确认正规获取与购买说明时，可查看下载说明。进入商品页后仍应以 App Store 对当前 Apple 账户显示的内容为准。
协议、规则与耗电：看实际工作方式
协议列表只说明客户端可处理哪些连接类型，不表示用户可以任意选择一种协议来替代已有服务端设置。Shadowrocket 的协议类型要与自己的服务端资料一致；例如 Shadowsocks、VMess、VLESS、Trojan、Hysteria2 与 WireGuard 所需的认证和传输参数并不相同。若订阅已经正确导入，通常应先使用导入的条目，不要为了追求某个协议名称而手工改写参数。
规则功能则影响请求如何分流。Global Routing 中的 Config 会根据当前配置文件里的规则决定去向；Proxy 用于将流量按代理方式处理；Direct 表示直连。具体行为还与配置内容、请求类型和当前连接状态有关。排查时先记录所选模式，再检查规则命中结果，避免把“连接已建立”误认为“所有请求都按预期分流”。
按当前配置中的规则处理请求，适合需要分流并且已经核对过规则的日常使用。
适合：国内外请求需要不同策略、希望按规则管理
以代理方式处理流量，适合短时间检查代理连接是否能正常承载请求；不适合作为判断规则正确与否的唯一依据。
适合：临时排查分流规则，或按需使用全局代理
请求直连，不通过代理出站。可以用来确认当前网络本身是否可访问目标，但不能用它验证代理线路。
适合：核对直连访问与网络基础状态
耗电表现不宜用一句“某工具更省电”概括。持续建立 VPN 隧道、蜂窝信号强弱、屏幕使用时间、后台请求频率、规则复杂度和连接是否反复重试，都可能改变耗电。不同设备与网络条件下的测试也不能直接互换。若需要比较自己的实际使用情况，应固定同一台设备、同一网络和相近使用时长，并记录开始与结束电量；不要把一次测试结果当作所有用户的结论。
结论：先让连接与分流各自可验证
测试代理连通性时，先确认已选择有效条目；测试规则时，再确认 Global Routing 为 Config 并检查对应规则。拆开这两步，能减少把线路问题误判成规则问题的情况。
- 连接失败：优先核对 Address、Port、认证字段、TLS 或传输参数是否与已有资料一致。
- 只有部分网站异常：核对 Global Routing、规则顺序和具体策略，不要先删除整个配置。
- 电量下降明显：记录网络类型、连接时长与后台使用情况，再检查是否存在反复断开重连；单纯切换协议不能保证耗电下降。
按配置难度选择：新手与进阶用户的不同重点
配置难度不只取决于界面有多少按钮，也取决于用户手中资料是否完整。已经持有可导入订阅的用户，通常可以从 Subscribe 导入开始；需要手动添加时，则应确认协议类型、地址、端口、认证和传输字段齐全。没有完整参数时，反复尝试不同 Type 不会把缺失的信息补出来。
下面的操作顺序适合首次设置已有订阅。界面文字以应用当前版本实际显示为准；若本地界面布局不同，应按相同功能项核对，而不要照搬不匹配的字段。
-
核对来源
通过 App Store 获取 Shadowrocket，并核对商品页中的开发者与应用 ID。安装前确认设备和系统是否符合商品页当前列出的要求。
-
导入订阅
在 Home 右上角点击“+”，进入 Add Server，将 Type 设为 Subscribe；粘贴自己已有的完整订阅 URL，检查路径与查询参数没有遗漏后保存。
-
更新列表
返回 Home，下拉刷新订阅，等待请求结束后再检查条目是否出现。更新失败时记录提示原文，不要连续重复点击或先删除仍有用的记录。
-
选择路由
需要按规则分流时，核对 Global Routing 为 Config，并确认当前配置及规则策略；若只是验证直连或代理，可短时切换相应模式进行单项测试。
-
授权测试
选择一条已有条目并开启连接，按 iOS 提示允许 VPN 配置。先测试连接状态，再测试目标请求与规则结果；每次只改一个条件并记录结果。
新手应优先选择可解释、可恢复的设置路径：保留原订阅与配置，先验证导入是否成功，再处理路由。进阶用户可以进一步检查 Rule 顺序、DNS、Host 与传输选项，但同样应先备份可恢复的配置，并避免同时修改多个互相关联的参数。
使用免费代理 App 的宣传页面时，也应单独审查其数据收集说明、权限请求、服务条款和维护情况。若无法确认请求数据如何处理，或产品要求提交不必要的敏感资料，就不应仅因“免费”而交付订阅凭据。不要把自己的订阅链接公开粘贴到评论区、截图或第三方解析页面。
最终选择清单：把条件逐项落到可检查的设置
选择前可以用以下清单把抽象需求转成实际检查项。若某一项无法确认，就先查清楚再决定是否购买或导入；不要用网上的旧截图代替当前 App Store 信息，也不要根据某一台设备的耗电表现推断另一台设备会得到相同结果。
- 正规来源：能否在 App Store 核对 Shadowrocket 的名称、开发者与应用 ID
932747118？ - 预算边界：是否把客户端购买与自己已有订阅的费用分开核算？标价是否以当前店面显示为准？
- 资料完整：自己是否有可用的订阅 URL，或包含协议、认证与传输字段的完整参数？
- 规则需求：是否需要 Config 的规则分流？若需要，能否找到当前启用的配置并检查规则顺序？
- 隐私评估：是否清楚订阅链接、密码与 UUID 属于敏感信息，并避免交给不明服务处理？
- 实际测试：是否在同一设备、相近网络和相近时段测试连接稳定性与耗电，而不是只看宣传结论？
买了客户端就能直接连接吗？
不能。购买的是客户端使用权；还需要用户自己的订阅或完整服务端参数。先从 Home 导入已有订阅，再下拉更新并确认条目出现。
协议支持越多就一定越好吗？
不一定。协议类型必须与已有服务端资料匹配。进入 Home → “+” → Add Server 时，应依据资料选择 Type，而不是逐个切换类型试连。
为什么连上后仍有网站打不开？
连接建立与请求分流是不同环节。先在 Home 确认当前条目，再检查 Global Routing 是否为预期模式；使用 Config 时继续核对相关 Rule 与策略。
对希望按规则管理流量、并愿意核对自己的订阅与配置的用户，Shadowrocket 的价值在于把连接管理和路由设置集中在 iOS 应用中；对只看重“免费”或期望应用自动提供服务的人，则应先弄清产品本身、订阅和数据处理之间的边界。最终判断以当前 App Store 商品页、应用内可见设置和自己的实际测试为准。