sing-box DNS 怎么配置？服务器、策略与泄漏检查

更新于 2026-11-14 · xn--mesv7f5toqlp.shop

简答：sing-box DNS 配置的核心是先定义 servers，再用 rules 按域名选择服务器，最后用 final 指定默认服务器。建议先用 local + HTTPS/UDP 的最小配置验证，再决定是否让 DoH 通过 proxy 出站；TUN 场景还要检查 dns_mode、hijack-dns、IPv6 和系统自带 DoH。

定义：sing-box DNS 是由 servers、rules、final、strategy 等字段组成的解析模块，用来决定 DNS 请求发往哪个服务器，以及 DNS 服务器本身通过哪个路径连接。

先试这一步：复制最小 DNS 配置并检查语法

本文核对日期：2026-11-14。本文是第三方使用指南，不是任何客户端或服务的官方页面。sing-box 使用 JSON 配置，官方文档列出的 DNS 基本结构包括 servers、rules、final 和 strategy；其中 final 是默认 DNS 服务器标签，留空时使用第一个服务器。可先把下面片段合并到现有配置的 dns 段，再根据实际订阅和出站标签替换占位内容。参考sing-box DNS 配置文档与DNS Server 类型文档。

{ "dns": { "servers": [ { "type": "local", "tag": "local" }, { "type": "https", "tag": "doh", "server": "dns.example.com", "server_port": 443, "path": "/dns-query", "tls": {}, "domain_resolver": "local" } ], "rules": [ { "domain_suffix": [".lan", ".local"], "action": "route", "server": "local" } ], "final": "doh", "strategy": "prefer_ipv4" } }

必须替换：dns.example.com 只是占位域名，不能直接作为真实 DNS 服务使用。
域名服务器注意：官方文档要求 DNS Server 的 server 使用域名时配置 domain_resolver；这里用 local 解析 DNS 服务器自身的域名。
检查命令：在配置文件所在目录执行 sing-box check -c config.json。如果当前核心不接受 -c，先执行 sing-box check --help，按本机版本显示的参数改写。
预期结果：检查通过后不应出现 JSON 解析错误、unknown field、missing required field 或 unknown DNS server tag。
撤销方法：修改前先备份，例如 Linux/macOS 执行 cp config.json config.json.bak-2026-11-14，Windows PowerShell 执行 Copy-Item .\config.json .\config.json.bak-2026-11-14。

服务器怎么选：local、UDP、DoT、DoH 与 DoQ

服务器类型决定 DNS 请求使用的传输方式，不等于决定后续网页连接是否走代理。官方 DNS Server 文档列出 local、udp、tls、quic、https 和 h3 等类型。新配置应优先使用 1.12.0 之后的类型化写法；不要继续照搬旧式 address、address_resolver 和 detour 组合。

类型	适合场景	关键字段	排查重点
`local`	局域网域名、系统 DNS、启动阶段兜底	`type`、`tag`	系统 DNS 是否可靠，Android 和 macOS 的平台解析行为以当前客户端为准
`udp`	简单、低开销的 DNS 查询	`server`、`server_port`	UDP 53 是否可达，是否被系统或网络设备改写
`tls`	需要加密 DNS 查询的场景	`server`、`server_port`、`tls`	证书、服务端域名解析和 853 端口连通性
`https`	希望使用 HTTPS 传输 DNS 的场景	`server`、`path`、`tls`	DoH 路径是否正确，DNS 服务器域名是否能由 `domain_resolver` 解析
`quic`	已确认网络允许 DoQ 的场景	`server`、`tls`	UDP 853 是否被阻断；失败时先换 UDP、DoT 或 DoH 对照

例如，UDP DNS 的新写法是 type: udp、server 和可选的 server_port；DoT 使用 type: tls，DoH 使用 type: https、path 与 tls。官方说明还强调，新 DNS Server 使用 Dial Fields，域名解析字段是 domain_resolver，旧版的 address_resolver 不应继续套用到新格式。参考UDP DNS 文档、DoT 文档和DoH 文档。

不要把 local 填进 detour。local 是 DNS Server 标签，detour 需要引用出站标签；如果要让 DoH 通过代理连接，应填现有出站的标签，例如 proxy。节点服务器自身的域名解析则应在对应出站里使用 domain_resolver: local，不能混淆这两个字段。

策略怎么写：rules、final、detour 与节点域名解析

DNS 规则按配置顺序匹配，命中后执行 DNS Rule Action。常用的 route 动作会把 DNS 请求路由到指定的 DNS Server。最小分流骨架如下，规则集 URL 仅作占位，必须替换成已经核验格式和来源的规则集，不要把未知地址直接放进生产配置。

