树莓派Zero 2 W在树莓派家族里几乎是最不受待见的一块板子。相比树莓派5或树莓派4 Model B，它在内存和处理器上都没有明显升级，看起来毫无吸引力。但有人把它用成了整个家庭网络的核心——所有DNS请求都要经过它。 这块板子的定位本来很明确：适合入门学习，适合通过命令行或SSH和单板计算机打交道，也能跑几个轻量容器。作者的第一块单板计算机就是Zero 2 W，后来又买了一块，因为它在另一个用途上刚好合适。经过多年优化，它被用来跑Pi-hole，挡掉追踪、广告和公共DNS记录。 Pi-hole加Unbound，一套低需求的DNS组合 Pi-hole是一个免费、低负载的DNS黑洞。安装过程和普通单板计算机或迷你服务器一样直接，但作者没有选择直接安装软件包，而是用Docker部署。理由很实际：减少依赖冲突，维护起来方便，出问题时也更容易排查——容器闹脾气了，你仍然能进服务器处理。 Pi-hole的工作方式是建立一个DNS黑洞，拦截家庭设备的DNS请求，再用一份或多份屏蔽列表挡掉大部分广告和追踪手段。结果是多台设备都能获得更干净、更注重隐私的上网体验。但DNS查询仍然要经过谷歌或Cloudflare这类公共DNS提供商。 Unbound补上的正是这一环。它提供更安全的递归DNS解析，把广告和追踪交给Pi-hole处理，自己负责域名解析。这样DNS请求不再经过公共DNS提供商，而是由Unbound借助权威DNS服务器完成。多数用户部署Pi-hole时会忽略这个关键环节。 512MB内存怎么塞下这一切 关键在于从精简的操作系统开始。系统要轻量、支持良好、交互一致，作者的选择是DietPi，在x86系统上也是他的首选。它在Zero 2 W上占用约 70MB 内存，是目前见过的最低值。内置命令行工具是额外加分项，SSH进去后界面风格保持一致，折腾起来很顺手。 Zero 2 W会为GPU渲染预留一部分内存，留给实际部署的只有 410MB 。Docker再占去约 50MB ，剩下的空间对Pi-hole和Unbound来说仍然充裕。完成Unbound配置、部署两个容器之后，整套设置就能工作了。 要让树莓派真正接管DNS查询，还得改路由器设置。作者的Tenda路由器不算高级，开启了DHCP，所以只需把ISP的DNS地址改成树莓派的DNS地址即可。此后所有设备把请求发给路由器，路由器再转发给这套由Unbound和Pi-hole驱动的自定义DNS服务器。 即便如此，这块单板计算机仍有 40% 的空闲内存，意味着崩溃概率更低。还可以再装一个Tailscale，让它在Tailscale网络之外也能访问。不过作者没有让所有Tailnet设备都走Pi-hole——一旦Pi-hole出问题，新的DNS请求就过不去了。 故障时的兜底与自愈脚本 如果Pi-hole因为崩溃、设备故障或数据损坏而失效，备用DNS服务器就成了问题。有两种处理方式。第一种很简单：用公共DNS提供商，但这等于放弃了整套方案的意义。另一种是再搭一套Pi-hole和Unbound。由于路由器不保证会用哪一个，公共DNS服务器一旦被选中，广告拦截和隐私体验就没了。 理想情况下，这套设置不需要人工干预，直到Docker或板子本身出问题。可一旦出问题，而路由器里又没有配置备用DNS服务器，新网站就打不开了。这不是路由器的错——是你让它用Pi-hole，而Pi-hole此刻不工作。多数时候是服务卡住或Docker作怪，SSH进去再敲排查命令实在麻烦。 作者用一个自愈脚本接管了这些例行排查。脚本在后台按定时器运行，检查Pi-hole是否在运行、Unbound能否解析查询，比Docker自带的检查更细，还会测试网络连接。只有在多项检查失败时它才会重启设备，重启被留给长期存在的问题，而不是当作常规手段。没有这个脚本，一次故障就会让近十台设备断网。 一块性能偏弱的单板计算机，如今成了家庭网络的中心节点。DNS请求从它这里经过，不花一分钱就换来无广告的体验。这块板子现在不太好买，但如果你手头正好有一块在吃灰，它很适合拿来当Pi-hole设备。 特别