Clash·引擎 获取客户端
全版本更新日志 · 历史记录 · 迭代脉络清晰可查

每一次改动都留痕,
每一个版本都可追溯

从早期内核迭代到当前客户端功能演进,这一页按时间倒序收录每一个发布版本的完整记录。 变更清单、优化方向、修复条目与发布说明逐项列出,重要更新标注影响范围与推荐理由, 旧版留存下载入口。想追溯问题从哪一版开始、核对某个特性何时上线、评估跨期升级路径, 都可以在这里找到依据。

时间倒序变更分类影响范围 旧版入口稳定分支版本对照
v0.20.6 当前稳定版本,推荐日常使用
50+ 已收录的历史版本记录
3 维护分支:稳定 / 开发 / 归档
4 覆盖平台:Win / Mac / Android / iOS
Version Log

按发布时间倒序排列

每个版本条目内按变更类型分组。可用下方筛选快速定位你关心的类型。

筛选
v0.20.6 2026-09-24
推荐升级 稳定分支

本次为季度性整合更新。合并了此前开发分支中验证稳定的规则匹配优化与策略组调度改进, 并补齐了四个平台在配置热重载上的一致性。建议所有用户升级。

新增
  • 规则匹配引擎支持预编译缓存,同一配置二次载入耗时显著缩短
  • 策略组新增 url-test懒测速选项,空闲时不主动发起测速
  • 外部控制接口补充 /proxies 的延迟字段,便于面板展示
  • iOS 端支持按需连接的细粒度触发条件配置
优化
  • 规则列表在数千条规模下的匹配开销进一步下降
  • 订阅更新时的合并逻辑更保守,减少本地自定义条目被覆盖的情况
  • 桌面端托盘的策略组切换操作响应更快
  • 日志输出在高频请求下不再阻塞主流程
修复
  • 修复部分场景下 no-resolve 参数未生效导致的额外反查
  • 修复 macOS 端长时间运行后菜单栏图标偶发不响应
  • 修复 Android 端在 Wi-Fi 与移动网络切换瞬间规则判定短暂中断
  • 修复配置热重载时个别策略组状态未同步刷新的问题
调整
  • 默认 log-levelwarning 调整为 info,方便初次排查
  • 移动端权限提示文案更新,更明确说明 VPN 服务的用途
影响范围 全平台 规则引擎 策略组 配置热重载
v0.20.4 2026-08-03
安全修复 稳定分支

以安全与稳定性为主的维护版本。不引入新特性,重点处理外部控制接口的访问边界与订阅解析的异常输入。

修复
  • 修复外部控制接口在特定配置下可能被同网段设备未授权访问
  • 修复订阅解析遇到畸形 YAML 时的异常退出
  • 修复规则集中超长域名导致的匹配性能抖动
  • 修复桌面端系统代理开关在休眠唤醒后状态不一致
调整
  • external-controller 默认仅监听本地回环地址,如需局域网访问需显式配置
  • 订阅拉取增加超时与重试上限,避免长时间等待
影响范围 全平台 外部控制接口 订阅解析
v0.20.0 2026-06-18
推荐升级 稳定分支

一次结构性版本更新。规则语法扩展、策略组类型补充、配置结构向后兼容, 老配置文件无需改动即可继续使用,但新增能力需要按新写法启用。

新增
  • 规则类型新增 PROCESS-NAME多进程匹配写法
  • 策略组新增 load-balance 的轮询与一致性哈希两种模式
  • 配置支持 rule-providers 的本地文件与远程地址混用
  • 新增配置校验命令,保存前可先检查结构完整性
优化
  • 规则引擎对域名后缀与关键字的匹配做索引优化,大规则集下响应更快
  • 策略组测速结果缓存时间可配置,减少不必要的重复测速
  • 移动端后台保活策略调整,长时间驻留更稳定
修复
  • 修复嵌套策略组在多层引用下的选择状态不同步
  • 修复部分订阅格式在节点名称含特殊字符时解析失败
  • 修复配置文件过大时导入界面卡顿
影响范围 规则语法 策略组 配置结构 全平台
v0.19.2 2026-04-25
稳定分支

维护性更新。以修复已知问题与小幅体验改进为主,不涉及配置结构变化。

