sing-box TUN 模式 DNS 不生效：配置与回环排查

更新于 2026-10-26 · netcli.net

简答：sing-box TUN 模式 DNS 不生效，最常见是 TUN 未接管、hijack-dns 规则未命中或默认路由回环。

定义：sing-box TUN 模式 DNS 不生效，是指 TUN 虚拟接口已启动，但 DNS 请求没有按预期进入 sing-box DNS 模块，表现为域名解析失败、timeout、规则未命中或仍由系统 DNS 处理。

先做三步速查：配置、劫持、绕过

本文更新于 2026 年 10 月 26 日。本站与 sing-box 项目无关联。遇到 TUN 模式 DNS 不生效，不要先反复更换 DNS 地址，按下面三步定位更快。

1. 配置能否启动：先使用当前版本支持的 sing-box check 检查配置；如果客户端提供配置校验按钮，也应查看完整错误信息。
2. DNS 是否命中劫持动作：确认 TUN 已启用，路由规则能够匹配 DNS 请求，并且使用了 action: hijack-dns。
3. 是否被绕过：分别检查默认路由回环、浏览器安全 DNS（DoH）、IPv6、其他 VPN 和虚拟网卡。

官方配置文档列出的配置检查命令是 sing-box check；命令行参数和图形客户端入口可能不同，实际以当前版本帮助信息和客户端界面为准。可查看 sing-box 配置文档。

dns_mode、dns_address 与 hijack-dns 怎么区分

这三个名称经常被混为一谈，但它们处在不同层级。根据 sing-box 当前官方 TUN 文档，dns_mode 是 TUN 接口的 DNS 处理方式，dns_address 是该模式使用的 DNS 地址列表，hijack-dns 则是路由规则动作，用于把 DNS 请求交给 sing-box DNS 模块。

当前官方文档明确写明，dns_address 是 DNS 服务器地址列表，因此不能把旧教程中单个地址的写法直接当成当前唯一格式。若你的客户端使用自己的配置封装或 schema，应以客户端生成的配置和 sing-box check 结果为准。详见 sing-box TUN 官方文档。

字段对照片段：只用于核对，不是完整可运行配置

下面是 TUN、DNS 处理和路由动作的字段对照片段，不包含完整 DNS 服务器、出站、认证和平台权限配置，因此不能直接复制后作为完整配置运行。它的用途是检查字段类型与层级，实际配置仍要补齐 dns、outbounds 等顶层内容。

{
  "inbounds": [
    {
      "type": "tun",
      "tag": "tun-in",
      "address": [
        "172.18.0.1/30"
      ],
      "dns_mode": "hijack",
      "dns_address": [
        "172.18.0.2"
      ],
      "auto_route": true
    }
  ],
  "route": {
    "auto_detect_interface": true,
    "rules": [
      {
        "action": "sniff"
      },
      {
        "protocol": "dns",
        "action": "hijack-dns"
      }
    ]
  }
}

这里的逻辑是：TUN 接口负责承载流量，dns_mode 决定接口层面的 DNS 处理方式，dns_address 给出地址列表，路由规则再通过 hijack-dns 将匹配到的 DNS 请求送入 sing-box DNS 模块。不能仅凭启用了 dns_mode: hijack 就断定所有应用的 DNS 都已经被接管。

如果启用了 dns_address，官方文档要求配置对应的 hijack-dns 路由规则。规则动作的官方说明见 sing-box 规则动作文档。

1.10.0、1.12.0、1.14.0 与 1.15.0 迁移重点

版本迁移时不要把不同字段变化合并成一个“DNS 语法变化”。官方资料对 TUN 字段和 DNS 服务器格式分别列出了变化，建议按实际运行版本逐项核对。

当前官方迁移资料明确覆盖 1.12.0 的 DNS 服务器格式和 1.15.0 的 TUN stack 迁移；关于 1.11.0，本文不把未经官方迁移页明确说明的 DNS 字段变化写成固定结论。遇到 1.11.0 配置问题，应以该版本实际 schema、配置检查输出和客户端生成文件为准。可查看 sing-box 官方迁移指南。

