第 2 节 · 平台与安装条件
五个平台，各自的体积与权限要求不同
安装包按平台分别构建，不做跨平台通用包。桌面端只申请本地网络访问权限，移动端使用系统级网络扩展授权，不申请通讯录、相册与位置权限。
| 平台 | 安装包体积 | 最低系统版本 | 授权项 |
|---|---|---|---|
| Windows 桌面端 | 18.4 MB | Windows 10 及以上 | 本地网络访问 |
| macOS 桌面端 | 16.8 MB | macOS 12 及以上 | 网络扩展授权 |
| Android 移动端 | 22.6 MB | Android 9 及以上 | 系统网络服务授权 |
| iOS 移动端 | 31.2 MB | iOS 15 及以上 | 系统网络配置授权 |
| Linux 桌面端 | 15.9 MB | 内核 5.4 及以上发行版 | 本机网络接口读写 |
第 3 节 · 开通四步
从申请到连通，四步都有可量化的通过条件
开通不涉及改动现网结构，客户端以旁路方式部署在网关侧或终端本地。每一步不达标就停在该步，不做跳步，避免把问题带到灰度阶段。
1
提交申请
填写团队规模、并发峰值、常用目的地与出口归属地，1 个工作日内返回档位建议与配置清单。
2
额度确认
按人均 4~6 Mbps 折算带宽并预留 30% 峰值余量，确认 C 档或 B 档的并发数是否够用，出口按 2~3 跳配置。
3
配置下发
配置包约 6 KB，包含线路清单与凭证指纹，客户端导入后实测生效耗时 12 秒。
4
连通校验
连续 30 分钟健康检查，12 条路径全部有回报才判定开通完成，探测颗粒度 3 秒一条。
申请材料只需三项：团队人数、同时在线峰值、常用目的地城市。出口归属地按目的地就近匹配，匹配规则与跳数配置见四层链路页。
第 4 节 · 首次连通自检
六条自检项，逐条对照再进入灰度
开通当天最常见的失败不是线路问题，而是本地拦截与权限未授予。下面六条按排查顺序排列，前三条能在 5 分钟内定位八成问题。
- 客户端版本与配置包版本一致，版本号不一致时配置不生效，错误记录写在本地日志第 1 行。
- 12 条路径探测全部有回报，缺失 1 条以上说明本地出口拦截了 32 字节探测包。
- 首包握手耗时落在 180~260 ms 区间，超过 320 ms 时先查本地协议栈参数是否被旧策略覆盖。
- 中位往返时延低于 130 ms；若仍停留在 168 ms 附近，说明流量没有进中继，仍然走固定出口。
- 丢包率低于 0.4%，高于 1.2% 时优先排查本地无线链路与网关队列，而不是直接判定线路异常。
- 配置包校验和与下发值一致（SHA-256 前 8 位），不一致时重新下载配置包，不做手工字段修改。
六条全部通过后，进入 10% 流量的灰度观察，观察窗口 24 小时，指标定义与判停条件与智能选路页的切换阈值一致。
第 5 节 · 配置包与校验和
一个纯文本文件，两层校验，三段可回滚
配置包不承担任何逻辑，只描述字段：线路清单、凭证指纹、跳数上限与出口归属。把它做成纯文本的好处是可核对、可对比、可回滚。
配置包是结构化纯文本，体积约 6 KB，包含线路清单、凭证指纹与跳数上限三个区块。导入时客户端只读取字段值并写入本地配置目录，不执行文件内的任何内容，因此即使包被篡改也不会触发执行行为。
- 版本号形如 2026-10-17.3，随数据集每周更新 1 次，跨 2 个大版本后旧包不再兼容。
- 传输层核对 SHA-256 前 8 位，人工核对耗时约 20 秒；应用层核对账号归属与并发额度。
- 导入后旧配置保留 7 天，回滚只需选中上一版本，实测回滚耗时 9 秒。
- 配置包与客户端安装包分开发放，任一方更新都不要求另一方同步升级。
两层校验都通过才写入本地；任一层不通过则保留旧配置运行并记录日志，不会进入无配置状态。这个设计在 2026-09 至 10 月的 46 次开通记录里，把配置类故障压到 0 次。
第 6 节 · 开通受阻原因
四类常见受阻，四组可核对的判据
受阻原因基本集中在额度、探测、权限与时钟四处。每一类都有明确的判据，不需要反复试错。
- 并发额度不匹配：人均常驻会话 2~3 条时，20 人团队容易冲到 60 条以上，A 档 50 条并发会在 19:00 之后出现排队。
- 本地出口拦截探测：部分企业网关丢弃 32 字节小包，表现为路径数为 0，探测记录里 12 条全部无回报。
- 授权未确认：移动端网络扩展授权未确认时客户端能启动，但无法接管流量，日志会记录 1 行授权失败。
- 本地时钟漂移：与标准时间偏差超过 300 秒时凭证校验失败，校准后重试即可，不需要重新开通。
四类之外的情况，把本地日志与探测记录一并发到 [email protected]，我们按同一套口径复算后给出结论。
第 7 节 · 升级与回滚
滚动升级、三个历史版本、24 小时判停
升级的目标不是拿到新功能，而是让配置与数据集保持同频。因此节奏固定在两周一个版本，灰度先切 10% 终端。
桌面端两周一个版本，移动端跟随系统商店节奏。版本号跨 2 个大版本后旧配置包不再兼容，这是唯一需要同步升级的情形，其余情况客户端与配置包可以独立更新。
回滚保留 3 个历史版本，实测回滚耗时 9 秒。升级过程中若新版本启动失败，客户端自动回到旧版本运行，不会进入无配置状态，也不影响已建立的会话。
灰度策略：先推 10% 终端，观察 24 小时内的路径切换次数与握手耗时；切换次数超过基线 2 倍或握手耗时中位数上浮 20% 即停止推送，等下一版本修复。历史数据表明，被判停的版本占全部推送的 1 个比例，实际影响窗口在 30 分钟以内。