修复
  • 修复部分 Windows 版本下托盘图标在缩放变化后显示异常
  • 修复策略组名称含中文时外部控制接口返回乱码
  • 修复配置重载后连接记录未清空导致的误读
优化
  • 启动阶段配置载入顺序调整,减少首屏等待
  • 日志文件滚动策略调整,长时间运行不会无限增长
影响范围 桌面端 外部控制接口
v0.19.0 2026-02-09
推荐升级

同步与备份能力的一次集中补强。为多端使用场景提供了更完整的配置流转支持。

新增
  • 配置导出支持仅导出本地自定义条目,便于与订阅基线分离
  • 新增局域网直传功能,同一网络下设备之间可快速递送配置
  • 配置版本记录功能上线,可回看最近若干次改动
优化
  • 配置导入界面重新组织,订阅与本地文件两条路径区分更清晰
  • 导入大配置时的进度提示更准确
修复
  • 修复移动端导入本地文件时路径解析错误
  • 修复部分场景下配置导出内容不完整
影响范围 全平台 配置管理 同步备份
v0.18.5 2025-12-14
归档分支

0.18 系列最后一个维护版本。该系列已进入归档,不再接收新功能, 仅保留下载入口供特殊场景回退对照使用。

修复
  • 修复配置文件包含大量注释时解析耗时偏长
  • 修复个别协议在特定端口下的连接建立失败
影响范围 归档分支 不再更新
i

更早版本按时间归档。0.17 及更早的记录以同样的结构保留在归档中, 包含完整的变更清单与下载入口。如需查询,可按版本号或日期检索。

Version Map

版本号与功能对应关系

长期维护的对照表,用于核对某个特性从哪一版开始可用,以及各分支当前的维护状态。

版本发布日期关键变化状态
v0.20.6 2026-09-24 预编译缓存、懒测速、跨平台热重载一致性 当前稳定
v0.20.4 2026-08-03 外部控制接口访问边界收紧 维护中
v0.20.0 2026-06-18 规则语法扩展、负载均衡策略组 维护中
v0.19.2 2026-04-25 桌面端显示与日志滚动修复 维护中
v0.19.0 2026-02-09 配置分离导出、局域网直传、版本记录 维护中
v0.18.5 2025-12-14 0.18 系列收尾维护 已归档
v0.18.0 2025-10-20 移动端权限与后台策略调整 已归档
v0.17.x 2025-08 及以前 规则匹配基础能力完善 已归档
Evolution

项目成长轨迹,几个关键节点

从规则引擎的成型到多端能力的补齐,迭代脉络可以按阶段来理解。

2024 — 2025

内核打磨与规则引擎成型

这一阶段的重点是把规则匹配做稳、做快。域名、IP、端口、进程几个判断维度逐步补齐, 规则集的引用方式也在这段时间定型。配置结构在此期间经历了几次调整, 最终形成现在这份以 proxiesproxy-groupsrules 为主干的形态。

2025 下半年

多平台覆盖与体验统一

Windows、macOS、Android、iOS 四个平台的操作逻辑趋于一致, 同一份配置在各端读取后行为相同。移动端的权限模型与后台策略在这一阶段稳定下来, 桌面端的托盘与菜单栏交互也形成了各自平台的习惯做法。

2026 上半年

配置管理与同步能力补强

v0.19.0 引入配置分离导出与局域网直传,v0.20.0 扩展规则语法与策略组类型。 这一阶段的迭代方向从「能用」转向「好维护」——让配置在多端之间流转更顺畅, 让规则在长期使用中更容易保持清晰。

2026 下半年至今

性能与稳定性的持续收敛

预编译缓存、匹配索引优化、热重载一致性——最近的版本不再追求功能数量, 而是把已有能力做扎实。规则规模增长时响应依旧从容,配置改动时服务不中断, 这些细节构成了当前版本的稳定基础。

迭代脉络不是线性堆叠,而是有方向的收敛。从补齐维度,到统一体验,再到优化维护成本, 每一阶段的重点都在解决当时最突出的问题。回看这些节点,也更容易判断当前版本处在哪个位置上。
Upgrade Guide

什么时候该升级,什么时候可以等

