客户端指南

Clash/Mihomo 配置里的 hosts 会改电脑 hosts 吗？

Mihomo 配置 hosts 与系统 hosts 是两条独立来源。解释自定义域名映射何时生效、为什么只影响部分应用，以及错误映射和 HTTPS 证书警告的边界。

发布于 2026/8/23 · 更新于 2026/8/23 · 4 项可核验来源

先看重点配置里的 hosts 是 Mihomo 解析路径中的自定义映射，不等于系统 hosts 文件已被改写。官方用 use-hosts 和 use-system-hosts 分别控制两类来源。若异常只在 Clash 运行时出现，应核对最终运行配置里的精确域名和通配符映射；不要用关闭证书校验来掩盖错误指向。

订阅更新后，某个网站忽然跳到陌生页面或弹出证书错误；关掉 Clash，访问又恢复正常。你在配置里搜到一段 hosts:，很容易把它理解成“客户端偷偷改了电脑的 hosts 文件”。

先把这两类 hosts 分开看。 Mihomo 可以在自己的解析过程中使用配置映射，也可以读取操作系统的 hosts；官方为它们提供了两个不同的开关。只看到运行配置里有 hosts:，还不足以证明 Windows、macOS 或 Linux 的系统文件被写过。

两类来源由两个开关控制

Mihomo 官方文档把顶层 hosts 定义为域名到 IP 或另一个域名的映射。DNS 配置里的 use-hosts 决定是否响应这组自定义映射，use-system-hosts 则决定是否查询系统 hosts；两项默认都为 true。

这两个开关把边界说得很清楚：Mihomo 配置和系统 hosts 是可以同时参与解析的独立来源。 use-hosts: false 不是“忽略系统 hosts”，而 use-system-hosts: false 也不等于配置中的 hosts: 已失效。

Clash Verge Rev 还支持 Merge 与 Script 配置增强。订阅原文、全局增强和客户端覆写可能共同生成最终配置，因此在原始订阅里没搜到某条映射，不能证明运行中的内核没有收到它。判断时应以最终运行配置为准，而不是只看下载下来的那份 YAML。

一条映射实际改变了什么

下面只是结构示例，不是建议把任何真实网站固定到这个地址：

hosts:
  'api.example.com': 192.0.2.10
  '*.internal.example': 192.0.2.20

dns:
  use-hosts: true
  use-system-hosts: true

第一条只针对完整域名，第二条覆盖匹配的子域名。Mihomo 官方还规定了匹配优先级：完整域名高于 *.example.com，后者又高于 .example.com 这类更宽的写法。值可以是单个地址、地址数组或另一个域名；域名重定向不能写成数组。

映射生效时，地址栏里的域名没有被改名，但后续连接可能被送到指定地址。它可以用于局域网服务或临时解析，也同样可能因过期 IP、写错通配符或陌生配置而让网站打不开。用途正常不代表来源可以不核对。

为什么只影响部分应用

应用是否受到影响，要看它的域名解析和连接有没有进入 Mihomo 的处理路径。系统代理、TUN、应用自带 DNS、浏览器安全 DNS 各走各的路径，已经建立的连接也会干扰判断。

于是你可能看到：浏览器异常而命令行正常；TUN 开启时异常，系统代理模式却正常；配置改回后，一个旧标签页仍复用之前的连接。浏览器自带 DNS 可能绕开哪一层，可对照浏览器安全 DNS 与代理 DNS 的边界；旧结果来自哪层缓存，则看切换代理后是否需要刷新 DNS。

这种差异能帮助定位路径，却不能单独证明机场节点、系统 DNS 或某个应用出了问题。一次只看一个变量，比同时换节点、清缓存和改 DNS 更容易保留因果。

错误指向不等于 HTTPS 已经失守

把域名解析到错误 IP，确实可能把连接送到另一台服务器。正常 HTTPS 客户端还会核对服务器证书所代表的身份是否与原始域名匹配；IETF 的 TLS 服务身份规范要求客户端用自己预期的标识与服务器证书中的标识进行匹配。

按这个机制，错误地址通常会带来证书警告或连接失败，而不是自动获得 HTTPS 正文。它也不是绝对安全网：明文 HTTP 没有这层 TLS 身份核验；用户若关闭证书校验、信任陌生根证书，保护边界也会改变。看到证书错误时，不要靠 skip-cert-verify 让页面“先打开”，相关风险见Clash 跳过证书校验会放宽什么。

反过来，没有证书错误也不能替配置来源背书。同一服务可能合法使用多个地址，错误映射也可能只造成超时；单凭页面能打开，无法证明整份订阅没有其他 DNS、监听或远程资源设置。

陌生映射该怎样定性

异常只在客户端运行时出现，并且最终配置里有匹配该域名的精确项或通配符，这是一条值得验证的线索；它仍不是“系统 hosts 已被篡改”的证据。恢复来源可信的配置后异常随之消失，才能把范围进一步收窄到 Mihomo 配置层。

关闭客户端后问题仍持续，则还要分别看系统 hosts、系统或浏览器 DNS 缓存，以及网络侧解析。不要因为两处都叫 hosts，就默认它们一定同步变化。

如果映射来自群文件、陌生短链或说不清维护者的订阅，不必在主力设备上继续试。普通 YAML 虽不是安装包，却能改变 DNS、路由和监听等网络行为；陌生 Clash 配置的权限边界说明了为什么“只是文本”也不能替来源担保。本文没有检查你的实际配置，也不能仅凭一次跳转把它定性为劫持。

资料来源

以下来源于 2026/8/23 复核。版本、支持平台和发布状态以后续官方页面为准。

持续更新

收到新教程，也欢迎纠错

想收到新文章，可以关注 TG 频道；发现下载失效、套餐变化或步骤不一致，请附上页面链接和可公开的截图。不要发送订阅链接、密码或完整账户信息。

关注 TG 频道 Telegram 纠错邮件纠错

读者互动

这篇内容对你有帮助吗？

— 次访问— 累计日独立访问— 条评论

直接说出你的问题