DHCP 与 DNS 分流

为什么要做分流

很多人以为 DHCP 就是自动分配地址、DNS 就是负责解析，开箱即用没什么好调。等家里设备多起来，问题就一个个冒头：智能电视经常拿到营销机顶盒的地址、DNS 被运营商劫持返回乱七八糟的结果、特定域名的解析慢得像拨号。分流要解决的就是这一类需求：让不同设备走不同的网络参数，让不同域名走不同的解析路径。

先说 DHCP 分流。典型场景有两类：一是给固定设备保留固定地址，NAS、打印机、智能家居网关这类东西重启后换 IP 会让各种客户端配置全部失效；二是把 IoT 设备隔离到专门的子网，限制它们访问内网其他机器。再说 DNS 分流：国内国外域名走不同上游、广告域名直接屏蔽、内网域名走本地解析。两者配合，家庭网络体验会产生质的飞跃。但它们都依赖同一个前提：你想清楚家里有哪些设备、要分几层，这一步功夫省不掉。

实施前提与子网规划

动手前先完成两件事：在路由器或 DHCP 服务器上导出现有设备列表（MAC 与作用），对照排一张表；再决定要不要划 VLAN。十台设备以下的小家庭，单子网加静态绑定就够了；设备超过三十台、或者有大量不明IoT 固件的场景，再考虑 VLAN 隔离。子网规划要与已有网段错开，避免日后并网时大规模改地址。

DHCP 分配实践

在 OpenWrt 这类软路由里，DHCP 服务通常带静态地址分配功能。把关键设备的 MAC 填进去，指定 IP，保存应用即可，设备重新获取地址后永久生效。几个细节值得注意：保留地址最好落在地址池范围之外，避免冲突；带 WiFi 的设备 MAC 可能随 MAC 地址随机化而变化，需要在设备端关掉随机或按设备的真实 MAC 绑定；租期默认几小时，大规模网络才需要调长。

地址池的大小要留足余量：来访者手机、平板、笔记本总会带来一堆新设备，地址池太小会在高峰期出现拿不到地址的情况。反过来地址池也别大大咧咧跨整个子网，给后续扩展留地方。一个常见错误是同时开两个 DHCP 服务器——主路由与一旁的旧 AP 都在分配地址，客户端时通时断，查起来非常烦人。记住一条铁律：一个广播域只能有一个 DHCP 服务器。

DNS 分流的上游设计

DNS 分流的核心是指派不同的上游解析器。家庭常见组合是：国内域名走运营商或国内公共 DNS，解析快且 CDN 结果准确；国外域名走可靠的公共解析；广告与追踪域名走黑洞直接拒绝。在 OpenWrt 上可以装 dnsmasq 的分流插件，或者直接用 AdGuard Home 做统一入口，在它的上游配置里写多条上游并按域名规则分组。AdGuard Home 本身就能做重写、过滤与分流三件事，部署一个顶过去好几个组件。

判断一个域名走哪条上游，可以按域名后缀建规则：以国内国际域名为主的解析交给近端服务器，其余默认走远端。规则越简单越好维护，千万别陷入一天加几十条规则的境地，维护成本会让整个方案活不过三个月。换种说法，分流规则的生命力在于克制：能用默认上游解决的就不要写规则，规则数量控制在二十条以内，每个季度清理一次失效条目，这套系统才能长期稳定地跑下去。规则文件建议放容器挂载的目录里用 git 管理，改错了一条，几秒内就能回滚滚回来。

部署 AdGuard Home

AdGuard Home 用 Docker 部署最省事，镜像拉下来映射两个端口就能跑：初始配置用 3000 端口，向导里设置管理密码与监听端口（建议 53 与 80），随后把主路由的 DHCP 下发 DNS 指向它即可。它的过滤规则由订阅列表提供，初次启用建议只开两三个主流列表，观察几天解析速度再决定加量。规则越多解析越慢，家庭场景几十万条的规则集得花在缓存上的功夫远多于收益。

更强的做法是设置上游的并行查询与超时时间：并行查询虽然让每次解析都打多个包，但可以显著降低首请求延迟。同时打开缓存乐观模式（cache_optimistic），对过期记录先返回旧值再后台刷新，体感会快很多。但要注意它对家庭 IoT 设备的兼容性——部分廉价设备的 DNS 客户端不按标准实现（不按 TTL 缓存），开启激进过滤后可能莫名失联，遇到这类设备就把它的 MAC 加入过滤白名单。

