AdGuardHome中基于MAC地址的持久客户端请求计数异常分析

问题背景

在AdGuardHome的DNS服务部署场景中，管理员发现一个特殊现象：当使用MAC地址作为持久客户端的唯一标识时，系统界面无法正确显示客户端的请求计数。而如果采用IP地址作为标识，则统计功能完全正常。该问题在v0.107.48版本中被首次报告。

技术现象深度解析

1. 客户端识别机制
   系统能够正确识别MAC地址绑定的客户端，在客户端列表中可见对应条目，证明基础识别功能正常运作。这表明MAC地址与客户端的映射关系已成功建立。

2. 统计子系统异常
   请求计数模块未能将DNS查询记录与MAC地址标识的客户端关联。这种部分功能失效现象暗示着统计模块可能存在独立的标识匹配逻辑。

3. 数据流差异
   对比IP地址标识的工作场景，系统在以下环节可能出现问题：

   • 查询日志记录时未捕获MAC地址信息
   • 统计聚合阶段无法将日志条目与MAC标识关联
   • 界面展示层未能正确读取MAC关联的统计数据

底层机制推测

根据网络服务架构经验，可能涉及以下技术环节：

1. DHCP与DNS的协同
   当使用MAC地址标识时，系统需要维护动态IP与MAC的映射关系。统计模块可能仍依赖传统的IP-based计数方式，未能适配MAC标识的新路径。

2. 统计索引构建
   数据库索引可能仅针对IP地址优化，MAC地址查询时触发全表扫描导致性能问题，进而被降级处理。

3. 日志流水线设计
   DNS查询日志可能默认记录解析时的客户端IP，而MAC地址信息需要额外的ARP查询或DHCP租约查询才能获取，增加了实现复杂度。

临时解决方案

现场验证有效的临时措施包括：

1. 重建持久客户端条目（建议修改Client ID格式）
2. 清除现有查询日志和统计记录
3. 等待系统重建统计索引

技术启示

该案例揭示了网络服务软件设计中常见的标识系统耦合问题。在混合使用二层（MAC）和三层（IP）标识时，需要特别注意：

• 统计模块的多维度兼容设计
• 日志系统的扩展字段支持
• 缓存机制的一致性维护

建议开发者在类似系统设计中采用统一的客户端抽象层，隔离标识类型与业务逻辑的耦合，提高系统的扩展性和稳定性。