{ "dns": { "servers": [ {"type": "local", "tag": "local"}, { "type": "https", "tag": "remote-doh", "server": "dns.example.com", "path": "/dns-query", "tls": {}, "domain_resolver": "local", "detour": "proxy" } ], "rules": [ { "rule_set": ["local-domains"], "action": "route", "server": "local" }, { "action": "route", "server": "remote-doh" } ], "final": "remote-doh" }, "route": { "rule_set": [ { "type": "remote", "tag": "local-domains", "format": "binary", "url": "https://rules.example.com/local-domains.srs", "download_detour": "direct" } ], "default_domain_resolver": "local" } }

国内外或局域网分流：先在 route.rule_set 定义标签，再在 dns.rules 里用 rule_set 引用；只写引用而没有定义，通常会得到未知标签或规则不生效。
DoH 走代理：detour: proxy 中的 proxy 必须是现有出站标签。它不是 DNS Server 标签，也不是 local。
节点域名解析：在代理出站对象中添加 domain_resolver: local，或在 route.default_domain_resolver 中设置默认解析器。官方 Dial Fields 文档说明，detour 设置后会忽略其他 Dial Fields，因此具体出站结构要结合当前配置和核心版本核对。
规则集下载：官方 rule-set 文档显示，download_detour 在 1.14.0 已弃用，后续应迁移到 http_client；旧字段状态以当前 Migration/Deprecated 页面为准。

官方 DNS Rule 文档还显示，旧的 DNS 规则字段如直接写 server 已迁移到 DNS Rule Action；旧式 DNS outbound 在 1.11.0 弃用，官方页面写明 Legacy special outbounds 将在 1.13.0 移除。不要继续使用 {"type":"dns","tag":"dns-out"} 作为新配置的核心方案。参考DNS Rule 文档、DNS Rule Action 文档、Dial Fields 文档和Migration 文档。

TUN 模式怎么接管 DNS：dns_mode、hijack-dns 与 IPv6

只配置 dns 段，不代表 TUN 下所有应用都会使用 sing-box DNS。官方 TUN 文档显示，1.14.0 起可以使用 dns_mode：disabled 不配置原生 DNS 也不劫持 DNS，native 尽可能设置平台接口 DNS，hijack 在此基础上增加 53 端口劫持；当 auto_route 开启时，默认模式是 hijack，但仍应结合当前配置检查。

{ "inbounds": [ { "type": "tun", "tag": "tun-in", "address": ["172.19.0.1/30", "fdfe:dcba:9876::1/126"], "auto_route": true, "strict_route": true, "dns_mode": "hijack" } ], "route": { "rules": [ { "protocol": "dns", "action": "hijack-dns" } ], "auto_detect_interface": true, "final": "proxy" } }

Windows：strict_route 可用于阻止通过非 TUN 接口产生的 DNS 泄漏，但官方也提醒它可能影响部分应用；启用后用 nslookup example.com 和 sing-box 日志对照。
Linux：官方推荐在 auto_route 下使用 auto_redirect 改善路由和性能；需要管理员权限，修改前先备份 nftables 或防火墙配置。
macOS、iOS、Android：系统 VPN、平台 DNS、应用自带 DoH/DoT 的行为可能不同，不能只凭一个检测站判断全部流量；应结合客户端日志和关闭/开启 sing-box 的对照结果。
IPv6：如果只检查 IPv4，IPv6 可能绕过预期路径。可暂时把 strategy 改为 ipv4_only 做对照；确认 IPv6 路由、DNS 和 TUN 地址都可用后，再恢复原策略。

如果启用 TUN 后网页仍能打开但检测结果显示本地 DNS，先检查三项：TUN 是否真的接管默认路由、是否存在 hijack-dns 规则、系统或浏览器是否启用了独立的 DoH/DoT。恢复方法是关闭 TUN 或将 dns_mode 改回 disabled，然后重启客户端。

泄漏检查：关闭与开启 sing-box 做四组对照

DNS 泄漏检查不要只依赖在线检测站。更可靠的流程是先建立关闭 sing-box 时的基线，再开启 sing-box，分别检查配置、日志、本地端口和系统解析结果。检测站只能反映检测页面发出的请求，不能代表所有应用、系统服务和 IPv6 流量。

