Pi-hole 这些年一直是自托管圈的“装完就忘”型选手。把路由器的 DHCP 指向它，剩下的交给它自己跑，基本不用天天盯着。但有个坑不少人会忘：面板只统计真正到达它的查询。设备只要把请求发给另一个 DNS 服务器，Pi-hole 这边就永远看不到。 对多数家庭网络来说这不算大事，真正让人翻车的是 IPv6。在路由器层面把它打开，设备就可能用上一个和 Pi-hole 毫无关系的 DNS，广告和追踪器于是从黑洞旁边直接走了过去。 IPv4 配得再完美，也可能白配 典型的 Pi-hole 部署里，一切都在 IPv4 上发生：路由器的 DHCP 服务器给每台设备发地址、网关，最关键的是指向 Pi-hole 的 DNS 地址。只要 DHCP 是设备获取 DNS 配置的唯一途径，这套逻辑就成立。 IPv6 一开，事情就复杂了。设备会通过路由器通告（Router Advertisements）自行配置，这类消息用来宣告网络前缀。路由器可以在里面用 RDNSS 选项带上一个 DNS 服务器，也可以通过 DHCPv6 发一个，或者两个都做。很多消费级路由器出厂就通告自己，地址常常是以 fe80 开头的链路本地地址。 于是每台设备可能同时握着两个解析器：IPv4 上的 Pi-hole，和 IPv6 上的路由器。麻烦在于没有任何机制告诉它哪个才算权威，怎么选基本看操作系统心情。发给路由器的查询会进入它内置的转发器，再交给它用的上游，全程没有任何过滤。Pi-hole 自己处理 IPv6 没问题，出问题的是查询走的那条路。 为什么只有部分设备溜过去 这种 DNS 请求泄漏很难被发现，因为各设备接收 IPv6 DNS 设置的方式不一样。Android 长期依赖 RDNSS 而不是 DHCPv6 来获取 IPv6 DNS 服务器。Windows 多年依赖 DHCPv6，在一次 Windows 10 更新后获得了 RDNSS 支持，但两者都收到时它仍然优先选 DHCPv6 提供的服务器。苹果的平台和各个 Linux 发行版各有各的行为，所以你用的是什么设备，直接决定了这事会不会被完全忽略。 路由器的 IPv6 设置也决定哪些设备会漏。TP-Link Archer 提供四种模式：ND Proxy、DHCPv6、SLAAC+无状态 DHCP、SLAAC+RDNSS。在只通过无状态 DHCPv6 下发 DNS 的模式下，Android 手机可能永远拿不到 IPv6 解析器、继续留在 Pi-hole 上，而 Windows 机器会改用路由器的。换成 RDNSS 模式，手机也会拿到路由器的解析器。 如果所有设备都绕过 Pi-hole，面板会安静下来，你立刻就能察觉。可当只有一部分设备这样，也就是大多数部分泄漏的情形，图表依旧一副健康模样——这正是让人栽跟头的地方。只有少数几台设备的行为和其余不同，光看面板根本不知道出了问题。 五分钟排查与收尾 先从 Pi-hole 的 Clients 视图看起，和你确认在网上的设备对一遍。发现少了谁，就去那台设备上查。Windows 跑 ipconfig /all ，macOS 跑 scutil --dns ，Linux 跑 resolvectl status ，都能列出正在使用的 DNS 服务器。如果 Pi-hole 地址旁边还坐着一个 fe80 地址或运营商 IPv6 解析器，泄漏的元凶就找到了。 最干净的修法是给 Pi-hole 一个稳定的 IPv6 地址，让路由器去通告它。另一种办法是：如果你根本没有任何 IPv6 服务在跑，直接在路由器层面关掉 IPv6，问题同样解决。 IPv6 不是唯一能绕过 IPv4 版 Pi-hole 的路径。DNS-over-HTTPS 这类功能也能穿过去，不过有些实现会检查拦截——Firefox 在这点上做得不错。Pi-hole 还会拦截苹果用来判断 iCloud 私密代理能否运行的域名，所以这条路也走不通。另有一些设备把公共解析器硬编码在系统里，处理起来会更麻烦一些。 特别