升级不是越新越好,也不是越稳越好。判断依据应该来自你的实际使用场景。

建议尽快升级的情况

版本标注了安全修复,或变更清单里包含你正在使用的功能相关修复。 这类更新通常解决的是实际遇到的问题,延迟升级只会让问题继续存在。

可以按节奏升级的情况

版本以体验优化与小幅改进为主,没有涉及你当前依赖的功能结构。 可以等一两个维护版本之后再升,观察社区反馈后再决定。

建议暂缓的情况

版本包含配置结构变化,而你当前的配置经过长期调整、结构复杂。 建议先导出备份,在另一台设备或便携版上验证新版本兼容性,再决定是否全面升级。

i

升级前先导出配置。这是成本最低、收益最高的习惯。配置是纯文本,导出只需一步, 但万一遇到兼容性问题,能让你快速回到可用状态。升级后如果发现异常, 对照更新日志中本次版本的变更条目,通常能快速定位到原因。

How to Trace

三个常见的追溯场景

更新日志的价值不只在于「看新版本改了什么」,也在于回看问题时提供依据。

追溯问题从哪一版开始

回想问题出现的大致时间,在对应时间段内的版本里查找相关功能的变更条目。 如果是某次改动引入的行为变化,通常在「调整」或「修复」分组里能找到线索。

核对某个特性何时上线

用版本对照表定位包含该特性的最早版本,再到对应的版本条目里看它的具体说明。 这样能确认该特性是否在你当前使用的版本中可用。

评估跨期升级路径

如果当前版本较旧,可以按顺序阅读中间的每个重要版本条目, 了解配置结构是否发生变化、是否有需要手动调整的地方,再决定升级节奏。

对照稳定分支与开发分支

稳定分支只收录经过验证的修复与小改进;开发分支包含新特性与结构性调整。 如果只是日常使用,跟随稳定分支即可;如果想尝鲜,可以关注开发分支的变更清单。

可追溯的更新记录,本身就是一种维护能力。它让你在遇到问题时不必猜测, 在决定升级时不必犹豫,在回退旧版本时也有据可依。
Archive

关于旧版与归档分支

旧版本保留的意义是「可回退」,而不是「长期依赖」。下面几点需要说清楚。

下载入口保留

主要历史版本提供下载入口,供特殊场景回退对照使用。 如果某个旧版本上运行着特定环境验证过的配置,保留一份副本是稳妥做法。

不再接收更新

归档分支不再接收安全更新与问题修复。长期使用旧版本意味着已知问题会一直存在, 新发现的问题也不会在旧分支上处理。

配置兼容性提示

跨大版本回退时,新配置中的某些字段可能在旧版本中不被识别。 回退前建议先确认配置结构与目标版本兼容,或准备一份对应的旧配置备份。

Q & A

关于版本与更新,常被问到的几件事

更新日志按什么顺序排列?

按发布时间倒序排列,最新版本在最上方。每个版本条目内部再按变更类型分组:新增、优化、修复、调整,方便快速定位你关心的那类改动。

如何判断某个版本是否值得升级?

看三个信息:变更类型是否涉及你正在使用的功能、是否标注了影响范围、是否属于安全或稳定性修复。标注「推荐升级」的版本通常包含重要修复或广泛影响的改进。

旧版本还能下载吗?

主要历史版本保留下载入口,便于特殊场景回退对照。但旧版本不再接收安全更新与问题修复,长期使用建议跟随当前稳定分支。

怎么追溯某个问题的起始版本?

可以用页面上的筛选或搜索,定位与问题相关的功能首次出现或最后一次正常工作的版本。变更清单中的「修复」条目也常能直接指出问题从哪一版开始被处理。

稳定分支和开发分支有什么区别?

稳定分支只收录经过验证的修复与小改进,适合日常使用;开发分支包含新特性与结构性调整,变化较快,适合愿意跟进尝鲜并接受偶发问题的用户。

更新日志会一直保留吗?

会。历史记录按时间归档,不会因为发布新版本而删除旧条目。早期内核迭代到当前客户端演进的完整脉络,都可以在这一页上追溯。

每一次改动都留在记录里

升级有依据,回退有入口,追溯有脉络。想找的版本记录,都在这一页上。