企业官网建设流程全解析

一台巴掌大的开发板插在路由器旁边，全家十几台设备的开屏广告、视频贴片、App 里的信息流推广就都安静了——这件事听起来像魔法，实际上只是把 DNS 解析这一步攥在了自己手里。esp32-c3-adblock 这类项目干的活儿，本质上是让一块 ESP32-C3 顶替掉路由器下发的默认 DNS，所有终端要访问什么域名，先来问它一句，它再决定是放行、是撒谎，还是干脆不搭理。三大日常操作——封禁设备、暂停拦截、自定义域名——恰好对应了这套机制里最常用的三种"改主意"的方式：我不想让某台设备上网、我暂时不想拦了、这个域名我要单独处理。玩这套东西的人，多半是家里设备多、又不想天天被广告骚扰的折腾党，也有拿它做家庭网络管理的。下面这些内容，是我自己反复折腾、反复踩坑之后整理出来的操作细节和判断逻辑，新手照着做能跑通，老手可以挑着看那些容易翻车的地方。

1. 先搞清楚这台小板子站在网络的哪个位置

1.1 DNS 拦截的本质：在解析环节"撒谎"

广告拦截有两条路，一条是在浏览器里装插件，把页面上的元素藏起来；另一条是在网络层，让广告域名的解析直接失败。前者只能管住装了插件的那个浏览器，后者管的是整个局域网。esp32-c3-adblock 走的是后一条。

具体原理很朴素：终端要访问ads.example.com，第一步是问 DNS"这个域名对应哪个 IP"。正常情况下，DNS 会返回一个真实地址，终端拿着地址去建立连接。而当这台 ESP32-C3 拿到这个查询时，如果域名命中了拦截规则，它就直接返回0.0.0.0（IPv4）或者::（IPv6），或者干脆回一个NXDOMAIN表示"这域名不存在"。终端拿到这个结果，连接自然建立不起来，广告资源加载失败，页面上的广告位就空着或者被跳过。

这里有个关键点很多人忽略：拦截发生在解析阶段，不是连接阶段。也就是说，只要终端绕过这台设备去解析，拦截就完全失效。手机开个"私人 DNS"、浏览器开个"安全 DNS"、装个自带 DoH 的 App，都能轻松绕过去。理解了这一点，后面所有的"拦截不生效"问题，排查思路就清晰了——先确认流量到底有没有经过它。

1.2 三大操作对应三种状态：拒绝、旁路、覆盖

封禁设备、暂停拦截、自定义域名，听着是三件不相干的事，其实对应的是三种状态切换：

• 封禁设备：针对"谁"做限制，粒度是客户端。某台设备的所有查询都被特殊对待，常见做法是全部返回失败，或者全部透传给上游不做任何拦截。
• 暂停拦截：针对"什么时候"做限制，粒度是时间。规则表原封不动，只是临时不生效，到点恢复。
• 自定义域名：针对"哪个域名"做限制，粒度是规则。在订阅来的大规则表之外，手工加一条黑名单、白名单或者重定向。

这三者的优先级在实际系统里是有讲究的。我的经验是：客户端级别的策略优先于全局策略，自定义规则优先于订阅规则。也就是说，一台被封禁的设备，你给它单独放行某个域名，它照样能解析；而一个被加进白名单的域名，即使订阅规则里明确要拦，也应该放行。这个优先级顺序在配置的时候一定要心里有数，否则很容易出现"我明明加了白名单怎么还是打不开"的情况。

1.3 ESP32-C3 的硬件天花板决定了哪些事不能做

ESP32-C3 是一颗单核 RISC-V、主频 160MHz 的芯片，SRAM 只有 400KB 左右，其中相当一部分还要分给 Wi-Fi 协议栈和 TCP/IP 栈。市面上常见的模组一般是 4MB Flash，Wi-Fi 只支持 2.4GHz 单频，没有有线网口。这些参数直接框定了它能干什么、不能干什么。