备份配置：复制当前配置文件，确认客户端实际加载的路径。Linux systemd 环境可执行 systemctl cat sing-box 查看服务启动参数；重启服务使用 sudo systemctl restart sing-box，日志使用 sudo journalctl -u sing-box --output cat -f。
检查配置：执行 sing-box check -c config.json。出现 unknown field 多半是字段版本不匹配；出现 unknown DNS server 或标签错误，重点检查 rules[].server、dns.final 与 servers[].tag 是否完全一致。
Windows 复测：执行 ipconfig /flushdns 清理缓存，再执行 nslookup example.com。对照 sing-box 日志，判定标准是请求命中预期 DNS Server 标签，且开启 TUN 后结果不再稳定指向未配置的本地 DNS。
Linux 复测：执行 dig example.com、resolvectl status；若没有 dig，可使用 nslookup example.com。检查 systemd-resolved 当前上游与 sing-box 配置是否一致。
macOS 复测：执行 scutil --dns 查看系统 DNS，再执行 dig example.com。如果系统 DNS 与客户端日志不同，不要立即判定为泄漏，要继续检查 TUN、应用自带解析和缓存。
Android/iOS 复测：使用客户端日志、系统 VPN 状态和检测站对照；系统没有统一可用的 shell 命令时，不要把某个应用显示的 DNS 结果当成全系统结论。
端口复核：Linux 可执行 sudo ss -lunpt | grep ':53'，Windows PowerShell 可执行 Get-NetUDPEndpoint -LocalPort 53。若没有监听并不一定是错误，TUN 的 hijack-dns 可能通过路由接管；应以日志和实际请求是否命中为准。

四组结果建议记录为：关闭 sing-box、开启系统代理、开启 TUN、关闭 TUN 但保留 DNS 配置。只有当开启模式下的请求命中预期规则、节点域名可以解析、网页和应用都能访问，并且 IPv4/IPv6 对照没有旁路，才可以认为当前配置通过了基本检查。不要公开完整订阅链接、节点凭据、完整日志或真实内网地址。

常见故障速查与回滚

现象	优先检查	处理方式
所有域名都解析失败	`dns.final` 是否引用存在的标签；DoH 域名是否能由 `domain_resolver` 解析	先改为 `local` 或已知可达的 UDP 服务器做对照，再逐项恢复
能解析但网页打不开	DNS 与实际出站是两条路径；检查 `route.final`、代理出站和节点服务器域名解析	在代理出站中添加 `domain_resolver: local`，不要把 `local` 填进 `detour`
部分域名失败	规则顺序、`domain_suffix`、规则集标签和 IPv6	暂时删除分流规则，只保留 `final`，确认基础 DNS 正常后再加规则
启动报 unknown field	旧版字段与当前核心不兼容	执行 `sing-box version` 和 `sing-box check --help`，按当前官方 Migration 页面迁移；不要猜字段
DoH 走代理后无法启动	`detour` 是否真的是出站标签；代理出站自身是否有域名解析依赖	先用 `detour: direct` 对照，节点域名解析交给 `domain_resolver: local`；确认直连后再恢复代理路径

回滚时停止 sing-box，恢复备份文件，再执行配置检查。Linux systemd 可使用 sudo systemctl stop sing-box、sudo cp /etc/sing-box/config.json.bak-2026-11-14 /etc/sing-box/config.json、sudo systemctl start sing-box；其中路径必须替换为服务实际使用的配置路径。Windows 或图形客户端则恢复配置文件后重新加载配置。旧版 DNS outbound、Legacy DNS Server 和旧 GeoIP/Geosite 写法的状态以当前官方Migration与Deprecated页面为准，不在未核实版本上继续套用。

常见问题

DoH 的 detour 应该写 proxy 还是 direct？

两者都可能正确，取决于你要验证的路径。若先做基础对照，建议使用现有出站标签 direct；若确认 DoH 要通过代理连接，则填写真实的代理出站标签，例如 proxy。不要填写 local，因为 local 是 DNS Server 标签，不是出站标签。节点服务器的域名解析应在代理出站中使用 domain_resolver: local。

sing-box DNS 配置里 final 和 rules 怎么配？

servers 先定义带 tag 的 DNS Server，rules 按顺序匹配域名或 rule_set，命中后使用 action: route 和 server 指定目标 DNS Server，final 再指定没有命中规则时使用的默认标签。最小排查时可以暂时删除 rules，只保留 final，确认基础解析正常后再恢复分流。

为什么 DNS 配置通过检查，但仍然出现泄漏？

sing-box check 只验证配置结构，不证明所有流量都经过 DNS 模块。还要检查 TUN 是否接管路由、是否有 hijack-dns 规则、Windows strict_route 或 Linux auto_redirect 是否符合当前场景，以及浏览器或应用是否启用了独立 DoH/DoT。开启与关闭 sing-box 做对照，并结合日志、系统 DNS 和 IPv6 结果判断。

FakeIP 要不要一起配置？

不建议在首次排障时同时引入 FakeIP。先用 local 或加密 DNS 验证 servers、rules、final、TUN 和出站路径，再根据具体客户端兼容性和应用需求评估 FakeIP。FakeIP 会改变应用看到的地址，出现部分应用打不开时应先回退到普通解析做对照。

旧版 dns outbound 还能继续使用吗？

官方 DNS outbound 页面显示该功能在 sing-box 1.11.0 弃用，并说明 Legacy special outbounds 将在 1.13.0 移除。实际是否还能运行取决于本机核心版本；新配置应优先迁移到 DNS Server、DNS Rule Action 和 domain_resolver，具体字段以当前 Migration/Deprecated 页面为准。