mihomo 与原版 Clash 有什么区别：协议支持、DNS 配置与迁移注意事项

先分清 Clash、Clash Meta、mihomo 与客户端

原版 Clash 通常指 Dreamacro 项目发布的 Clash 内核。它读取 YAML 配置，建立 HTTP、SOCKS 或 mixed 监听端口，再按照代理组与规则决定连接去向。Clash Meta 是在这套配置思路上扩展出来的内核分支，后来使用 mihomo 作为项目名称。实际迁移时，可以把“Clash Meta 配置”与“mihomo 配置”理解为同一技术路线不同阶段的称呼，但不能据此认定任意版本之间都完全兼容。

Clash Verge Rev、FlClash 等图形客户端负责配置导入、系统代理开关、日志展示和内核管理；mihomo 才是执行协议、DNS、规则和 TUN 接管的内核。订阅服务则提供节点与策略配置。这三者分别属于界面、执行层和配置来源，排查问题时应先确定报错来自哪一层。

用命令确认当前运行的内核

命令行部署可先执行版本查询。不同构建输出的附加信息可能不同，但结果中应能看到 mihomo 名称、版本、目标系统和处理器架构。

mihomo -v

例如，某台机器可能显示 Mihomo Meta v1.19.3 linux amd64。这里的 v1.19.3 只用于说明如何读取版本，不应被当作所有功能的统一最低要求。协议、配置字段和默认行为会随发布版本变化，迁移前应以当前二进制的版本信息和对应发布说明为准。

如果机器上仍使用名为 clash 的旧可执行文件，也要执行一次 clash -v。仅把新文件改名为旧名称，不会把旧内核升级为 mihomo；判断依据应是程序输出与实际进程路径，而不是文件名。

协议与规则能力有哪些实际差异

原版 Clash 已覆盖 Shadowsocks、VMess、Trojan、HTTP、SOCKS5 等常见代理类型，并提供 DIRECT、REJECT、代理组、规则模式和基础 DNS 功能。mihomo 延续这些配置结构，同时加入或扩展了 VLESS、Reality、Hysteria2、TUIC、WireGuard 等能力。具体协议能否使用，还取决于内核版本、订阅生成方式以及服务端参数是否完整。

协议名称相同，不代表参数可以直接复用

迁移中最容易误判的是“订阅里能看到节点，所以节点一定能连接”。客户端成功解析 YAML，只说明配置格式基本可读，不代表握手参数正确。例如 VLESS Reality 通常还涉及服务器名称、公钥、短 ID、客户端指纹与流控参数；Hysteria2 需要核对服务器地址、认证信息、TLS 服务器名称及证书验证设置。缺少字段时，节点仍可能出现在列表里，但连接日志会在握手阶段失败。

• 先选择一个明确可用的节点，不要一开始就通过自动测速组间接测试。
• 将日志级别临时设为 debug，完成一次目标连接后立即查看握手错误。
• 区分超时、DNS 解析失败、TLS 名称不匹配和认证失败，它们对应不同修复方向。
• 订阅转换器可能改写字段，必要时对照订阅原始内容与客户端落盘配置。

规则仍然按顺序执行

mihomo 没有改变规则模式的核心原则：从上到下求值，第一条匹配规则决定去向。迁移后如果出现“所有流量都走代理”或“特定域名没有直连”，首先检查规则顺序，而不是反复切换节点。

mode: rule
rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DOMAIN,blocked.example,REJECT
  - MATCH,PROXY

这里的 PROXY 必须是配置中已经定义的策略组，并不是内核自带出口。no-resolve 表示匹配这条 IP 规则时不主动把域名解析成 IP，并不等于关闭全部 DNS。旧配置如果缺少名为 PROXY 的策略组，测试配置时就应先报出引用错误，而不是等到连接阶段再处理。

DNS 配置为何是迁移的高风险部分

旧 Clash 配置迁移到 mihomo 后，即使代理节点可以连接，也可能出现网页打开缓慢、局域网域名失效、国内外解析结果不符合预期或 TUN 开启后完全无法解析。这类问题通常不是协议不兼容，而是系统 DNS、mihomo DNS、代理节点域名解析和 fake-ip 映射之间形成了错误路径。

理解 fake-ip 与 redir-host

enhanced-mode: fake-ip 会先向应用返回保留地址，再由内核保存域名映射并在接管连接时恢复真实目标。常见地址池是 198.18.0.1/16。它适合需要按域名规则处理的场景，但局域网发现、打印机、部分游戏平台或自行校验证书与地址的应用可能需要加入过滤列表。

redir-host 更接近先解析真实地址再处理连接。它减少了 fake-ip 对局域网应用的影响，但域名规则命中、解析延迟和缓存行为会有所不同。迁移时不应只因为某个模板使用 fake-ip 就直接覆盖现有配置，应先确认当前接管方式与应用需求。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 1.1.1.1
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

示例将 DNS 监听限制在 127.0.0.1:1053，用于说明端口与监听地址的关系。若由 TUN 的 DNS 劫持接管请求，配置还要与客户端生成的 TUN 段配合。端口 1053 不是强制值，也不会自动修改操作系统 DNS。

代理节点域名需要独立考虑

如果代理服务器本身填写的是域名，内核必须先解析该域名，才能建立代理连接。若这个解析请求又被规则送进尚未建立的代理，就可能形成启动循环。mihomo 配置可通过 proxy-server-nameserver 指定代理节点域名的解析服务器，并通过 nameserver-policy 为特定域名选择解析路径。

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - 223.5.5.5
  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query

