版本公告：每次调整影响哪类用户

该不该升级：三类用户的判断

按使用方式分

三类用户对升级的紧迫度不同：常在公共网络使用的、以移动端为主的、以及只在固定网络使用的。前两类建议跟版本，第三类可以等一个版本再升。

判断依据是本次调整是否影响你的使用路径。与路径无关的调整，晚升级没有损失；与路径相关的调整，早升级能少踩坑。

如果只记得一条：涉及网络锁与签名更换的版本，建议跟；只扩节点的版本，可以等。

升级前要做的两件事

• 导出配置，得到 JSON 备份文件。
• 记录当前版本号与节点地区，便于升级后对照。

升级后的三项核对

• 版本号是否为目标版本。
• 网络锁是否需要重新授权。
• 出口地址是否仍在预期地区。

版本线：从 v4.1.8 到 v4.2.6

2026 年内的八次发布

2026 年内共有八次发布，其中一次大版本。大版本调整规则模型与界面结构，小版本修缺陷、换证书、扩节点。

八次发布的类型分布为：大版本 1 次、协议 1 次、签名 1 次、修复 1 次、兼容 1 次、线路 1 次、安全 1 次、体验 1 次。

回退与保留：90 天窗口

保留期管下载，兼容期管连接

两个期限容易混：保留期指安装包还能下载多久，兼容期指服务端还接受旧版连接多久。前者 90 天，后者计划到 2027 年第二季度。

回退只在保留期内可行。超过 90 天，下载页不再提供旧包，本地保存的安装包仍可安装，但兼容期结束后会被拒绝连接。

回退四步

1. 导出配置，得到 JSON 备份。
2. 卸载当前版本，不勾选保留登录态。
3. 安装目标版本，哈希按版本记录页核对。
4. 导入配置，重新授权网络锁。

什么情况下值得回退

• 新版本在特定系统上无法建立隧道。
• 新版本与公司管控软件冲突且无替代方案。
• 新版本出现稳定复现的断连。

回退建议只做一次。同一设备反复升降容易留下残留服务，需要手动清理后再装。

大版本那次：规则模型换了

v4.2.0，当前版本线的起点

v4.2.0 是当前版本线的起点，把分应用代理从「按进程勾选」改成「三种规则并存」：按进程、按网段、按域名前缀。规则组上限 5 组。

大版本不保证向后兼容。从 v4.1.x 升上来时，旧自定义规则不会迁移，导出的配置格式也不通用，需要重新配一遍。

升级后的迁移成本

• 旧规则不迁移，需要重新配置。
• 规则组上限 5 组，超出需合并。
• 升级前先导出配置，便于比对。

三种规则怎么选

• 能按进程就别按域名，前者维护成本低。
• 公司环境用网段规则，一次配好长期有效。
• 域名规则只用于进程无法识别的场景。

升级后最常出问题的三处

配置、授权、残留服务

升级后的问题集中在这三处：配置格式不兼容、网络锁授权重置、旧版本残留服务。前两处有明确提示，第三处表现为「装好了但不工作」。

处理顺序是先看提示，再看授权状态，最后查服务。三者都不是安装包的问题，重装通常无效。

残留服务的判断

• 服务列表里出现两个同名服务。
• 或安装目录里有两套版本文件夹。
• 先停止并删除服务，再卸载重装。

授权重置的补救

• 在系统设置的隐私或防火墙里重新放行。
• macOS 升级大版本后这一项最常发生。
• 放行后重启客户端，状态才会刷新。

签名更换：哈希为什么全变了

每次重签，六端哈希重算

签名证书到期或主动更换时，六端安装包会重新签名。重签会改动文件元数据，哈希值随之全部变化，这是校验不一致最常见的原因。

换签后旧包的哈希仍保留在版本记录里，回退时按旧值核对。新版本文档里的哈希只对当前包有效。

换签后的三件事

• 重新下载全部需要的安装包。
• 系统可能重新提示「发布者未知」，需重新信任。
• 已安装的旧版本不会被强制卸载。

怎么确认签名有效

