广告域名提取工具实战：从流量捕获到规则判定引擎

在实际工作中，网站页面上堆积的广告脚本和追踪器往往比可见内容还要多，这些资源不仅拖慢加载速度，还会默默收集用户行为数据。与其一个个手动查看开发者工具里的网络请求，不如直接做一个广告域名提取工具，把散落在流量里的广告请求自动筛出来。这篇文章我会从原理到落地，拆解一个自用提取工具的设计思路和完整实现过程，包括流量捕获、域名归一化、规则判定、误报处理这些关键环节。

1. 广告域名识别的技术底座：流量捕获与分析思路

1.1 为什么从网络流量层入手，而不是依赖现成黑名单

做广告域名提取，最直接的想法可能是去抓现成的广告过滤列表，比如EasyList或者uBlock Origin的规则集。但这会有几个问题：首先是更新时效，规则列表往往滞后于新出现的广告域名，今天刚上线的广告服务可能要等几天甚至几周才会被收录；其次是个性化缺失，现成列表面向全球用户，里面会有大量与目标站点无关的域名，而且不同地区、不同业务的广告投放差异很大，直接套用容易误伤或者漏掉。

从网络流量层入手意味着拿到的是一手数据，每个域名都是在真实访问场景中产生过请求的，不存在“理论上的广告域名”和“实际请求的广告域名”之间的偏差。这个思路本质上是在做一个采集器加分析器的组合，先通过代理或者抓包方式让流量经过工具，然后从这些流量里提取出域名，再根据域名特征、请求特征、资源类型等多维信息判断哪些属于广告追踪链路。

1.2 两个核心捕获方案：代理模式和旁路抓包

流量捕获是整个工具的数据入口，方案选择会直接影响后续分析逻辑。最常见的两种方式各有适用场景。

代理模式是把工具作为一个中间人，浏览器或系统配置代理后，所有HTTP/HTTPS请求都会先经过工具再转发出去。这种方式最大的好处是能看到明文HTTP请求的完整细节——URL路径、查询参数、请求头、Cookie、响应体等等，这让域名判定维度变得非常充足。比如某个请求的URL是https://ad.example.com/api/v1/tracker?pid=123&ref=homepage，代理模式下可以完整解析出路径和参数特征，精确判断。

旁路抓包模式是用tcpdump或者Wireshark对网卡做镜像流量分析，这种方案不干扰业务流量，比较适合在路由器或者网关设备上做全局监控。但问题是现在互联网流量绝大部分是HTTPS加密的，旁路抓包只能看到TLS握手阶段的SNI字段，也就是裸域名，看不到URL路径和请求参数，特征维度少很多。

实操中我倾向于两者结合：在家里或者办公网的路由器上旁路抓包做长期数据沉淀，拿到宏观的域名访问矩阵；在对特定站点做深入分析时用代理模式，拿到完整的请求上下文。工具设计上要留出两种输入接口，便于切换。

1.3 域名特征提取的标准化处理链路

无论哪种捕获方式，最终都会得到一条条URL记录或者域名记录。在这之前必须做标准化处理，否则后续的规则匹配会非常痛苦。标准化的核心是域名归一化。

归一化要做的事情包括：把URL的scheme去掉、把www这类前缀去掉（注意不是全部子域名都去掉，而是根据业务需要保留二级注册域）、把大写转小写、把端口号去掉、把末尾的点和空白字符清理掉。以https://AD.Example.com:8443/path?id=1#frag为例，经过归一化后应该得到ad.example.com。

在Python里用tldextract库处理这个非常合适，它不是简单的字符串切割，而是内置了公共后缀列表，能正确区分example.com和example.co.uk这类不同结构的域名。接着还需要维护一个“已观测域名池”，用于后续的重复过滤和频次统计。

2. 工具架构设计：模块划分与数据流走向

2.1 五个核心模块的职责边界

广告域名提取工具的整体架构我分为五个模块：流量输入模块、域名解析与归一化模块、特征提取模块、规则判定模块、结果输出模块。

流量输入模块解决“数据从哪来”的问题，支持读取代理日志文件、标准输入流、或者直接对接数据库表。归一化模块解决“域名怎么洗干净”的问题，把原始流量里的URL处理成标准域名和标准化路径。特征提取模块做的是把每个域名的多个维度特征打包成结构化记录，比如请求量、资源类型分布、是否携带Cookie、是否常发生在隐私模式下。规则判定模块是核心引擎，负责把特征向量映射为“广告/非广告”的结论。结果输出模块生成最