Mihomo dns-hijack 配置教程：TUN 模式写法与排错
简答：Mihomo 的 dns-hijack 写在顶层 tun 配置下，用于把匹配到的 DNS 请求转交给 Mihomo 内置 DNS 模块。先启用 TUN、配置 dns.enable，再从 - any:53 和 - tcp://any:53 开始；Windows 通常需要 strict-route，Linux 的相关场景需要 auto-redirect，Android 还要检查 Private DNS 是否关闭。
定义：dns-hijack 是 Mihomo TUN 配置中的 DNS 接管规则，用于将匹配到的 DNS 连接重定向到 Mihomo 的内部 DNS 模块，而不是单独定义一个上游 DNS 服务器。
先试这一步：最小配置、位置和校验顺序
如果你的目标只是让 TUN 模式先接管常见 DNS 请求，可以先在现有配置中确认或补齐以下结构。这里是配置骨架，不是包含节点、代理组和规则的完整成品；其中的上游 DNS、代理节点和客户端启动方式仍应以你的实际配置为准。
最小结构：dns: 下启用内置 DNS，tun: 下配置 DNS 接管：
dns: enable: true listen: 0.0.0.0:1053 enhanced-mode: fake-ip
tun: enable: true auto-route: true strict-route: true dns-hijack: - any:53 - tcp://any:53
实际 YAML 必须保持缩进和列表格式。官方 TUN 示例把 dns-hijack 放在 tun 下，并展示了 any:53 与 tcp://any:53 两种写法；官方 DNS 文档则将 dns.enable、listen 和 enhanced-mode 作为 DNS 模块配置项。可先查看 mihomo TUN 配置文档 与 mihomo DNS 配置文档。
| 检查项 | 正确方向 | 常见错误 |
|---|---|---|
| 配置层级 | dns-hijack 位于顶层 tun 下 | 把它写进 dns 下 |
| DNS 模块 | dns.enable: true，并有可用的 nameserver 或其他上游设置 | 只写劫持规则，没有启用 DNS 模块 |
| 协议 | 先用 any:53，需要明确 TCP 时再加 tcp://any:53 | 把 TCP 写成普通 UDP 地址或混用无效格式 |
| 路由前提 | Windows 关注 strict-route，Linux 关注 auto-redirect | 只打开 TUN，不检查系统路由与权限 |
| 配置校验 | 使用客户端提供的配置检查功能，或按当前核心版本执行测试命令 | 只看界面显示“已启动”，不看日志 |
dns-hijack、dns-mode 和 DNS 上游分别做什么
dns-hijack 解决的是“哪些 DNS 连接要被转交给内部 DNS 模块”；dns.enable 决定内部 DNS 模块是否启用；dns.listen 决定该模块监听的地址和端口；nameserver、fallback、nameserver-policy 才负责指定或分配上游解析路径。它们不是同一个字段，不能用填写上游 DNS 来替代 DNS 接管。
在 TUN 文档中，dns-mode 的 disabled、native 和 hijack 分别对应不同的系统 DNS 配置行为。文档还说明，hijack 会在 native 基础上拦截其他接口发往 53 端口的流量，并指出 Windows 需要 strict-route、Linux 需要 auto-redirect 才能满足相关条件。不要因为某个字段名称里有 hijack，就把所有 DNS 流量都视为已经被接管。
如果只使用 dns-hijack，没有同步配置可工作的内部 DNS，上层应用可能表现为“连接已建立但域名打不开”或日志出现解析失败。官方 DNS 文档说明，dns.listen 支持 UDP 和 TCP，enhanced-mode 可选 fake-ip 或 redir-host；具体选择要结合局域网域名、应用兼容性和现有规则核验。
any:53、udp://any:53、tcp://any:53 怎么选
| 写法 | 含义 | 适合怎样使用 |
|---|---|---|
any:53 | 未写协议时，官方文档说明默认按 UDP 处理 | 先覆盖常见 UDP DNS 请求，作为最短排查起点 |
udp://any:53 | 明确匹配 UDP 53 端口 | 希望配置含义更直观，或需要逐项排查时使用 |
tcp://any:53 | 匹配 TCP 53 端口 | 处理使用 TCP DNS 的应用或补充 UDP 规则 |
| 具体地址加端口 | 只匹配指定 DNS 地址的 53 端口 | 需要缩小匹配范围时使用，但必须严格检查 YAML 和 IPv6 格式 |
官方示例同时展示了 any:53 和 tcp://any:53。因此，常见的起步写法是同时覆盖 UDP 和 TCP，而不是把一个地址误认为同时代表两种协议。若你使用具体 IPv6 DNS 地址，必须按照当前核心文档和版本测试配置格式。曾有公开 issue 记录 IPv6 地址列表写法导致 YAML 解析错误的案例，例如方括号、引号和列表缩进不正确时，问题可能发生在配置解析阶段，而不是网络连通阶段；可参考 mihomo 的 IPv6 dns-hijack issue。
按平台启用：Windows、macOS、Linux、Android
Windows
- 先备份当前配置，并确认客户端以足够权限创建 TUN 接口。
- 在
tun下启用enable、auto-route和dns-hijack。 - 优先检查
strict-route: true。官方文档说明，Windows 相关 DNS 接管需要严格路由；它还用于增加防止系统多宿主 DNS 解析造成泄漏的防火墙规则。 - 启动后观察日志，先确认 TUN 创建成功，再确认 DNS 请求没有持续走原网络接口。
macOS
- 确认 TUN 设备名称符合当前客户端要求。官方文档说明，macOS 的设备名只能以
utun开头。 - 不要假设 macOS 会自动接管局域网 DNS。官方文档明确提示，Windows 和 macOS 不能自动劫持发往本地网络的 DNS 请求。
- 如果使用局域网域名、NAS 或打印机，先在
fake-ip-filter或相应的 DNS 策略中保留局域网域名，再单独验证公网域名。
Linux
- 启用
auto-route；需要自动配置 TCP 重定向时，再检查auto-redirect。 - 确认客户端具备修改路由、iptables 或 nftables 的权限。官方文档说明，
auto-redirect只适用于 Linux，并要求auto-route已启用。 - 如果使用
system或mixed协议栈，检查防火墙是否放行核心程序和 TUN 接口；不要未经判断直接清空防火墙规则。
Android
- 确认客户端已获得创建 VPN/TUN 所需权限。
- 检查系统的 Private DNS。官方文档说明，启用 Private DNS 时，DNS 请求不能被自动劫持。
- 如果启用了严格路由，先观察是否导致局域网设备不可访问，再决定是否加入局域网排除项。
- 不要把“手机本机能解析”推断为“热点共享设备也会被同样接管”；官方文档对 Android 的转发范围有单独限制。
从日志到命令：如何验证是否真的接管
验证应分成三层：配置能否加载、DNS 请求是否进入 Mihomo、应用是否能正常连接。只要其中一层失败，就不要直接把问题归因于节点或上游 DNS。
- 先做配置校验：使用客户端的“检查配置”功能，或使用当前 Mihomo 核心支持的配置测试命令。预期结果是 YAML 能被加载，不能出现缩进错误、字段类型错误或未知字段提示。
- 再看启动日志：确认 TUN 接口创建、路由设置和 DNS 模块启动成功。若日志显示权限不足、端口冲突或路由写入失败，应先处理这些本地问题。
- 检查解析结果：Windows 可使用
nslookup example.com；macOS、Linux 可使用dig example.com。命令成功只说明当前请求得到响应，不能单独证明所有程序都经过 Mihomo。 - 对比关闭 TUN：记录 TUN 开启和关闭时的 DNS 服务器、解析结果和日志变化。对比用于缩小范围，不应把单次结果当成完整泄漏证明。
- 检查绕过路径：浏览器的 Secure DNS/DoH、Android Private DNS、IPv6 DNS、路由器本地 DNS，以及局域网专用解析，都可能不符合普通 53 端口劫持的范围。逐项关闭或调整后再复测，并在复测完成后恢复原设置。
如果需要检查 DNS 泄漏，应同时检查 IPv4、IPv6、浏览器和系统解析路径。一个 dig 或 nslookup 命令通过，不等于浏览器、游戏、后台服务和局域网请求都遵循同一路径。
常见故障分流与恢复方法
| 现象 | 优先检查 | 恢复或修正 |
|---|---|---|
| 配置加载失败 | dns-hijack 层级、列表缩进、IPv6 地址格式 | 恢复上一份备份，先只保留 any:53，校验通过后再逐项添加 |
| TUN 已启动但域名打不开 | dns.enable、nameserver、DNS 监听端口和日志 | 暂时移除复杂的 policy/fallback，使用最小 DNS 配置验证内部模块 |
| Windows 仍出现 DNS 绕过 | strict-route、多网卡、系统防火墙和浏览器 DoH | 逐项关闭浏览器 Secure DNS，检查严格路由是否生效；完成测试后恢复需要保留的安全设置 |
| macOS 局域网域名失效 | 本地网络 DNS 不会自动被完全劫持，及 fake-ip-filter | 为局域网域名配置正确的过滤或策略，不要把所有局域网请求强制送往公网 DNS |
| Android 开启后仍走系统 DNS | Private DNS、VPN 权限和严格路由 | 关闭 Private DNS 后复测；若设备有管理策略，需以系统限制为准 |
| 启用后整体断网 | 路由循环、TUN 权限、DNS 上游无法访问、代理节点域名无法解析 | 关闭 TUN 并恢复备份，先验证普通网络，再只启用 DNS 模块和最小 TUN 选项 |
恢复时建议按“关闭 TUN—恢复备份—确认普通网络—逐项加回设置”的顺序操作。不要在无法确认影响范围时直接修改默认路由、清空防火墙规则或删除系统网络配置。
常见问题 FAQ
1. dns-hijack 应该写在 dns 下吗？
不应这样理解。按当前 Mihomo TUN 文档，dns-hijack 是 tun 下的配置项；dns.enable、listen、enhanced-mode 等才属于 dns 模块。写错层级时，可能出现未知字段、配置不生效或启动失败。
2. 只写 any:53 是否足够？
它适合覆盖常见 UDP DNS 请求，且官方文档说明未指定协议时默认使用 UDP。若应用使用 TCP 53，可补充 tcp://any:53。这仍不覆盖浏览器 DoH、Android Private DNS 或所有 IPv6/局域网解析路径。
3. dns-hijack 开启后，为什么 DNS 泄漏检查仍可能显示异常？
DNS 接管通常针对匹配到的连接，不能自动覆盖所有加密 DNS、Private DNS、多网卡策略或 IPv6 路径。应按平台分别检查浏览器 Secure DNS、系统 Private DNS、IPv6 和路由器 DNS，并结合日志与关闭对比复测。
4. fake-ip 和 redir-host 会影响 dns-hijack 吗？
它们都属于 Mihomo DNS 的处理模式，不等同于 DNS 接管规则。官方 DNS 文档列出两种增强模式，并说明 fake-ip-filter 可让特定域名不返回 fake IP。局域网域名、设备发现和部分应用兼容性异常时，应优先检查过滤列表，而不是盲目更换所有 DNS 上游。
5. Windows、macOS、Linux、Android 可以完全共用一份 TUN 配置吗？
不能直接假设完全通用。官方文档对 strict-route、auto-redirect、macOS 的 utun 设备名以及 Android Private DNS 都有平台差异说明。建议保留一份基础配置，再按平台调整权限、路由和系统 DNS 设置。
资料与核验范围
本文按 2026-10-28 检索到的 Mihomo 文档整理。配置字段、平台行为和客户端菜单可能随核心或衍生客户端版本变化；如果客户端内置核心版本不同，应以该版本的有效配置检查结果和运行日志为准。本文只说明配置与排查方法，不据此判断某个节点、线路或服务的稳定性。
本站是第三方使用指南站，不是 Mihomo 官方站。涉及具体客户端封装、权限开关或菜单名称时，请以当前客户端说明和实际日志为准。
常见问题
dns-hijack 应该写在 dns 下吗？
不应这样写。按当前 Mihomo TUN 文档，dns-hijack 位于 tun 下；dns.enable、listen 和 enhanced-mode 才属于 dns 模块。
只写 any:53 是否足够？
它适合覆盖常见 UDP DNS 请求。若应用使用 TCP 53，可补充 tcp://any:53，但浏览器 DoH、Android Private DNS 和部分 IPv6 路径仍需单独检查。
dns-hijack 开启后为什么仍可能出现 DNS 泄漏？
因为加密 DNS、Private DNS、多网卡、IPv6 或局域网解析可能绕过普通 53 端口规则，应按平台逐项复测。
fake-ip 和 redir-host 会影响 dns-hijack 吗？
它们是 DNS 处理模式，不是接管规则。局域网域名或应用兼容性异常时，应检查 fake-ip-filter 和相关 DNS 策略。
不同系统能否直接共用一份配置？
不能假设完全通用。Windows、macOS、Linux 和 Android 在路由、权限、TUN 设备名及系统 DNS 方面存在差异。