📋 一分钟速览：域名太多测不过来，分层抽样是唯一解

本文核心是一套分层抽样检测法：① 认清「全量高频检测测不过来」——检测通道有额度与频率上限，域名越多缺口越大 → ② 给域名资产分层分级（核心/重要/长尾），每层定一个检测频率 → ③ 用随机抽样代替「每层全量」，核心全检、重要抽三成、长尾抽一成轮换 → ④ 抽样发现异常就「追测」同分组/同后缀/共享IP的连坐域名，把风险一网打尽。核心结论：检测资源是有限的，把力气花在最可能出事、出事最疼的域名上，而不是平均撒胡椒面。

⏱ 工具：Python + crontab（全部免费）| 覆盖四维：谷歌 Safe Browsing / QQ微信 urlsec / 反诈 DNS / APK 多引擎 | 零额外成本

为什么域名一多，全量高频检测就测不过来了？

很多站长是从「单个域名」起步的，习惯上「每 15 分钟查一次、四个维度全跑一遍」。这个习惯在只有几个域名时没问题，可一旦域名积累到几百上千个，就会撞上三堵墙：

  • 额度墙。谷歌 Safe Browsing API、VirusTotal 的免费额度是按「天」算的。你 1000 个域名 × 四维 × 每天 96 次（15 分钟一次）= 每天 38 万次查询，而免费额度通常只有几千到几万次，一天就爆。
  • 频率墙。QQ微信 urlsec、反诈 DNS 这些通道虽没有严格 API 额度，但高频轮询会触发风控——你的服务器 IP 可能被当作「爬虫」限流甚至封禁，反而污染了检测结果。
  • 收益墙。绝大多数长尾域名常年都是绿的，99% 的检测都是「重复确认它还是绿的」。把有限的检测次数平均分给每一个域名，等于在「几乎不会出事」的域名上浪费了大量资源，真正高危的域名反而没盯住。

下面这张图把「域名数量」和「检测资源缺口」的关系画了出来——缺口不是固定值，而是随域名数量线性放大的：

域名越多，全量检测的「资源缺口」越大 100 个域名 全量高频 ≈ 3.8 万次/天 勉强扛得住 1000 个域名 全量高频 ≈ 38 万次/天 额度几天打爆 10000 个域名 全量高频 ≈ 384 万次/天 彻底测不过来 结论：检测资源有限，必须「分优先级」，不能平均撒胡椒面 把力气花在「最可能出事、出事最疼」的域名上 → 这就是分层抽样的起点

▲ 资源缺口随域名数线性放大——1000 个域名全量高频，额度几天就耗尽

既然「每个域名都高频全维度测」不现实，正确思路就是给域名分优先级，把检测资源集中在高风险、高价值的目标上。下面这张表把「全量高频」和「分层抽样」两条路线的差距摆清楚：

对比维度 全量高频检测 分层抽样检测
检测总次数 域名数 × 频率 × 维度，线性爆炸 核心全检 + 其余抽样，可压缩 70%–90%
额度消耗 几天耗尽免费额度 额度可控，预算可长期平摊
高危域名覆盖率 ⚠️ 被大量「常年绿」域名稀释 ✅ 核心域名 100% 高频盯死
发现异常的速度 依赖全量轮询完成才看到 ✅ 核心高频 + 抽样异常即追测

怎么给域名资产分层分级，确定每个域名该多久检测一次？

分层抽样的第一步，是给手里的域名「分级」——分级的唯一标准不是「域名好不好看」，而是「这个域名一旦被红，你损失有多大」。损失大、概率高、影响广的域名往上放，检测频率就高；反之往下放，检测频率就低。

一个简单可落地的三层分级，覆盖绝大多数运营场景：

域名资产三层分级金字塔 核心层 · 15 分钟 支付/APP/主力落地页 · 全量高频 重要层 · 1 小时 活动页/推广页 · 抽三成轮换 长尾层 · 6 小时抽样 批量长尾/备用域名 · 抽一成轮换 越往上：数量越少、价值越高、被红损失越大 → 检测频率越高

▲ 三层金字塔：核心层数量少但价值最高，配最高检测频率；长尾层数量多但价值低，用低频抽样覆盖

分级没有绝对标准，但你记住三条经验：「直接产生收入或流量的」进核心层（支付回调、APP 下载页、主力投放落地页），「有活动、有预算但非主力」的进重要层，「批量注册的备用、长尾域名」进长尾层。下面这张表给出每层的检测频率建议和理由：

