Mihomo Party Fake-IP 与 DNS 配置教程：Windows / macOS 防泄漏完整方案 2026

Mihomo Party 连上了但 DNS 还在裸奔——这是最常见也最容易被忽略的坑。代理图标变绿只代表 TCP 流量走了代理通道，DNS 请求默认走的是另一条路：你的系统 DNS 设置，通常是宽带运营商的 DNS 服务器。任何一步漏配，ipleak.net 一查就现原形。

换到 Fake-IP 模式是让 DNS 也进入代理通道的最彻底方案。整个过程不需要额外装工具，只需要在 Mihomo Party 的配置文件里改三段内容，重启核心就能生效。

代理图标绿了，DNS 为什么还是漏的？

代理客户端和 DNS 解析是两条独立的通道。

你的浏览器在访问任何网站之前，必须先向 DNS 服务器查询域名的 IP 地址。这个查询默认走的是系统网络栈——Windows 下是网络适配器设置里的 DNS，macOS 下是系统偏好设置里的 DNS，通常都是 114.114.114.114、223.5.5.5 或者宽带运营商自动下发的 DNS 地址。

代理客户端管的是 TCP/UDP 流量。DNS 查询用的是 UDP 53 端口，如果代理没有专门劫持这个端口，DNS 请求就直接绕过了代理通道，明文发给运营商。运营商不需要解密你的 HTTPS 流量——它只要看 DNS 查询记录，就知道你访问了哪些域名。

Mihomo Party 的默认配置里，enhanced-mode 通常被订阅模板设置为 redir-host。这个模式下客户端会做真实的 DNS 解析，然后根据解析出的 IP 去匹配规则。如果上游 nameserver 填的是 114.114.114.114 这类明文 DNS，泄漏就板上钉钉。

泄漏现象	可能原因	优先排查哪
ipleak.net 显示 114.114.114.114 或 223.5.5.5	nameserver 填了明文 DNS 直连地址	切到 Fake-IP，或把 nameserver 换成 DoH URL
ipleak.net 显示运营商 DNS（如 202.96.x.x）	系统 DNS 没被劫持	检查 tun.dns-hijack 是否配了 any:53
Fake-IP 开了但 ipleak.net 还是显示本地 DNS	浏览器 DoH 绕过了系统 DNS	Chrome/Edge 设置里关闭「使用安全的 DNS」
nslookup 返回真实 IP 而非 198.18.x.x	TUN 模式没开或 dns-hijack 未生效	检查 tun.enable 和 dns-hijack 字段
Android 端 DNS 泄漏	系统私人 DNS 独立于代理客户端	设置 → 网络 → 私人 DNS → 关闭

198.18.x.x 虚拟 IP 到底是怎么工作的

Fake-IP 的核心改动只有一步：把 DNS 解析从「建连之前做」推迟到「建连那一刻做」，并且先给一个假答案稳住发起请求的应用。

流程是这样的：

1. 浏览器发起 DNS 查询：www.google.com 的 IP 是什么？
2. Mihomo Party 拦截到这个查询，不从上游 DNS 要真实 IP，直接从 198.18.0.0/16 池子里分配一个虚拟地址，比如 198.18.1.45。
3. 浏览器拿到 198.18.1.45，向这个 IP 发起 TCP 连接。
4. Mihomo Party 在连接建立时查内部映射表，发现 198.18.1.45 对应的是 www.google.com，然后根据规则判断：这个域名匹配 geosite:gfw，走代理节点。此时才真正通过代理节点发起连接。
5. 对于映射表中找不到对应域名的请求（比如某些应用直接用 IP 通信），Mihomo Party 按默认规则处理。

整个过程 DNS 请求没有离开过 Mihomo Party 的内存。外部唯一能看到的就是出口流量走了代理节点。这就是为什么 Fake-IP 能做到 DNS 零泄漏——它根本没有向外发出 DNS 查询。

