sing-box DNS 泄漏怎么排查？按 TUN、规则和上游逐层定位

更新于 2026-11-03 · dragonvpn.buzz

简答：先把问题拆成三层：检测站看到的解析器、sing-box 是否真正接管 DNS 请求、上游 DNS 是否按预期经过指定出站。最短路径是先运行 sing-box check，再确认 TUN 的 DNS 模式和 53 端口接管，随后看日志、用 dig 或 nslookup 复测；检测站结果不能单独证明某个代理节点正在解析。

定义：DNS 泄漏是应用或系统的 DNS 查询没有按预期进入 sing-box，而是由本地网络、系统 DNS 或应用自己的加密 DNS 直接发出；它不同于真实 IP 泄漏、DNS 污染和 WebRTC 泄漏。

先试这一步：用五分钟判断问题在哪一层

本文是面向 sing-box 使用者的第三方排查指南，核验日期为 2026-11-03。不同图形客户端的按钮名称、权限提示和 TUN 实现可能不同，因此以下步骤优先使用 sing-box 官方配置结构与命令；客户端界面找不到对应选项时，以当前客户端显示为准。

现象	优先检查	不要直接下的结论
检测站显示本地运营商或路由器 DNS	TUN 是否运行、DNS 模式是否启用、53 端口是否被接管	不能仅凭一次检测断定所有应用都泄漏
检测站显示公共 DNS，但仍不放心	查看 sing-box 日志、系统 DNS、应用独立 DNS 和抓包	公共 DNS 不等于请求一定经过代理出站
sing-box 能启动，但域名打不开	检查 DNS server 类型、final、规则 action 和上游连接	不要把 `ipv4_only` 当成完整的 IPv6 防绕过方案
浏览器正常，命令行结果不同	分别测试系统解析、浏览器独立加密 DNS 和 TUN 流量	`nslookup` 或 `dig` 不能代表所有应用

官方配置入口使用 JSON，配置根结构包括 dns、inbounds、outbounds 和 route；可先查看官方配置总览，再对照官方 DNS 配置。

第一层：先确认“检测到的异常”是不是 DNS 泄漏

打开一个你信任的 DNS 泄漏检测页面，在 sing-box 已连接和未连接两种状态下各测试一次。记录检测页面显示的解析器名称、IP、测试时间，以及系统网络是否发生切换。不要只截图结果，最好同时记录 sing-box 当前版本、运行模式和配置文件是否刚刚修改。

DNS 泄漏：重点看 DNS 查询是否绕过了 sing-box 预期路径。
DNS 污染：重点看返回地址或记录是否异常，原因可能在解析结果、缓存、规则或上游，不等于查询一定泄漏。
真实 IP 泄漏：重点看应用连接使用的公网地址，不能用 DNS 检测结果替代判断。
WebRTC 泄漏：属于浏览器通信行为，不能用 sing-box DNS 日志单独证明已经解决。

检测站通常只能展示它观察到的解析器，不能凭显示结果证明解析请求一定来自某个代理节点。因此，检测结果只负责提出线索，后续必须结合配置、日志和本机网络观察。

如果两次检测结果完全相同，先不要急着改 DNS 地址：继续执行下一层，确认 sing-box 是否真的接管请求。

第二层：校验版本、配置结构和实际生效文件

在实际运行 sing-box 的环境中查看版本。图形客户端通常会在核心或关于页面显示版本；命令行环境以当前安装方式提供的版本命令为准。不要把下载文件名或配置注释中的版本当成运行版本。
对正在使用的配置执行 sing-box check。官方配置总览明确列出了该校验命令；校验失败时先修复 JSON、字段类型和已废弃字段，再继续排查网络。
必要时使用 sing-box format -w -c 配置文件 -D 配置目录 整理格式，但先复制备份。该命令会改写文件，不要对唯一配置直接执行。
确认图形客户端实际加载的配置路径、远程配置更新时间和本地覆盖项。只修改磁盘上的另一份 JSON，可能不会改变正在运行的实例。

版本差异必须单独核对。官方 DNS 文档当前标注：independent_cache 在 sing-box 1.14.0 已废弃，并写明后续移除计划；发布前请按当前官方迁移文档再次确认，不要机械照抄旧教程。官方变更记录也显示 1.12.0 之后 DNS server 结构发生过迁移，旧字段与新字段不能混用。

本页不提供一份跨版本“万能配置”，因为出站类型、客户端版本、系统权限和 TUN 实现不同。重点是验证你正在运行的配置，而不是复制一段未经核验的完整 JSON。

第三层：检查 TUN 是否接管 DNS 请求

系统代理模式和 TUN 模式的接管范围不同。系统代理通常只影响遵循系统代理设置的应用；TUN 才是检查全局流量接管时的重点，但是否能接管 DNS 仍取决于 TUN 的 DNS 模式、系统权限、路由和平台实现。