资产层 典型域名 建议检测频率 理由
核心层 支付回调、APP 下载页、主力落地页 15–30 分钟 被红即停收，损失按分钟计，必须最快发现
重要层 活动页、推广页、二级落地页 1 小时 被红影响投放但可快速切换，中等敏感
长尾层 批量长尾、备用、冷备域名 6 小时抽样 数量大、价值低，抽样轮换即可守住

先把分级定义成一段可维护的数据结构，方便以后增删域名、调整频率：

1

把域名资产分层定义成一个 Python 字典，每层绑定自己的检测间隔

用「层级 → 配置」的结构存资产，每层记录「检测间隔」和「域名列表」。以后有新域名，判断它属于哪层、往对应列表里塞就行。

# assets.py —— 域名资产分层分级（检测频率从这里决定） DOMAIN_TIERS = { "core": { # 核心层：主要流量/收入，被红损失最大 → 最高频 "interval_min": 15, "domains": ["pay.example.com", "app.example.com", "h5.example.com"], }, "important": { # 重要层：活动/推广页，次高频 "interval_min": 60, "domains": ["promo1.example.com", "promo2.example.com"], }, "longtail": { # 长尾层：批量备用，低频抽样 "interval_min": 360, "domains": ["lt001.example.com", "lt002.example.com", "lt003.example.com"], }, }
💡 分级标准只认一条：「这个域名被红，你损失多大」。损失大就往上放、加频率；损失小就往下放、降频率。别凭「域名好不好看」分级。

分层抽样具体怎么抽，才能用最少的检测次数覆盖全局风险？

分完层之后，每一层要不要全量测，答案不一样。核心层数量少、价值高，值得全量高频；但重要层和长尾层数量大，如果也全量测，就又回到「测不过来」的老问题。这时就要用分层随机抽样——每一层只随机抽一部分域名测，用样本去「代表」整层。

抽样能成立的逻辑是：同一层里的域名，被红风险是「同质」的。它们后缀相近、业务相近、注册信息相近，如果一个抽样样本里出现了红，大概率整层都已经「集体中招」（比如整层共用同一批共享 IP、同一个注册人、同一套内容模板被平台扫到了）。所以抽样不是为了「省事」，而是因为「同层域名会连坐」——抽几个就能感知整层风向。

抽样比例的三个经验值：

  • 核心层：抽 100%（全检）。数量少、损失大，不值得省。
  • 重要层：抽 30% 左右。每轮轮换，保证几轮之后每个域名都被覆盖过。
  • 长尾层：抽 10% 左右。数量最大、风险最低，抽一成轮换即可守住全局风向。

「轮换」是关键——如果每轮都抽固定的那几个域名，没被抽到的就成了「检测盲区」。所以抽样必须每轮随机、且记录历史已抽名单，确保一段时间内每个域名都被扫到过。下面这张图把「分层抽样 → 检测 → 判断异常」的流程画了出来：

分层抽样检测流程 ① 分层抽样 核心全检/其余轮换抽 ② 四维检测 谷歌/QQ微信/反诈/APK ③ 有无异常？ 抽样样本是否变红 全绿 → 结束本轮 记录已抽名单，下轮轮换 发现红 → 触发追测 进入「异常追测」环节 追测连坐域名 同分组/后缀/共享IP 核心思想：用「抽样」感知整层风向 → 用「追测」把已中招的连坐域名全部捞出

▲ 抽样只是「哨兵」，追测才是「收网」——两者配合，用最少检测次数覆盖最大风险面

下面这段代码实现「分层随机抽样 + 每轮轮换」的核心逻辑：

2

写一个「分层抽样」函数：核心全检、重要抽三成、长尾抽一成，且每轮轮换

用 random.sample 做无放回随机抽样，用一份「历史已抽名单」保证轮换覆盖，避免总抽那几个、留下盲区。

