Repository navigation
fix(clash-rs): 核心升到 v0.20.23-alpha，BUILD-INFO 记全代理开关 - #49
Merged
Merged
Conversation
一、核心钉住值 v0.20.10-alpha -> v0.20.23-alpha
feed 在 2026-10-20～10-22 前进了 9 个 commit，其中 67ffca956 把 clash-rs 包从
nikki-rs/files/ 挪到仓库根，并让它的 CI 在构建时追最新 release
（scripts/packaging/update-clash-rs.sh 现算每个架构的哈希）。也就是说 feed 的
Makefile 里那份哈希随时会被它的 CI 改写：跟着它走，同一个 feed 提交在不同日子会
构建出不同核心。显式钉住因此比以前更必要，而原来的钉住值已经落后 13 个 release。
升级前核了两件事，都不是推断：
* 字段面：v0.20.10 -> v0.20.23，EbpfConfig / EbpfLanConfig / EbpfHostConfig /
EbpfTargetConfig / Dns2Config / Dns2UpstreamDef 六个结构体逐字段比对，字段数与
名字完全一致。feed 现在写的 19 个 ebpf 键与 9 个 dns2 键两版核心都认（dns2
upstreams 里的 type 是 pub r#type + #[serde(rename = "type")]，不是未知字段）。
* eBPF 功能：v0.20.23 的发布矩阵给每个 Linux 目标都是
extra-features: "jemallocator,ebpf"，另外单独有一个 build-ebpf 作业编字节码。
这一条必须查 —— def.rs 里的 ebpf 结构体不受 feature gate 控制，所以
--strict-config 能解析并不能证明功能真的编进去了。
顺带修掉一处会让例行升级变红的地方：checks.yml 原来断言字面量
want_v="0.20.10_alpha"，而它自己的注释正写着"bumping this is fine"。改成断言
"want_v 与 want_url 指向同一版本、且不低于 0.20.10（第一个认识 proxy-src-macs 的
release）"。三种情形都跑过：当前版本通过、降到 0.20.9 报错、版本与 URL 不一致报错。
二、BUILD-INFO.txt 补上六个开关
10-19 那个周更镜像只记了 fancontrol / netmode / wwand / mt5700m / upnp / adblock /
dockerman，而它实际启用了 mosdns、并且 ENABLE_EBPF_PROXY_KERNEL=true。也就是说从
产物本身看不出一个固件带的是哪套代理前端，排查"这台机器为什么没有某个页面"时第一步
得去翻 70 万行的构建日志。
补上 enable_nikki / enable_openclash / enable_mosdns / enable_homeproxy /
enable_adguardhome / enable_ebpf_proxy_kernel 六个键。六个变量在 local-build.sh 里
都有默认值，set -u 下引用是安全的。
本地门禁对着新版本重跑：本仓库钉住 v0.20.23-alpha，五个架构哈希与 release 的
digest 逐条一致；Nikki-RS 四处锚点 4/4 仍在（含挪到仓库根之后的 clash-rs/Makefile）。
existyay
force-pushed
the
fix/clash-rs-v0.20.23
branch
from
October 24, 2026 13:53
261f3a7 to
fad37e4
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
三个问题的答案，以及据此做的两处改动
检查的结论先说：补丁栈没有漂移，nikki-rs 没有字段缺口，固件没有告警级缺陷；真正该动的只有一处版本滞后和一处记录缺失，都在这个 PR 里。
1. 固件当前缺陷面（最新镜像是 2026-10-19 那次定时构建）
openwrt-5b8554a95eee055c5bee96f6f2dfd3beb241e0e7，kernel 6.18.55，6 个资产齐全。逐项查过：##[warning]= 0，##[error]= 0（全 8791 行日志）0 script warning(s), 0 arithmetic error(s), 0 of this project's Makefiles, 4 upstream feed Makefiles+No warnings about packages this project builds.5b8554a9；今天 main 是b5bc4becb4（10-24），即约 5 天的上游改动尚未进镜像 —— 周更节奏的正常状态，下一次定时构建是 10-26 04:00 UTC唯一的真缺陷是产物记录不全：BUILD-INFO.txt 没记
enable_nikki / enable_openclash / enable_mosdns / enable_homeproxy / enable_adguardhome / enable_ebpf_proxy_kernel。这个镜像实际是mosdns=true、ebpf_proxy_kernel=true，但产物里只字未提，排查时只能去翻 70 万行日志。已补（第二个 commit）。2. 上游是否还有更新：有，但都不需要"合并"
openwrt/openwrtmain：b5bc4becb4（10-24）。我们打补丁的四个包自基线以来没有新提交 —— nftables 仍是 1.1.7、libnftnl 仍是 1.3.2、firewall4/mt76 的PKG_SOURCE_VERSION未变。b5bc4becb424b4d89f48e372675811821aa155bd）：nftables/libnftnl 两个补丁 OK、顶层patches/0001+0002OK、Nikki-RS 四处锚点 4/4 OK、clash-rs 五个资产哈希 5/5 OK。firewall4/mt76 那两项只是 Windows 建不了符号链接的环境限制（退出码 2），Linux CI 上一直是绿的。CHKayanami/clash-rs：从 v0.20.10-alpha 发到 v0.20.23-alpha（10-22），中间 13 个 release。这是唯一需要动作的"上游更新"。3. nikki-rs 是否需要修补：不需要改 feed 侧，但核心钉住值要升
feed 的 main 在 10-20～10-22 动了 9 个 commit，其中三个与我们相关：
67ffca956clash-rs/挪到仓库根 + CI 构建时现算哈希）clash-rs/Makefile取，4/4 通过。但钉住的必要性反而更强了 —— 跟着 feed 走，同一份提交在不同日子会构建出不同核心a7be43ab1mixin.uc现在写 9 个dns2.*键Dns2Config/Dns2UpstreamDef两版核心都认这 9 个键（含inet4-range/inet6-range）05ac84130/4e9a36c10所以：feed 侧不用打补丁（打补丁还得跟着它每次提交重新同步）；核心侧的钉住值升到 v0.20.23-alpha（第一个 commit）。升级前做了两项静态核对，因为这两项都是"不看就会踩"的：
v0.20.23的构建矩阵给每个 Linux 目标都是extra-features: "jemallocator,ebpf"，另有独立build-ebpf作业。这一条必须单独查 ——def.rs里的 ebpf 结构体不受 feature gate 控制，所以--strict-config能解析不能证明功能编进去了。顺手修掉的一个隐患：断言写死了版本号
checks.yml原来断言字面量want_v="0.20.10_alpha"，而它自己的注释写着"bumping this is fine" —— 一次例行升级就会让必需检查变红。改成：want_v与want_url必须指向同一版本、且不低于0.20.10（第一个认识proxy-src-macs的 release）。三种情形都验过（当前版本通过 / 降到 0.20.9 报错 / 版本与 URL 不一致报错）。这个 PR 不改变周更镜像
ENABLE_NIKKI默认false，定时构建不含 Nikki-RS，所以升级核心对周更镜像零影响；它只影响workflow_dispatch且enable_nikki=true的构建。运行期验证需要那样一次构建，见 PR 评论。