确认 TUN 已启动，并观察客户端是否显示 VPN、虚拟网卡或系统网络扩展已获得授权。
检查 TUN 的 auto_route、DNS 模式和是否启用 DNS hijack。官方 TUN 文档说明，hijack 模式会在 native 基础上增加端口 53 接管；在部分系统上还存在平台和路由限制。
如果配置了 dns_address，确认它与实际 DNS server 地址一致。官方文档说明，设置该字段后，应使用 hijack-dns 路由动作处理发往这些地址的 DNS 流量。
暂时关闭其他 VPN、虚拟网卡、网络加速器或安全软件的 DNS 接管，再重启 sing-box 复测。一次只改变一个变量，避免无法判断是哪一层生效。

官方 TUN 说明尤其提示：不同平台对本机接口地址、端口 53、系统 DNS 和路由的处理并不完全相同。Linux、Windows、macOS、Android 和 iOS 的具体权限入口也可能不同，所以不要把某个平台的“私人 DNS”设置路径套用到其他平台。可先阅读官方 TUN 配置说明，再以客户端当前界面为准。

第四层：分清 DNS 规则、路由动作和上游 detour

DNS 规则的作用是决定查询匹配后采取什么动作；它不是普通路由规则的替代品。官方 DNS 规则文档显示，较新的配置应围绕规则匹配条件和 action 组织，旧版教程中把 protocol 或 hijack-dns 随意放进 dns.rules 的写法不能直接照抄。

看 DNS server：确认 server 有明确的 type 和 tag，例如官方支持的 HTTPS、TLS、TCP、UDP、local 等类型；具体参数以对应 server 文档为准。
看 final：它决定没有更具体规则命中时使用的 DNS server。为空时，官方文档说明会使用列表中的第一个 server。
看规则顺序：先匹配的规则可能改变后续处理。把测试域名放在明确、容易识别的位置，查看日志是否出现对应命中。
看上游连接：DNS server 的连接是否需要通过某个出站，取决于该 server 的拨号字段和配置方式；不能仅凭 server 名称推断“已经走代理”。
看路由动作：路由侧的 hijack-dns 用来处理被接管的 DNS 流量，不能把它当成 DNS 规则中的普通字段。

如果你看到“配置能启动但没有日志命中”，优先回滚最近新增的复杂规则，只保留已知可校验的 server、final 和基础 TUN 设置，再逐项加回。官方 DNS 规则和 DNS rule action 文档分别列出了字段结构与动作定义，建议对照 DNS Rule、DNS Rule Action 和 Route Rule Action。

第五层：用日志、命令和抓包确认请求路径

命令行结果只能说明该命令本身使用了什么解析路径，不能单独证明浏览器、游戏或其他应用没有泄漏。建议按下面顺序复测，并在每一步记录结果。

看 sing-box 日志：临时将日志级别调高到客户端支持的调试级别，重启或重新连接后，只测试一个域名。观察是否出现 DNS 查询、规则命中、上游连接失败或超时。日志配置字段可参考官方 Log 文档。
测试系统解析：Windows 可使用 nslookup example.com；macOS 或 Linux 可使用 dig example.com。将命令输出中的服务器地址、响应时间和结果与 sing-box 日志对照。
测试指定解析器：可用命令工具直接查询一个指定 DNS 地址，目的是比较不同路径，不是证明代理节点身份。若系统解析和指定解析器结果不同，先检查缓存、规则和网络切换。
抓包复核：在你有权限的设备上观察物理网卡是否出现明文 UDP/TCP 53 流量，以及 TUN 或虚拟网卡是否出现对应流量。Linux 可使用 tcpdump，Windows/macOS 可使用系统或图形抓包工具；仅抓自己的设备和网络。
再次打开检测页面：清理浏览器缓存或新建隐私窗口后复测，并记录 sing-box 日志时间。若检测站仍显示旧结果，先排除页面缓存和测试网络未切换。

如果命令行没有明文 53 流量，但浏览器检测仍异常，检查浏览器是否启用了独立加密 DNS；如果 IPv6 流量从物理网卡直接出现，则应检查 TUN 的 IPv6 地址、路由和系统网络栈。dns.strategy 只影响域名解析时的地址选择，不能单独证明 IPv6 流量已被接管。

按结果分流：通过条件、失败原因和回滚动作

观察结果	更可能的层级	下一步	回滚方式
`sing-box check` 失败	配置结构或版本兼容	按当前官方 schema 删除旧字段，逐段恢复	恢复校验通过的备份配置
TUN 未启动或无系统权限	客户端授权、系统扩展或虚拟网卡	重新授权并确认客户端状态，不先改 DNS server	关闭 TUN，回到原系统网络设置
明文 53 从物理网卡发出	DNS hijack、路由或其他软件接管失败	检查 TUN DNS 模式、`dns_address`、路由动作和冲突软件	撤销最近新增的 hijack 规则
请求被接管但上游超时	DNS server、出站或 detour	先用一个已确认可连接的上游做单变量测试，再恢复分流	恢复原上游与原出站关联
系统无明文 53，浏览器仍异常	浏览器或应用独立 DNS	暂时关闭独立加密 DNS后复测，再按隐私需求决定是否重新启用	恢复浏览器原设置
IPv6 直连而 IPv4 正常	IPv6 路由或 TUN 接管范围	检查 IPv6 TUN 地址、默认路由和物理网卡抓包	恢复系统 IPv6 设置，不用只改解析策略