我做过的实测：在 20 台左右终端、日常浏览的场景下，DNS 查询峰值大概几十 QPS，这台板子完全扛得住，解析延迟基本在个位数毫秒，体感上察觉不到。规则表几千条的时候，线性匹配一次大概几十微秒，也不是瓶颈。真正的瓶颈在内存和 Flash 写入：规则表、DNS 缓存、客户端表、日志缓冲区全都要占 RAM，缓存条目一般控制在几百条量级；而配置保存要写 Flash，Flash 有擦写寿命，绝对不能每次状态变化都写一次。

所以你会看到这类固件在设计上有明显的取舍：不支持正则表达式规则（太吃内存）、缓存条目有上限、日志用环形缓冲区、暂停状态的持久化有防抖。这些不是偷懒，是在几百 KB 的预算里做出来的必然选择。想明白这一点，你配置的时候就不会去提"能不能加个正则"这种需求了。

1.4 影响范围：这块板子挂了，全家都上不了网

这一点必须提前说清楚。当路由器的 DHCP 把 DNS 指向这台 ESP32-C3 之后，它就变成了整个局域网的单点依赖。它正常工作时大家无感，它一挂——断电、死机、Wi-Fi 掉线、固件刷坏——所有设备的域名解析全部超时，表现就是"网还在，但什么都打不开"。

我踩过最惨的一次是刷固件刷到一半断电，板子起不来了，家里人拿着手机问我"为什么 Wi-Fi 连着但是没有网"。后来我养成两个习惯：一是给这块板子配一个静态 IP 或者 DHCP 静态绑定，别让它每次重启换地址；二是路由器上保留一个备用 DNS（比如运营商给的或者公共的），万一主 DNS 不响应，部分设备会自动 fallback。当然备用 DNS 一启用，拦截就漏了，这是可用性和拦截率之间的权衡，看你更在意哪个。

另外一个影响范围是误杀的传播性。一条错误的白名单或黑名单，影响的不是一台设备，而是全家所有走这台 DNS 的终端。所以自定义规则我建议一次只加一条，加完立刻验证，不要一口气导入几十条再一起测。

2. 封禁设备：不是断网，是让它在解析阶段拿不到地址

2.1 先想清楚你要的是哪一种"封禁"

很多人一说封禁设备，脑子里想的是"让它完全不能上网"。但 DNS 层能做到的其实很有限，这里要区分三种语义，选错了会出问题：

第三种容易被误解成"封禁"，其实它是"豁免"。我见过有人为了让某台办公设备不被误杀，把它设成透传，结果那台设备上的广告照样满屏飞，跑来问是不是规则没生效——不是没生效，是它压根没走规则。透传和封禁是两个方向的操作，后台按钮长得像，含义完全不同，点之前看清楚文案。

至于前两种怎么选，我的建议是优先用黑洞返回。NXDOMAIN 会让某些 App 直接把"网络异常"的弹窗甩给用户，而返回0.0.0.0时，连接尝试会快速失败，很多程序会安静地跳过这个资源。不过也有例外：某些老旧的嵌入式设备对0.0.0.0的处理很怪，会反复重试，这时候换 NXDOMAIN 反而更干净。没有绝对答案，实测为准。

2.2 设备识别：IP、MAC、主机名，各有各的坑

要给某台设备下策略，第一步是能稳定地认出它。这类固件一般提供三种识别依据：

按 IP 识别最直接，后台客户端列表里就是一个个 IP。问题在于 DHCP 租约到期或者设备重连，IP 可能变。一旦变了，原来的封禁策略就落到另一台设备头上。我就遇到过封了.103结果第二天.103变成了家里老人的平板，人家莫名其妙上不了网。所以按 IP 做策略，前提是你在路由器上做了DHCP 静态绑定（把 MAC 和 IP 绑死）。

按 MAC 识别相对稳，但现在的手机、平板默认开启"私有 Wi-Fi 地址"，每次连同一个网络都可能换一个随机 MAC。iOS 和部分 Android 机型都是这个逻辑。这种情况下 MAC 识别也会漂。解决办法是在设备的 Wi-Fi 设置里对该网络关闭私有地址，或者干脆接受它会漂，改用主机名识别。