按症状排查回环、系统绕过与权限

官方 TUN 文档说明，Windows 启用 strict_route 时可阻止经由非 TUN 接口的 53 端口流量，但这不代表所有平台都必须开启，也不能解决浏览器 DoH。先确认实际症状，再做单变量测试。

若怀疑回环，先恢复为单个 TUN、单个默认接口和最少路由规则，确认基本 DNS 查询恢复后，再逐项加入 IPv6、其他虚拟网卡和复杂 DNS 分流。

Windows、macOS、Android 的导入、开启与验证

不同客户端界面名称可能不同，下面按平台给出通用的导入、开启、验证三步，不把某个图形客户端的按钮名称当作 sing-box 的统一界面。

Windows

1. 导入：导入本地 JSON 或客户端支持的远程配置，确认最终配置中仍有 type: tun、address、DNS 设置和 route rules。
2. 开启：启用 TUN 或服务模式；如系统要求网络适配器、管理员权限或防火墙授权，先完成授权。
3. 验证：使用 PowerShell 执行 Resolve-DnsName example.com，再查看客户端日志或命令行输出。

日志入口通常是客户端日志窗口、配置目录中的日志文件，或直接运行 Core 时的标准输出。可搜索 dns、hijack、timeout、route。

macOS

1. 导入：导入配置后，检查客户端是否重新生成配置，以及 TUN 规则动作是否仍存在。
2. 开启：启用 TUN 或网络扩展，并在系统设置中允许所需权限。命令行运行成功，不等于图形客户端已经获得系统接管权限。
3. 验证：执行 scutil --dns 查看 DNS 状态，再用 nslookup example.com 或 dig example.com 测试，同时查看客户端日志。

Android

1. 导入：导入 JSON 或客户端支持的配置，确认封装层没有删除 TUN 地址、DNS 模式或路由规则。
2. 开启：授权 VPN/TUN，关闭其他 VPN 或始终在线 VPN 后再测试。
3. 验证：在 Wi-Fi 和移动网络各测试一次，记录域名解析、DNS timeout、IPv4 和 IPv6 结果，并查看客户端运行日志。

三个平台都应记录 Core 版本、客户端版本、系统版本、网络类型、配置校验结果和复现时间。不同客户端的日志路径未统一，无法确认时优先使用客户端的“日志”“调试”或“运行记录”入口。

用日志和对照测试确认 DNS 是否真正生效

网页能打开不等于 DNS 已按预期工作。应使用相同域名、相同网络和相同命令做开关对照，并把 DNS、TCP、IPv4、IPv6 分开记录。

官方日志配置支持 trace、debug、info、warn、error、fatal 和 panic 等级。排查时可临时使用 debug，不建议长期保留高详细度日志。

{
  "log": {
    "disabled": false,
    "level": "debug",
    "timestamp": true
  }
}

1. 关闭 TUN，执行一次 nslookup example.com 或 Resolve-DnsName example.com，记录结果。
2. 开启 TUN，重复同一命令，比较是否成功、是否持续 timeout。
3. 查看日志是否出现 DNS 请求、hijack-dns、DNS 服务器连接失败或反复重试。
4. 暂时关闭浏览器 DoH，再用浏览器测试；若结果恢复，优先检查浏览器配置。
5. 分别进行 IPv4 与 IPv6 测试，确认是否只有某一协议栈绕过或失败。
6. 关闭其他 VPN、虚拟网卡和系统代理后重测，避免多个接管层互相影响。

可以使用下面的记录模板：

日期：2026-10-26
sing-box 版本：
客户端名称与版本：
系统与网络：
TUN：开 / 关
dns_mode：
dns_address：
auto_route：
auto_detect_interface：
route.rules：
浏览器 DoH：开 / 关
IPv4 解析：
IPv6 解析：
日志关键词：
结论：

日志配置字段可参考 sing-box 官方日志文档。如果配置校验通过但运行时仍失败，应把完整错误、版本、平台和最小复现配置一起保存，避免只根据单条日志猜测原因。