排查完成的最低标准不是“检测站显示了某个公共 DNS”，而是：配置校验通过、TUN 状态明确、日志能看到预期处理、物理网卡没有不应出现的 DNS 请求，并且在关闭其他网络接管工具后复测结果稳定。无法观察到其中某一环时，应把结论写成“尚未确认”，不要写成“已经完全防漏”。

不同系统的最小入口

Windows：先确认客户端的 TUN/VPN 权限和虚拟适配器状态，再运行 nslookup；如果使用严格路由模式，观察端口 53 是否仍从其他接口发出。
macOS：确认网络扩展或 VPN 权限，使用 dig 对比连接前后结果；系统可能缓存或代理 DNS，因此命令结果需与 sing-box 日志和抓包一起看。
Linux：检查 TUN 接口、默认路由和本机解析服务；若使用 systemd-resolved 或本机监听地址，确认 DNS 请求是否确实进入 sing-box，而不是停留在本机解析器。
Android：确认 VPN 权限、TUN 状态和当前网络类型；系统设置中的私人 DNS、其他 VPN 和按应用分流可能改变结果，不能直接套用桌面系统步骤。
iOS：确认 VPN 配置授权、客户端的 TUN 状态和按应用设置；不要把 Android 的私人 DNS入口当作 iOS 的通用判断方法。

这些入口用于缩小范围，不代表所有设备都提供相同菜单。官方客户端页面会说明图形客户端的一般能力，例如当前核心版本显示和配置管理；具体按钮仍以你安装的客户端版本为准，可参考官方图形客户端说明。

一次可复制的排查记录模板

为了避免反复改配置，建议每次只记录以下内容，并删除订阅链接、私钥、访问令牌和服务器密码：

系统与网络：Windows、macOS、Linux、Android 或 iOS；Wi-Fi、蜂窝网络或有线网络。
sing-box 运行版本：从实际客户端或命令行读取，不凭配置文件名称填写。
运行模式：系统代理、TUN、按应用分流，以及是否同时运行其他 VPN。
校验结果：sing-box check 是否通过，报错字段是什么。
DNS 结构：server 的 type、tag，final，相关规则的 action，以及是否配置 dns_address。
复测结果：检测页面时间、dig 或 nslookup 输出、日志中的错误关键词和抓包是否看到明文 53。

不要公开完整配置中的密码、UUID、私钥、订阅地址或 API secret。若仍无法定位，先用最小配置复现，再逐项恢复规则和分流。

给需要稳定跨境办公连接的读者

如果你的问题不只是单台设备的 DNS 排查，还涉及办公网络、线路延迟、丢包或多终端连接，建议先把 DNS 接管、MTU、路由和实际链路分别记录，再根据业务系统的连接方式选择方案。

推荐：如果你需要进一步整理跨境办公场景的线路与网络排查，可了解边界云加速的相关服务，具体能力与当前信息以官网为准。

常见问题

sing-box DNS 泄漏检测显示公共 DNS，就能证明没有泄漏吗？

不能。检测站只能展示它观察到的解析器，不能单独证明请求经过了哪个出站，也不能覆盖所有应用。至少还要结合 sing-box 日志、系统解析命令和本机抓包复核。

sing-box 的系统代理模式可以防止所有 DNS 泄漏吗？

不能直接这样判断。系统代理通常只影响遵循代理设置的应用；是否覆盖 DNS，要看应用行为、系统解析服务和客户端实现。需要全局排查时，应确认 TUN 是否运行、DNS 模式是否启用以及端口 53 是否按预期接管。

把 dns.strategy 改成 ipv4_only，能解决 IPv6 DNS 泄漏吗？

不能单独解决。它主要影响解析时选择 IPv4 还是 IPv6 地址，不能证明 IPv6 数据流量已经经过 TUN。还要检查 TUN 的 IPv6 地址、路由表、系统网络栈和物理网卡抓包。

为什么 sing-box check 通过了，DNS 仍然可能泄漏？

check 主要验证配置结构和字段合法性，不能证明系统权限、TUN 状态、路由接管、上游连通性或浏览器独立 DNS 都符合预期。因此校验通过后仍需看运行日志并做实际复测。

浏览器开启加密 DNS，一定是 DNS 泄漏吗？

不一定。它说明浏览器可能使用独立于系统解析器的查询路径，但是否属于你要避免的路径，要结合你的网络目标和 sing-box 接管范围判断。可以暂时关闭后复测，用来确认它是否是造成结果差异的变量。

sing-box 1.14.0 的 independent_cache 应该怎么处理？

官方 DNS 文档目前将 independent_cache 标记为 1.14.0 废弃，并给出后续移除计划。不要从旧教程复制该字段；请按当前运行版本查看官方迁移文档，确认是否需要删除或改写，再运行 sing-box check。