Mihomo v1.19.29 修复项、选包与升级回滚

截至 2026-07-25，Mihomo v1.19.29 是 GitHub 上的最新稳定版。OpenVPN 在服务端 soft reset 后不重连、WireGuard 的 per-peer reserved 没有生效、TUIC 失败连接持续占用 openStreams，或规则里出现全角 IP-SUFFIX 后触发 panic，这几类用户有明确升级理由。配置一直正常的人，不必只为版本号立即动正在工作的内核。

GitHub API 给出的发布时间是 2026-07-18T12:34:03Z，draft 与 prerelease 均为 false。本文核对的是官方 core；Clash Verge Rev、FlClash、OpenClash 等上层项目是否已经打包这个版本，要看各自的版本页。

v1.19.29 修了哪些正在发生的故障？

v1.19.28...v1.19.29 比较页包含 68 个提交。与其逐条复述，先按故障表现找更新对应项：

当前表现	v1.19.29 的官方修复	升级后看什么
OpenVPN 服务端软重置后连接没有恢复	0ee58417 修复 soft reset 后重连	保留同一配置，观察重置后是否出现重新握手
WireGuard peer 写了 reserved 但行为不符	12c30af9 修复 per-peer reserved 被忽略	查看最终配置与连接日志，不要同时改 peer
TUIC 连接失败后资源占用持续累积	75a3ea8b 修复失败路径泄漏 openStreams	在相同失败条件下观察进程资源是否仍持续增长
hosts 里已有域名，CNAME 查询返回空答案	45f79309 修复 CNAME 与 hosts domain-entry 匹配	对原域名重复同一条 CNAME 查询
DOMAIN-WILDCARD 没匹配嗅探到的主机名	c5834396 修复 sniffed hostname 匹配	在日志中看该连接最终命中的规则
规则误用全角 IP-SUFFIX 后内核 panic	c079b0cc 修复该 panic	先修正规则字符，再用 -t 做配置预检

Release 还修了 xhttp session-table 的 alphabet size、监听器重名检查、取消 context 后 reaper goroutine 忙循环，以及 stream encryption 不必要封装带来的性能回退。只有配置碰到对应模块时，这些修复才会改变运行结果。

新增的 JLS、RESTLS 和 ShadowQUIC 会自动生效吗？

不会。v1.19.29 增加了 JLS、RESTLS、ShadowTLS 与 ShadowQUIC 相关的 outbound、listener 和组合支持；AnyTLS 同步到 v0.0.13。OpenVPN 部分加入 TLSAuth，并补入 TLS rekey 修复、data-ciphers 协商与 tls-crypt-v2。

这些都是显式配置能力。旧 YAML 没写相关字段，就不会因为换了 core 自动切换传输。Release notes 也没有承诺它们能改善所有订阅、延迟或连接质量。

正在维护 xhttp download-settings 的用户要多看一眼：本版修复了 override 中漏掉 jls-opts、shadow-tls-opts 和 restls-opts 的问题。升级前后用同一份 provider 与覆写文件做 diff，别同时改服务器端参数，否则无法判断差异来自 core 还是配置。

Windows、macOS、Linux 应该下哪个文件？

GitHub Release API 当前列出 127 个 asset。数量多是因为同一系统还按架构、AMD64 指令集和 Go 编译版本细分。先确定操作系统和处理器，再看兼容标签：

运行环境	默认查找的文件名	需要避开的误选
Windows 64 位 Intel / AMD	mihomo-windows-amd64-v1.19.29.zip	386、arm64、Linux 包
Windows ARM64	mihomo-windows-arm64-v1.19.29.zip	amd64、386
Apple Silicon Mac	mihomo-darwin-arm64-v1.19.29.gz	darwin-amd64
Intel Mac	mihomo-darwin-amd64-v1.19.29.gz	darwin-arm64
Linux 64 位 Intel / AMD	mihomo-linux-amd64-v1.19.29.gz	Darwin、Windows、ARM 包
Linux ARM64	mihomo-linux-arm64-v1.19.29.gz	amd64、armv7
Linux 内核 2.6.32 至 3.1	对应架构且带 go123 的构建	不带 Go 标签的新工具链构建

官方 FAQ 说明，v1、v2、v3 只用于标记 AMD64 CPU 指令集等级；go120、go123 等标签表示 Go 编译版本。设备架构不明时先查系统，不要把文件名里的版本数字当成性能档位。

GUI 用户只在客户端自己的内核更新入口里选择版本。直接把 zip 或 gz 覆盖到应用资源目录，可能绕开 GUI 管理的文件名、签名、权限和启动参数。

下载完成后怎样核对 SHA-256？

Release API 为每个 asset 返回 digest。校验时必须使用完整文件名；普通 amd64、compatible、v1/v2/v3 和不同 Go 标签的摘要都不相同。

macOS 或 Linux 可以先计算本地摘要，再查询同名 asset：

FILE="mihomo-linux-amd64-v1.19.29.gz"
shasum -a 256 "$FILE"
gh api repos/MetaCubeX/mihomo/releases/tags/v1.19.29 \
  --jq ".assets[] | select(.name == \"$FILE\") | .digest"

Windows PowerShell 计算 zip 的摘要：