这段配置只展示字段关系，不包含完整代理、策略组和规则定义。使用加密 DNS 时，还要确保其域名能够完成初始解析。迁移后若日志持续出现 DNS 超时，应先用普通 IP DNS 验证基础路径，再逐项恢复 DoH、策略解析与规则跟随，避免同时改动四五个变量。

TUN 模式迁移要检查权限、路由与接口

系统代理只影响主动读取系统代理设置的应用。终端命令、游戏、虚拟机和部分更新程序可能绕过系统代理，因此不少用户迁移到 mihomo 时会同时启用 TUN。TUN 会建立虚拟网络接口并修改路由，覆盖范围更广，也更依赖操作系统权限与路由配置。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

stack 可用值与行为应按当前 mihomo 版本核对，常见选择包括 system、gvisor 和 mixed。迁移时先沿用客户端默认值，再根据日志处理兼容问题。直接复制路由器模板到桌面系统，可能把接口名、路由表或 DNS 劫持方式一并带入，造成网络中断。

按顺序缩小 TUN 故障范围

1. 关闭 TUN，仅启用 mixed 端口，确认代理节点本身可以工作。
2. 检查监听端口。常见示例是 mixed-port: 7890，浏览器可临时设置 HTTP 与 SOCKS5 代理到 127.0.0.1:7890。
3. 启用 TUN，确认客户端已获得创建虚拟接口和修改路由所需权限。
4. 检查是否同时运行 VPN、虚拟机网络、游戏加速器或另一套透明代理。
5. 分别测试 IP 与域名。IP 可达而域名失败时，优先回到 DNS 配置。
6. 访问局域网设备，确认私有地址规则位于兜底规则之前。

在 Windows 上，权限申请通常由客户端完成；在 macOS 上，可能涉及 VPN 配置或网络扩展授权；Linux 服务部署则需要检查服务用户、网络能力和路由操作权限。不同客户端对这些步骤的封装不同，不能把某一客户端的菜单开关视为 mihomo 内核的通用配置字段。

旧配置迁移到 mihomo 的可复现步骤

第一步：保留旧文件与运行信息

复制当前 config.yaml、规则集、本地覆写和客户端配置目录，并记录旧内核版本、系统代理端口、控制端口、TUN 状态及正常使用的节点。订阅地址不应写入公开日志或截图。若客户端支持多个配置，应明确哪一份正在生效，避免修改了未选中的文件。

第二步：先做静态配置测试

mihomo 提供配置测试参数，可在启动服务前检查 YAML 语法、策略组引用和部分字段错误。假设配置文件位于当前目录，可以执行：

mihomo -t -f config.yaml

测试通过只表示内核能够加载配置，不代表每个节点都能建立连接，也不代表远程规则集一定可下载。若测试失败，应从首个错误开始修复；后续错误可能只是由前面的缩进或字段结构问题连带产生。

第三步：用最小配置验证监听端口

迁移时可以暂时保留一个代理、一个策略组和少量规则，将 mixed 端口设为 7890，控制接口限制在 127.0.0.1:9090。如果启用了外部控制接口，应同时设置访问密钥，并确认客户端填写的地址、端口和密钥一致。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090
secret: "change-this-local-secret"

这里的密钥是示例值，实际配置应替换。控制端口只供管理界面读取状态和切换策略，不承载网页代理流量；把浏览器代理指向 9090 不会得到正确结果。

第四步：逐项恢复规则集、DNS 与 TUN

建议按“节点连接 → 策略组 → 本地规则 → 远程规则集 → DNS → TUN”的顺序恢复。每加入一层，就完成一次域名访问、IP 访问、局域网访问与日志检查。这样出现问题时，回退范围只有一个步骤。

• 规则提供器：检查 behavior、文件格式、更新间隔和引用名称。
• 地理数据：确认 GEOIP、GEOSITE 数据文件能被当前内核读取。
• 策略组：检查规则目标名称与 proxy-groups 名称完全一致。
• 订阅覆写：确认客户端更新订阅时是否覆盖本地 DNS 或 TUN 设置。
• 局域网：需要其他设备连接时再启用 allow-lan，并配置监听地址和防火墙。

常见迁移症状与对应检查项

终端测试时可显式指定代理，避免把“终端没有读取系统代理”误判成内核故障。例如 mixed 端口为 7890 时，可以让支持 SOCKS5 的工具连接 socks5h://127.0.0.1:7890；其中由代理端解析域名的方式更适合验证 mihomo 的域名规则路径。

迁移完成后的验收标准

迁移完成不应只以客户端托盘图标变色为依据。至少应验证：配置测试通过；选定节点可建立连接；DIRECT 与代理规则分别命中；被拒绝规则确实阻断；DNS 没有持续超时；系统代理与 TUN 的覆盖范围符合预期；订阅更新后本地覆写仍然保留。

1. 记录当前 mihomo 版本与客户端版本，便于后续升级对比。
2. 在日志中确认一个直连请求、一个代理请求和一个拒绝请求的规则命中结果。
3. 关闭系统代理后检查 TUN 是否仍按预期接管；关闭 TUN 后检查 mixed 端口是否仍可独立使用。
4. 更新一次订阅并重新加载配置，确认策略组名称、DNS 与规则提供器没有被覆盖。
5. 重启客户端或系统，确认内核、配置与权限状态能够恢复。