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-level 由 warning 调整为 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、端口、进程几个判断维度逐步补齐, 规则集的引用方式也在这段时间定型。配置结构在此期间经历了几次调整, 最终形成现在这份以 proxies、proxy-groups、rules 为主干的形态。

2025 下半年

多平台覆盖与体验统一

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

2026 上半年

配置管理与同步能力补强

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

2026 下半年至今

性能与稳定性的持续收敛

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

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

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

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

①

建议尽快升级的情况

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

②

可以按节奏升级的情况

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

③

建议暂缓的情况

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

i

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

How to Trace

三个常见的追溯场景

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

◫

追溯问题从哪一版开始

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

◧

核对某个特性何时上线

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

◨

评估跨期升级路径

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

◩

对照稳定分支与开发分支

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

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

关于旧版与归档分支

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

◐

下载入口保留

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

◑

不再接收更新

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

◒

配置兼容性提示

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

Q & A

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

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

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

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

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

旧版本还能下载吗?

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

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

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

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

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

更新日志会一直保留吗?

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

每一次改动都留在记录里

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