$File = Get-Item ".\mihomo-windows-amd64-v1.19.29.zip"
$Local = (Get-FileHash $File.FullName -Algorithm SHA256).Hash.ToLower()
$Release = Invoke-RestMethod "https://api.github.com/repos/MetaCubeX/mihomo/releases/tags/v1.19.29"
$Official = ($Release.assets | Where-Object name -eq $File.Name).digest -replace "^sha256:", ""
if (-not $Official) { throw "Release 中没有同名 asset" }
$Local
$Official
$Local -eq $Official.ToLower()

最后一行只有返回 True 才表示文件摘要与同名官方 asset 一致。找不到同名 asset 时 $Official 会为空，这种情况也不能安装。

截至核对日期，普通 Windows amd64 zip 的官方 digest 以 1a8520cf 开头，Linux amd64 gz 以 60de76a3 开头，Darwin arm64 gz 以 4dc25df9 开头。前八位只能快速辨认，真正验收仍要比较 API 返回的完整 64 位摘要。完整操作可参考 GitHub Release SHA-256 校验。

升级前哪些目录必须留下副本？

直接运行 Mihomo 的用户先确认实际启动参数。官方的 systemd 服务示例把 HomeDir 放在 /etc/mihomo，你的机器不一定沿用这个路径。用下面的命令查看 ExecStart，重点找 -d 指向的 HomeDir 和 -f 指向的配置文件：

systemctl cat mihomo
systemctl show mihomo --property=ExecStart

常见目录是 ~/.config/mihomo/ 或 /etc/mihomo/，但服务文件可能完全不同。复制的是实际 HomeDir，不只是 config.yaml；provider 缓存、规则文件、数据库和状态文件也可能在里面。

确认路径后再备份。下面只是两种常见示例，按 ExecStart 的结果取舍：

cp -a "$HOME/.config/mihomo" "$HOME/.config/mihomo.backup-v1.19.28"
sudo cp -a /etc/mihomo /etc/mihomo.backup-v1.19.28

旧二进制也要单独保留，并记录升级前的输出：

/usr/local/bin/mihomo -v
sudo cp -a /usr/local/bin/mihomo /usr/local/bin/mihomo.v1.19.28

如果你用的是 Docker，保留当前 image digest 与 compose 文件。只记 latest 标签无法保证回滚时取回同一个镜像。

新内核怎么预检，才不会把服务直接拉倒？

先把 v1.19.29 解压到临时目录，不覆盖正在运行的二进制。官方 main.go 定义了 -v 查看版本、-d 指定配置目录、-f 指定配置文件、-t 测试配置并退出。以下命令以 Linux amd64 普通构建为例：

install -d /tmp/mihomo-v1.19.29
gzip -dc "$HOME/Downloads/mihomo-linux-amd64-v1.19.29.gz" \
  > /tmp/mihomo-v1.19.29/mihomo
chmod 0755 /tmp/mihomo-v1.19.29/mihomo

解压后用实际配置路径执行预检：

/tmp/mihomo-v1.19.29/mihomo -v
/tmp/mihomo-v1.19.29/mihomo -t \
  -d /etc/mihomo \
  -f /etc/mihomo/config.yaml

成功输出应包含 Mihomo Meta v1.19.29，配置检查应以 configuration file ... test is successful 结束。若出现 unknown field、文件权限错误或 provider 路径错误，先停在临时目录处理；不要启动服务验证语法。

配置预检通过后再进入维护窗口。下面沿用官方 systemd 示例的 /usr/local/bin/mihomo；如果 ExecStart 显示的是其他路径，就替换成实际路径：

sudo systemctl stop mihomo
sudo install -m 0755 /tmp/mihomo-v1.19.29/mihomo /usr/local/bin/mihomo
sudo systemctl start mihomo
systemctl status mihomo --no-pager
journalctl -u mihomo -n 100 --no-pager

怎么确认升级真的生效？日志里的版本必须是 v1.19.29，原有 provider 能加载，DNS 监听与代理端口存在，第一条请求能命中预期规则。正在排查 OpenVPN、WireGuard、TUIC、CNAME 或 DOMAIN-WILDCARD 时，再复现升级前那个单一故障。

哪些部署可以继续停在 v1.19.28？

只使用常规订阅、DNS 和规则分流，且没有命中本版修复项的设备，可以等一个维护窗口。上层 GUI 与 OpenWrt 插件用户更应该等项目自己的内核更新；core 的新字段已经存在，不代表界面、覆写器和升级脚本都完成了适配。

本文没有在每个操作系统、路由器架构或 GUI 客户端上执行安装，也不对 JLS、RESTLS、ShadowQUIC 的服务端兼容性作推断。Release 没写出的性能幅度、连接成功率和资源占用变化，这里不补数字。

需要回滚时，先停止服务，把保留的 v1.19.28 二进制恢复到原路径：

sudo systemctl stop mihomo
sudo install -m 0755 /usr/local/bin/mihomo.v1.19.28 /usr/local/bin/mihomo
sudo systemctl start mihomo
/usr/local/bin/mihomo -v
journalctl -u mihomo -n 100 --no-pager

版本输出应回到 v1.19.28。只有新 core 已经改写配置或状态、而旧 core 无法读取时，才恢复 HomeDir 副本。若回退旧二进制后故障仍在，问题更可能来自配置、provider 或外部服务，不要继续反复换内核。

旧版本新增 Tailscale、OpenVPN 与 GOST relay 的背景可看 Mihomo v1.19.25 版本动态；GUI 内核不匹配则按 Mihomo core 版本回滚清单 处理。