常见报错与排查顺序

• unknown field、类型错误：先确认 Core 版本和当前 schema，重点检查 dns_address 是否按当前官方结构写成地址列表，以及 address 是否为 TUN 前缀列表。
• DNS timeout：先查 TUN 是否接管，再查 auto_detect_interface、DNS 出站和回环，最后才调整超时。
• hijack-dns 未命中：检查 route rules 是否匹配 DNS 请求，并确认客户端没有把规则移动到其他配置区域。
• 配置成功但网页打不开：分离 DNS、TCP、UDP、IPv4 和 IPv6 测试，不要把全部连接问题都归因于 DNS。
• 平台开启失败：检查 Windows 管理员权限、macOS 网络扩展授权、Android VPN 权限及其他 VPN 冲突。

当前官方文档是字段定义和迁移判断的优先依据；第三方客户端可能增加自己的配置封装，不能仅凭界面名称判断 Core 最终收到的配置。

常见问题

sing-box TUN 模式 DNS 不生效，先改 dns_mode 还是 hijack-dns？

先确认配置能通过当前版本的检查，再查看 route rules 是否匹配 DNS 并执行 hijack-dns。dns_mode 是 TUN 接口的 DNS 处理方式，不能代替路由动作。

dns_address 应该写字符串还是数组？

当前官方 TUN 文档将 dns_address 定义为 DNS 服务器地址列表，官方结构示例使用数组。若客户端有自己的 schema，应以实际配置检查结果为准。

为什么已经写了 hijack-dns，DNS 仍然 timeout？

可能是 TUN 没有真正接管系统流量，也可能是默认路由形成回环或 DNS 出站不可达。先检查 auto_route、auto_detect_interface 和运行日志。

sing-box 1.10.0 的旧 TUN 配置还能直接用于 1.14.0 吗？

不能直接假定兼容。1.10.0 涉及 TUN 地址字段合并，1.12.0 涉及 DNS 服务器格式，1.14.0 增加 dns_mode 和 dns_address，应按迁移文档与当前 schema 逐项校验。

1.11.0 一定要把旧 DNS 出站改成 hijack-dns 吗？

不能仅凭版本号下结论。应查看实际配置、Core 版本和当前官方规则动作文档；不同客户端可能继续封装或转换旧配置，最终以校验结果和运行日志为准。

strict_route 是否必须开启才能避免 DNS 绕过？

不是所有环境都必须开启。官方 TUN 文档针对 Windows 说明了 strict_route 对非 TUN 接口 53 端口流量的限制，但它可能影响部分应用，应在出现对应症状时单独对照测试。

浏览器能打开网页，是否说明 sing-box DNS 已经生效？

不能仅凭网页打开判断。浏览器可能使用 DoH 或其他应用级解析路径，应结合命令行解析、客户端日志以及 IPv4 和 IPv6 对照测试。

macOS 命令行能运行，为什么图形客户端仍不接管 DNS？

命令行与图形客户端获得的系统权限可能不同。检查网络扩展授权、配置是否被客户端重写，以及是否存在其他 VPN 或虚拟网卡冲突。

如何判断问题是 DNS，而不是出站或线路？

先分别测试域名解析、IP 连接和 IPv4/IPv6。只有域名解析失败而 IP 连接正常时，才优先继续检查 DNS 规则；若 IP 连接也失败，应转查出站、路由或网络本身。

相关阅读

• TUN 模式开启后无法上网：驱动、路由与 DNS 排查
• TUN 模式开启后局域网断网：保留内网访问的配置思路
• 开启 IPv6 后节点频繁超时：双栈网络排障
• 多个代理客户端冲突：系统代理、端口与虚拟网卡治理
• sing-box Windows 服务开机后秒退：dhcp://auto DNS 排查

参考资料

1. sing-box 官方文档：TUN 入站
2. sing-box 官方文档：规则动作
3. sing-box 官方文档：迁移指南
4. sing-box 官方文档：配置、检查与格式化
5. sing-box 官方文档：日志配置