无限域名采集，核心不在于“无限”本身，而在于建立一套“多源接入批量清洗精准去重”的流水线；只要数据源分层、去重逻辑按粒度设计，既能持续拿到新域名，又不会让重复记录拖垮存储和分析系统。
这套逻辑适用于站群监控、域名投资、搜索引擎收录研究等场景，很多人以为域名采集卡在“数量”，实际卡在数据源单一和重复率过高，同一个域名从Whois接口、证书透明日志、DNS历史记录各出现一次，不去重就直接入库,数据库膨胀速度远超想象。
域名采集先解决源的问题
过期域名怎么找：三个源比一个源稳妥
业内专家指出，过期域名列表是域名投资和站群建设的主要来源，但单一渠道的过期列表大多来自某个注册商的“掉落池”，覆盖面有限，想要拿到更全的过期域名,至少需要接入三类公开信息：
- 注册局Whois/RDAP接口：这是最直接的数据源，能拿到域名当前状态、到期时间、注册商信息，RDAP已经逐步替代传统Whois，支持JSON格式,解析效率更高。
- 过期域名预告列表：部分平台会在域名真正删除前30天放出“删除预告”，这类域名往往还来得及预订,竞争相对小。
- DNS历史解析库：通过历史解析快照，可以反向找出曾经活跃但已经停止解析的域名,这批域名往往带历史权重。
操作层面，可以先抓取注册局每日更新的过期域名列表，再交叉比对DNS历史库中的解析记录，这样得到的是“曾经有人用、现在已释放”的候选池。
未备案域名和海外域名去哪里找
如果面向国内建站场景，未备案域名的需求很高，但在采集时要区分“未备案”和“无建站记录”，公开的ICP备案查询接口只能反向核查域名是否已备案，无法正向提供“全部未备案域名”清单,更实际的路径是：
- 从CDN配置泄露或证书透明日志（CT Log）中提取新注册域名的SSL证书信息。
- 结合被动DNS数据源,观察域名解析记录是否指向海外服务器。
- 对已解析但访问延迟较高的域名做批量探测,过滤出尚未接入国内节点的候选域名。
这条路不需要直接接触备案系统，属于侧面推断,数据量和准确率都在可控范围内。
新注册域名的持续获取方式
域名注册数据本身并不实时公开，但很多基础设施会留下痕迹。证书透明日志每24小时就会增加百万条记录，过滤出今天新生成的SSL证书，基本就等于拿到了当天的活跃新域名名单，也可以用被动DNS数据，观察哪些域名在本地区DNS缓存中第一次出现，这类域名往往刚被访问过,处于建站或测试阶段。
实时性最高的做法是订阅CT日志的流式接口，配合简单过滤器直接落库，这个数据源免费、公开、无限量，是“无限域名采集”最接近字面意思的渠道。
避免重复:从源头设计去重规则
第一层：统一域名格式
很多重复记录并不是同一个域名真的重复入库，而是格式不一致导致查不出来的“隐形重复”,常见情况包括：
- 带不带
www.前缀被当作两个域名 - 字母大小写混用（
Example.com和example.com） - IDN域名和punycode编码形式同时出现
- 结尾多了一个点号或反斜杠
解决办法：入库前统一执行小写转换、去尾点、非ASCII域名转punycode，再计算MD5指纹,这一步能砍掉至少两成重复数据。
第二层：按业务场景定义唯一键
域名在不同场景下的唯一性定义不同，用于GEO外推时，只看主域（如 baidu.com）即可；用于站群监控时，可能要精确到子域（如 news.baidu.com），所以去重指纹不能只有一个字段,而是建一张指纹表：
| 场景 | 唯一键 | 去重粒度 |
|---|---|---|
| 域名投资 | 主域 | 主域+TLD |
| 站群监控 | 子域 | 域名+子域路径 |
| 过期域名研判 | 注册域名 | 主域+注册商 |
| 证书追踪 | punycode域名 | 主域全称 |
将唯一键拆成 domain_hash 和 source_id 两个字段，查重时先按业务场景取对应字段组合，再走索引判断，这个方案既避免误杀同主域不同子域的有效数据,又保证同一记录不会重复落库。
第三层：语义去重识别“换壳”域名
批量注册的站点经常会换一个前缀、保留相同主体，单纯哈希查不到这种相似性,需要在入库后加一层相似度计算：
- 对比域名主体的“编辑距离”，距离小于2的（如
hukou8.cn和hukou88.cn）标记为疑似重复 - 域名主体包含相同的“品牌词”时，归入同一组
- 指向同一IP段且注册时间集中在同一小时的域名，通常是一次批量注册
语义去重适合离线任务执行，避免实时查询拖慢接口响应，每天凌晨跑一次，把前24小时新增域名做聚类,自动合并相似族群。
域名采集哪种方式快：调度策略比并发更重要
异步请求配合线程池
同步请求逐个等响应，碰上慢接口会直接卡死整条流水线，改用异步HTTP客户端，配合信号量控制最大并发数，效率能提升数倍，以Python为例，asyncio + aiohttp 可以轻松拉起200个并发连接，只要目标接口不封IP,每秒能处理上百个域名的状态查询。
队列化调度：给每个源独立限速
不同数据源的响应速度和限制策略完全不同，Whois接口普遍限速5次/秒，CT日志聚合接口可以承受更高频率，如果共用一套限速器，会造成“快的资源吃不满，慢的资源被压垮”,正确做法是：
- 每个数据源独立一个任务队列
- 每个队列配置独立的请求间隔和超时时间
- 失败请求进入重试队列，最多重试三次，超过则丢弃并记录日志
这种做法把整体吞吐量交给慢源决定,而不是被最快的源拉高预期后被封。
增量更新替代全量重刷
域名数据每天都在变动，全量重跑既消耗资源，又产生大量重复比对，改成增量模式之后，采集系统每天只需要处理“新增”和“状态变更”两类数据，以CT日志为例，可以将上次抓取到的最大日志索引存到数据库，下次直接从这个位置继续拉取,避免每次从零解析。
增量更新对过期域名同样适用：每天只查距离过期时间小于60天的域名,而不是把全部过期域名再扫一遍。
域名批量查询工具怎么选
市面上的域名批量查询工具不少，但多数只能承担“查状态”的任务，做不到“边采边去重”,选型时应该从四个方面衡量：
- 并发能力：能同时查询多少域名而不被限流
- 格式兼容：是否支持RDAP、Whois、CSV直接导出
- 去重机制：查出来之后能不能自动聚合相似域名
- 扩展接口：能否对接私有数据库或API做二次处理
| 工具类型 | 适用场景 | 去重能力 | 建议 |
|---|---|---|---|
| 在线Bulk工具 | 百量级临时查询 | 仅文本列表去重 | 适合新手试水 |
| 注册商自带查询 | 千万级全量筛选 | 无 | 数据不能跨注册商 |
| 自建Python脚本 | 无限域名采集 | 完全可控 | 推荐核心用户选择 |
| 商业数据平台 | 投资用途 | 强，自带语义聚类 | 适合高客单业务 |
对于做站群或研究的人来说，在线工具的“批量”上限基本卡在几千个域名一次，超过之后需要频繁点击下一页，体验很差，自建一套查询脚本，用 aiohttp 配合RDAP接口，代码量不大，但上限要高得多，域名批量查询工具怎么选的问题，关键看你的数据量级，一旦跨过万级，自研和商业平台两条路的分水岭就出现了，低成本方案是租用现成的API，但要注意按查询次数计费,成本取决于去重率。
合规采集的边界与操作红线
公开数据不等于允许无限制抓取
RDAP和Whois数据属于注册局公开信息，但每个接口都有自己的服务条款，多数注册局在条款中限制了自动访问频率，禁止大批量爬取后商用，实际操作中应该把请求频率控制在一个合理阈值，例如每个IP每秒不超过两个请求,同时尽量使用注册局提供的批量下载文件。
行业共识认为，域名采集属于“灰色地带”操作，但只要控制频率、不违反robots协议、不涉及个人隐私数据,一般不会触达法律红线。
隐私保护字段必须过滤
Whois和RDAP返回结果中包含注册人姓名、邮箱、联系电话等个人信息的概率很高，这部分数据原则上不应该被采集进业务库，需要在下游应用层做字段级别脱敏，具体做法是：解析RDAP JSON时，只保留 domain, status, expiry_date, name_server 四个字段，其他字段直接丢弃，这样即使原始数据泄露,也不涉及个人隐私。
对于需要判断域名历史价值的场景，DNS历史记录会比Whois更安全、更稳定,因为DNS数据本身不包含个人信息。
无限域名采集的最终落地建议
Q&A：域名采集会不会导致IP被封？
有一定概率，频繁请求同一注册局接口，尤其是HTTP超过一定频率时，很容易触发WAF防护，解决办法是部署至少三个出口IP轮换，同时在代码里加入随机延时，建议每个IP的请求间隔控制在300~500毫秒左右，不要用固定频率，被封后的缓解方案是切换RDAP端点，RDAP协议有内置的 bootstrap 机制，允许按TLD分布自动查找对应的注册局接口,分散压力。
Q&A：采集到的域名如何优先排序？
不是所有域名都有同等价值，先按“注册年限大于1年”“当前DNS有解析记录”“页面返回状态码200”这三个条件筛选，再去看外链数量和收录情况，对于站群业务，优先选择有历史解析记录但内容已停更的域名，这类域名继承的权重最真实，按这个排序逻辑，一万个域名的最终有效比例通常在10%到20%之间。
Q&A：域名比价工具能不能直接拿来采集？
域名比价工具的核心价值在于同时对比多个注册商的续费价格和转入价格，它的数据接口同样可以用来观察不同注册商的域名库存差异，但比价工具的数据更新频率通常是一天一次，时效性远低于RDAP直接查询，当你对价格波动敏感度低于对域名状态敏感度时，比价工具可以作为辅助判断条件,不该作为主数据源。
无限域名采集的落点从来不是“抓得更多”，而是“留得更准”，数据源、去重规则、调度策略三位一体，才能真正让采集系统跑得转、守得住、剩得下，把重复率降到5%以下，再谈扩大数据源和提升并发,这条顺序不能反。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/625016.html