按主机名识别依赖设备上报的 DHCP 主机名，可读性好，比如living-room-tv、kids-tablet。但主机名可以被随意修改，也可能为空或是出厂默认的一串乱码。我的做法是：先用主机名找到设备，确认无误后在路由器上做静态绑定，再用 IP 或 MAC 下策略。这样既好认又稳定。

2.3 实操：从客户端列表到封禁生效

后台的客户端页面通常长这样：一行一台设备，显示 IP、MAC、主机名、最近的查询次数、当前是否被策略命中。下面是典型的操作流程，不同固件按钮文案不一样，但逻辑一致。

第一步，进入 Web 管理页，找到"客户端"或"设备"列表，等几秒让它刷新出活跃设备。列表是按最近活跃排序的，你刚用过的手机一般排在最前面。

第二步，对照主机名和 MAC 确认目标设备。这一步别偷懒，我见过把自家 NAS 当成陌生设备封掉的。确认方法很简单：在目标设备上打开任意网页，回后台看哪一行的查询计数在涨。

第三步，点该设备对应的"封禁"按钮，选择封禁模式（拒绝解析或黑洞返回）。多数固件会弹一个确认框，同时提示这个操作会影响该设备的全部域名解析。

第四步，保存。如果固件支持 API，也可以用命令行操作，做自动化更方便：

# 查看当前客户端列表（IP 换成你板子的实际地址） curl -s "http://192.168.1.50/api/clients" | head -c 2000 # 对某个 MAC 下发封禁策略 curl -s -X POST "http://192.168.1.50/api/clients/block" \ -H "Content-Type: application/json" \ -d '{"mac":"AA:BB:CC:DD:EE:FF","mode":"zero"}'

第五步，验证。一定要在被封禁的那台设备上执行，而不是在你的电脑上：

# Windows nslookup example.com 192.168.1.50 # macOS / Linux dig @192.168.1.50 example.com A +short

正常情况下应该看到0.0.0.0或者NXDOMAIN。如果还是返回真实 IP，说明策略没生效，或者这台设备根本没在问这台 DNS。

2.4 封禁失败的四种常见原因

设备根本没走这台 DNS。手动设过 DNS 的设备、开了私人 DNS 的手机、装了自带解析的浏览器，都会绕过。判断方法是在板子的实时日志里搜这台设备的 IP，如果一条查询都看不到，那就不是策略问题，是流量没来。

IPv6 在偷偷工作。现在很多家庭宽带是双栈，路由器通过 RDNSS 下发 IPv6 DNS 地址。如果这台板子只处理了 IPv4 的 DNS，终端会优先用 IPv6 的 DNS 去解析，你的策略完全不生效。解决办法是在路由器上把 IPv6 的 DNS 也指向这台板子，或者在不需要 IPv6 的场景下关掉路由器的 IPv6 DNS 下发。

MAC 漂移了。上面说过的私有 Wi-Fi 地址。后台看列表，同一个主机名出现两行不同 MAC，基本就是这个原因。

策略缓存没刷新。有些固件为了性能会把客户端策略缓存一小段时间，改完之后要等几秒或者等下一次 DHCP 交互才生效。急着验证的话，把目标设备的 Wi-Fi 关掉再打开。

注意：封禁设备是不可逆的"重手"操作。如果封的是家里共用的电视盒子或者老人的平板，会直接影响他们使用。我的习惯是封禁前先在备注里写清楚为什么封、什么时候解，隔几天回头看一遍，避免时间久了自己都忘了。

3. 暂停拦截：最容易忘了恢复的那个开关

3.1 为什么需要暂停，以及三种暂停粒度

去广告这套东西最大的痛点不是拦不住，是拦错了。常见的翻车场景：某个网站的登录回调域名命中了规则、某个银行的验证页面加载不出来、某个视频网站的播放器请求被当成广告拦了、某个软件的自动更新检查失败导致功能异常。这时候你需要一个"先放它一马"的开关。

暂停的粒度有三档，用哪个取决于你的问题范围：

全局暂停：所有设备、所有规则临时失效，全部透传给上游。最粗暴，也最常用。适合"我不知道是哪条规则的问题，先整体关掉看看是不是它干的"。

按客户端暂停：只让某一台设备豁免。适合"我手机上的某个 App 打不开，但其他设备都正常"。