# sampling.py —— 分层随机抽样：用最少检测次数覆盖全层 import random # 历史已抽名单：记录「每层最近被抽过的域名」，用于轮换 recently_picked = {"important": set(), "longtail": set()} def pick_samples(domains, ratio, layer): """从某层随机抽 ratio 比例，优先抽「最近没抽过」的，实现轮换覆盖""" fresh = [d for d in domains if d not in recently_picked[layer]] if not fresh: # 全抽过一轮了，重置 fresh = list(domains) recently_picked[layer].clear() n = max(1, int(len(fresh) * ratio)) picked = random.sample(fresh, n) recently_picked[layer].update(picked) return picked def run_round(tiers): """跑一轮分层抽样：核心全检、重要抽30%、长尾抽10%""" plan = {} plan["core"] = tiers["core"]["domains"] # 核心全检 plan["important"] = pick_samples(tiers["important"]["domains"], 0.3, "important") plan["longtail"] = pick_samples(tiers["longtail"]["domains"], 0.1, "longtail") return plan
💡 轮换是防盲区的关键：如果每轮都抽固定那几个，没被抽到的就成了「永不被测」的死角。记录历史已抽名单，保证一段时间内每个域名都被扫到过。

抽样发现异常后，怎么「追测」把相关域名一网打尽？

抽样样本里只要有一个域名红了，不要只看那一个——它极可能是「连坐」的冰山一角。域名被红很少是孤立的，最常见的连带关系有三类：

  • 同分组 / 同业务：同一套内容模板、同一个落地页批量复制的域名，平台扫到一个，往往会把一批全标上。
  • 同后缀 / 同前缀家族：lt001 / lt002 / lt003 这种批量注册的家族域名，注册时间、注册人、解析记录高度一致，极易连带。
  • 共享 IP / 共享解析：同一个源站 IP、同一台服务器上的邻居域名，被红一个，邻居也跟着遭殃（连坐）。

所以「追测」的本质是：一个哨兵报警了，立刻把「可能被连带」的域名全部拉出来逐个测一遍，把已经中招但还没被抽到的域名一次性捞出来。下面这段代码实现追测逻辑：

3

写一个「异常追测」函数：一个域名红了，把同分组/同后缀的连坐域名全测一遍

追测规则可以自定义：同后缀、同前缀家族、同分组标签、共享 IP。命中一条就进「嫌疑人名单」，逐个跑四维检测。

# expand.py —— 抽样发现异常后，追测「可能连坐」的相关域名 def same_suffix(a, b): return a.rsplit(".", 1)[-1] == b.rsplit(".", 1)[-1] def same_family(a, b): # 前缀家族：去掉数字尾巴后前缀一致（如 lt001 与 lt002） import re base = lambda s: re.sub(r"\d+$", "", s.split(".")[0]) return base(a) == base(b) def expand_investigation(hit_domain, all_domains): """一个域名红了，把所有「可能连坐」的域名列进追测名单""" suspects = [] for d in all_domains: if d == hit_domain: continue if same_suffix(d, hit_domain) or same_family(d, hit_domain): suspects.append(d) return suspects # 使用：抽样样本 hit 变红后，把 suspects 全部跑一遍四维检测 for s in expand_investigation(hit, all_domains): result = check_four_dims(s) # 你已有的四维检测实现 if result["any_red"]: notify(s, result) # 中招的推送告警
💡 追测是「收网」不是「复查那一个」：哨兵报警只说明「整层风向变了」，追测要做的就是把已经连带中招、还没被抽到的域名一次性全部捞出。

把「抽样 + 追测」串起来，就形成一套「抽样哨兵 → 异常追测 → 全量收网」的完整闭环。最后用 crontab 把不同层按不同频率挂起来：

4

用 crontab 把分层检测挂成定时任务：核心 15 分钟、重要 1 小时、长尾 6 小时

核心层高频、长尾层低频，各自独立跑，互不挤占额度。抽样发现异常时，由追测逻辑自动扩大检测范围。

# crontab -e —— 分层检测调度：核心15分钟 / 重要1小时 / 长尾6小时抽样 */15 * * * * cd /opt/domain-check && python3 check_tier.py core >> core.log 2>&1 0 * * * * cd /opt/domain-check && python3 check_tier.py important >> imp.log 2>&1 0 */6 * * * cd /opt/domain-check && python3 check_tier.py longtail >> lt.log 2>&1
💡 check_tier.py 内部逻辑：先按层抽样 → 跑四维检测 → 发现红就调用 expand_investigation 追测连坐域名 → 命中就推送告警。一层一个入口，独立调度。

谷歌域名防红、QQ微信防红、防反诈屏蔽、APK爆毒四个维度怎么分配检测预算？

