协议选型 × 平台限制 × 上架门槛 · 2026-10

用户怎么连上来
决定了你能不能留住他

"用户在 PC、Android、iPhone 上怎么用"看着是个使用说明问题， 其实是协议选型 → 要不要自研 App → 能不能上架的一连串决策。 最便宜的做法（只发配置文件）几乎必然留不住普通用户， 而最贵的做法（四平台自研 App）在拿到用户前就要先付一大笔。

协议主流选择 WireGuard 四平台全内置的 IKEv2 自研 App 门槛 6–12 个月 Play 认证徽章 MASA L2
01

协议选型 —— 这一步决定后面所有平台的成本

协议选错了，后面每个平台都要自己写 App。选对了，四个平台都能用系统自带或官方客户端直接连， 你只需要提供一个配置文件或二维码。

协议WindowsmacOSAndroidiOS速度说明
WireGuard 官方客户端官方客户端 官方 App官方 App 最快 现代默认选择。代码量小、握手快、切换网络恢复迅速。缺点是仅 UDP，少数封闭网络会阻断。
IKEv2 / IPsec 系统内置系统内置 系统内置系统内置 快 唯一四个平台都内置的协议，用户不用装任何 App。但配置需要证书或凭据，手工步骤多，且被识别封锁的概率高于 WireGuard。
OpenVPN 官方客户端第三方 官方 App第三方 App 中 兼容性最好、TCP 模式穿透强，但代码庞大、耗电高、重连慢。iOS 不原生支持，必须靠第三方客户端。
自研 / 混淆协议 需自研需自研 需自研需自研 视实现 抗封锁能力强，但每个平台都要自己写，且应用商店审核风险明显更高。除非你的目标市场有强封锁，否则不建议第一步就走这条路。
建议：标准层（隐私 / 公共 WiFi）用 WireGuard，可先用官方客户端 + 配置文件起步； 流媒体层一开始也用 WireGuard，先用真实用户验证解锁率，再决定是否值得投入自研 App。 不要一上来就自研协议——那是把钱花在你还没验证的需求上。
02

三条交付路径 —— 你打算让用户装什么

A · 只发配置文件

$0 开发

用户自己装 WireGuard 官方客户端，你给 .conf 文件或二维码。

问题：普通用户不知道 WireGuard 是什么，装完还要手动选节点、手动开关。 换节点、续费、故障提示全都做不了。退款率会很高。

适合：极客向产品、内部测试、验证阶段。

已可开工：0 成本启动包 —— 服务端脚本 + 配置生成器（含二维码）+ 四平台导入步骤，都在里面。

B · 自研 App

$40k–150k

自己写四个平台的客户端，包装 WireGuard 内核。能做一键连接、节点列表、自动选最优、断线重连、故障提示。

代价：iOS / macOS / Android / Windows 四套，加上持续维护和商店审核应对， 实际是一个长期团队，不是一次性项目。

适合：已验证付费需求后的正式产品。

C · 白标 App

按量付费

采购第三方白标客户端，换成你的品牌和节点。

代价：功能受制于人、更新节奏不由你控制，且你仍然要对商店审核和用户数据负责—— 白标不等于责任转移。

适合：快速上线验证，或在自研完成前的过渡。

成本数字是区间估算，需要实际报价：外包与自建团队差异极大，且各平台工作量不同 （iOS + macOS 可复用一部分，Windows 的驱动与安装包是独立一块）。 建议先做单平台（Android 或 Windows）验证，再决定要不要铺满。

三条路径怎么排：先用 A 打底，再走 B

如果你的付费需求还没验证过，不要先做 B。 A 的成本接近零（就是本页路径 A + 0 成本启动包）， 能让你在花 $40k–150k 之前先确认一件事：到底有没有人愿意付钱。 拿到真实付费和退款数据后，再按 iOS + macOS → Android → Windows 的顺序做 B。 C（白标）适合作为过渡，但责任不转移。

03

四个平台逐个拆开

点平台看细节。每张卡的"用户要做什么"就是你客服工单的来源。

04

流媒体最大的盲区：电视