基于时间的自动暂停：设定一个时长（比如 5 分钟、30 分钟、2 小时），到点自动恢复。这是最实用的设计，后面详细说。

3.2 定时暂停为什么比手动开关重要

我见过太多人（包括我自己）手动关掉拦截之后忘了开回来。过了一个月突然想起来"最近广告怎么这么多"，回去一看，暂停开关还亮着。手动开关的设计缺陷就在这——它依赖人的记性。

所以选固件的时候，我会优先看它有没有"暂停 N 分钟后自动恢复"的功能。实现上通常是一个倒计时：点击暂停时输入分钟数，固件记录一个恢复时间戳，后台有个定时器每秒（或者每几秒）检查一次，到点就把状态切回来。

如果固件没有这个功能，也有土办法：用 Cron 或者宿主机上的脚本定时调 API。

# 暂停 30 分钟后自动恢复的思路： # 先调用暂停接口，再用 sleep + 恢复接口兜底 curl -s -X POST "http://192.168.1.50/api/pause" -d '{"seconds":1800}' # 部分固件支持一次性带时长，不支持的话用下面这种 ( sleep 1800; curl -s -X POST "http://192.168.1.50/api/resume" ) &

这个脚本丢在常开的小主机或者 NAS 上就能用。缺点是宿主机重启脚本就没了，所以更稳妥的做法还是用固件自带的定时功能。

3.3 暂停状态怎么持久化才不伤 Flash

这里有个容易被忽略的工程细节：暂停状态要不要写进 Flash？

如果每次都写，你在 30 分钟里反复点暂停/恢复，Flash 就被反复擦写，长期下来是有寿命风险的。如果不写，板子中途重启，暂停状态就丢了，可能会在你不知情的时候恢复拦截，把正在用的业务又打断。

合理的做法是状态变化时写一次，倒计时的秒数放在 RAM 里，重启后按"已恢复拦截"的默认值处理。这样既保证了状态不会因为频繁倒计时而写 Flash，又保证了重启后的行为是可预期的（宁可多拦，不可漏拦）。你在用的时候如果发现板子重启后暂停状态没了，别急着骂，想想这个设计取舍，其实是合理的。

3.4 暂停期间的三个坑

坑一：缓存里的旧结果还在。暂停只是让新查询透传，已经缓存的拦截结果还在缓存里，终端在 TTL 到期前仍然拿不到真实地址。所以暂停之后如果目标网站还是打不开，先清一下 DNS 缓存，或者在终端上换个域名试试。

坑二：暂停期间产生的缓存会污染恢复后的行为。反过来的情况也存在：暂停时透传拿到的解析结果被缓存下来，恢复拦截后，这个域名在 TTL 内仍然是通的。表现出来就是"我明明恢复了拦截，怎么这个广告还在"。等 TTL 过期或者手动清缓存即可。

坑三：把暂停当成了修复。有些人遇到问题就暂停，暂停完网站能开了，就再也不管了，规则一直没修。我的做法是暂停之后务必记一笔，等手头空下来去日志里找到那条被误杀的域名，加进白名单，然后解除暂停。暂停是止血，白名单才是治疗。

4. 自定义域名：规则优先级和匹配逻辑是全部

4.1 四类规则，别用错

自定义域名是这套系统里最灵活也最容易出错的部分。常见的规则类型有这么几种：

写规则之前先想清楚你要的是哪一种。我见过有人想放行pay.example.com，结果写成了*.example.com的黑名单，把整个域全拦了，支付页面直接白屏。域名的方向（拦还是放）和范围（精确还是后缀）是两个独立维度，写的时候一个字一个字对着看。

4.2 匹配顺序：白名单永远在前面

规则引擎的执行顺序决定了最终结果，这一点必须搞清楚。合理的设计一般是这个顺序：

1. 先查客户端策略，如果这台设备被设为透传，直接转发上游，后面的规则全不看。
2. 查自定义白名单，命中就放行，不再往下走。
3. 查自定义黑名单和重定向，命中就按配置处理。
4. 查订阅规则表，命中就拦截。
5. 全都没命中，转发上游正常解析。