防污染与日常维护

DNS 分流的动机之一是解析结果被污染。国内常见的现象是某些域名解析到错误的 IP，导致访问缓慢或失败。两条实践建议：第一，分流规则要及时更新并定期 review，去年还有效的规则今年可能已经没意义；第二，不要过度依赖单一公共 DNS，家庭网络的关键路径最好留一个备用上游，主解析挂掉时能自动切换。DNS 故障的表现很迷惑：QQ 能上、网页打不开，遇到这种症状先查 DNS。

排查 DNS 问题的常用命令无非 nslookup 与 dig 两条，配合 AdGuard Home 自带的查询日志，绝大多数问题都能定位。查询日志是排查 DNS 的第一现场：打开 AdGuard Home 的日志页，输入打不开的域名，立刻能看到它走了哪条上游、返回了什么结果、是过滤规则拦的还是上游超时。比抓包与命令行逐层试要直观得多，值得在做任何变更前先看两眼日志确认现状。

家里有老人小孩的场景，DNS 过滤还能承担家长控制的角色：把游戏、短视频域名的列表整个屏蔽，DNS 层面的拦截对各类客户端都生效，App 嵌入的网页也跑不掉。不过要诚实说明，DNS 过滤是君子防线，懂行的人改个 DNS 就能绕过，真正的隔离还得靠 VLAN 与防火墙，别把两者混为一谈。

想深入理解 DNS 的工作原理与排查思路，可以参考 计算机网络入门 的相关章节。

从变更到故障：DNS 的运维节奏

DNS 变更需要一套小纪律：每次改动只动一处，观察一整天再下一处。原因在于 DNS 的故障有延迟性：客户端按 TTL 缓存记录，今天改的上游可能明天才在各种设备上表现异常，批量改动会让故障源不可辨识。改动记在一个小文件里（用 git 更好），就三列——日期、改了什么、为什么。出问题的时候这份记录就是排查地图。

DHCP 的变更同理但方向相反：它不会延迟暴露问题，而是直接在当场炸。改地址池或绑定后建议立刻拿一台设备释放重取地址验证，别等家人晚上回家才发现自己连不上 NAS。大规模改网段则提前规划两套并行（新旧池共存一周），给设备平滑迁移的时间。

智能音箱与摄像头这类设备的网络习惯也要留意：它们对 DHCP 租期到期后的续约行为千奇百怪，有的设备拿到地址后从不续约，租期到了直接断连而不是重新申请。遇到这种设备，要么把它的地址做成静态绑定（相当于延长租期到无限），要么把 DHCP 租期调到 24 小时以上。这类细节排查起来很消磨耐心，但解决一次就永久安静。

变更的心理节奏

最后给一组家用 DNS 的性能参照：本地的 AdGuard Home 缓存命中响应在 1 毫秒级、缺失要回上游约 20 至 80 毫秒；如果发现解析明显变慢，先怀疑过滤规则膨胀与上游超时，而非急着换解析器。把这几条节奏与参照内化，DHCP 与 DNS 分流就是一组安静可靠的基础设施，而不是三天两头要救火的服务。

这四项各自独立又彼此咬合：DNS 决定解析路径，DHCP 决定地址分配，过滤决定内容边界，通告决定客户端怎么找到它们。任何一项改动都建议在维护日志里记一行。家庭网络的好处是用户少、变更少，坏处也是用户少——出问题时没有别人帮你定位，全靠自己的记录。四项服务上线后的第一周多观察查询日志与 DHCP 租约列表，熟悉正常状态下的样子，异常才看得出来。

上线后的验收清单

分流体系上线后，逐项做一次验收：DNS 查询日志里广告域名的过滤命中率、各区域 DNS 上游分流规则的命中率、DHCP 静态绑定设备的地址稳定性、新设备入网时间的实测速度。四项都有可观测量，分流的收益才能被家人“看到”——家人们不懂技术，但他们知道家里的广告少了、打开网页快了。把验收结果记录成基线，每次调整后对照差距，这套系统就有了持续改进的闭环。

延伸阅读

• 计算机网络入门：DNS 协议与 DHCP 机制的来龙去脉，排错必备。
• SSH 远程登录与加固：软路由与 DNS 服务的命令行管理常用技能。