Mihomo v1.19.30 已于 2026 年 8 月 16 日发布正式版。这次 Mihomo v1.19.30 更新加入 H2C 与 QUICv2 嗅探、Hysteria2 握手超时，以及 WireGuard、ZeroTier、MASQUE、OpenVPN 出站的 IP 栈选项，同时修复了 DNS、TUN、嗅探和网络恢复相关问题。使用这些功能的 Clash 兼容客户端用户适合优先评估升级。
合理做法不是看到新字段就立即改配置，而是先备份当前 YAML 和内核文件，确认所用前端确实能加载 v1.19.30，再用原配置完成一次基线验证。若当前版本稳定且未涉及上述协议，也可以等待客户端渠道完成集成；官方发布说明并未承诺所有第三方前端会同步提供该内核。
关键结论
- 这是正式版而非 Alpha 预发布版，官方 GitHub 页面记录的发布日期为 2026 年 8 月 16 日。
- H2C、QUICv2 嗅探是识别能力扩展，不等于所有用户都应开启嗅探或覆盖目标地址。
- Hysteria2 新增
handshake-timeout，适合需要单独控制握手等待时间的配置；默认值为 0 时仍使用外层连接超时。 ip-stack扩展到多种出站，可用于明确双栈策略，但不应把它当作修复所有 IPv6 问题的开关。- 升级后应核对实际内核版本、配置解析、DNS、规则命中、TUN 流量和断网恢复，而不只看“代理已连接”。
v1.19.30 的变化与影响范围
MetaCubeX 的 v1.19.30 发布页列出了新增功能和修复。以下解读把官方事实与使用建议分开：发布页能证明某项能力或修复进入该版本，但不能单独证明它在每个操作系统、每个第三方客户端中都有相同效果。
H2C 与 QUICv2 嗅探：先确认规则是否依赖域名
官方发布说明写明新增 H2C 和 QUICv2 嗅探支持。嗅探的作用是从连接特征中识别协议或域名，以辅助规则匹配；它不是 DNS 的替代品，也不会自动纠正错误的规则顺序。若升级前存在“只有 IP、域名规则不命中”的现象，可以观察新版本日志中的嗅探结果，再结合域名、IP、GeoIP 与规则优先级排查确认最终匹配的是哪条规则。
编辑建议是保留原有嗅探范围完成第一次升级验证，不要同时扩大端口、打开全局覆盖目的地址并更换 DNS。多项变更一起发生时，即使问题消失，也很难判断真正原因；若问题出现，也难以回滚到单一变量。
Hysteria2 handshake-timeout：控制的是握手等待
v1.19.30 为 Hysteria2 增加 handshake-timeout。同日更新的MetaCubeX Hysteria2 配置文档说明：该值单位为秒；配置后，握手不受外层连接超时影响；默认值 0 表示仅使用外层连接超时。
这意味着它适用于“希望单独限定 Hysteria2 握手等待”的场景，而不是通用加速参数。数值过短可能让高延迟或丢包网络过早失败，数值过长则可能延迟故障反馈。官方文档没有给出适合所有网络的最佳数值，因此应根据自己的日志和网络条件选择；没有明确问题时，保留默认行为更稳妥。
多种出站新增 ip-stack：先分清解析与传输
发布说明分别列出 MASQUE、ZeroTier、WireGuard 和 OpenVPN 出站的 ip-stack 选项。官方WireGuard 配置页也把 ip-stack 纳入完整写法。它提供的是出站 IP 栈选择能力，不代表设置后本地 DNS、系统路由、TUN 地址和远端可达性会自动一致。
如果设备处于 IPv4/IPv6 双栈环境，应把排查拆成三层：域名是否返回预期记录、Mihomo 是否选择预期地址族、系统路由是否能到达远端。有关 DNS 选择可参考Fake DNS、远程 DNS 和 DoH 配置指南；遇到“能连接但页面卡住”时，还应结合MTU 与 MSS 排查，不要直接把所有症状归因于 IP 栈。
DNS、TUN 与网络恢复修复：更值得观察回归
v1.19.30 发布页还列出多项修复，包括：Tailscale 在网络恢复后无法恢复、UDP DNS 回复按客户端声明的缓冲区截断、DNS dialer 不支持 UDP 时可能发生 panic、初始化 DNS 晚于 NTP，以及 TUN DNS 劫持在缓冲区重新分配时可能发送异常数据。另有嗅探等待、HTTP/2、QUIC 和 WebSocket 0-RTT 数据顺序相关修复。
这些项目让经常切换 Wi-Fi/移动网络、使用 TUN 或依赖 DNS 劫持的用户更有升级理由。不过“修复进入内核”不等于前端的服务生命周期、系统 VPN 权限或平台网络栈问题也被修复。升级后仍应区分内核日志、前端日志和操作系统事件。
谁应该升级，谁可以先等待
建议优先评估升级
- 正在使用 Hysteria2，且需要独立设置握手等待时间；
- 使用 WireGuard、ZeroTier、MASQUE 或 OpenVPN，需要明确控制出站 IP 栈；
- 依赖域名嗅探处理 H2C、HTTP/2 或 QUIC 流量；
- 遇到断网恢复后 Tailscale 不恢复、TUN DNS 劫持异常或特定 UDP DNS 问题；
- 运维多台设备，需要统一到包含上述修复的正式版本。
可以等待前端集成
如果你使用的是封装 Mihomo 的桌面或移动客户端，前端版本号不一定等于内核版本号。应用商店、系统包管理器或客户端自带更新器尚未提供 v1.19.30 时，不建议用来源不明的二进制覆盖。需要手动更换内核的读者，可先阅读站内Clash Verge 内核升级说明，但具体入口仍以当前前端文档为准。
若原配置只使用常见 HTTP、SOCKS、VMess 或 VLESS 出站，且没有 DNS、嗅探、TUN 或网络恢复故障，可以先等待前端维护者验证。上一个正式版的变化可在Mihomo v1.19.29 更新指南中对照，避免把跨版本配置差异误认为本次新增。
升级与验证清单
- 记录现状：保存前端版本、内核版本、操作系统、当前运行模式和一段无敏感信息的错误日志。
- 备份：复制 YAML、规则集引用、DNS 设置和可回滚的旧内核。不要在备份中公开订阅地址、密钥或令牌。
- 核验来源：只从 MetaCubeX 官方发布页或可信前端的官方更新渠道获取文件；按发布资产提供的校验信息核对对应文件。
- 先验配置：加载原配置，确认没有未知字段、缩进错误或弃用提示。此时不要添加
handshake-timeout或ip-stack。 - 确认内核：在前端“关于”、日志开头或命令行版本输出中确认实际运行的是 v1.19.30，而不是只更新了界面。
- 逐层验证：检查 DNS 返回、规则命中、TCP 与 UDP 连接、TUN 流量、睡眠唤醒及断网重连。只对与自己有关的协议进行测试。
- 单项改动：确实需要时再添加一个新字段，重载配置并记录前后日志；不要一次调整超时、IP 栈、嗅探和 DNS。
- 准备回滚：若出现持续崩溃、配置无法加载或核心业务中断，恢复旧内核与原配置，并保留可脱敏复现材料。
常见问题
升级 v1.19.30 后必须添加 ip-stack 吗？
不必须。官方把它作为若干出站的新选项，而不是强制迁移项。原配置在新内核中能正常解析、连接和路由时，可保持不变。只有需要明确地址族选择并能验证 DNS、路由和远端可达性时，才值得配置。
handshake-timeout 设置得越短越好吗？
不是。官方文档只定义了单位和默认行为，没有给出通用最佳值。过短可能在高延迟或丢包环境提前判定失败；应根据连接日志和实际网络设定。默认 0 表示沿用外层连接超时。
新版本支持 QUICv2 嗅探，是否应该开启全局覆盖？
不能由“新增支持”直接得出这个结论。嗅探范围与是否覆盖目的地址会影响规则和实际访问目标。建议先保持原范围验证，再针对有证据的问题调整，并检查最终规则命中。
前端显示已更新，为什么功能仍不可用？
常见原因是只更新了前端，实际加载的内核仍是旧版，或前端尚未暴露新字段。先查看内核版本输出和启动日志，再确认配置是否由该实例加载。第三方客户端的集成时间属于平台差异，不能从 Mihomo 发布页推断。
v1.19.30 是否能解决所有 DNS 或 TUN 故障？
不能。发布页只列出若干具体修复，DNS 服务器、规则、系统权限、MTU、前端服务和操作系统路由仍可能造成故障。应按复现条件核对，不要把版本升级当作安全性、兼容性或性能保证。
官方来源与核验入口
- MetaCubeX，Release v1.19.30 · MetaCubeX/mihomo，2026 年 8 月 16 日：查看正式版发布说明、修复列表与发布资产。
- MetaCubeX，Hysteria2 - 虚空终端 Docs，2026 年 8 月 16 日：核对 Hysteria2 配置与 handshake-timeout 定义。
- MetaCubeX，WireGuard - 虚空终端 Docs，访问于 2026 年 8 月 17 日：核对 WireGuard 完整配置与 ip-stack 字段。
关于作者