这个顺序带来的一个重要结论是：白名单可以覆盖一切拦截。所以当你不确定某个域名是不是被误杀时，最安全的做法是加一条精确白名单，而不是去订阅规则里找那条规则删掉——订阅规则一更新，你删的又回来了。

反过来说，如果你的自定义黑名单没生效，先检查是不是有一条更宽的白名单在上面挡着。比如你加了*.example.com的白名单，又想单独拦ads.example.com，那大概率拦不住，因为白名单优先级更高。

4.3 精确、后缀、通配，选哪个

精确匹配只影响一个域名，最安全，适合放行具体的接口域名。比如某个支付回调是notify.example.com，你就精确放行这一个，不要图省事写*.example.com。

后缀匹配影响整个域及其子域，威力大，风险也大。广告域名用这个没问题，业务域名慎用。*.example.com这种写法在有些固件里等价于||example.com^，在另一些固件里只匹配一级子域（a.example.com匹配，a.b.example.com不一定），具体语义必须以你用的固件的文档为准，别想当然。

通配符（比如ad*.example.com）支持的固件不多，因为实现起来要做模式匹配，占资源。如果你的固件不支持，用多条精确规则代替，别硬凑。

至于正则表达式，我的建议是别指望。ESP32-C3 那点内存跑正则引擎，规则一多就容易出问题，而且调试起来极其痛苦。真要复杂匹配，不如在路由器或者旁路由上做，这颗芯片就干好简单的活。

4.4 三个真实场景的配置示例

场景一：某个漏网的广告域名。你在日志里看到某台设备反复查询tracker.example.net，订阅规则里没这条。加一条后缀拦截：

类型：黑名单（后缀） 域名：tracker.example.net

保存后立刻验证：

dig @192.168.1.50 tracker.example.net A +short # 期望输出：0.0.0.0

场景二：某网站的支付回调被误杀。现象是下单后一直转圈，F12 看到某个请求失败。把失败的域名精确加白：

类型：白名单（精确） 域名：notify.example.com

这里千万不要用后缀匹配，白名单的范围越大，漏进来的广告越多。

场景三：把某个域名指到内网设备。家里有台 NAS，习惯用域名访问而不是记 IP。加一条重定向：

类型：重定向 域名：nas.example.com 目标：192.168.1.10

这类重定向本质上是一个极简的内网 DNS，比在每台设备上改 hosts 文件省事得多。注意重定向的 TTL 别设太长，万一 NAS 换了 IP，你还得等缓存过期。

4.5 调试：怎么确认规则到底命中没有

规则加完不生效，按这个顺序查：

第一，确认查询到了板子。在板子的实时日志里搜这个域名，看有没有对应的查询记录。搜不到就是流量没来，跟规则无关。

第二，确认规则语法对。大小写、前后空格、有没有多打一个点（example.com.和example.com在有些实现里不等价）、通配符位置对不对。这些细节看着蠢，但确实是最高频的错误来源。

第三，确认优先级没被覆盖。往上翻，看看是不是有更宽的白名单。

第四，确认缓存。用dig的时候加+norecurse或者直接看返回的 TTL，判断是缓存命中还是实时解析。清缓存后再试一次。

第五，确认记录类型。这条最隐蔽。很多固件只处理 A 记录，终端查询 AAAA（IPv6）的时候直接透传，结果设备走了 IPv6 绕过拦截。查日志的时候把记录类型也看一眼，别只盯着域名。

注意：加自定义规则一次只加一条，加完立刻验证。批量导入十几条再一起测，出了问题你根本不知道是哪条引起的。这个习惯能帮你省下大量排查时间。

4.6 AAAA 和 HTTPS 记录：两个必须补的漏洞

前面提过 AAAA 记录的问题，这里展开说一下，因为它是"拦截不生效"里最容易被误判成玄学的原因。

终端在解析域名时，通常会同时查 A（IPv4）和 AAAA（IPv6）。如果你的固件只对 A 记录返回0.0.0.0，对 AAAA 记录照常透传，而终端所在网络又支持 IPv6，那么终端会拿着真实的 IPv6 地址去连接，广告照样加载。表现出来就是"电脑上拦住了，手机上没拦住"或者"有时候拦得住有时候拦不住"。

