开启 3 天免费试用
注册即可免费体验全部高级功能。
*仅限新用户；每位用户只能获得一次试用。
Mihomo Fake-IP 与 Redir-Host：DNS 兼容排障与恢复
Ryan Foster
2026年10月11日· 7 分钟阅读
Mihomo Fake-IP 与 Redir-Host 的差别在于应用收到什么地址，而不是哪种模式能让整个互联网变安全。Fake-IP 返回与域名建立内部映射的合成地址，Redir-Host 返回解析得到的地址。排查兼容性时，应让同一域名依次经过解析器、应用、捕获路径和实际出站，找出哪次交接失败。［1］［2］
关键要点
- 合成 DNS 答案是映射标记，不是网站的公网地址。
- 浏览器、应用和系统解析器可能走不同路径。
- 每次只改一个模式或例外，再建立新连接验证。
- 调整期间保留局域网服务和独立管理通道。
什么时候需要比较 Mihomo Fake-IP 与 Redir-Host？
本文面向你有权管理的 Mihomo 实例，DNS 字段以稳定版 v1.19.32 和官方配置文档核对。这是一套依据文档设计的诊断流程，不是作者完整端到端实测，也不保证所有客户端封装行为相同。先登记实际核心与封装版本；封装可能重新生成 YAML，覆盖手工修改。［1］［3］
用自建方案的责任划分方法确认谁维护配置和恢复。如果真正的问题是哪些应用进入代理，先比较TUN 与系统代理的覆盖范围。连接没有进入 Mihomo 时，改 DNS 模式不能替它完成捕获。
准备私密备份、原解析器设置及独立管理连接。共享机器先约定维护窗口，不动他人的代理。已在使用日常代理或 VPN 客户端时保持其原状态，改用另一台获授权测试设备，避免多个捕获层叠加后无法解释结果。
步骤 1：固定域名与解析路径
选择一个允许你请求的公网域名，以及一项你控制的局域网服务。记录主机名、记录类型、客户端、时间、Mihomo 配置、DNS 监听和具体故障。超时、证书错误、应用拒绝某类地址是不同现象，不能统称 DNS 泄漏。
下面直接查询本机 1053 端口的 DNS 监听。把示例域名换成选定主机名，端口换成实际端口；只能在该监听所在机器执行，第二台设备的 loopback 指向第二台设备自身。
dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com AAAA
私下保存答案类型和 TTL，再与系统解析器及故障应用比较，保持网络和域名不变。不要把订阅、完整配置或浏览记录上传到公开检测站。浏览器的加密 DNS 可能绕过系统解析器，因此 dig 的答案不能证明浏览器走同一条路。
不要把 127.0.0.1:1053 填进操作系统的普通 DNS 地址框，许多此类设置不接受自定义端口。使用封装已经支持的接入方式，或仅把它当直接诊断查询。为方便查询而监听所有接口，会额外扩大暴露面。［1］
步骤 2：读取实际模式与地址映射
查看核心实际加载的配置，并计入封装覆写。以下仅演示已有可用 DNS 配置中的部分字段，不是完整互联网代理配置；保留获授权的上游解析器、路由、IPv6 策略及既有例外。
dns:
enable: true
listen: 127.0.0.1:1053
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter-mode: blacklist
fake-ip-filter:
- 'printer.home.arpa'
把 printer.home.arpa 换成你管理的准确本地名称，或删除这个演示例外。blacklist 模式下，匹配项不返回 Fake-IP，但它不会创建 DNS 记录，也不会自动选择能回答本地域名的解析器。已有 whitelist 或 rule 模式时，过滤含义不同，不能直接套入这份列表。［1］
区分应用拿到的合成地址，以及出站最终解析或选择的目标。映射必须能被接收连接的 Mihomo 实例理解；把答案交给另一台主机、换配置后沿用缓存、让连接绕过捕获，都可能在公网域名正常时失败。Redir-Host 改变答案地址行为，不会取消 DNS 策略与路由判断。［2］
198.18.0.0/15 中的地址既不能证明公网可达，也不能单独证明恶意劫持。服务器侧 SSRF 防护仍须拒绝不合格特殊用途及私网目标，不能因为桌面代理使用合成 DNS 就整段放行。抓取 URL 的服务器要采用自己的可信解析和目标校验，这里的解释不构成安全例外。
步骤 3：分开定位 Mihomo DNS 兼容性问题
让不同应用请求同一资源，并使用新连接；不要拿旧浏览器连接与刚发出的命令行查询比较。浏览器加密 DNS、上游、捕获模式和 DNS 模式同时改动，会使结果无法归因。
| 现象 | 应比较什么 | 不能据此证明什么 |
|---|---|---|
| 直接查询得到合成 A 记录 | 实际模式与过滤匹配 | 浏览器也用了此监听 |
| 浏览器正常而原生应用失败 | 应用解析器、代理支持及缓存 | 所有原生应用都需要 Redir-Host |
| 打印机名称解析失败 | 本地 DNS 权威与准确例外 | 私网名称都应交给公网 DNS |
| A 正常但 AAAA 不同 | DNS IPv6 设置及真实 IPv6 路由 | IPv6 流量已经受保护 |
| 两种模式都超时 | 上游连通与引导解析 | 换模式能修复上游 |
Ubuntu 的解析归属和分域 DNS 另按系统解析排障路径检查。讨论隐私时，要区分答案格式与DNS 请求离开预期解析路径。合成答案或页面打开，都不足以说明所有查询去了哪里。
局域网例外还要确认权威本地解析器有对应记录，返回地址能沿预期本地路由到达。除非它们就是获授权目标，否则将管理和设备发现流量留在实验之外。mDNS 名称可能走不同于普通单播 DNS 的发现机制，过滤条目不能替代该机制。
步骤 4：每次只改一项并重新请求
私下复制有效配置，确认封装怎样持久保存修改。证据只指向一个局域网名称时，先试准确例外和正确本地解析器；应用普遍不接受合成地址时，再比较 enhanced-mode: redir-host，保持上游、捕获规则及网络不变。［1］
加载前使用所选核心或封装有文档依据的检查功能。语法通过不证明路由、凭证或应用兼容；如果没有明确的旧配置恢复入口，停止在唯一管理路径上试改。
Fake-IP 故障排查只通过应用文档支持的控制刷新测试连接与相关缓存。持久 Fake-IP 映射与普通 DNS 缓存是不同状态，不要删除共享缓存数据库、重置所有应用或重启无关网络服务来制造干净对照。
变更有效时，保留域名、查询路径、答案类别、应用结果和未改变的控制条件；无效则先恢复，再试下一假设。捕获和路由问题单独参照Linux 透明捕获机制比较。
步骤 5：读者需要怎样验证？
下表是应由你检查的预期现象，不是作者已经取得的结果。逐项填写实际观察和未验证分支；DNS 答案、代理流量记录与目标响应互相补充，不能互相代替。
| 检查方法 | 预期现象 | 失败处理 |
|---|---|---|
| 查询指定监听的 A 与 AAAA | 答案符合实际策略 | 核对加载配置和解析错误 |
| 新连接重复原应用任务 | 资源按记录路径可用 | 撤销变更并比较应用 DNS |
| 请求自有本地服务 | 服务身份与管理仍可达 | 恢复本地 DNS 和窄例外 |
| 只查本次流量日志 | 域名与出站符合预期规则 | 核对捕获和映射归属 |
| 从配置所有者重新打开 | 预期设置确实保留 | 先修持久化再保留变更 |
实验同时改变互联网出口时，核对这一请求的可见 IP，另测 DNS、IPv6 和失败行为。IP 页面只描述自己的请求，不代表所有应用；不要据此声称匿名、提速或完整覆盖。
步骤 6：恢复配置与本次缓存状态
通过原配置所有者加载保存的旧配置，恢复本次刻意调整的解析器或应用 DNS 设置，关闭测试连接。若未决定保留，移除本次添加的例外。
应用支持按范围清理时，只清测试相关记录；不能选择性清理时，等待文档规定的过期时间，或采用隔离测试配置，不删除共享状态。恢复后确认原答案类别、本地服务和管理连接。
删除临时详细日志，保护要保留的诊断记录；含代理凭证的备份也是敏感文件。恢复无法确认就停止后续变更，使用独立管理通道，不以关闭防火墙或另一代理补救。
总结
- 先确认解析器与捕获路径，再比较地址模式。
- 测试模式或准确例外时，保持上游策略不变。
- 用新连接核对原应用与本地服务。
- 恢复配置和测试缓存后，再开展下一项实验。
常见问题
Fake-IP 答案是否代表 DNS 被劫持？
应用使用你配置的 Mihomo DNS 时，合成答案可能是预期行为。应先核对解析器归属和实际策略，再判断是否存在恶意干预。
Redir-Host 是否总是兼容性更好？
应用无法处理合成目标时，Redir-Host 可能有帮助，但兼容性仍取决于解析、捕获和路由。应比较故障任务，不设通用赢家。
fake-ip-filter 能修复所有本地名称吗？
过滤器只改变合成地址处理，不会提供权威本地记录。保留适当的局域网解析器与路由，并验证具体服务身份。
为什么 dig 和浏览器结果不一样？
浏览器可能自带加密解析器或复用已有连接。应对照其实际 DNS 设置建立新请求，而不是把直接查询当成浏览器路径证据。
是否应该关闭 IPv6 简化测试？
不要把关闭 IPv6 当通用修复。记录 A、AAAA 和实际 IPv6 路由；没有 AAAA 答案也不能证明每个应用怎样连接。
服务器可以放行 Fake-IP 网段通过 SSRF 检查吗？
桌面代理映射不能让特殊用途地址变成安全服务器目标。保留目标校验和可信服务器解析路径，不对整个网段设置例外。
换模式后必须清空所有缓存吗？
通过文档支持的控制刷新测试连接与对应缓存即可。无法按范围清理时等待过期或隔离测试，不破坏共享应用状态。
免责声明：流程依据文末官方资料设计，未声明作者完整部署或兼容实测。仅在获授权且有恢复路径的环境操作。
来源:
- Mihomo — DNS configuration — https://wiki.metacubex.one/config/dns/
- Mihomo — DNS resolution process — https://wiki.metacubex.one/config/dns/diagram/
- Mihomo — v1.19.32 configuration source — https://github.com/MetaCubeX/mihomo/blob/v1.19.32/config/config.go
Sources checked 2026 年 10 月 11 日。
延伸阅读:
