升级 Mihomo v1.19.33 后报错或无法使用怎么办？
简答：升级 Mihomo v1.19.33 后先关闭 TUN 和系统代理，保留旧内核、最终配置及 Profile，再用同一二进制执行配置测试；若测试失败就修配置，若新内核仍无法启动再安全回滚。
定义：Mihomo v1.19.33 升级排障，是核对实际运行内核、校验最终配置、区分客户端与网络问题，并在必要时恢复旧版本的过程。
先做这四步：停用 TUN、备份、核对版本、校验配置
升级后内核起不来、开 TUN 后断网，先不要反复刷新订阅或覆盖旧文件。本文与 Mihomo 项目及其开发者无隶属关系；截至 2026 年 10 月 22 日，官方 Release 已列出 v1.19.33，并记录了 TUN 的 dns-mode 支持、内置 Shadowsocks listener 关闭、DoH 拨号堆积、代理循环检查等修复，以及一项 TLS 安全修复。具体变更以v1.19.33 官方 Release为准。
- 在客户端先关闭 TUN、系统代理和自动启动，避免异常配置继续接管系统流量。
- 复制升级前旧内核、v1.19.33 新内核、最终生效配置、Profile、覆写文件、规则集和订阅转换模板。不要只保存订阅地址，因为远程内容可能已经变化。
- 确认客户端实际调用的文件和版本。命令行可先执行
mihomo -v；Windows 使用.\mihomo.exe -v。将输出的版本与客户端日志开头或内核管理页显示的版本逐字对比。 - 用同一个 v1.19.33 二进制测试最终配置。先执行
mihomo -h确认当前构建支持的参数，再运行下面的命令；示例路径必须替换为实际目录。
-d 用于指定工作目录，-f 用于指定配置文件；如果当前构建提示参数不存在，应以 mihomo -h显示的兼容写法为准。
mihomo -t -d "/path/to/work" -f "/path/to/work/config.yaml"
Windows 示例：
.\mihomo.exe -t -d "C:\path\to\work" -f "C:\path\to\work\config.yaml"
判定标准：测试命令正常退出且没有新的配置错误，才继续启动；如果相对路径找不到文件，改用绝对路径，并让 -d 指向包含配置及相关规则资源的工作目录。
按日志关键词分流，不要先盲目回滚
| 现象 | 对应日志关键词或表现 | 优先处理 | 正常判定 |
|---|---|---|---|
| 内核启动即退出 | Parse config error、Invalid YAML | 保留完整错误行，检查缩进、引号、列表结构，再用同一内核执行 -t | 配置测试通过，进程不再立即退出 |
| 代理组或引用失败 | 以实际日志为准，例如 'xxx' not found | 检查代理组、代理提供者或规则引用的名称是否真实存在；不要搜索未经日志证实的固定报错 | 引用对象存在，启动日志不再出现对应错误 |
出现 invalid domain | 域名列表、fake-ip-filter 或嗅探跳过列表相关 | 先检查域名通配写法，再逐段移除最近修改的 DNS 配置；普通 YAML 能解析不代表 Mihomo 可加载 | 同一二进制的配置测试通过 |
| 内核能启动但无法上网 | 节点可选但请求超时、域名无法解析 | 关闭 TUN，先测试 HTTP、SOCKS 或 mixed 入口；再分别检查 DNS、规则模式和节点 | 代理端口能建立连接，测试域名能解析 |
| 只有 TUN 失效 | 无法建立网卡、连接循环、DNS 请求未被接管 | 检查权限、路由、防火墙、dns-mode 和系统私人 DNS | TUN 网卡出现，流量按预期进入代理 |
| 客户端仍使用旧内核 | 客户端版本与 mihomo -v 不一致 | 检查内核目录、运行设置、启动日志和自定义内核路径，必要时切回旧文件验证 | 客户端显示版本、日志版本、命令行版本一致 |
官方 FAQ 说明，Release 文件名通常包含系统、CPU 架构、编译标签、分支和提交哈希；AMD64 文件可能出现 v1、v2、v3 指令集标签，也可能出现 go120 编译标签。下载时应对照官方 FAQ 的文件选择说明，不要只看文件名中的版本号。
如果 Release 页面提供校验值，Windows 可执行：
certutil -hashfile mihomo.exe SHA256
macOS 或 Linux 可执行：
shasum -a 256 ./mihomo
判定标准是文件名、系统、架构和 SHA-256 值均与官方资产一致；若页面没有提供校验值，只能完成资产和架构核对，不能声称已完成完整性验证。
v1.19.33 的 TUN 与 DNS：先恢复简单路径
v1.19.33 新增的是 TUN 的 dns-mode支持，不等于所有旧配置都必须立即增加这个字段。升级后如果普通代理可用、TUN 一开就断网，应先保持 TUN 关闭，再逐项恢复。
- 先关闭 TUN，只保留 HTTP、SOCKS 或 mixed 入口，确认节点和代理模式正常。
- 再只恢复 TUN，不同时修改 DNS、MTU、规则和节点。记录是否出现网卡、路由或权限错误。
- 最后才测试
dns-mode。官方文档列出disabled、native和hijack：disabled不设置系统 DNS，native将 TUN 地址设为系统 DNS，hijack还会拦截发往其他网卡的 53 端口流量。 - 使用
hijack时，Windows 需要strict-route，Linux 需要auto-redirect；Android 开启私人 DNS 时，DNS 劫持可能无法自动接管。具体条件以官方 TUN 配置文档为准。 - 如果使用 fake-IP，检查
enhanced-mode、fake-ip-filter和域名列表。DNS 字段的合法范围以官方 DNS 配置文档为准。
Windows TUN 还应排查物理出口网卡是否开启 IPv4 转发。官方 Issue #3186 记录了在特定绑定出口网卡和 TUN 条件下，流量可能重新进入自身 TUN；如果日志出现连接循环、重复拨号或 CPU 异常升高，可暂时关闭该网卡的 IPv4 Forwarding，再复测。不要把该 Issue 当作所有 Windows TUN 故障的通用结论。
PowerShell 示例，先用 Get-NetIPInterface 找到实际出口网卡的 ifIndex，再替换下方的 接口编号：
Get-NetIPInterface -AddressFamily IPv4
Set-NetIPInterface -InterfaceIndex 接口编号 -AddressFamily IPv4 -Forwarding Disabled -PolicyStore ActiveStore
判定标准：关闭转发后，TUN 日志不再持续重复同一自回环连接；如果现象不变，应继续检查权限、路由和 DNS，而不是仅凭这一项下结论。参考官方 Issue #3186。
客户端适配检查：确认它没有继续调用旧内核
官方文档明确提醒，使用 Mihomo 的第三方工具和客户端不一定及时包含内核最新功能或修复；由客户端本身产生的问题，应向对应客户端反馈。可查看官方三方工具与客户端列表，但列表不代表本文站点对这些客户端作出兼容性保证。
| 使用场景 | 先查哪里 | 如何判定 |
|---|---|---|
| Clash Verge Rev、Clash Nyanpasu | 内核管理、运行设置、自定义内核目录、启动日志 | 日志开头的版本和路径必须与 mihomo -v一致 |
| Mihomo Party 或其他桌面前端 | 内核文件目录、当前配置目录、应用日志 | 切换旧内核后现象应有可重复差异；无差异则继续查配置或系统代理 |
| Android 客户端 | 内核文件选择、VPN/TUN权限、私人 DNS 设置 | 关闭私人 DNS 和 TUN 后，普通代理是否恢复 |
| OpenWrt 或路由器 | 服务脚本、二进制路径、配置目录、启动日志 | 服务实际启动命令中的二进制、-d目录和配置文件一致 |
如果客户端没有显示路径，使用系统文件搜索定位最近修改的 Mihomo 二进制，再分别执行版本命令；Linux 还可用 ps 查看正在运行的命令行。不要只依据文件修改时间，因为客户端可能复制或重命名内核。
Linux 使用 systemd 时，可先停止服务并确认服务定义中的 ExecStart，再替换文件：
systemctl cat mihomo
sudo systemctl stop mihomo
sudo cp ./mihomo /usr/local/bin/mihomo
sudo cp ./config.yaml /etc/mihomo/config.yaml
sudo systemctl start mihomo
sudo systemctl status mihomo
sudo journalctl -u mihomo -o cat -e
示例中的二进制和配置路径必须替换为服务定义中实际使用的路径。判定标准是服务保持 active，日志不再反复退出，并且配置测试与服务启动使用同一份文件。systemd 操作可参考官方运行服务文档。
按平台恢复网络与安全回滚
Windows
关闭 TUN、系统代理和自动启动，恢复旧 Profile 后再测试。清理 DNS 缓存可执行：
ipconfig /flushdns
它只清理 Windows DNS 缓存，不会修复配置错误。若仍无法访问，检查 TUN 网卡、系统代理开关和客户端内核路径。
macOS
先关闭 TUN 和系统代理，再恢复旧配置。清理 DNS 缓存可执行：
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
官方 FAQ 当前写明官方构建支持 macOS 10.13 及更高版本；非官方构建不适用这一保证。TUN 设备名应按官方文档检查，macOS 设备名需要以 utun 开头，不能直接套用其他系统的接口名。参考官方 FAQ和TUN 文档。
Linux
按前文 systemd 流程停止、备份、替换、启动和查看日志。若不是 systemd，先用 ps -ef | grep mihomo 找到实际进程和启动参数，再停止对应进程；不要直接覆盖仍在运行的二进制。
Android 与 OpenWrt
Android 重点检查客户端选择的内核文件、VPN/TUN 权限和私人 DNS；OpenWrt 重点检查服务脚本、启动命令、配置目录和架构。由于不同前端和固件菜单并不统一，无法核实时不要写死菜单名称。优先恢复升级前文件，再用日志确认实际运行版本。
安全回滚顺序如下：
- 停止客户端、TUN 和系统代理。
- 复制并保留 v1.19.33、新配置和完整日志，不要直接删除证据。
- 将新内核改名保存，例如加入
.v1.19.33后缀，避免客户端自动覆盖。 - 恢复升级前已验证可用的内核和配置，先执行配置测试。
- 先测试普通代理，再单独恢复 TUN、DNS 和规则功能。
当 v1.19.33 在相同配置下稳定复现启动失败、客户端无法确认实际调用文件，或关闭 TUN 后仍无法恢复时，可以优先回滚；这只能说明当前设备或配置存在可复现问题，不能推断所有用户都会遇到相同故障。
反馈问题前的最小信息清单
如果修复后仍失败，建议整理最小复现信息再提交到相应项目：
- 系统版本、CPU 架构、客户端版本和 Mihomo 版本。
- 实际二进制路径、配置路径、启动参数和
mihomo -v输出。 - 完整错误行、出现时间、是否开启 TUN、使用的
dns-mode以及复现步骤。 - 经过脱敏的最小配置和一份能复现问题的 Profile。
删除订阅令牌、服务器地址、用户名、密码、私钥、内网地址和个人 IP。不要只提交“无法使用”或单张截图，优先保留完整日志和升级前后配置差异。
本文站点只提供通用排查信息，不代表 Mihomo 项目、各客户端或任何第三方服务的官方支持。
常见问题
Mihomo v1.19.33 提示 Parse config error，应该先改配置还是先回滚？
先保留旧内核、旧配置和完整日志，使用同一份最终配置执行 mihomo -t -d 工作目录 -f 配置文件。能定位字段就先修配置；测试仍失败且旧版本可用，再安全回滚。
为什么 YAML 工具能打开配置，Mihomo 仍然无法启动？
YAML 语法正确只代表文件结构可解析，不代表 Mihomo 能识别字段、代理组引用、域名列表或客户端生成的覆写。最终判断应以同一 Mihomo 二进制的 -t 测试和启动日志为准。
v1.19.33 的 dns-mode 应该直接设置成什么？
不要直接套用一个值。先关闭 TUN确认普通代理正常，再按系统检查 disabled、native 或 hijack 的条件；hijack 在 Windows 需要 strict-route，在 Linux 需要 auto-redirect。
如何确认客户端真的运行的是 Mihomo v1.19.33？
同时核对客户端显示版本、启动日志中的版本和路径，以及 mihomo -v或Windows下 .\mihomo.exe -v的输出。三者不一致时，优先检查客户端是否仍调用旧文件。
Windows 开启 TUN 后出现循环连接或 CPU 异常，怎么办？
先关闭 TUN和系统代理，检查出口物理网卡是否开启 IPv4 Forwarding，再重新测试。该现象只应按官方 Issue #3186描述的条件核对，不能把它当作所有 TUN 故障的唯一原因。
什么时候适合恢复旧版本？
当升级前内核和配置仍完整、v1.19.33在相同配置下可稳定复现启动失败，或客户端无法确认实际调用文件时，可先保存新文件与日志，再恢复升级前已验证可用的版本。