OpenWrt 25.12 正式版放出快三个月了, 期间已经迭代到 25.12.4(2026-05-14)。release notes 写得克制, 实质变化不少: opkg 换 apk, 内核 6.6 升 6.12, Attended Sysupgrade 默认装上, Wi-Fi 脚本用 ucode 重写, 2200+ 设备支持(新增 180+)。
但我手头那台跑了一年多的 OpenWrt 24.10 旁路由, 我没动它。
这版本到底变了啥
从 24.10 跳到 25.12, 中间隔了 4700+ commits, 一年多的开发, 名字叫 “Dave’s Guitar”, 纪念 Dave Täht(bufferbloat/SQM 的关键推动者)。
1. 包管理器从 opkg 换成 apk
这是个大事。我那台旁路由上跑的代理插件等几个第三方包, 它们都基于 opkg。25.12 切 apk 之后, 这些包的兼容性得一个个确认, 短期内大概率能用, 但万一某个包不维护了, 就得自己 fork 改包名。opkg 那个 fork 早就不维护了, apk 是 Alpine 那边的, 还在持续更新。命令参数不同, 官方有 cheatsheet, 但所有第三方教程、CI 脚本、容器里的命令都得跟着改。短期成本不低。
2. 内核从 6.6 升到 6.12
Wi-Fi 驱动从 6.18 backport 过来, 性能会好一点。但对一台做旁路代理的机器来说, Wi-Fi 性能不是核心, 倒是不影响我。
3. Attended Sysupgrade 默认装进 LuCI
这个我喜欢。以前升级 OpenWrt, 装一堆 kmod-* 之后, 跨大版本升级时手工把 50 多个包记下来、装回去, 烦得很。现在 LuCI 里点几下, 它会基于你当前装的包在线重新构建一个镜像, 直接刷。这个流程放进默认安装, 等于把升级门槛砍掉一大截。命令行工具 owut 也内置了, 适合 ssh 党。
4. Wi-Fi 脚本从 shell 换 ucode
shell 脚本换 ucode, 跑得更快, 跟 ubus/UCI 集成更好。理论上我管不到——旁路由不负责 Wi-Fi, 主路由是硬路由, 这部分对我是黑盒。
5. 新设备支持翻一番
官方 25.12 支持 2200+ 设备, 比 24.10 新增 180+, 包括 10G 交换机 SoC(realtek target)、ipq50xx/ipq60xx、新加的 siflower、microchipsw/lan969x target。硬路由玩家或 ARM 单板玩家挑机器空间大了不少。
6. Shell 历史记录存 RAM
24.10 之前, shell history 每次重启就没了, 一堆人(包括我)写脚本存到 flash 里, 写多了伤 flash。现在直接 RAM-backed, 想持久化就改 /etc/profile.d/busybox-history-file.sh。小细节, 但能省事。
24.10 还能再蹲多久
25.12 转正后, 24.10 立刻进入 security-only maintenance 模式。24.10.7 是当前最后一个, 之后到 9 月 5 日 EOL 之前可能还有一两个小修订。算下来, 24.10 还有大概 4 个安全更新窗口, 然后就停止维护了。
这意味着: 24.10.7 之后的洞不会再被官方修。你能做的只有两件事: 要么尽早升 25.12, 要么不接不可信网络。我那台旁路由只在内网跑, 跑一年多没出过事, 6 月底到 9 月初之间安排升上去, 时间窗口够用。
顺便说一句, 25.12.4 修了几个 dnsmasq 的 CVE, 包括 CVE-2026-2291 (DNS 域名处理堆缓冲区溢出), CVE-2026-4890/4891 (DNSSEC NSEC 崩溃)。24.10 上 24.10.7 也 backport 了这些, 所以短期内安全风险不算大。
我为啥先不动
我的情况可能和很多人不一样: 主路由是硬路由, OpenWrt 跑在旁路由上, 主要职责是代理出网和 DNS 分流。这种角色下, 升级 OpenWrt 的边际收益很低, 边际成本却不小。
几个具体原因:
1. apk 替换成本
我用 OpenWrt 上跑的代理插件等几个第三方包, 它们都基于 opkg。25.12 切 apk 之后, 这些包的兼容性得一个个确认, 短期内大概率能用, 但万一某个包不维护了, 就得自己 fork 改包名。
2. 脚本改造
旁路由上跑的几个自写脚本(cron 任务、流量监控、API 调用)都用 opkg 命令, 升级后这些脚本全部要改。一行行 sed 替换, 出问题就麻烦了。
3. 24.10.7 还很稳
24.10.6/24.10.7 修了几个安全洞, 性能稳定, Wi-Fi 也没问题(虽然跟我无关)。我那台跑了 14 个月, uptime 都在 90 天以上, 没有非升不可的理由。
4. 25.12 还有几个已知坑
比如 Pixel 10 手机连不上 WPA3 Wi-Fi 6 AP、802.11r FT 在 WPA3 下问题、SQM CAKE MQ 性能可能下降。这些都跟我主路由的硬路由没直接关系, 但既然还有坑, 不急。
所以我的计划是: 7 月底到 8 月初, 在另一台备用路由器上刷 25.12.4, 把脚本和 opkg→apk 改造跑一遍, 没问题; 9 月初(24.10 EOL 前 1 个月)再把主力旁路由升上去。中间留一个月 buffer 应急。
几个升级建议
如果你也在用 OpenWrt, 我的建议分几种情况:
主路由跑 OpenWrt(主路由就是软路由): 别拖, 24.10 EOL 是 9 月 5 日。Attended Sysupgrade 现在是默认装好的, 在 LuCI 里直接操作, 把当前包列表保留下来就行, 跨大版本升级的复杂度比之前小多了。
旁路由跑 OpenWrt, 没自编译脚本: 也可以直接升, Attended Sysupgrade 救你一命。建议先在备用机或虚拟机上 dry-run 一次, 确认 opkg→apk 的兼容性没问题再上主力。
旁路由跑 OpenWrt, 有自编译脚本或自己 fork 的包: 先把脚本里的 opkg 命令 grep 出来, 算下工作量。我自己那台大概 20 多个调用点, 改起来要一两个小时, 这种不建议直接跳, 留出 buffer 慢慢来。
用其他 fork 固件的玩家: 25.12 出来后, 主流 fork 跟进需要时间, 等 fork 仓库出 25.12 based 镜像再动也不迟——fork 的核心价值就是稳定 + 兼容性, 急升反而违背初衷。
升级时的几个小坑
如果你决定升 25.12, 几个 release notes 里标红的地方注意下:
- Bananapi BPI-R4: eth1 改名为 sfp-lan/lan4, eth2 改名为 sfp-wan, 升级时不保存配置, 否则网络会断。
- 几款老路由(RE355 v1 / RE450 v1 v2 等): 分区布局变了, 从 25.12.0 之前升要加
-F强制, 镜像不能超 5.875 MB。 - Meraki MX60: 直接升不到 25.12.4, 要先改
meraki_loadaddr。 - Zyxel EX5601-T0: WAN 改名为 wan, 自己改网络配置。
Attended Sysupgrade 会自动适配大多数设备, 但碰到上面这些特例, 还是建议看一眼自己设备的 wiki。
Pixel 10 + WPA3 那个坑也留意下, 家里有 Pixel 10 又跑 WPA3 的朋友, 升级前先看下 issue #21486 的进展。
最后
25.12 转正, OpenWrt 这个项目在 IoT/软路由这一块的地位还是稳的。一年发一个大版本、4 个月一个 service release 的节奏也没变。我这种 24.10 蹲半年的玩法, 不适合所有玩家, 但对稳定性要求高、变动需求低的人, 是最低风险的选择。
9 月 5 日之前, 24.10 用户总归要动一次。早动晚动, 看你的 buffer 厚度。