198.18.0.0/16 这个地址段在 IANA 注册表中属于 RFC 2544 网络基准测试保留段，正常情况下公网上不会出现。Mihomo 选中它当虚拟地址池也是因为这个原因——不会和公网真实 IP 冲突。但这也导致一个实际麻烦：某些安全工具和 SSRF 防护会把 198.18.0.0/16 当成特殊用途地址拦截，比如某些 WebFetch 工具在升级后就会阻止访问 198.18.x.x 段的地址。

Mihomo Party 和 Clash Verge Rev 的 DNS 面板有什么不同

两个客户端底层都是 mihomo 内核，YAML 配置结构完全一致。差异出在 UI 交互上。

Clash Verge Rev 有一个专门的 DNS 设置面板（Settings → DNS Settings），在 UI 里可以直接选 DNS Mode（Fake-IP / Redir-Host），不需要手动编辑 YAML。面板里还会把 dns-hijack、nameserver、fallback 等选项拆成独立的开关和输入框，对新手更友好。

Mihomo Party（现在的 Clash Party）大量操作依赖直接编辑 YAML 配置文件。主界面进 Profiles → 选中当前订阅 → Edit，打开的就是原始 YAML 文本编辑器。DNS 配置全在 dns: 段落下，需要用户自己写 YAML 字段。v1.9.5 新增了配置覆写功能，可以在不修改原始订阅配置的情况下叠加自定义设置，适合订阅会定期从远程更新的用户。

迁移建议：如果你从 Clash Verge Rev 迁到 Mihomo Party，不要把旧客户端的 UI 面板截图当参照去找 Mihomo Party 的对应按钮。直接把 Clash Verge Rev 导出的 YAML 配置里 dns: 以下的内容完整复制到 Mihomo Party 的配置编辑器里，结构完全通用。

三步开启 Mihomo Party 的 Fake-IP

下面按 Mihomo Party v1.9.x 的操作路径走，Windows 和 macOS 通用。

第一步：打开配置编辑器。

Mihomo Party 主界面 → 左侧导航点 Profiles → 在列表里选中当前正在使用的订阅配置（名称后有绿色圆点标记）→ 点击 Edit 按钮。这时会打开一个 YAML 编辑器窗口。往下滚动找到 dns: 段落。如果你的订阅配置里没有 dns: 段落，在文件末尾另起一行写。

第二步：填入 Fake-IP 的 DNS 配置。

把以下 YAML 替换或插入到配置文件中。注意缩进——YAML 缩进错一个空格就会报解析错误。

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  respect-rules: true
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.google/dns-query
    - https://cloudflare-dns.com/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  direct-nameserver:
    - https://dns.alidns.com/dns-query
    - 223.5.5.5
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - '*.localdomain'
    - '*.home.arpa'
    - '+.msftconnecttest.com'
    - '+.msftncsi.com'
    - 'localhost.ptlogin2.qq.com'
    - '+.stun.*.*'
    - '+.stun.*.*.*'
    - '*.n.n.srv.nintendo.net'
    - '+.srv.nintendo.net'

几行关键字段的取舍：

• default-nameserver：自举 DNS，用于解析 nameserver 里 DoH 域名的真实 IP。必须填 IP 地址，不能填域名。填了域名会造成死循环——客户端还没有 DNS 能力就要去解析 DoH 服务的域名。阿里 DNS（223.5.5.5）和腾讯 DNS（119.29.29.29）的国内响应速度够快。
• nameserver：默认上游，Fake-IP 模式下主要用于 fake-ip-filter 里的域名和直连规则域名的真实解析。用 Google 和 Cloudflare 的 DoH，走代理通道加密。
• proxy-server-nameserver：解析代理节点域名用，走国内 DNS 直连，避免节点域名解析被代理延迟拖慢。
• direct-nameserver：直连规则匹配到的域名走这里解析，同样用国内 DNS 直连提速。
• respect-rules: true：让 DNS 请求也遵守代理规则路由。nameserver 里的 DoH URL 走代理，阿里 DNS 走直连。

