本文目录
买一款手机代理应用,不只是比较价格和能否添加节点。已经有桌面规则、想让其他设备共用代理,或准备维护脚本的人,后续投入会很不一样。把现在的配置和真正会用到的功能列出来,再核对商店与官方说明,能减少买完才发现要重做设置的情况。
Shadowrocket、Stash、Surge 各适合什么需求?
| 主要需求 | 可以优先考虑 | 需要权衡的地方 |
|---|---|---|
| 导入常见节点、做基础分流,比较在意价格 | Shadowrocket | 需要完整的 Surge 模块工作流或团队调试时,操作方式不够统一 |
| 沿用 Clash 风格的策略组与规则 | Stash | 只使用单个节点、不维护规则时,功能可能偏重 |
| 日常需要调试请求、脚本、模块或 MITM | Surge | 只想更新订阅和切换节点时,成本与学习量较高 |
选定应用后,再核对现有配置能否导入、规则怎样编辑、局域网共享是否满足需求,以及购买方式和迁移成本。不能仅凭节点成功导入,就认定原来的规则和设置也能原样保留。
Clash 配置能直接导入这三款应用吗?
Stash 官方定位是把 Clash Premium 风格能力带到 Apple 平台,因此已经使用 proxy-groups、rules 和 Rule Provider 的用户通常更容易延续原来的组织方式。仍要查看实际导入结果:脚本、TUN、DNS 和个别 Mihomo 新字段未必一一对应。
Shadowrocket 是独立的规则代理工具。官方 App Store 说明列出了域名、CIDR、GeoIP 规则、远程规则文件、DNS、脚本过滤和多级转发,但它不是 Mihomo 图形前端。节点导入成功后,原来的 Clash 策略组和覆写不一定还保持同样结构。
Surge 使用自己的 Profile 与 Module 体系。Module 会以更高优先级覆盖 Profile,适合维护可审查的本地补丁;只有 Clash 订阅、又不准备重做规则时,不应因为 Surge 功能多就默认迁移成本最低。
策略组、节点与模块:日常维护方式的区别
- Stash
- 更适合围绕 Clash 风格策略组选择、覆写和规则集维护;也覆盖 iOS、tvOS、macOS 与 visionOS。
- Shadowrocket
- 适合快速添加常见节点与规则,并可在 iPhone、iPad、Mac 和 Apple TV 使用;当前功能与购买地区以 App Store 页面为准。
- Surge
- 适合查看连接、维护模块、执行脚本和调试 HTTP 流量。官方文档对 Module、MITM 和脚本有完整体系。


局域网共享有哪些支持和限制?
局域网共享方式
| 应用 | 可以确认的做法 | 选择时要注意 |
|---|---|---|
| Stash | 官方文档明确支持 iOS 提供 HTTP 与 SOCKS 代理;开启“允许局域网连接”后使用手机局域网 IP 和 7890 端口 | 这是手动代理共享,iPhone 不会因此变成完整透明网关 |
| Shadowrocket | App Store 说明覆盖本机流量与多级转发,但没有把局域网共享写成主要承诺 | 若当前版本设置里没有明确的共享监听入口,不要按第三方旧截图推断 |
| Surge | 官方原理文档说明 iOS 可用本地代理服务接管另一台设备的请求 | 目标设备仍要手动填写代理;具体监听地址与权限以当前 Profile 和版本为准 |
无论使用哪款应用,共享前都要允许 iOS 的“本地网络”权限,并让两台设备处于同一 Wi-Fi 或个人热点。先用另一台设备打开一个测试网页,再从 iPhone 的请求记录确认它确实进入预期策略;不用时关闭监听,公共 Wi-Fi 上不要暴露无认证代理。
普通订阅连接不需要安装 MITM 根证书
三款工具都可能出现重写、脚本或 HTTPS 解密相关能力,但普通订阅连接并不需要安装根证书。MITM 会让应用在本机重新签发证书,部分采用证书锁定的 App 还会直接拒绝连接。
安装 Module 或远程脚本前,先读源文件,确认它会修改哪些主机、请求头和响应内容。Surge 官方文档说明,Module 可以覆盖 Rule、Script、URL Rewrite 与 MITM 设置。来源不明的模块可能改变这些设置,不要随手导入。
价格、上架地区与设备支持以当前商店为准
价格、上架地区、家庭共享与支持设备都可能调整。Shadowrocket 当前美国区 App Store 页面显示为独立付费应用,并明确说明不附带代理服务;Stash 与 Surge 也需要以购买账号所在地区的商店页面和官方说明为准。
如果未来还要在 Apple TV、Mac 或家庭成员设备上使用,先确认同一购买能否下载、配置怎样同步,以及脚本和证书是否会跟着迁移。把这些成本算进去,才是实际价格。
换客户端时,订阅、规则与设置如何迁移?
更换客户端时,不要把旧应用的全部缓存和证书一起复制过去。先在新应用中导入订阅,用一个固定节点确认能联网,再逐项添加自己维护的规则、模块或脚本。
迁移顺序
- 保存原始订阅地址和当前可用的策略组名称
- 列出自己写过的规则、模块或脚本,不复制未知缓存
- 新应用第一轮只验证订阅、固定节点、锁屏和切网
- 高级规则逐项重建,每加入一项就查看一次连接
- 新应用稳定数日后再删除旧配置与证书