你的用户买流媒体套餐，很可能是在电视上看
而电视恰恰是最难覆盖的终端。这不是小问题——用户会认为"我买了你家的服务却看不了"，然后来退款。
终端能装 VPN App 吗现实做法代价
Apple TV tvOS 17 起才支持 老机型只能走 Smart DNS 或 路由器 VPN 需要额外维护一套 Smart DNS 基础设施，或让用户自己折腾路由器（门槛极高）
Android TV / Google TV 可以 Play Store 上架 TV 版，需适配遥控器与 Leanback 界面 多一套 TV 端 UI，且商店对 TV 应用有独立的质量要求
智能电视（三星 / LG 等） 基本不能 Smart DNS 或路由器 同上
游戏主机（PS / Xbox） 不能 Smart DNS 或路由器 同上
Smart DNS 的真相：它不加密、不改 IP，只把解析请求导向你的服务器，让平台以为用户在目标地区。 好处是电视、游戏机都能用、速度快；坏处是没有隐私保护，且同样会被平台识别并封锁。 它是流媒体的配套方案，不能拿来当"隐私层"卖。
05

上架门槛 —— 两条已经查实的硬要求

这两条是官方文档与公开公告里的真实要求，不是经验之谈。它们会直接影响你的上线排期。

Apple · Network Extension

  • 要在 iOS / macOS 上做自定义协议的隧道，需要 com.apple.developer.networking.networkextension entitlement，常见取值是 packet-tunnel-provider。
  • 上架 App Store 的应用：在 Xcode 里开启 Network Extensions capability 即可。
  • 用 Developer ID 签名、在 Mac App Store 外分发的 macOS 应用：需要先在开发者网站为 App ID 启用该 capability，重新生成并下载 provisioning profile，再手动签名。这一步不能靠 Xcode 自动完成。
  • 另有 com.apple.developer.networking.vpn.api（Personal VPN）用于管理系统 VPN 配置。
  • tvOS 要到 17.0 才支持这套 API——这是上一节电视盲区的根因。

    • Google Play · Verified VPN 徽章

  • Google 于 2025 年 1 月推出面向 VPN 应用的 "Verified" 徽章，出现在应用详情页和搜索结果中。
  • 要拿到徽章，应用须完成 MASA Level 2（移动应用安全评估）验证——即通过一次独立的安全审计。
  • 同时需要：至少 10,000 次安装、至少 250 条评价、上架满 90 天，并满足 target API level 要求。
  • 含义很直接：新应用最少要 3 个月 + 一万安装才有资格被标记可信。在此之前，你在商店里没有任何信任背书。
    • 两个平台共同的隐含要求：完整且可访问的隐私政策、明确的自动续费披露、真实可联系的支持渠道。 VPN 属于高敏感类别，审核对"你到底收集了什么"格外较真。 宣称"无日志"之前，先确定你的法域和架构真的允许你不留日志——见规划台的印度 CERT-In 条目。
    06

    用户上手流程（官网要照这个写）

    这一段可以直接搬进英文官网的 Get started 章节。目标是把每一步都压缩到用户不会放弃的程度。

  • 注册账号 —— 邮箱 + 密码，不要在这一步要手机号或身份证。注册摩擦是流失第一大来源。
  • 选套餐并付款 —— 明确写出价格、续费周期、怎么取消。含糊的续费条款是拒付和差评的主要来源。
  • 下载客户端 —— 自动识别平台给对应下载链接，不要让用户自己判断该下哪个。
  • 登录 —— 支持在客户端内直接登录，不要让用户回网站复制一长串密钥。
  • 一键连接 —— 默认给"最优节点"，而不是甩给用户 39 个国家的列表。选择过载会让人直接关掉。
  • 首次连接授权 —— Android 会弹系统授权框、macOS 会要求批准系统扩展、Windows 需管理员权限。这一步必须在官网和帮助文档里提前说明，否则用户会以为是恶意软件。
    • 第六步是最容易被忽略、也最容易产生差评的一步。系统弹出的权限请求看起来很吓人， 提前告知可以把"这软件要干什么"的疑虑降到最低。
    07

    按你的平台分布排开发顺序

    你给的分布是 iOS 40% / Android 30% / Windows 20% / macOS 10%。 这组数字直接推翻了我上一轮"先做单个平台验证"的建议——下面说清楚为什么。

    坏消息：占比最大的平台，恰好是最难做的那个
    iOS 占 40%，而它同时是四个平台里审核最严、能力受限最多的一个： Network Extension entitlement、无法按应用分流、后台重连要调 On-Demand 规则、 审核周期长且可能被反复打回。你最大的用户群在第一批就要啃最硬的骨头。
    平台用户占比相对工作量
    以 iOS = 100 计    		能与谁复用关键判断
    iOS40%100 → macOS 可复用核心 最大市场，也最难。审核是主要不确定性来源。
    Android30%70 几乎无法复用 VpnService 权限模型最宽松，可按需分流。长期坑是厂商 ROM 的后台杀进程。
    Windows20%60 完全独立 驱动 + 代码签名 + 安装包是独立一块，一行代码都不能复用。
    macOS10%30 ← 复用 iOS 核心 性价比最高的一块：iOS 做完后，增量只有约 30。不要因为只有 10% 就砍掉。
    工作量数字是我的估算，不是你给的：以"iOS = 100"为基准的相对值， 用于比较优先级，不能拿去做预算。真实报价请找 2–3 家外包或按你的团队产能折算。

    覆盖率计算器

    勾选已上线的平台，看你能覆盖多少用户。数字可改—— 占比按你填的值归一化，所以删掉某个平台后，其余平台的占比会自动放大。

    已覆盖用户0%
    未覆盖（无法服务的用户）100%
    累计投入工作量0
    每单位工作量换到的用户—

    三条排期路线

    A · 先啃最大最难

    iOS+macOS → Android → Windows

    第一批 130 单位工作量换 50% 覆盖，且两平台同属 Apple 技术栈， Network Extension 核心与业务逻辑可复用。

    风险：iOS 审核一旦反复打回，你的上线时间完全不可控， 前几个月覆盖率为 0。

    B · 先易后难

    Android → iOS+macOS → Windows

    第一批 70 单位换 30% 覆盖，单平台效率最高（0.43%/单位）， 且 Android 审核宽松、迭代快，能最早拿到真实用户反馈。

    代价：占比最大的 iOS 用户要等到第二批。

    C · 配置文件先打底 建议

    官方客户端 → 再按 A 的顺序自研

    四个平台都有官方 WireGuard 客户端。先用配置文件让 100% 的用户 都能付费，成本接近零。

    拿到真实的付费与解锁数据后，再按 A 的顺序自研。 这样你不会把 $40k–150k 押在还没验证的需求上。

    还有一个会影响排序、但你得自己验证的因素：海外市场 iOS 用户的付费能力通常明显高于 Android。 如果 iOS 的 ARPU 是 Android 的 1.5 倍，那 40% 的用户可能贡献接近一半的收入—— 这会让 iOS 的优先级比单看占比更高。 但这是行业常识不是你的数据，请用自己的实际订阅数据验证后再调整排序。
    对我上一轮建议的修正：我上一轮说"先做单平台（Android 或 Windows）验证"。 那是在不知道平台分布时的建议。知道 iOS 占 40% 后，结论要改： 用路径 C 打底覆盖全部用户，自研顺序走 A（iOS+macOS 优先）—— 因为 iOS+macOS 覆盖 50%，且 macOS 的边际成本只有 iOS 的 30%， 把 macOS 拖到后面单独做是不划算的。
    下一步可以做：把英文官网的 Get started 章节按上面六步写出来； 出一份各平台的客户端开发工作量拆解（Android / iOS / macOS / Windows 分别多少人月）； 或者做一份电视端的 Smart DNS 方案对比。
    ← 回运营规划台 看英文产品官网 iOS 客户端开发拆解
    成本区间为估算，需实际报价核实。Apple 与 Google 的要求来自官方文档与公开公告，政策会变动，提交前请以当期官方页面为准。 本页不构成法律意见。