北京
阻止广告侵入家庭的初衷，最后让我维护起两个DNS服务容器。这听起来像过度设计，但许多自托管用户都走过类似的路：从简单的全网广告拦截，一步步被好奇心拖进DNS隐私加密的深坑。我自己也没想到，一个试图让家人上网更清爽的决定，会让一台八年前的老笔记本负担起双容器接力的运维任务。
起因和多数家庭实验者一致——受不了每台设备单独装拦截插件。家里有超过十五台手机、平板和电脑，给每台设备配置浏览器级广告屏蔽实在太繁琐，而年长的家人常被弹窗广告误导。那时我的老旧笔记本上搭着勉强跑动的Docker环境，社区里几乎所有人都推荐Pi-hole作为起点。只需一条Docker命令，它就在双WAN网关上启动，扮演起DNS黑洞的角色，把广告域名解析时的请求统统吸收。初始目标极简：全网广告拦截，干净浏览。
Pi-hole完美完成了任务，九成以上的广告消失，且因为部署在网关，任何设备无需更改DNS设置就能受益。如果故事停在这里，那便是一个简单、有效的家庭网络升级案例。然而，日常管理时对DNS机制渐生好奇，促使我开始查阅隐私相关资料。一个事实击碎了我的平静：DNSSEC虽然能验证响应是否被篡改，但对查询内容本身不做任何加密。也就是说，所有离开我网络的DNS请求都以明文形式奔走，中间的网络节点可以随意旁观。
这个发现让我立刻转向加密上游解析器，而Pi-hole的设计初衷从未包含加密出站查询。于是，我引入了dnscrypt-proxy。Pi-hole仍担任过滤层，判断哪些域名要丢掉；dnscrypt-proxy则作为加密隧道，将请求封装后转发给Cloudflare和Quad9等公共解析器。逻辑上顺畅，但实际操作中，一个简单的广告拦截功能现在需要两个容器协作：一个负责拦截，一个负责加密。它们分别需要更新、记录日志和故障排查。
维护两套系统的负担是悄悄累积的。每天检查日志时，我得先看拦截统计，再核对加密连接情况；遇到解析失败，得从Pi-hole的界面追到dnscrypt-proxy的配置文件。虽然加密后的查询确实保护了浏览隐私，家庭网络的安全层级提高了，但运维复杂度翻倍。那个当初“不想搞DNS基础设施项目”的念头早已被推翻，我亲手把一个轻量拦截器改造成了双容器接力赛，每个环节各管半截任务。
这样的演进在自托管圈子并不少见。需求引出工具，工具又催生新需求：为了全家人的清爽体验部署Pi-hole，为了查询隐私追加dnscrypt-proxy。从单点广告过滤到加密出站流小型隐私工程，反映出的正是家庭用户从关注便利性到重视数据主权的普遍转变。虽然维护两个容器的代价正在增加，但在今天这个广告比正文还多的数字环境中，多一层保护似乎成了无法回头的理性选择。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