第三步：保存并重启核心。

编辑器右上角点 Save（或 Ctrl+S）→ 回到主界面 → 点右上角或底部的 Restart Core 按钮。核心重启需要 2-5 秒，重启完成后系统托盘图标恢复为已连接状态。

DNS 劫持没开：Fake-IP 最常见的遗漏

把 enhanced-mode 改成 fake-ip 只是第一步。Fake-IP 的 DNS 拦截范围默认只覆盖 Mihomo Party 自身网络栈内的应用。系统里打开的命令行、浏览器、其他工具，它们的 DNS 查询仍然走系统 DNS 设置，不会被拦截。

要让全机 DNS 都进 Mihomo Party 的通道，必须在 TUN 配置里写 dns-hijack：

tun:
  enable: true
  stack: system
  dns-hijack:
    - any:53
    - tcp://any:53

any:53 劫持所有发往 UDP 53 端口的请求。tcp://any:53 覆盖 TCP DNS（某些 DoT 回退或长 DNS 响应会用 TCP 53）。两条都写上才能兜底。

验证 DNS 劫持是否生效：打开终端或命令提示符，输入 nslookup baidu.com。如果返回的 IP 是 198.18.x.x 格式，说明劫持生效。如果返回了真实的公网 IP（如 110.242.68.66），说明系统 DNS 绕过了 Mihomo Party。

几个常见的劫持失败原因：

1. 浏览器内置 DoH：Chrome、Edge、Firefox 的设置里都有一个「使用安全的 DNS」选项，打开后浏览器直接向 Cloudflare 或 Google 发加密 DNS，完全不走系统 53 端口。Mihomo Party 在 53 端口上的劫持管不到它。在各浏览器的隐私与安全设置里关掉这个选项，让浏览器回退到系统 DNS。
2. macOS 防火墙：Little Snitch、Lulu 等防火墙如果拦截了 Mihomo Party 的入站 UDP 53 请求，劫持就形同虚设。在防火墙规则里放行 Mihomo Party 的 53 端口入站流量。
3. Android 私人 DNS：系统设置 → 网络和互联网 → 私人 DNS。这个功能让全机 DNS 走 DoT 通道，连接独立于代理路由，是目前移动端最隐蔽的泄漏源。关掉就好。

配完后怎么确认 DNS 没泄漏

三步验证：

ipleak.net：连上代理后打开 https://ipleak.net，看页面中段 DNS Addresses 列表。列表中应该只有 198.18.0.0/16 段地址或代理节点出口 IP。出现任何公网 DNS（114、223、8.8、1.1 开头）或运营商名称，说明还有泄漏点。

nslookup 测试：终端执行 nslookup www.google.com。返回 IP 在 198.18.x.x 范围内即生效。如果不是，检查 tun.dns-hijack 配置和浏览器 DoH 设置。

Mihomo Party 日志面板：打开 Logs 页面，日志级别选 Info。访问任意海外网站后看日志里的 DNS 相关条目——解析结果应该全是 198.18.x.x。如果日志里出现了一条对 8.8.8.8:53 或 1.1.1.1:53 的 UDP 连接，说明配置里某条 rules 或 fallback 走了明文上游。

如果换了设备、换了配置、三条路都查了，ipleak.net 还是出现本地 DNS，那问题可能不在客户端这边——企业网关或运营商在网络层强制劫持了 53 端口，无论你本地怎么配都会被拦截重定向。这种情况把所有上游都改成 DoH（443 端口），或者换一份预配好 DNS 的 兼容 Clash / Singbox / V2Ray 的订阅，减少手动配置里的不确定变量。

相关阅读

• Clash Verge Rev 开启 TUN 模式完整教程（Windows / macOS / Linux 2026）
• Mihomo TUN 模式 Windows 配置详解：从驱动安装到排错（2026）
• Clash Verge Rev 导入订阅完整步骤（Windows / macOS 2026）