正确的做法是：命中拦截规则时，A 返回0.0.0.0，AAAA 返回::，两者同步。选固件的时候可以专门测一下这条，方法很简单——找一个确定被拦的域名，分别查 A 和 AAAA：

dig @192.168.1.50 ads.example.com A +short dig @192.168.1.50 ads.example.com AAAA +short

两个都返回空地址才算完整拦截。

HTTPS 记录（type 65）是另一回事。新版浏览器会用 HTTPS 记录来获取连接参数，某些实现会顺着这条记录拿到真实的目标地址。如果你的固件对 HTTPS 记录的处理是"不认识就透传"，理论上存在被绕过的可能。实际影响有多大，取决于终端和浏览器的行为，但既然发现了，配置的时候顺手确认一下固件有没有处理这类记录，心里更踏实。

5. 常见问题与排查速查表

5.1 一张表覆盖八成问题

5.2 三个典型排查案例

案例一：家里老人的平板突然上不了网。现象是 Wi-Fi 显示已连接，但所有网页打不开。第一反应是板子挂了，但自己的电脑能正常上网，说明板子没事。登录后台看客户端列表，发现平板的 IP 正好是之前封禁过的那台设备用过的地址——租约到期后地址被重新分配了。把封禁策略从按 IP 改成按 MAC，问题解决。这个案例的教训是：任何基于 IP 的策略，都必须配静态绑定。

案例二：手机上广告拦得干干净净，电脑上满屏都是。两台设备连的是同一个 Wi-Fi，理论上走同一个 DNS。差别在于电脑上装了某个浏览器，开启了自己的"安全 DNS"。关掉之后立刻恢复正常。这个案例说明，排查的时候第一步永远是确认"流量到底有没有经过板子"，而不是去翻规则表。

案例三：加了条白名单，网站能打开了，但广告又回来了。因为白名单写得太宽，用的是*.example.com，把这个域下所有的广告子域也一起放行了。改成精确匹配具体的回调域名，问题解决。这个案例的教训是：白名单的范围越小越好，能精确就别用通配。

5.3 几条别人不太会告诉你的避坑经验

别把日志级别开太高。实时日志对调试很有用，但如果一直开着详细级别，串口或者 WebSocket 会不停刷数据，一方面占 CPU，另一方面容易把环形缓冲区冲爆，真正想看的历史记录反而被覆盖了。我平时用默认级别，只在排查问题时临时调高，查完立刻调回来。

规则表别贪多。网上有那种几十万条的巨型规则列表，塞进 ESP32-C3 是不现实的。这类固件通常有个规则条数上限，超过就加载失败或者被截断。选规则列表的时候，优先选精简版、按地区或按场景定制的版本，几千条的量级对家庭场景足够了。

改配置前先导出备份。大部分固件支持配置导出，导出来是一个文本文件。我每次做大改动之前都导一份，出问题直接刷回去，比一条条手工回滚快得多。这个习惯救过我好几次。

别用开发板的 USB 口供电。有些开发板的 USB 口供电能力有限，Wi-Fi 发射瞬间的电流尖峰可能导致电压跌落，表现出来就是"随机重启""用着用着就掉线"。换成独立的 5V 电源，或者换个质量好点的适配器，很多莫名其妙的稳定性问题就消失了。这个坑很隐蔽，因为现象看起来像是固件的 bug。

留一条后路。在路由器上把备用 DNS 配好，虽然会漏一点拦截，但至少板子挂了全家不至于断网。等哪天你在外面出差，家里人打电话说上不了网，你会感谢自己当初留了这一手。

我自己用下来最大的体会是：这套东西的价值不在于"拦住了多少广告"，而在于它让你对整个家庭网络的解析行为有了掌控感。哪个设备在偷偷连什么、哪个 App 在后台请求哪些域名，日志里看得一清二楚。封禁、暂停、自定义这三招练熟了，基本上就覆盖了日常九成以上的需求。剩下的那一成，多半是你遇到了一个特别顽固的、走同域名的广告，那就只能回到浏览器插件那条路上去了——工具各有边界，认清边界比死磕更省时间。