简介这是一份面向 Web 开发者与企业后端工程师的微信/QQ官方域名检测接口源码包可用于对接域名真实性校验服务识别伪造或未认证域名提升账户安全与风控能力。压缩包共956个文件大小约3.62MB以 JavaScript 源文件为主辅以 TypeScript 类型声明、JSON 配置、Markdown 说明文档以及 License 和辅助脚本整体分类清晰覆盖接口调用示例、依赖管理与运行配置便于按需集成与排查。已有358人学习下载。资源内的接口调用样例和参数参考可帮助开发者快速理解官方 API 的认证流程与返回数据在社交、电商或企业通讯场景中接入域名真伪校验可减少钓鱼和垃圾信息传播风险。结合文档说明与示例还能降低常见错误处理的学习成本适合中高级技术人员按需二次开发。1. 微信QQ域名检测接口源码一条查询链路避免业务链接断裂运营同学经常会遇到一个诡异场景域名昨天还能在微信里正常转发今天一打开就是“网页包含不安全内容”用户看到提示后直接退出流量一夜归零。这类拦截不提前通知、不给你解释等你发现时往往已经损失了几个小时。这套微信QQ域名检测接口源码就是为了提前发现这种变化它通过调用微信和QQ各自的官方安全检测通道用一段HTTP请求查询目标域名当前的拦截状态再统一封装成API返回结果。适合两类人一类是做导流、短链接的运营需要监控自己域名有没有被封另一类是后端开发想用最少代码把域名检测能力集成进自己的监控体系。下面先从原理说起。2. 检测原理与接口身份“纯官方接口”经过了怎样一条链路2.1 微信域名拦截链路加载前预检与安全提示页微信内置浏览器打开一个链接时并不是直接把页面渲染给你而是先走一遍“安全预检”。这个预检的核心是客户端向微信侧的安全检测服务提交目标URL服务端返回该URL当前的风险状态客户端再根据状态决定直接放行、显示风险提示页还是完全阻止访问。这个预检过程对用户是黑匣子用户只看到“该网页包含不安全内容”的提示但背后的请求参数和响应字段都是固定结构这也是域名检测接口能存在的前提。源码里所谓的“微信检测”本质上就是复刻这个预检请求。请求中一般要带三样东西目标URL、当前登录态的会话票据、客户端标识。返回值里最关键的字段是一个状态值不同数字分别代表正常、风险提示、严重拦截。有一点容易误解预检往往不是同步等到的。微信在实际打开页面时部分场景会先渲染内容再异步拉取安全报告并覆盖拦截提示所以检测接口返回的“拦截”和用户在手机上看到的最终结果会有极短的时间差做监控时没必要纠结这个时差。2.2 QQ域名检测的独立通道移动端与桌面端两条判定QQ的域名拦截链路和微信并不互通。手机QQ访问链接时内置浏览器会调用QQ侧的安全检测服务桌面QQ又走另一套逻辑。这就是为什么现实里经常出现“同一个域名手机QQ提示危险电脑QQ能正常打开”的情况。两套通道的拦截库不完全共享举报数据处理和阈值也不同做监控绝不能只查一边。QQ侧检测的返回结果不像微信那样有一个明显的状态字段。常见的做法是请求QQ的安全查询页面然后解析HTML里的关键文案比如“危险”“恶意”“包含垃圾信息”等。麻烦在于这种页面结果会随活动策略变化比如节假日或专项治理期间同样的域名可能从“无提示”变成“被多人举报”过了那几天又恢复。所以检测代码里必须把文案判断做成可配置的而不是硬编码一组关键词就完事。2.3 “纯官方接口”到底指什么官方业务HTTP服务而非开放API文档这里要澄清一个容易误导的说法。微信和QQ的官方开放平台并没有一个叫“域名安全检测”的对外API文档你翻遍文档中心也找不到对应条目。标题里的“纯官方接口”准确理解是“官方业务客户端自己在调用的HTTP查询服务”源码做的事情是把这条链路的请求参数复刻出来把结果重新编码成方便程序读取的JSON。它不经过任何第三方中转所以叫“纯官方接口”。这也是为什么这类源码通常依赖登录态客户端必须先拿到有效会话票据才有资格调用预检服务。同样“带API”在这个上下文里指的是源码把微信、QQ两条检测链路重新封装成一个统一的HTTP API可以让外部监控系统通过一个/check接口传入域名和平台参数拿到标准化的返回结果。理解了这层身份你就明白为什么这类源码不可能给你一个永久token——会话票据会过期而且请求频率过高会被风控这是后面第五章里最容易被忽略的坑。3. 从源码到服务搭建环境、写检测函数并暴露成API3.1 环境准备与项目结构这类检测源码我在实际项目中重构过好几版下面按一种最常见、也最容易维护的结构来拆解。源码包解压后内部一般分成检测核心和服务入口两部分。你可以把检测逻辑放在checker目录里把HTTP暴露层放在服务入口文件里。wechat_qq_domain_checker/ ├── config.json # 接口地址、会话票据、超时参数 ├── checker/ │ ├── __init__.py │ ├── wechat.py # 微信域名检测 │ └── qq.py # QQ域名检测 ├── server.py # FastAPI 服务入口 └── requirements.txt运行环境推荐 Python 3.8 以上依赖只需要三件套requests负责HTTP请求fastapi和uvicorn负责把检测逻辑暴露成HTTP服务。安装命令如下python3 -m venv venv source venv/bin/activate pip install requests fastapi uvicorn装完后先别急着写代码去config.json里确认三个配置项微信检测接口地址、QQ检测接口地址、当前有效的会话票据。这三个值缺一不可地址错了请求直接失败票据过期了接口会返回错误码但不会告诉你是票据问题后面排错会很头疼。3.2 实现微信检测函数微信侧检测的核心是发送一个带参数的POST请求把要检测的域名交给官方预检服务。下面这个函数就是完整的检测单元注意看参数标准化和超时处理。import time import requests from urllib.parse import quote # 从config.json中读取这里仅做演示 WECHAT_ENDPOINT https://example.com/wx/urlcheck WECHAT_TOKEN login_token_here def check_wechat(domain: str) - dict: 查询微信侧对指定域名的拦截状态 返回: code0 正常; code1 风险提示; code2 严重拦截; code-1 接口异常 normalized domain.strip() if not normalized.startswith(http://) and not normalized.startswith(https://): normalized https:// normalized params { url: quote(normalized, safe), token: WECHAT_TOKEN, _t: int(time.time() * 1000), } resp requests.post(WECHAT_ENDPOINT, dataparams, timeout5) data resp.json() if data.get(errno) ! 0: return {code: -1, msg: data.get(errmsg, 微信接口返回异常)} return {code: data.get(status, 0), msg: ok}这里对域名做了标准化处理先去掉首尾空格再给没有协议头的域名补上https://。这一步很关键因为签名或者服务端判断依赖的是完整的URL格式。quote函数会把://等特殊字符做URL编码避免服务端解析时歧义。timeout5是我实际使用后的经验值低于3秒在弱网环境下容易误报接口异常高于8秒又拖慢整体巡检效率。需要注意这里用的WECHAT_TOKEN是会话票据。不同来源的源码包里这个值可能是通过登录某官方入口后从Cookie或LocalStorage里提取的也可能是预先配置好的长期令牌。无论哪种它都会过期后面会说怎么处理。3.3 实现QQ检测函数QQ侧没有统一的状态字段最常见的实现是请求QQ安全查询接口再对响应文本做关键词判定。这个函数对页面文案的变化更敏感所以我把关键词判断独立出来方便后续调整。QQ_ENDPOINT https://example.com/qq/safety/check QQ_HEADERS { User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0) } def check_qq(domain: str) - dict: normalized domain.strip() if not normalized.startswith(http://) and not normalized.startswith(https://): normalized https:// normalized resp requests.get( QQ_ENDPOINT, params{url: normalized}, headersQQ_HEADERS, timeout6, ) text resp.text if 异常 in text or 危险 in text or 拦截 in text: return {code: 2, msg: 被拦截} if 举报 in text and 正常 not in text: return {code: 1, msg: 风险提示} return {code: 0, msg: 正常}这个实现里有两个经验点。一是User-Agent要尽量贴近QQ内置浏览器的UA空UA或纯Python UA很容易触发服务端的异常行为返回结果可能全是“危险”。二是关键词判定顺序优先判断强拦截词危险、异常、拦截再判断弱提示词举报避免“已被举报”这种同时包含两个关键词的文案被错误分到强拦截里。QQ检测接口的响应体在不同时期会变化。某次活动中页面文案从“已被多人举报”改成了“该网址存在风险”如果你的代码还在匹配旧关键词结果就会从拦截变成正常造成漏报。因此实际部署时我会把关键词列表写到config.json里每次上线后先手动验证两个已知风险域名确认能命中再放开自动化。3.4 用FastAPI暴露统一查询API检测函数写好后最后一步是把它们封装成HTTP接口。用FastAPI只需要很少代码就能完成而且还自动带了请求参数校验和文档页面。from fastapi import FastAPI, Query from checker.wechat import check_wechat from checker.qq import check_qq app FastAPI(title域名检测接口, version1.0.0) app.get(/check) def check( domain: str Query(..., description要检测的域名可不带协议头), platform: str Query(both, descriptionwechat / qq / both), ): out {domain: domain.strip()} if platform in (wechat, both): out[wechat] check_wechat(domain) if platform in (qq, both): out[qq] check_qq(domain) return out启动服务uvicorn server:app --host 0.0.0.0 --port 8000本地验证curl http://127.0.0.1:8000/check?domainexample.complatformbothdomain是必填参数platform默认查两个平台。之所以把平台参数暴露给调用方是因为实际监控中有些域名只跑微信渠道有些只跑QQ渠道每次全查既浪费配额又容易被限流。返回值里wechat和qq分别是一层对象包含code和msg。如果某个平台接口异常它的code会是-1而不是整个请求失败这样外部监控系统就知道是该告警还是该重试。4. 判定规则与参数调优四种返回状态、超时重试和并发限流怎么设4.1 一份清晰的状态码表正常、风险、拦截与接口异常检测服务要能用前提是返回状态可被外部系统理解。不同源码的状态编码不一致有的用0表示正常、-1表示异常有的反过来。我的习惯是统一成下面这张表并在API文档里写清楚code含义建议处理方式0正常可访问不处理1风险提示距完全拦截一步之遥告警准备备用域名2严重拦截用户无法打开立即切换域名-1接口异常非域名端口问题重试或检查会话票据把“风险提示”和“严重拦截”拆开很重要。很多第一次用的人只看“是不是被拦了”结果等到域名彻底被拦才收到告警实际上从风险提示到严重拦截往往只有几天窗口这段时间足够你从容换链。反过来频繁把风险提示当成严重拦截告警运维同学又会麻痹。我实际项目里做到第三周时才真正理解这张表的价值一个导流域名连续三天返回风险提示第四天变成严重拦截如果当时没有提前切换整个投放计划都会受影响。4.2 三个必调参数超时、重试间隔、UA参数调优是整个方案里成本最低但收益最明显的部分。第一个是超时。微信接口我设为5秒QQ是6秒中间差了1秒是因为QQ查询接口的响应体更大、解析更慢。如果你要检测的页面在境外CDN建议整体加到8秒但上限不要超过10秒否则排队请求会把服务拖垮。第二个是重试间隔。接口返回-1时直接重试往往还是-1因为要么是参数问题、要么是网络瞬间抖动。我自己习惯做两级重试第一级间隔3秒重试1次第二级间隔30秒重试1次两次都失败才判定接口异常。这里要注意重试只针对code-1如果返回code1或code2那是域名真实状态重试没有意义。第三个是User-Agent。微信检测接口对UA要求不算严但QQ侧对UA非常敏感空UA或者明显非浏览器UA会直接被判定为恶意请求返回的结果永远是“危险”。建议至少使用常见浏览器的UA并在headers里同时带上Accept-Language和Referer模拟真实客户端访问。下面是一份我目前使用的请求头模板HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Accept-Language: zh-CN,zh;q0.9, Referer: https://example.com/safety, }4.3 并发场景下的信号量限流防止触发风控一旦检测服务被外部系统反复调用并发问题很快就会暴露。如果你不加任何限制监控平台每秒发来几十个请求出口IP会在几十秒内被风控系统记录随后所有请求都会返回“操作频繁”或直接超时。解决思路是在自己这一侧先做限流用一个令牌桶控制请求速率。import time class TokenBucket: 每秒钟补充 refill_per_sec 个令牌桶容量为 capacity用于限制检测请求速率 def __init__(self, capacity: int, refill_per_sec: int): self.capacity capacity self.tokens capacity self.refill refill_per_sec self.last time.time() def acquire(self) - bool: now time.time() self.tokens min( self.capacity, self.tokens (now - self.last) * self.refill ) self.last now if self.tokens 1: self.tokens - 1 return True return False在server.py里实例化一个全局桶比如bucket TokenBucket(capacity10, refill_per_sec1)每个检测请求处理前先调bucket.acquire()拿不到令牌就直接返回{code: -1, msg: rate limited}。容量设10、每秒补1是为了应对突发监控系统扫描一堆域名时前10个能立刻通过后续请求按每秒1个的节奏排队既保证服务可用又不会把出口流量打爆。5. 避坑排查报错、误判与状态抖动应该怎么办5.1 接口返回 errno9003 或其他参数错误码现象调用微信检测接口时返回类似errno9003、invalid url的字段部分实现还会附带“参数不合法”。换了域名也一样并不是某个域名特有的问题。原因我在本地复现过三次基本都是URL标准化不一致。有的接口要求传完整协议头https://example.com有的接口要求只传域名example.com还有的会把末尾换行符一起提交导致签名校验失败。解决在请求前统一走一个标准化函数先strip()去掉空白再用urlparse解析出scheme和netloc只保留域名[:端口]部分最后根据目标接口的文档要求决定是否拼接协议头。同时注意生成签名用的URL必须和实际POST出去的URL完全一致哪怕多一个/都会导致签名校验不通过。5.2 连续查询几十个域名后返回“操作频繁”现象手动测试时一切正常但脚本一跑循环到第30个左右域名就陆续超时或者返回“操作频繁请稍后再试”。原因同一个出口IP在短时间内的请求频率超过了风控阈值。这在第一次接监控系统时尤其常见因为监控脚本总是把检测目标放在一个循环里十分钟内就把所有域名扫了一遍。解决用第四章的令牌桶把速率降下来并把检测任务做成队列而不是并发。我实际用的配置是每秒最多1个请求一小时内最多1000个请求跑了一个季度没再触发过限流。如果你确实有大量域名要检测就把任务拆到多台部署机上让出口IP分散开。5.3 微信正常、QQ拦截同域名结果不一致现象同一个域名check_wechat返回code0check_qq返回code2两边结果对不上。原因这不是Bug而是两套拦截库数据不同步。微信和QQ各自维护独立的安全域名库举报数据、黑白名单更新节奏都不一样出现差异是常态。域名在微信里正常、在QQ里被拦截可能只是QQ侧处理举报更快。解决对外提供的检测接口建议把platform参数默认设为both结果里同时返回两边状态不要合并成一个简单的is_blocked字段。监控告警的规则也要区分场景如果是导流到微信场景只认微信结果如果是做全网监控则任一边返回code2就告警但code1可以保留24小时观察后再决定是否提醒。5.4 UA或会话票据过期导致大面积误判现象检测服务稳定运行几天后某天突然所有域名都返回“被拦截”或“危险”吓得运营紧急切换域名结果人工用手机打开却一切正常。原因会话票据过期后官方接口并不会明确告诉你“登录态失效”而是统一返回一个风险状态的兜底结果。同样的问题也会出现在UA被风控拦下的场景服务端不拒绝请求但返回一个固定的危险标记。解决在检测函数里把响应结果做一层“异常识别”。比如微信接口返回status异常值且errno为特定码时直接返回code-1而不是code2QQ侧如果发现页面文案同时包含“危险”和“请先登录”这类特征也要走接口异常分支。我自己还加了一个自检任务每天固定检测一个已知正常的备用域名如果它返回拦截就说明接口侧出了问题触发重新登录告警。5.5 本地正常、部署到服务器后结果不一致现象本地跑python server.py测试一切正常部署到服务器后同一域名返回的结果不同甚至一部署就全部拦截。原因最典型的是出口IP被风控。服务器的出口IP如果之前有其他恶意行为记录或者被检测服务标记过高危就会拉低所有查询结果的信任度。另外服务器环境里如果缺失系统证书HTTPS请求会验证失败代码里有人会写成verifyFalse绕过结果反而更容易被风控识别。解决用固定的requests.Session把headers统一设置不要每根请求新建连接。同时检查服务器的出口IP是否在本地能正常返回如果本地一切正常、服务器全部异常优先怀疑IP信誉问题换一台干净出口的机器验证最直接。6. 把单次检测升级为定时巡检快照记录、告警通知与回看习惯单次API调用只能回答“此刻这个域名是否被拦”但实际业务需要的是“域名状态从什么时候开始变化”。我最终的做法是加一层定时巡检用一个循环每10分钟跑一次域名列表把每次结果连同时间戳写入本地SQLite同时和历史状态做对比。只有当状态发生跳变时才对外通知比如从0变成1、从1变成2减少无效打扰。import sqlite3 import time conn sqlite3.connect(domain_status.db) conn.execute( CREATE TABLE IF NOT EXISTS domain_log ( id INTEGER PRIMARY KEY AUTOINCREMENT, domain TEXT NOT NULL, platform TEXT NOT NULL, code INTEGER NOT NULL, checked_at INTEGER NOT NULL ) ) def save_result(domain: str, platform: str, code: int): conn.execute( INSERT INTO domain_log (domain, platform, code, checked_at) VALUES (?, ?, ?, ?), (domain, platform, code, int(time.time())), ) conn.commit()告警触发后除了在监控面板里标红我还会把前后几次快照导出来看变化路径。线上有个真实案例一个短链接域名在凌晨3点被标记为风险提示早上7点变成严重拦截由于巡检是10分钟一次我们在3点10分就收到了第一条告警赶在流量高峰前把链接切到了备用域名。这个巡检服务里我养成了一个习惯不追求实时只追求连续。10分钟一次的频率足够覆盖绝大多数业务场景比实时检测更不容易被风控也更容易从历史数据里看出规律。比如某个域名每到晚上就被标记风险、早上自动恢复那基本可以断定是夜间用户举报集中导致的临时状态没必要一看到风险就切换域名。希望帮到你。本文还有配套的精品资源点击获取