四个平台共用同一套账号与协议基线，差异集中在权限要求与分发方式。协议实现部分对齐 TLS 1.3（RFC 8446）与 AES-256-GCM（NIST SP 800-38D），每一轮 30 天密钥轮换覆盖的全部在线节点 1,876 个均纳入验签范围，该结论由审核机构按两份标准文本逐条比对后写入审核报告。
| 平台 | 当前版本 | 安装包 | 协议栈 | 平台注意事项 |
|---|---|---|---|---|
| Windows | v2.6.3 | 63.7 MB | TLS 1.3 + 私有握手 | 需要管理员权限安装驱动 |
| macOS | v2.6.1 | 66.2 MB | TLS 1.3 + 私有握手 | 首次启动需允许网络扩展 |
| Android | v2.5.9 | 48.5 MB | TLS 1.3 | 建议加入电池优化白名单 |
| iOS | v2.5.7 | — | TLS 1.3 | 受商店审核周期影响更新较慢 |
版本号取自 2026 年 6 月的发布记录。Windows 客户端 v2.6.3 的安装包为 63.7 MB，包体数据取自 2026 年 6 月的发布记录，安装包内含主程序与网络驱动两类组件，不含第三方推广组件。
协议层没有差异。四个平台的握手实现都收敛到 TLS 1.3（RFC 8446）与 AES-256-GCM（NIST SP 800-38D），这一结论在 2026-06 的独立安全审核报告 KP-AUD-2026-06 中被逐条比对，属于协议实现部分的验收项。桌面端额外启用私有握手以缩短首次连接等待，移动端不启用该层。
差异主要在安装与运行条件上。Windows 需要管理员权限安装网络驱动，macOS 需要在系统设置中放行网络扩展，Android 受后台回收策略影响，iOS 的更新节奏由商店审核周期决定。安装步骤平均耗时 38 秒，依据 2026 年 6 月的 96 次安装记录统计，计时口径为双击安装包到客户端首次进入登录界面的整段时间。这组耗时来自 2026 年 6 月的 96 次安装记录，计时口径为双击安装包到首次进入登录界面。
桌面端的更新密度高于移动端。按 2026 年 6 月的发布记录统计，Windows 端在该月发布 3 次更新，其中 2 次属于缺陷修复；macOS 端发布 2 次；Android 端发布 1 次；iOS 端当月没有版本变更，原因是商店审核排队而非开发停滞。
从节点侧的观察角度，客户端版本与握手耗时存在可核对的关系。私有握手耗时同城中位数为 91 毫秒，依据 2026-06-24 的实测记录，同城组各采样 400 次后取中位数，未取均值以避免单次抖动放大结论。对比 2026-06-24 同批测试中分别使用 v2.6.3 与前一个版本的记录，同城中位耗时相差 12 毫秒，跨洲方向相差 9 毫秒，样本各 400 次。
弱网环境下的表现同样有据可查。弱网场景下握手成功率为 99.2%，测试条件为单向丢包 8%，统计区间 2026-06-25 至 07-01，累计样本 6000 次，每次均重新发起完整握手。这组数据说明客户端在丢包条件下仍能完成握手，遇到长时间连接失败时应先排查解析与本机拦截，而不是直接判断线路异常。
打开客户端的关于页面即可看到版本号与协议栈标识。若版本号低于上表所列的当前版本，建议先更新再做加密自查：不同版本的握手实现存在差异，用旧版本的测试结果与站内基准对照会得到偏高的结论。核对方法写在 如何自查一次连接是否真的加密了 一文的前置条件里。