家里网络里挂一台 ESP32-C3 做 DNS 层面的去广告这个方案我前后用了小半年最大感受是真正决定这套东西好不好用的不是拦截列表有多大而是封禁设备、暂停拦截、自定义域名这三件日常操作顺不顺手。装好第一天你会觉得很神奇第二周开始你就会发现——孩子的新平板要单独放行、家里来客人要临时开一下、某个 App 的推送域名要精准掐掉这些全是边用边调的活儿。ESP32-C3 这块芯片只有单核 160MHz、400KB 左右的 SRAM跑一个精简的 DNS 过滤服务刚好够用也正因为资源紧它的功能设计反而逼着人把逻辑想清楚哪些是全局状态、哪些是每客户端状态、哪些是规则层的事。下面我按三大操作把踩过的坑和可以照抄的做法摊开讲适合已经把这套东西跑起来、正在琢磨怎么把它用顺手的人看。1. 三个操作背后其实是三层不同的东西很多人第一次打开管理页面会懵封禁设备、暂停拦截、自定义域名看着都是控制谁能访问什么为什么不能合并成一个开关我一开始也这么想直到有一次把暂停拦截当成了封禁设备的反向操作结果整晚有台设备在刷广告第二天查日志才发现自己搞错了作用域。搞清楚这三者的层级关系是后面所有操作不出错的前提。1.1 一次 DNS 请求要经过的四道关口把整个处理链路拆开看一个来自局域网的 DNS 查询到达 ESP32-C3 之后大致会走这么几关先是客户端识别从 UDP 包的源 IP 判断这是哪台设备然后是全局开关检查当前是否处于暂停状态接着是规则匹配拿域名去比拦截表和放行表最后是上游转发没被拦的查出去被拦的按配置返回。三个日常操作恰好各自对应其中的一环封禁设备改的是第一关的客户端状态粒度是这台机器影响它发出的所有查询。暂停拦截改的是第二关的全局或分组状态粒度是一段时间内和域名、设备都无关除非你做了分组。自定义域名改的是第三关的规则数据粒度和时间都无关是永久性的配置变更。这三层之所以不能合并是因为它们的生命周期完全不同。设备封禁通常跟着设备的接入状态走暂停拦截天然带倒计时自定义域名是写进 Flash 的持久配置。如果硬把它们塞进一个总开关你迟早会遇到我明明关掉了过滤为什么这台设备还是打不开网页这种问题——因为它的封禁状态还在生效。提示任何时候页面表现和预期不符先按客户端状态 → 全局状态 → 规则数据这个顺序逐层确认比漫无目的地翻日志快得多。1.2 三者在生效范围与持久化上的差异对照我把这三者的关键属性列了个表贴在备忘里排障时对着看基本不会走错方向维度封禁设备暂停拦截自定义域名作用对象单个客户端 IP关联 MAC全局或某个分组单个域名或域名后缀生效范围该设备的全部查询范围内全部设备、全部域名所有设备时间属性长期直到手动解除通常带倒计时永久直到手动删除存储位置RAM 可选NVSRAM 标志位 NVS 时间戳Flash 规则文件断电后表现视是否持久化而定需要靠时间戳恢复剩余时长完全保留典型误用想临时放行却去封了设备忘了暂停还在生效父域把子域一起带走了这张表里最容易被忽略的是断电后表现那一行。ESP32-C3 没有板载 RTC断电重启之后系统时间是从零开始的必须靠网络对时才能恢复。如果你在暂停拦截的实现里只存了一个remaining_seconds重启后这个值还在看上去没问题但如果你存的是结束时刻而时间还没同步上来那么比较逻辑就会得到一堆莫名其妙的负数。这个坑我在第三部分会详细讲。1.3 ESP32-C3 的资源约束反过来决定了功能该怎么做为什么要在意芯片规格因为它直接限制了你能不能用最直觉的做法。400KB SRAM 里Wi-Fi 协议栈和 lwIP 就要吃掉一大半留给 DNS 服务的堆空间通常在几十 KB 到一百多 KB 的量级。这意味着规则表不能无限大。常见家用路由器上那种几十万条的列表在这块芯片上塞不进去实际能舒服跑起来的量级通常是几万条域名而且要用紧凑的存储结构比如按域名倒序排列的前缀树或者哈希桶。不能靠删规则来实现暂停。把几万条规则从 Flash 读出来、清空、再写回去既慢又伤 Flash 擦写寿命ESP32-C3 的 Flash 擦写次数典型值是十万次量级天天这么干很快就到寿命了。所以暂停必须做成一个内存标志位匹配流程照走只是在命中后跳过拦截动作。不能给每个设备存一份完整规则副本。设备级的差异必须用一个轻量的状态表来表达比如一张最多存二三十条记录的客户端表。理解了这一层你会发现后面所有操作的奇怪设计其实都是被逼出来的合理选择。比如为什么暂停拦截只支持固定的几个时长档位而不是任意输入——因为省掉了一个文本输入解析和范围校验的代码路径在只有几百 KB 可用堆的情况下少一个分支就少一分崩溃风险。2. 封禁设备DNS 服务器眼里的设备到底长什么样这是三大操作里最容易想当然的一个。很多人以为在页面上点一下封禁路由器就知道是哪台机器了实际上 DNS 服务收到的 UDP 包里只有源 IP 地址没有任何设备标识。你看到的设备名、MAC 地址全都是系统额外维护的一张映射表查出来的。这个认知差异直接导致了后面一大半的排障问题。2.1 用 IP 当主键MAC 只是显示用的标签一个 DNS 查询到达时代码能拿到的就是源 IP 和源端口。所以设备封禁在实现上必然是一张IP → 状态的表。那 MAC 从哪来从 DHCP 租约表里关联。如果你的 ESP32-C3 同时还兼做 DHCP 服务器很多这类固件都这么干那它手上就有完整的租约信息谁在什么时间拿了哪个 IP、对应哪个 MAC。如果 DHCP 还是交给上游路由器做的那这块芯片就只能看到 IPMAC 需要靠 ARP 表或者干脆拿不到。这就引出一个很实际的问题封禁的稳定性取决于 IP 的稳定性。默认情况下 DHCP 租约到期续租客户端通常会拿到同一个 IP但这不是保证。设备断电几天再上线、或者局域网里设备数量变动都可能让 IP 漂移。漂移之后你封禁的就不是原来那台机器了。我的做法是两步走先在上游 DHCP或者这套固件自带的 DHCP 服务里给要做管控的设备建静态租约把 MAC 和 IP 绑死。再来做封禁此时封的是 IP但实质上等价于封了那台设备。如果懒得配静态租约还有个折中方案在封禁记录里同时存 IP 和 MAC匹配时以 IP 为主但每次命中后回查一下 ARP 表发现 MAC 对不上就自动失效这条规则并记一条日志。这个逻辑不复杂但能挡住大部分封错了人的尴尬。2.2 三种处理方式黑洞、拒绝、透传选错了会很麻烦确定要封某台设备之后还有个更细的选择封到什么程度。这三种做法我都试过体验差别很大处理方式DNS 返回设备侧表现适用场景黑洞返回 0.0.0.0A 记录指向 0.0.0.0连接超时页面一直转圈想让对方明确感知到被限制拒绝REFUSEDRCODE5部分系统会立刻报DNS 解析失败快速定位问题日志清晰不存在NXDOMAINRCODE3表现和域名真的不存在一样干扰最小适合长期静默限制完全透传正常上游结果完全不受过滤影响只想让它不过滤不想让它断网这里有个反直觉的点返回 NXDOMAIN 反而是最狠的一种。因为设备会认为这个域名真的不存在很多 App 的容错逻辑是域名解析失败就重试几次然后放弃用户体验上就是加载慢、功能缺失但不会报明确的错误用户也很难判断是网络问题还是别的原因。而返回 REFUSED 至少让客户端的系统日志里留下清晰痕迹你自己排障时也好定位。至于完全透传它和封禁其实是两种东西但很多固件把它们放在同一个设备列表里用状态区分这就很容易混淆。我的建议是如果你只是想让这台设备不受过滤影响比如工作用的机器某些开发域名被误拦了用透传如果是这台设备我不想让它上网比如孩子的平板在写作业时间那才用拒绝或 NXDOMAIN。2.3 操作流程与字段说明实际配置下来一个完整的封禁记录大概包含这么几个字段不同固件的字段名不一样但语义基本一致设备标识: living-room-tv IP 地址: 192.168.1.42 MAC 地址: aa:bb:cc:dd:ee:ff (可选用于校验) 处理方式: nxdomain | refused | blackhole | bypass 生效时段: 全天 | 自定义时间窗 备注: 电视开机广告注意如果固件支持生效时段一定要确认它用的是本地时间而不是 UTC。ESP32-C3 靠 SNTP 对时默认拿到的往往是 UTC如果你按 UTC 配了 22:00 到 06:00实际生效时间可能整整差出八小时这种错误排查起来非常费劲。配置完成之后怎么验证别急着去设备上开网页试先在局域网里用另一台机器做定向查询把源 IP 伪造是不现实的所以更靠谱的验证方式是在目标设备上执行一次查询或者干脆看服务端的实时日志——好的固件会打印来自 x.x.x.x 的查询 example.com → 命中客户端规则 → 返回 NXDOMAIN一眼就能确认规则生效了。2.4 封了没效果先排查客户端的 DNS 逃逸这是我踩得最深的一个坑。有一段时间我发现某台设备明明在封禁列表里广告却照刷。查了半小时服务端日志才反应过来这台设备压根没在往我这儿发查询。原因有三类都很常见系统级备用 DNS。有些设备在首选 DNS 超时或返回异常时会自动切换到网络里通告的备用 DNS或者干脆切到内置的公共 DNS。加密 DNS。较新的移动系统默认开启了加密解析查询直接走加密通道局域网里的明文 DNS 服务器完全看不到。应用内置解析。部分应用不调用系统解析器自己实现一套。排查方法很简单在服务端日志里按源 IP 过滤看这台设备到底有没有查询记录。如果一条都没有那问题不在过滤规则而在流量路径。此时要么在路由器层面做 DNS 重定向把 53 端口的出网流量劫持回本地要么在设备上手动关掉加密解析选项。实操心得做设备封禁之前先花两分钟确认这台设备确实在用我的 DNS能省掉后面一小时的困惑。日志里源 IP 出现频率就是最好的证据。2.5 解封与临时放行的正确姿势解封很简单把记录删掉或者把状态改回正常即可。但我更推荐的做法是保留记录、切换状态而不是直接删除。原因是你可能过几天又要封一次重新走一遍查 IP、查 MAC、填备注的流程很烦而且保留记录之后历史备注还在半年后你看到这条还能想起来当初为什么封它。临时放行则是另一个需求比如孩子的平板平时限制周末放开。这时候不要用暂停拦截因为暂停是全局的会把所有设备的过滤都关掉。正确做法是给这条封禁记录加一个时间窗或者干脆在需要的时候手动切状态。前者更省心后者更可控看你自己的习惯。3. 暂停拦截看起来最简单实际最容易出事暂停这个按钮是整套系统里点击率最高的也是最容易埋雷的。表面逻辑就一句话暂停期间不拦截到点自动恢复。但真要做到可靠需要处理的问题比想象中多——尤其是断电、重启、时间同步这几件事凑到一起的时候。3.1 三种粒度全局、分组、单域名别用错层级严格来说暂停拦截可以有三个粒度能力从大到小全局暂停所有设备、所有域名都不拦。适合的场景是我要排查某个网页打不开是不是被误拦了或者今天有重要会议任何异常都不能出。分组暂停只暂停某一类设备比如访客设备组。适合家里来了客人你不想让他们的设备受限制但自己的设备继续过滤。单域名放行严格说不算暂停是往放行表里加一条临时规则。适合就这一个网站要用其他继续拦。很多人一遇到问题就点全局暂停然后忘了恢复结果第二天发现广告全回来了还以为是固件出 bug。我的习惯是能用单域名放行解决的绝不用全局暂停。因为单域名放行的影响面最小事后也容易追溯——放行表里能看到你加了什么而全局暂停一旦过期就什么都不留。3.2 倒计时怎么存RAM 标志位 NVS 时间戳这是实现层面最有意思的部分也直接决定了你按下暂停后能不能放心走开。ESP32-C3 上millis()返回的是开机以来的毫秒数重启就归零。所以你不能只存一个还剩多少秒在 RAM 里——重启后这个值虽然还在如果存在 NVS 里但它对应的现在已经变了。正确的做法是存绝对时间戳暂停开始时刻: 1735689600 (Unix 时间戳来自 SNTP) 暂停时长: 1800 秒然后每次判断时用当前的 Unix 时间戳去减。这样即使中途重启只要重启后能重新对上时间剩余时长就自动算对了。但这里有个致命的边界情况如果重启后网络还没通、SNTP 还没同步当前时间戳是多少很多实现里这时候会返回 0 或者一个很小的值于是now - start变成一个大负数判断逻辑直接失效——要么永久暂停要么立即恢复全看你代码里怎么写的比较符。我遇到过最坑的一次是设备断电重启后自动恢复了拦截但界面上的倒计时还在正常走显示还剩 12 分钟。原因是界面读的是 NVS 里的旧值而实际匹配逻辑走的是另一条路径。这种界面和实际不一致的问题比功能直接失效更难发现。稳妥的写法是加一个状态机状态条件行为时间未同步SNTP 尚未成功过暂停状态按未知处理默认保持暂停宁松勿紧正常暂停中now start duration不拦截已过期now start duration恢复拦截清除标志位时钟回跳now start视为异常清除暂停状态并记日志时间未同步时默认保持暂停这个选择是我踩坑之后改的。原来的逻辑是默认恢复拦截结果有一次路由器重启ESP32-C3 比路由器先起来时间没同步上暂停状态被误判为已过期家里正在看的一个需要临时放行的页面直接挂了。改成宁松勿紧之后最坏情况是暂停时间比预期长一点需要手动点一下恢复但不会出现莫名其妙又拦上了的情况。3.3 排查网页打不开时的正确使用顺序暂停拦截最实用的场景其实不是我要看广告而是排障。一个页面打不开可能是 DNS 被拦、可能是网络本身有问题、可能是网站自己挂了。用暂停来二分定位顺序很重要先看服务端日志确认这个域名到底有没有被拦。有记录且命中拦截那基本可以确定是误拦。加一条单域名放行再刷新页面。好了说明就是这条规则的问题去放行表里留着它。如果加了放行还是不行再试全局暂停。这时候如果好了说明是别的域名也被拦了一个页面往往要加载十几个域名你只看到了主域名。全局暂停也不行那就不是过滤的问题了去查上游网络。这个顺序的价值在于每一步都在缩小范围而且每一步都有明确的判断依据。直接上全局暂停虽然快但你放弃了所有诊断信息事后什么也学不到。提示全局暂停期间记得看一眼日志里的未拦截记录数量。如果暂停 5 分钟内出现大量本该被拦的域名说明这台设备的日常流量里广告请求密度很高可以考虑针对性地把其中几个高频域名加进永久拦截表。3.4 暂停期间的缓存问题TTL 和负缓存还有一个很隐蔽的点DNS 结果会被客户端缓存。你在服务端暂停了拦截但设备上可能还存着之前被拦截的那个结果TTL 没到期就不会重新查询。表现出来就是我明明暂停了怎么还是打不开。解决思路有两个把拦截响应的 TTL 设得很短比如 30 秒甚至 10 秒。代价是客户端会更频繁地查询对这块小芯片来说是额外负载但 10 秒的 TTL 在家庭规模几十台设备下完全扛得住。接受现实暂停之后等一会儿再刷新或者手动清一下设备缓存。我选择的是前者把拦截响应的 TTL 设成 30 秒。这个值是个折中既不会让客户端缓存太久导致暂停失效也不会让查询频率高到影响性能。顺便说一句负缓存NXDOMAIN 的缓存也要注意有些系统对 NXDOMAIN 的缓存时间比普通记录更长这也是为什么我用 REFUSED 而不是 NXDOMAIN 做设备封禁——REFUSED 通常不会被长时间缓存。4. 自定义域名把通用列表调成自家的规则拦截列表再全也总有覆盖不到的地方。用了几个月之后你会发现真正让你烦的那几个广告位往往来自一些不太出名但很固定的域名。自定义域名这个功能就是干这个的——但它的坑主要集中在匹配规则和误伤上。4.1 放行优先于拦截这个顺序不能反所有规则匹配的第一原则放行表的优先级高于拦截表。也就是说哪怕一个域名同时出现在两张表里最终结果也应该是放行。这个设计的理由是拦截错了会导致功能不可用用户会立刻发现并抱怨放行错了只是多看到一个广告用户可能根本不在意。两者代价不对等所以优先保证能用。理解这一点之后很多奇怪现象就解释得通了。比如你手动把一个域名加进拦截表结果没生效——八成是它已经被某个上游列表的放行规则覆盖了或者它的父域在放行表里。实际操作中我建议自定义域名的时候分成两个独立的输入框而不是一个带前缀的文本框拦截域名: ads.example-a.com tracker.example-b.net 放行域名: api.example-c.com cdn.example-d.org分开填的好处是不容易手滑把方向搞反。我见过有人把要放行的域名填进了拦截框然后花了半天排查为什么这个网站打不开。4.2 匹配规则精确、后缀、通配符三种写法别混域名匹配的写法有好几种流派混用是出错的重灾区。常见的有这么几类写法含义匹配示例example.com精确匹配该域名只匹配example.com不含子域*.example.com匹配一级子域匹配a.example.com不匹配a.b.example.com.example.com匹配该域及其所有子域匹配example.com、a.example.com、a.b.example.comexample.com^最坑的是第一行和第三行的区别。很多固件为了省事把不带前缀的域名默认当成含所有子域来处理这在拦截场景下通常没问题多拦一点无所谓但在放行场景下就是灾难——你想放行api.example.com结果把整个example.com都放行了包括它的广告子域。我的经验是放行一律用精确匹配拦截才用后缀匹配。这样即使写错影响也是可控的。4.3 父域和子域一条规则可能带走一大片这是自定义域名最容易出事的地方。假设你把example.com整段拦了那么mail.example.com、pay.example.com、login.example.com全部一起被拦。有些网站的所有服务都挂在同一个主域下一拦全废。判断方法很简单加规则之前先想一想这个域名下面有没有你需要的服务如果不确定就先只用精确匹配拦最具体的那个子域。比如你要拦的是ads.example.com那就只写ads.example.com别图省事写成example.com。还有一种情况是看起来是子域其实不是。比如example.com.cn和example.com是两个完全不同的域名不同的注册主体后缀匹配example.com是不会误伤example.com.cn的因为域名匹配是按标签label边界对齐的不是简单的字符串包含。这一点倒是可以放心。但反过来如果你手写了一个简单的字符串contains判断那就真会误伤——所以匹配实现一定要按标签边界来。4.4 共享 CDN 域名这类绝对不能整段封有一类域名我建议列进永久放行白名单就是各大 CDN 和云服务的公共域名。原因很直接它们承载了几百上千个不同网站的资源。你把某个 CDN 域名封了可能顺手把几十个正常网站的图片、脚本全干掉了表现出来就是某些网站排版错乱、按钮点不了而且极难联想到是 DNS 拦截导致的。典型的判断依据是如果这个域名你在多个不相关的网站的服务端日志里都见过那它大概率是共享基础设施不能封。我在放行表里固定留了几条这类记录遇到页面样式异常时先检查它们有没有被误拦。顺带提一下 CNAME 的问题。有些广告域名的解析结果是 CNAME 到一个共享域名如果你只按最终解析结果匹配就会误伤共享域名如果只按查询的原始域名匹配又拦不到换了壳的变体。稳妥的做法是只按用户查询的原始域名做匹配不要去追踪 CNAME 链。追踪链看起来更聪明实际上在资源受限的设备上既费内存又容易误伤收益远小于风险。4.5 规则写入 Flash 的几个注意事项自定义域名最终要持久化到 Flash 里这里有几个实操层面的细节值得说别频繁写。ESP32-C3 板载 Flash 的擦写寿命是十万次量级听起来很多但如果你每次改配置都整块重写一年下来也可能上万次。好的做法是把规则攒一攒再写或者只写变更的那一页。注意分区大小。自定义规则和系统自带的拦截列表通常共享一个存储分区规则加多了会挤占空间。加之前看一眼剩余空间别等到写失败才发现。写入后要重载内存表。有些实现写完 Flash 就完事了内存里的规则表还是旧的得重启才生效。改完规则之后立刻做一次查询验证能立刻发现这个问题。注意规则数量上限。前面说过这块芯片的哈希表或前缀树是有容量上限的超出之后要么写入失败要么新规则被静默丢弃。界面上最好能显示已用 X / 上限 Y否则你会疑惑为什么加了规则没反应。实操心得我习惯在批量加规则之前先导出一次当前配置做备份。ESP32-C3 的配置分区一旦写坏恢复起来要么重新刷固件要么手工重建规则都挺麻烦。备份文件几十 KB存手机里就行。5. 把三个操作串起来几个真实场景的处理流程单独看每个操作都不难难的是遇到具体问题时快速判断该动哪一个。下面这几个场景是我这半年里反复遇到的处理流程可以直接照搬。5.1 智能电视的开机广告设备封禁 域名拦截组合用电视开机广告是最好解决的也是最容易解决的过头的一类。我的处理顺序是先只看不改跑两三天让日志把电视发出的所有 DNS 查询记下来。然后在日志里挑出那些明显是广告和推送的域名通常出现在开机后头 30 秒内且重复出现。把这些域名加进拦截表观察一周。如果还有残留再考虑对这台设备做更严格的管控。这里不建议一上来就封禁设备。因为电视除了广告还有系统更新、应用商店、投屏协议全封了会影响正常使用。设备封禁应该留给这台设备在规定时段内不该联网这种场景而不是用来治广告。5.2 家里来客人分组暂停而不是全局暂停客人设备接进来最省事的做法是给它们单独划一个分组然后对这个分组做不拦截策略。这样你的设备继续过滤客人的设备完全不受影响谁都不用折腾。如果没有分组功能退而求其次用全局暂停但要设一个明确的时长比如 4 小时。千万别选无限期——我干过一次忘了恢复一周后才发现家里的过滤全停了。5.3 固件升级前后的配置处理升级固件是唯一一个会把三个操作全部重置的场景所以流程要格外小心升级前导出配置包括设备列表、暂停状态如果有、自定义规则。升级后先别急着导入确认新固件的字段结构有没有变化。我就遇到过升级之后规则字段改名导入直接失败的。导入后做三项验证设备封禁是否还有效、暂停状态是否已清空升级后应该默认恢复、自定义规则条数对不对。观察一天日志确认没有异常的大量拦截或大量放行。这套流程走下来大概十分钟但能省掉后面几小时的困惑。尤其是暂停状态是否已清空这一项——如果旧固件里存了个很长的暂停时间戳新固件又正好用了不同的时间基准那可能会出现升级完过滤就失效了的情况而且界面上一点提示都没有。最后再分享一个小技巧不管哪个操作做完之后都用同一条命令验证一遍——在局域网里对某个已知的拦截域名做一次查询看返回结果对不对。这一条命令能同时验证规则加载、匹配逻辑、响应构造三个环节比在浏览器里刷半天页面高效得多。我现在改完任何配置都是先跑这一下确认没问题再去实际使用。
家里网络里挂一台 ESP32-C3 做 DNS 层面的去广告这个方案我前后用了小半年最大感受是真正决定这套东西好不好用的不是拦截列表有多大而是封禁设备、暂停拦截、自定义域名这三件日常操作顺不顺手。装好第一天你会觉得很神奇第二周开始你就会发现——孩子的新平板要单独放行、家里来客人要临时开一下、某个 App 的推送域名要精准掐掉这些全是边用边调的活儿。ESP32-C3 这块芯片只有单核 160MHz、400KB 左右的 SRAM跑一个精简的 DNS 过滤服务刚好够用也正因为资源紧它的功能设计反而逼着人把逻辑想清楚哪些是全局状态、哪些是每客户端状态、哪些是规则层的事。下面我按三大操作把踩过的坑和可以照抄的做法摊开讲适合已经把这套东西跑起来、正在琢磨怎么把它用顺手的人看。1. 三个操作背后其实是三层不同的东西很多人第一次打开管理页面会懵封禁设备、暂停拦截、自定义域名看着都是控制谁能访问什么为什么不能合并成一个开关我一开始也这么想直到有一次把暂停拦截当成了封禁设备的反向操作结果整晚有台设备在刷广告第二天查日志才发现自己搞错了作用域。搞清楚这三者的层级关系是后面所有操作不出错的前提。1.1 一次 DNS 请求要经过的四道关口把整个处理链路拆开看一个来自局域网的 DNS 查询到达 ESP32-C3 之后大致会走这么几关先是客户端识别从 UDP 包的源 IP 判断这是哪台设备然后是全局开关检查当前是否处于暂停状态接着是规则匹配拿域名去比拦截表和放行表最后是上游转发没被拦的查出去被拦的按配置返回。三个日常操作恰好各自对应其中的一环封禁设备改的是第一关的客户端状态粒度是这台机器影响它发出的所有查询。暂停拦截改的是第二关的全局或分组状态粒度是一段时间内和域名、设备都无关除非你做了分组。自定义域名改的是第三关的规则数据粒度和时间都无关是永久性的配置变更。这三层之所以不能合并是因为它们的生命周期完全不同。设备封禁通常跟着设备的接入状态走暂停拦截天然带倒计时自定义域名是写进 Flash 的持久配置。如果硬把它们塞进一个总开关你迟早会遇到我明明关掉了过滤为什么这台设备还是打不开网页这种问题——因为它的封禁状态还在生效。提示任何时候页面表现和预期不符先按客户端状态 → 全局状态 → 规则数据这个顺序逐层确认比漫无目的地翻日志快得多。1.2 三者在生效范围与持久化上的差异对照我把这三者的关键属性列了个表贴在备忘里排障时对着看基本不会走错方向维度封禁设备暂停拦截自定义域名作用对象单个客户端 IP关联 MAC全局或某个分组单个域名或域名后缀生效范围该设备的全部查询范围内全部设备、全部域名所有设备时间属性长期直到手动解除通常带倒计时永久直到手动删除存储位置RAM 可选NVSRAM 标志位 NVS 时间戳Flash 规则文件断电后表现视是否持久化而定需要靠时间戳恢复剩余时长完全保留典型误用想临时放行却去封了设备忘了暂停还在生效父域把子域一起带走了这张表里最容易被忽略的是断电后表现那一行。ESP32-C3 没有板载 RTC断电重启之后系统时间是从零开始的必须靠网络对时才能恢复。如果你在暂停拦截的实现里只存了一个remaining_seconds重启后这个值还在看上去没问题但如果你存的是结束时刻而时间还没同步上来那么比较逻辑就会得到一堆莫名其妙的负数。这个坑我在第三部分会详细讲。1.3 ESP32-C3 的资源约束反过来决定了功能该怎么做为什么要在意芯片规格因为它直接限制了你能不能用最直觉的做法。400KB SRAM 里Wi-Fi 协议栈和 lwIP 就要吃掉一大半留给 DNS 服务的堆空间通常在几十 KB 到一百多 KB 的量级。这意味着规则表不能无限大。常见家用路由器上那种几十万条的列表在这块芯片上塞不进去实际能舒服跑起来的量级通常是几万条域名而且要用紧凑的存储结构比如按域名倒序排列的前缀树或者哈希桶。不能靠删规则来实现暂停。把几万条规则从 Flash 读出来、清空、再写回去既慢又伤 Flash 擦写寿命ESP32-C3 的 Flash 擦写次数典型值是十万次量级天天这么干很快就到寿命了。所以暂停必须做成一个内存标志位匹配流程照走只是在命中后跳过拦截动作。不能给每个设备存一份完整规则副本。设备级的差异必须用一个轻量的状态表来表达比如一张最多存二三十条记录的客户端表。理解了这一层你会发现后面所有操作的奇怪设计其实都是被逼出来的合理选择。比如为什么暂停拦截只支持固定的几个时长档位而不是任意输入——因为省掉了一个文本输入解析和范围校验的代码路径在只有几百 KB 可用堆的情况下少一个分支就少一分崩溃风险。2. 封禁设备DNS 服务器眼里的设备到底长什么样这是三大操作里最容易想当然的一个。很多人以为在页面上点一下封禁路由器就知道是哪台机器了实际上 DNS 服务收到的 UDP 包里只有源 IP 地址没有任何设备标识。你看到的设备名、MAC 地址全都是系统额外维护的一张映射表查出来的。这个认知差异直接导致了后面一大半的排障问题。2.1 用 IP 当主键MAC 只是显示用的标签一个 DNS 查询到达时代码能拿到的就是源 IP 和源端口。所以设备封禁在实现上必然是一张IP → 状态的表。那 MAC 从哪来从 DHCP 租约表里关联。如果你的 ESP32-C3 同时还兼做 DHCP 服务器很多这类固件都这么干那它手上就有完整的租约信息谁在什么时间拿了哪个 IP、对应哪个 MAC。如果 DHCP 还是交给上游路由器做的那这块芯片就只能看到 IPMAC 需要靠 ARP 表或者干脆拿不到。这就引出一个很实际的问题封禁的稳定性取决于 IP 的稳定性。默认情况下 DHCP 租约到期续租客户端通常会拿到同一个 IP但这不是保证。设备断电几天再上线、或者局域网里设备数量变动都可能让 IP 漂移。漂移之后你封禁的就不是原来那台机器了。我的做法是两步走先在上游 DHCP或者这套固件自带的 DHCP 服务里给要做管控的设备建静态租约把 MAC 和 IP 绑死。再来做封禁此时封的是 IP但实质上等价于封了那台设备。如果懒得配静态租约还有个折中方案在封禁记录里同时存 IP 和 MAC匹配时以 IP 为主但每次命中后回查一下 ARP 表发现 MAC 对不上就自动失效这条规则并记一条日志。这个逻辑不复杂但能挡住大部分封错了人的尴尬。2.2 三种处理方式黑洞、拒绝、透传选错了会很麻烦确定要封某台设备之后还有个更细的选择封到什么程度。这三种做法我都试过体验差别很大处理方式DNS 返回设备侧表现适用场景黑洞返回 0.0.0.0A 记录指向 0.0.0.0连接超时页面一直转圈想让对方明确感知到被限制拒绝REFUSEDRCODE5部分系统会立刻报DNS 解析失败快速定位问题日志清晰不存在NXDOMAINRCODE3表现和域名真的不存在一样干扰最小适合长期静默限制完全透传正常上游结果完全不受过滤影响只想让它不过滤不想让它断网这里有个反直觉的点返回 NXDOMAIN 反而是最狠的一种。因为设备会认为这个域名真的不存在很多 App 的容错逻辑是域名解析失败就重试几次然后放弃用户体验上就是加载慢、功能缺失但不会报明确的错误用户也很难判断是网络问题还是别的原因。而返回 REFUSED 至少让客户端的系统日志里留下清晰痕迹你自己排障时也好定位。至于完全透传它和封禁其实是两种东西但很多固件把它们放在同一个设备列表里用状态区分这就很容易混淆。我的建议是如果你只是想让这台设备不受过滤影响比如工作用的机器某些开发域名被误拦了用透传如果是这台设备我不想让它上网比如孩子的平板在写作业时间那才用拒绝或 NXDOMAIN。2.3 操作流程与字段说明实际配置下来一个完整的封禁记录大概包含这么几个字段不同固件的字段名不一样但语义基本一致设备标识: living-room-tv IP 地址: 192.168.1.42 MAC 地址: aa:bb:cc:dd:ee:ff (可选用于校验) 处理方式: nxdomain | refused | blackhole | bypass 生效时段: 全天 | 自定义时间窗 备注: 电视开机广告注意如果固件支持生效时段一定要确认它用的是本地时间而不是 UTC。ESP32-C3 靠 SNTP 对时默认拿到的往往是 UTC如果你按 UTC 配了 22:00 到 06:00实际生效时间可能整整差出八小时这种错误排查起来非常费劲。配置完成之后怎么验证别急着去设备上开网页试先在局域网里用另一台机器做定向查询把源 IP 伪造是不现实的所以更靠谱的验证方式是在目标设备上执行一次查询或者干脆看服务端的实时日志——好的固件会打印来自 x.x.x.x 的查询 example.com → 命中客户端规则 → 返回 NXDOMAIN一眼就能确认规则生效了。2.4 封了没效果先排查客户端的 DNS 逃逸这是我踩得最深的一个坑。有一段时间我发现某台设备明明在封禁列表里广告却照刷。查了半小时服务端日志才反应过来这台设备压根没在往我这儿发查询。原因有三类都很常见系统级备用 DNS。有些设备在首选 DNS 超时或返回异常时会自动切换到网络里通告的备用 DNS或者干脆切到内置的公共 DNS。加密 DNS。较新的移动系统默认开启了加密解析查询直接走加密通道局域网里的明文 DNS 服务器完全看不到。应用内置解析。部分应用不调用系统解析器自己实现一套。排查方法很简单在服务端日志里按源 IP 过滤看这台设备到底有没有查询记录。如果一条都没有那问题不在过滤规则而在流量路径。此时要么在路由器层面做 DNS 重定向把 53 端口的出网流量劫持回本地要么在设备上手动关掉加密解析选项。实操心得做设备封禁之前先花两分钟确认这台设备确实在用我的 DNS能省掉后面一小时的困惑。日志里源 IP 出现频率就是最好的证据。2.5 解封与临时放行的正确姿势解封很简单把记录删掉或者把状态改回正常即可。但我更推荐的做法是保留记录、切换状态而不是直接删除。原因是你可能过几天又要封一次重新走一遍查 IP、查 MAC、填备注的流程很烦而且保留记录之后历史备注还在半年后你看到这条还能想起来当初为什么封它。临时放行则是另一个需求比如孩子的平板平时限制周末放开。这时候不要用暂停拦截因为暂停是全局的会把所有设备的过滤都关掉。正确做法是给这条封禁记录加一个时间窗或者干脆在需要的时候手动切状态。前者更省心后者更可控看你自己的习惯。3. 暂停拦截看起来最简单实际最容易出事暂停这个按钮是整套系统里点击率最高的也是最容易埋雷的。表面逻辑就一句话暂停期间不拦截到点自动恢复。但真要做到可靠需要处理的问题比想象中多——尤其是断电、重启、时间同步这几件事凑到一起的时候。3.1 三种粒度全局、分组、单域名别用错层级严格来说暂停拦截可以有三个粒度能力从大到小全局暂停所有设备、所有域名都不拦。适合的场景是我要排查某个网页打不开是不是被误拦了或者今天有重要会议任何异常都不能出。分组暂停只暂停某一类设备比如访客设备组。适合家里来了客人你不想让他们的设备受限制但自己的设备继续过滤。单域名放行严格说不算暂停是往放行表里加一条临时规则。适合就这一个网站要用其他继续拦。很多人一遇到问题就点全局暂停然后忘了恢复结果第二天发现广告全回来了还以为是固件出 bug。我的习惯是能用单域名放行解决的绝不用全局暂停。因为单域名放行的影响面最小事后也容易追溯——放行表里能看到你加了什么而全局暂停一旦过期就什么都不留。3.2 倒计时怎么存RAM 标志位 NVS 时间戳这是实现层面最有意思的部分也直接决定了你按下暂停后能不能放心走开。ESP32-C3 上millis()返回的是开机以来的毫秒数重启就归零。所以你不能只存一个还剩多少秒在 RAM 里——重启后这个值虽然还在如果存在 NVS 里但它对应的现在已经变了。正确的做法是存绝对时间戳暂停开始时刻: 1735689600 (Unix 时间戳来自 SNTP) 暂停时长: 1800 秒然后每次判断时用当前的 Unix 时间戳去减。这样即使中途重启只要重启后能重新对上时间剩余时长就自动算对了。但这里有个致命的边界情况如果重启后网络还没通、SNTP 还没同步当前时间戳是多少很多实现里这时候会返回 0 或者一个很小的值于是now - start变成一个大负数判断逻辑直接失效——要么永久暂停要么立即恢复全看你代码里怎么写的比较符。我遇到过最坑的一次是设备断电重启后自动恢复了拦截但界面上的倒计时还在正常走显示还剩 12 分钟。原因是界面读的是 NVS 里的旧值而实际匹配逻辑走的是另一条路径。这种界面和实际不一致的问题比功能直接失效更难发现。稳妥的写法是加一个状态机状态条件行为时间未同步SNTP 尚未成功过暂停状态按未知处理默认保持暂停宁松勿紧正常暂停中now start duration不拦截已过期now start duration恢复拦截清除标志位时钟回跳now start视为异常清除暂停状态并记日志时间未同步时默认保持暂停这个选择是我踩坑之后改的。原来的逻辑是默认恢复拦截结果有一次路由器重启ESP32-C3 比路由器先起来时间没同步上暂停状态被误判为已过期家里正在看的一个需要临时放行的页面直接挂了。改成宁松勿紧之后最坏情况是暂停时间比预期长一点需要手动点一下恢复但不会出现莫名其妙又拦上了的情况。3.3 排查网页打不开时的正确使用顺序暂停拦截最实用的场景其实不是我要看广告而是排障。一个页面打不开可能是 DNS 被拦、可能是网络本身有问题、可能是网站自己挂了。用暂停来二分定位顺序很重要先看服务端日志确认这个域名到底有没有被拦。有记录且命中拦截那基本可以确定是误拦。加一条单域名放行再刷新页面。好了说明就是这条规则的问题去放行表里留着它。如果加了放行还是不行再试全局暂停。这时候如果好了说明是别的域名也被拦了一个页面往往要加载十几个域名你只看到了主域名。全局暂停也不行那就不是过滤的问题了去查上游网络。这个顺序的价值在于每一步都在缩小范围而且每一步都有明确的判断依据。直接上全局暂停虽然快但你放弃了所有诊断信息事后什么也学不到。提示全局暂停期间记得看一眼日志里的未拦截记录数量。如果暂停 5 分钟内出现大量本该被拦的域名说明这台设备的日常流量里广告请求密度很高可以考虑针对性地把其中几个高频域名加进永久拦截表。3.4 暂停期间的缓存问题TTL 和负缓存还有一个很隐蔽的点DNS 结果会被客户端缓存。你在服务端暂停了拦截但设备上可能还存着之前被拦截的那个结果TTL 没到期就不会重新查询。表现出来就是我明明暂停了怎么还是打不开。解决思路有两个把拦截响应的 TTL 设得很短比如 30 秒甚至 10 秒。代价是客户端会更频繁地查询对这块小芯片来说是额外负载但 10 秒的 TTL 在家庭规模几十台设备下完全扛得住。接受现实暂停之后等一会儿再刷新或者手动清一下设备缓存。我选择的是前者把拦截响应的 TTL 设成 30 秒。这个值是个折中既不会让客户端缓存太久导致暂停失效也不会让查询频率高到影响性能。顺便说一句负缓存NXDOMAIN 的缓存也要注意有些系统对 NXDOMAIN 的缓存时间比普通记录更长这也是为什么我用 REFUSED 而不是 NXDOMAIN 做设备封禁——REFUSED 通常不会被长时间缓存。4. 自定义域名把通用列表调成自家的规则拦截列表再全也总有覆盖不到的地方。用了几个月之后你会发现真正让你烦的那几个广告位往往来自一些不太出名但很固定的域名。自定义域名这个功能就是干这个的——但它的坑主要集中在匹配规则和误伤上。4.1 放行优先于拦截这个顺序不能反所有规则匹配的第一原则放行表的优先级高于拦截表。也就是说哪怕一个域名同时出现在两张表里最终结果也应该是放行。这个设计的理由是拦截错了会导致功能不可用用户会立刻发现并抱怨放行错了只是多看到一个广告用户可能根本不在意。两者代价不对等所以优先保证能用。理解这一点之后很多奇怪现象就解释得通了。比如你手动把一个域名加进拦截表结果没生效——八成是它已经被某个上游列表的放行规则覆盖了或者它的父域在放行表里。实际操作中我建议自定义域名的时候分成两个独立的输入框而不是一个带前缀的文本框拦截域名: ads.example-a.com tracker.example-b.net 放行域名: api.example-c.com cdn.example-d.org分开填的好处是不容易手滑把方向搞反。我见过有人把要放行的域名填进了拦截框然后花了半天排查为什么这个网站打不开。4.2 匹配规则精确、后缀、通配符三种写法别混域名匹配的写法有好几种流派混用是出错的重灾区。常见的有这么几类写法含义匹配示例example.com精确匹配该域名只匹配example.com不含子域*.example.com匹配一级子域匹配a.example.com不匹配a.b.example.com.example.com匹配该域及其所有子域匹配example.com、a.example.com、a.b.example.comexample.com^最坑的是第一行和第三行的区别。很多固件为了省事把不带前缀的域名默认当成含所有子域来处理这在拦截场景下通常没问题多拦一点无所谓但在放行场景下就是灾难——你想放行api.example.com结果把整个example.com都放行了包括它的广告子域。我的经验是放行一律用精确匹配拦截才用后缀匹配。这样即使写错影响也是可控的。4.3 父域和子域一条规则可能带走一大片这是自定义域名最容易出事的地方。假设你把example.com整段拦了那么mail.example.com、pay.example.com、login.example.com全部一起被拦。有些网站的所有服务都挂在同一个主域下一拦全废。判断方法很简单加规则之前先想一想这个域名下面有没有你需要的服务如果不确定就先只用精确匹配拦最具体的那个子域。比如你要拦的是ads.example.com那就只写ads.example.com别图省事写成example.com。还有一种情况是看起来是子域其实不是。比如example.com.cn和example.com是两个完全不同的域名不同的注册主体后缀匹配example.com是不会误伤example.com.cn的因为域名匹配是按标签label边界对齐的不是简单的字符串包含。这一点倒是可以放心。但反过来如果你手写了一个简单的字符串contains判断那就真会误伤——所以匹配实现一定要按标签边界来。4.4 共享 CDN 域名这类绝对不能整段封有一类域名我建议列进永久放行白名单就是各大 CDN 和云服务的公共域名。原因很直接它们承载了几百上千个不同网站的资源。你把某个 CDN 域名封了可能顺手把几十个正常网站的图片、脚本全干掉了表现出来就是某些网站排版错乱、按钮点不了而且极难联想到是 DNS 拦截导致的。典型的判断依据是如果这个域名你在多个不相关的网站的服务端日志里都见过那它大概率是共享基础设施不能封。我在放行表里固定留了几条这类记录遇到页面样式异常时先检查它们有没有被误拦。顺带提一下 CNAME 的问题。有些广告域名的解析结果是 CNAME 到一个共享域名如果你只按最终解析结果匹配就会误伤共享域名如果只按查询的原始域名匹配又拦不到换了壳的变体。稳妥的做法是只按用户查询的原始域名做匹配不要去追踪 CNAME 链。追踪链看起来更聪明实际上在资源受限的设备上既费内存又容易误伤收益远小于风险。4.5 规则写入 Flash 的几个注意事项自定义域名最终要持久化到 Flash 里这里有几个实操层面的细节值得说别频繁写。ESP32-C3 板载 Flash 的擦写寿命是十万次量级听起来很多但如果你每次改配置都整块重写一年下来也可能上万次。好的做法是把规则攒一攒再写或者只写变更的那一页。注意分区大小。自定义规则和系统自带的拦截列表通常共享一个存储分区规则加多了会挤占空间。加之前看一眼剩余空间别等到写失败才发现。写入后要重载内存表。有些实现写完 Flash 就完事了内存里的规则表还是旧的得重启才生效。改完规则之后立刻做一次查询验证能立刻发现这个问题。注意规则数量上限。前面说过这块芯片的哈希表或前缀树是有容量上限的超出之后要么写入失败要么新规则被静默丢弃。界面上最好能显示已用 X / 上限 Y否则你会疑惑为什么加了规则没反应。实操心得我习惯在批量加规则之前先导出一次当前配置做备份。ESP32-C3 的配置分区一旦写坏恢复起来要么重新刷固件要么手工重建规则都挺麻烦。备份文件几十 KB存手机里就行。5. 把三个操作串起来几个真实场景的处理流程单独看每个操作都不难难的是遇到具体问题时快速判断该动哪一个。下面这几个场景是我这半年里反复遇到的处理流程可以直接照搬。5.1 智能电视的开机广告设备封禁 域名拦截组合用电视开机广告是最好解决的也是最容易解决的过头的一类。我的处理顺序是先只看不改跑两三天让日志把电视发出的所有 DNS 查询记下来。然后在日志里挑出那些明显是广告和推送的域名通常出现在开机后头 30 秒内且重复出现。把这些域名加进拦截表观察一周。如果还有残留再考虑对这台设备做更严格的管控。这里不建议一上来就封禁设备。因为电视除了广告还有系统更新、应用商店、投屏协议全封了会影响正常使用。设备封禁应该留给这台设备在规定时段内不该联网这种场景而不是用来治广告。5.2 家里来客人分组暂停而不是全局暂停客人设备接进来最省事的做法是给它们单独划一个分组然后对这个分组做不拦截策略。这样你的设备继续过滤客人的设备完全不受影响谁都不用折腾。如果没有分组功能退而求其次用全局暂停但要设一个明确的时长比如 4 小时。千万别选无限期——我干过一次忘了恢复一周后才发现家里的过滤全停了。5.3 固件升级前后的配置处理升级固件是唯一一个会把三个操作全部重置的场景所以流程要格外小心升级前导出配置包括设备列表、暂停状态如果有、自定义规则。升级后先别急着导入确认新固件的字段结构有没有变化。我就遇到过升级之后规则字段改名导入直接失败的。导入后做三项验证设备封禁是否还有效、暂停状态是否已清空升级后应该默认恢复、自定义规则条数对不对。观察一天日志确认没有异常的大量拦截或大量放行。这套流程走下来大概十分钟但能省掉后面几小时的困惑。尤其是暂停状态是否已清空这一项——如果旧固件里存了个很长的暂停时间戳新固件又正好用了不同的时间基准那可能会出现升级完过滤就失效了的情况而且界面上一点提示都没有。最后再分享一个小技巧不管哪个操作做完之后都用同一条命令验证一遍——在局域网里对某个已知的拦截域名做一次查询看返回结果对不对。这一条命令能同时验证规则加载、匹配逻辑、响应构造三个环节比在浏览器里刷半天页面高效得多。我现在改完任何配置都是先跑这一下确认没问题再去实际使用。