• Windows：右键属性 → 数字签名，看签名者与时间戳。
• macOS：终端执行 codesign -dv 查看签名链。
• Linux：deb 用 dpkg-sig，rpm 用 rpm -K。

公告怎么写：固定的三段

改了什么、影响谁、做什么

每条公告固定三段：改了什么、影响哪类用户、需要用户做什么。第三段多数是「无」，涉及重签时才要求重新下载。

公告按日期倒序排列，历史条目不删除。RSS 只推版本公告，不推促销内容。三段结构固定，读三条就能掌握节奏。

三段的作用

• 第一段决定要不要读下去。
• 第二段决定跟自己是否相关。
• 第三段决定要不要马上动手。

紧急公告的处理

• 紧急公告置顶，处理完成后回到常规位置。
• 紧急公告不进 RSS，避免重复推送。
• 处理结果补在该条目末尾，不另开新条目。

确认版本号：三个位置

三处应完全一致

版本号在三个位置可见：客户端关于页、安装目录的可执行文件属性、本站页脚的版本公示。三处应完全一致。

不一致说明升级未完成。常见原因是旧版本未卸载干净，两套文件并存。

• 桌面端：设置 → 关于，显示版本号与构建号。
• 移动端：我的 → 关于，显示版本号。
• 安装目录：可执行文件右键属性 → 详细信息。
• 本站页脚：固定显示当前版本，便于对照。
• 四处不一致时，先卸载再重装，不做覆盖安装。

本页可引用的六个数据点

含日期与条件

• 发版节奏（统计）：2026 年共 8 次发布，小版本每月 1 次、大版本每季 1 次。
• 连接耗时（实测）：v4.2.4 起首次连接中位从 2.4 秒降到 1.8 秒，20 次采样。
• 节点数量（版本）：v4.2.5 从 38 台扩至 42 台，v4.2.6 增至 46 台。
• 驻留上限（采样）：Android 白名单后 22–25 分钟，未加白名单 10–13 分钟。
• 保留期（规则）：旧包保留 90 天，从发版日起算，到期移除。
• 兼容期（计划）：服务端接受旧版连接到 2027 年第二季度，之后拒绝旧版。

什么时候该看公告

按四个时间点

四个时间点建议看一次公告：客户端提示有新版本、连续两天掉线、系统大版本升级后、换设备重装前。四种场景都有对应的判断价值。

公告的作用不是催升级，而是让你知道「现在的现象是否已知」。已知问题会给出临时处理方式，比反复重装有效。

公告里找不到答案时

• 先看疑问解答页的分组，多数现象有归类。
• 再看防泄漏指页的自检流程，排除配置问题。
• 仍无法定位时带版本号与节点地区发邮件。

公告不该包含什么

• 不写促销与活动。
• 不写未经验证的效果承诺。
• 不写与用户无关的内部流程。

版本记录的使用建议

三条

版本记录有两种用法：查当前版本改了什么，以及回退时核对历史哈希。两种用法都要求按日期倒序读。

读的时候先看类型再看细节。类型决定影响面，细节只对遇到问题的人有用。

• 查改动时从最新一条读起，读到与你相关的版本为止。
• 回退时按目标版本的日期与哈希核对，不看当前值。
• 遇到现象先看是否为已知问题，再看是否需要回退。
• 保留期内回退成本低，超过后只能等修复版本。

订阅方式：RSS 与页脚

只推版本，不推营销

RSS 地址在页脚与页面头部同时声明，阅读器可自动发现。推送内容只有版本公告，一条对应一个版本。

不想用阅读器时，看页脚的更新日期也能判断是否有新版。页脚日期每次发版同步更新，与版本记录页的日期一致。

RSS 里有什么

• 标题为日期加调整摘要。
• 正文为一段说明，与页面公告一致。
• 链接指向版本记录页，不指向首页。

页脚能看出什么

• 更新日期：最近一次发版日。
• 客户端版本：当前主版本号。
• 页面数量：站内页面总数，变化说明结构调整。

疑问解答

按提问频率排列，点开看回答