分层抽样解决的是「测哪些域名」，还有一个维度同样关键：「每个域名测哪几个维度、各测多频繁」。四个维度的「成本」和「紧迫性」并不一样，平均分配同样是在浪费检测预算。下面这张表给出四个维度的差异化分配建议：

检测维度 判定特点 建议频率 预算优先级
防反诈屏蔽 分省运营商 DNS 拦截，波及面最广、用户直接打不开 核心域名 15 分钟 🔴 最高（最先查、查最勤）
QQ微信防红 微信内打开提示风险，与内容强相关 核心域名 30 分钟 🟠 高（社交传播主战场）
谷歌域名防红 Safe Browsing 信誉累积，判定偏慢、有额度 核心域名 1 小时 🟡 中（海外流量、谨慎控额度）
APK爆毒 多引擎报毒率，判定重、会连坐域名 每次发版时 + 每日一次 🟢 常规（有 APK 才重点测）

这里有两个很容易踩的坑，单独拎出来说：

⚠️ 反诈屏蔽是最该「高频」却最常被忽略的一维

很多站长把大部分检测预算砸在谷歌域名防红上，因为「谷歌红」最直观。但实际上对国内业务伤害最大、最该第一时间发现的是「防反诈屏蔽」——它是分省 DNS 拦截，一个省份的用户可能已经打不开了，你却还在盯着谷歌面板看。反诈维度要「最先查、查最勤」，谷歌维度反而可以因为额度有限而放低频。

⚠️ APK爆毒不是「检测一次就完事」，它会连坐域名

APK 报毒率是会变化的——多引擎数据库刷新后，一个昨天还「干净」的 APK 今天可能就爆毒了。更关键的是，APK 爆毒常常连带域名：下载页域名会因为 APK 报毒被平台标记。所以有 APK 业务的域名，要把「APK 爆毒」和「域名防红」两个维度绑定检测，别只测域名不测包、或只测包不测域名。

✅ 记住这套检测资源分配铁律：分层定频率，四维分预算

「测哪些域名」用分层抽样决定——核心全检、重要抽三成、长尾抽一成轮换；「每维测多勤」用预算优先级决定——防反诈屏蔽最先查、QQ微信防红次之、谷歌域名防红控额度、APK爆毒绑定域名一起测。两条规则一横一纵，把有限的检测资源精准投到「最可能出事、出事最疼」的地方，而不是平均撒胡椒面。

❌ 常见误区：「抽样会漏掉没被抽到的域名，还不如不测」

这个想法把「抽样」理解成了「只测一部分、其余不管」。恰恰相反，抽样检测是「哨兵 + 追测」的组合拳：抽样负责快速感知整层风向，一旦样本变红，立刻触发追测把「可能连坐」的域名全部捞出。它漏掉的不是「问题域名」，而是「常年绿的重复确认」——而那部分本来就是浪费。真正的盲区风险，恰恰来自「不轮换的固定抽样」和「只测不追测」，那才是把抽样用错了。

客户怎么说？

"我们的棋牌APP之前每天被封，接入Ai防红后连续运营90天零封禁。"

——某东南亚游戏运营商，月付1500U套餐

"谷歌防红提交后24小时解除Safe Browsing警告，比自己申诉快10倍。"

——某海外贸易平台，使用谷歌防红500U/月

"我手里800多个域名，以前每天全量跑一遍，免费额度三天就没了，还老是漏掉真正出事的。后来按分层抽样的思路，核心域名15分钟一查、长尾域名抽一成轮换，发现红了就追测同批次的，现在额度一个月都用不完，反而更快发现被红的域名。"

——某批量域名运营者，用「分层抽样检测法」把检测成本降了八成

不想自己写抽样脚本，怎么用333Check把上千域名的高效检测交给专业工具？

本文教你用免费工具零成本自建「分层抽样 + 重点监控 + 异常追测」的高效检测体系——完全可以自己搞定。
如果你希望跳过写抽样脚本、配分层调度、维护轮换名单的繁琐步骤，直接把覆盖谷歌域名防红、QQ微信防红、防反诈屏蔽、APK爆毒四维、且按域名价值自动分级的持续检测交给专业工具，联系 @AICDN 免费测试。
检测到域名被红？联系 @AICDN 免费测试，3 分钟出结果。

🔍 提交域名 · 免费获取四维检测结果