微信域名批量检测实战：模拟UA与特征词库识别拦截状态

简介面向互联网从业者与网站管理员的微信域名批量检测工具用于解决微信内置浏览器对外部链接严格管控导致的域名无法正常访问问题。工具通过模拟微信内核环境支持批量输入或导入网址快速检测域名可用性并导出报告适合依赖微信流量运营、需要批量维护域名白名单或排查链接被屏蔽场景的用户使用。压缩包共64个文件大小12.17MB主要包含53个pak资源文件、5个dll动态库、1个exe主程序另附说明文档、源码下载指引及界面图片等其中dll与pak用于支撑工具运行与界面展示txt和htm文档则帮助用户快速上手并了解源码获取途径。目前已有365人学习下载。该工具能有效替代人工逐个在微信中打开链接验证的繁琐流程导出结构化检测结果后可方便后续统计分析域名状态同时附加的源码下载说明也为有二次开发需求的用户提供参考。1. 草根微信域名批量检测工具没有官方接口怎么判断域名在微信里“死了”做微信生态的运营或开发大概率都遇过这种窘境客户说链接在微信里打不开你换个浏览器试了一下一切正常查了半天才发现域名被微信拦了。问题是手上一两百个域名要持续盯微信官方又没有开放“域名体检”接口挨个拿手机扫码是纯体力活。草根微信域名批量检测工具 v8.0 要解决的就是这件事在接入网页授权回调域名、JS 接口安全域名、微信支付授权目录之前快速筛掉已经被拦和即将有风险的域名。它的核心思路不是去调什么神秘接口而是模拟微信内置浏览器的访问特征去探测返回内容。适合一个人维护几十个站点、没有专职安全人员的草根站长、渠道代理以及做公众号和小程序生态的开发。2. 微信对域名的判定机制与 v8.0 的整体架构一次检测请求背后发生了什么2.1 微信拦截域名的真实粒度不是只有“封域名”这一档微信对域名的管控并不是一个简单的开关。当用户在微信里点开一个链接微信客户端会先做本地域名判断再请求腾讯侧的链接安全检测服务拿到页面安全等级后决定是放行还是用本地拦截页替换真实页面。你在微信里看到“已停止访问该网页”“网页包含诱导分享、关注等诱导行为内容被多人投诉”这类固定文案就是微信内置浏览器在客户端本地渲染出来的安全提示页。也就是说被拦的域名可能在你的服务器上连一个请求都没收到访问链路在微信这一层就被掐断了。这带来一个工程上的关键结论检测工具如果只做 TCP 连通性或 DNS 解析测试结论是“域名正常”实际在微信里可能已经是死链。所以草根工具的判定必须发生在 HTTP 这一层并且要模拟微信的请求特征。另一个容易忽略的点是拦截粒度。整域名被拉黑是一种情况只拦截某个路径是另一种情况。比如一个域名下某个落地页被举报其余页面还能正常打开这在批量检测里很容易漏掉。做 v8.0 这类工具时我一般在输入层保留完整 URL不自动删路径和查询参数并在结果里多出一列“拦截粒度”方便后续到底是换域名还是只换落地页。顺带一提微信公众号后台配置网页授权回调域名和业务域名时填的也是带路径的地址输入层按完整 URL 处理才贴合真实业务场景。还有一个和检测结果强相关的点微信对域名的安全判定是实时且动态的。今天正常不代表下周还正常投诉量上去以后原本白名单里的域名也可能被临时拦截。因此批量检测工具的使用场景不只是上线前预检还包括持续巡检——比如每周把渠道域名清单整体跑一遍再配合第三方的域名拦截查询接口做交叉验证。把巡检做成固定任务后才发现真正帮你省时间的不是“检测”本身而是把检测结果分类、追踪和告警这一整套流程。2.2 草根检测的原理闭环UA 模拟、抓返回、特征匹配草根级别的域名检测工具说到底是在用“欺骗层”的方式探测微信的判定结果。常见的实现路线有两条。一条是模拟微信内置浏览器的 User-Agent 发起 HTTP 请求抓到服务器返回的内容再用特征词库判断是不是微信拦截页另一条是调用腾讯侧未公开的 URL 安全检测接口把域名抛过去拿 JSON 结果。前一条可控性强、不依赖第三方服务稳定性后一条速度快但对参数格式很敏感官方接口一旦调整就容易拿不到结果。做 v8.0 这类偏向自用和长期维护的工具我建议把第一条作为主干把第二条作为辅助交叉验证两边结果一致才出结论。整个检测链路一般是这样的先对域名清单做格式化补协议、去空格、去重然后逐个发起带微信 UA 的 GET 请求拿到状态码和响应体再做一次压缩和编码处理用特征词库匹配拦截文案和验证页文案最后决定这一条 URL 的状态是正常、疑似拦截、无法访问还是需人工复核。为了降低误判每个 URL 会做两次请求两次结果一致才出最终结论不一致就归到“需人工复核”。这个二次复核机制对草根工具特别重要因为微信的安全页有时会临时跳去“安全验证”页单次请求很容易把验证页当成拦截页产生不少假阳性。我遇到过有人为了省时间直接拿 HTTP 状态码判断域名状态看到 404 或 500 就判定为“域名挂了”。实际上微信拦截页返回的往往也是 200而很多正常单页应用在某些路径下也会返回 404。状态码只能作为辅助维度真正有区分度的是响应体的内容特征。这也是为什么特征词库的质量直接决定工具好不好用。2.3 分层结构和参数维护v8.0 比老版本强在哪草根工具的迭代史基本就是把一个不能维护的大脚本慢慢拆成可维护的小模块。常见做法是把工具拆成四层输入层支持 txt、CSV、Excel、剪贴板粘贴、引擎层请求调度、并发池、超时、重试、代理、判定层特征词库、状态码、阈值、输出层CSV 结果、控制台汇总、未通过清单单独落盘。这个结构对一个人维护最友好判定层加词不用动引擎引擎层调并发不用动输入解析。层级职责关键参数输入层读取域名清单并规范化支持格式、默认协议、去重规则引擎层发起请求、调度并发、重试timeout、workers、重试次数、请求间隔判定层特征匹配、结果分级特征词库、状态码映射、复核阈值输出层结果落盘与展示输出格式、分级策略参数层面我会重点维护三块。一是请求参数timeout 默认 8 秒重试 2 次单 URL 检测间隔不低于 1.5 秒二是特征词库把微信各版本拦截页的固定文案、标题、跳转逻辑单独抽出存成数组或正则列表三是并发参数线程数默认 5 到 8整体 QPS 压到 5 以内防止本机 IP 被微信侧临时限制。这些值不建议一开始就拍脑袋定死要先拿 20 个已知状态的域名做校准再根据你自己的网络线路和域名规模逐步调整第 5 章的踩坑记录里会展开讲。3. 最小可跑的域名检测脚本requests 与特征词实现 v8.0 单域名检测3.1 微信内置浏览器 UA 与请求伪装先把单个域名的检测脚本跑通再谈批量。核心是请求头里的 User-Agent 要尽量接近真实微信内置浏览器。以下是一段能直接跑的最小代码我用它做了 v8.0 的单测基座。import requests WECHAT_UA ( Mozilla/5.0 (Linux; Android 10; M2006C3C) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.120 Mobile Safari/537.36 MicroMessenger/8.0.47(0x28002F3B) WeChat/arm64 Weixin NetType/WIFI Language/zh_CN ) def detect_single(url, timeout8): headers { User-Agent: WECHAT_UA, Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8, Accept-Encoding: gzip, deflate, } try: resp requests.get( url, headersheaders, timeouttimeout, allow_redirectsTrue ) return resp.status_code, resp.text except requests.RequestException as e: return None, str(e)这段代码最关键的参数有三个。第一个是WECHAT_UAMicroMessenger 后面的版本号建议跟着主流微信版本走老 UA 容易被风控识别成机器人新 UA 可能还没覆盖你目标用户的微信版本所以这个版本号要定期更新。第二个是timeout默认 8 秒足以覆盖国内大多数机房响应但遇到境外服务器可以单独调大。第三个是allow_redirectsTrue微信拦截逻辑里经常出现 302 跳转不跟随的话拿不到最终页面也就无法判断是否被拦。3.2 特征词库与状态码的组合判定拿到响应体和状态码之后接下来要做的是判定。微信拦截页的文案在不同版本里略有差异但核心措辞一直比较稳定我把它们维护成一个特征词数组用包含匹配而不是全等匹配避免网页加了些噪声标签导致漏判。BLOCK_KEYWORDS [ 已停止访问该网页, 网页包含诱导分享, 被多人投诉, 该网页已屏蔽, 恶意营销, ] VERIFY_KEYWORDS [ 请完成安全验证, 拖动滑块完成验证, 安全验证, verify, ] def classify(status_code, html): if status_code is None: return unreachable if not html: return empty text html.lower() for kw in BLOCK_KEYWORDS: if kw.lower() in text: return blocked for kw in VERIFY_KEYWORDS: if kw.lower() in text: return verify if status_code 400: return http_error return normal这里的判定顺序是有讲究的先查拦截词再查验证页词最后才看状态码。因为微信拦截页的 HTTP 状态码往往也是 200先看状态码会把拦截页误判成正常页。VERIFY_KEYWORDS单独拎出来也很关键它对应微信风控返回的人机验证页这类页面不代表域名被封只代表当前 IP 或 UA 触发了安全策略应该归到“需人工复核”而不是“已拦截”。特征词库的维护不要只靠网上抄来的几条我一般会定期用真机打开几个已知正常和已知被拦的域名把页面源码保存下来手动比对提炼新的关键词。3.3 响应内容里的编码坑不转码特征词匹配全是空实际抓回来的页面不一定是纯 UTF-8。不少老站点还是 GBK 或 GB2312 编码requests 会按响应头里的 charset 去解码但如果服务器没在响应头里声明 charsetrequests 默认用 ISO-8859-1中文字符全变成乱码。这时拿特征词去做包含匹配结果永远是 False域名被拦了也报 normal。import chardet def decode_html(resp): if resp.encoding and resp.encoding.lower() in (utf-8, gbk, gb2312): return resp.text guess chardet.detect(resp.content) enc guess.get(encoding) or utf-8 return resp.content.decode(enc, errorsignore)所以在 v8.0 的单测脚本里我不用resp.text而是先拿resp.content做编码探测再手动 decode。这一步不处理后面不管加多少特征词都是白搭。另外顺便说一下resp.content拿到的可能是 gzip 压缩后的二进制requests 在Accept-Encoding里声明支持 gzip 时会自动解压所以这里不需要手动处理但如果有一天你改用其他 HTTP 客户端就得自己解压否则特征词匹配同样失效。4. 批量域名的并发调度与结果导出把单测脚本变成 v8.0 工具4.1 域名清单规范化这步不做检测结果全是噪声单测跑通之后批量化的第一个坑是输入脏数据。很多人直接从 Excel 或网页后台复制域名清单里面带着换行、空格、引号、逗号甚至有的行是“域名备注”混在一起的。如果不做规范化脚本会把“example.com备注”当成一个域名去请求结果自然是 unreachable然后你还得人工去核对白费功夫。from urllib.parse import urlparse, urlunparse def normalize_url(raw): raw raw.strip().strip().strip(,) if not raw: return None if :// not in raw: raw https:// raw u urlparse(raw) if not u.hostname: return None path u.path or / return urlunparse((u.scheme, u.netloc, path, , , ))这里有个默认协议选择的细节。我习惯默认补https://而不是http://因为微信内置浏览器对 HTTPS 和 HTTP 的拦截策略并不完全一致线上正式业务基本都是 HTTPS按 HTTPS 检测出的结果才贴近真实用户场景。补协议之后保留路径是为了能检测“整站正常、单页被拦”的情况前面章节说过这个粒度差异。另外查询参数我选择丢弃因为带 query 的 URL 检测结果可复现性差也和配置白名单时填的域名格式不一致。4.2 线程池限速与二次复核快不是目的稳才是批量检测最忌讳的就是一股脑并发。很多人第一次写批量脚本直接开 50 个线程结果跑了 300 个域名之后后面所有请求全变成安全验证页或“操作频繁”整批结果作废。微信侧对同一个 IP 的访问频率有风控这个东西没有明确阈值但经验上整体 QPS 控制在 5 以内基本安全。from concurrent.futures import ThreadPoolExecutor, as_completed import time def run_batch(urls, workers5, retries2, interval1.5): results {} def worker(url): first detect_single(url) first_label classify(first[0], first[1]) if retries 0: time.sleep(interval) second detect_single(url) second_label classify(second[0], second[1]) final_label first_label if first_label second_label else review_required else: final_label first_label return url, final_label with ThreadPoolExecutor(max_workersworkers) as pool: futures [pool.submit(worker, u) for u in urls] for future in as_completed(futures): url, final_label future.result() results[url] final_label return results这段代码里的几个参数直接决定工具的可用性。workers5是线程数不是越大越好建议从 5 起步retries2代表每个域名最多请求两次两次结果不一致就标记review_requiredinterval1.5是同一域名两次请求之间的间隔秒数这个间隔加上 workers 的数量决定了整体请求速率。把interval调大比调小 workers 更有效因为微信风控更多是看单位时间内的请求总量。二次复核机制对结果质量的影响很大。我拿自己的清单做过统计单次检测的误报率大约在 15% 左右大量误报来自风控验证页和临时网络抖动。加了二次复核后误报率能降到 3% 到 5%节省的却是逐个手工确认的时间。所以这个机制不是可选项是必须项。4.3 结果导出与分级正常、疑似拦截、需人工复核检测结果如果只打印在控制台别人没法用。这里我按三个级别输出到 CSV再用不同文件名区分避免把正常域名和异常域名混在一起。import csv def export_results(results, base_name): groups { normal: [], blocked: [], unreachable: [], verify: [], review_required: [], } for url, label in results.items(): groups.setdefault(label, []).append(url) with open(f{base_name}.csv, w, newline, encodingutf-8-sig) as f: writer csv.writer(f) writer.writerow([URL, 状态]) for url, label in results.items(): writer.writerow([url, label]) for label in (blocked, review_required): with open(f{base_name}_{label}.txt, w, encodingutf-8) as f: f.write(\n.join(groups.get(label, [])))这里有个细节CSV 的 encoding 一定要用utf-8-sig不是utf-8。不带 BOM 的 UTF-8 文件用 Excel 打开中文字段会全部乱码而review_required.txt这种纯文本清单用来给人工复核用倒是无所谓编码。分文件导出还有一个好处后续做巡检时可以直接拿上一次的blocked.txt和这次的做 diff看出哪些域名是持续被封、哪些恢复了这对跟进渠道投诉非常有用。到了这一步工具的骨架已经完整输入域名清单自动规范化并发检测二次复核结果分级导出。但真正的可用性是在避坑过程中磨出来的下一章写几个我实际踩过的坑。5. 微信域名检测避坑与排查五个很容易误判的场景5.1 “安全验证”页被当成拦截页误报率飙升现象第一次跑批量检测跑出来的 blocked 域名有四十多个拿手机扫码一看大部分根本不是拦截页而是“请完成安全验证”的滑块验证页。原因微信风控对可疑 IP 和 UA 会先返回一个人机验证页这个页面状态码同样是 200且页面里的文案和真实拦截页有部分重叠。如果特征词库里写了“已停止访问”这种宽泛词验证页也可能命中更常见的是根本没写验证页特征词所有非正常页面都被归到了 blocked。解决把验证页特征词单独抽出来比如“请完成安全验证”“拖动滑块”“verify”在判定逻辑里先查拦截词、再查验证页词命中的验证页归到verify状态不进 blocked。另外要从源头减少验证页出现频率控制请求速度。我在工具里加了一个统计项如果一批检测里verify占比超过 10%就提示检测者当前 IP 已经被风控盯上建议停一会儿再跑或者换网络出口避免后边的请求全部失真。5.2 工具报正常手机微信打开却被拦截现象v8.0 跑出来一批 normal 域名交付给渠道后对方反馈其中两个在微信里打不开复核发现确实被拦了。原因这是最让人头疼的假阴性。排查下来发现问题出在 UA 指纹上。我脚本里的 MicroMessenger 版本还停留在 8.0.30 左右而当时用户的主流微信已经到 8.0.40 以上微信侧对不同版本的内置浏览器 UA 返回的拦截策略不一样。老 UA 拿到的可能是一张正常的错误页或重定向新 UA 才会拿到真正的拦截页。解决用微信开发者工具或真机抓包把当前主流微信版本的内置浏览器 UA 抓出来替换掉特征库里的旧值。更稳妥的办法是维护两到三个不同版本的微信 UA对同一个域名分别请求只要其中一个返回 blocked就把结果标记为“疑似拦截”而不是用单一 UA 的 normal 下结论。这个多 UA 交叉验证逻辑我后来直接加进了判定层。5.3 域名服务器在国外检测结果大量超时现象一批面向海外用户的域名检测结果里 unreachable 占了六成但实际这些域名在微信里都能正常打开。原因我的检测脚本跑在自己本机或国内普通云主机上到海外机房的线路延迟高、丢包多8 秒超时根本不够用。更要命的是微信对域名的拦截判断节点在国内我在国内发起请求的路径和微信真实用户的访问路径并不完全一致把网络不可达误判成了拦截。解决先区分问题层次。对 unreachable 的域名加一个不带微信 UA 的普通请求做对照如果普通请求也超时说明是网络层面问题先做 cURL 连通性测试如果普通请求正常、只有微信 UA 请求超时才考虑微信侧是否对请求做了限制。其次是把超时从 8 秒提高到 12 秒并考虑把检测节点部署到离目标用户更近的国内机房。工具的使用场景要提前想清楚你是要给国内用户用的站点做检测那节点放国内就行如果目标用户本身在海外就需要在海外和国内各跑一轮分别出报告。5.4 批量跑到一半请求全被限流现象清单里有 800 个域名跑到第 300 个左右后续请求几乎全部返回验证页甚至有一些直接超时。第一轮结果和第二轮复核结果对不上整批数据只能作废重跑。原因单 IP 在短时间内的请求频率超过了微信侧的默认识别阈值。做了二次复核之后实际请求次数是域名数量的两倍也就是 800 个域名实际会发起 1600 次请求频率直接翻倍触发限流是必然的。解决把检测任务拆成分片。每 100 个域名算一片片与片之间休息 30 到 60 秒片内的并发控制在 3 到 5间隔维持在 1.5 秒以上。同时把二次复核的间隔适当拉长比如从 1.5 秒改成 2 到 3 秒。这样跑完 800 个域名的时间会拉长但数据的可信度完全不是一个级别。如果你的域名清单本身就经常超过 1000 个建议直接在引擎层做成分布式任务把来源 IP 分散到多个节点而不是铤而走险加速并发——限流之后的清理成本远比慢跑一轮要高这是血泪经验。5.5 只测“打得开”没测“回调用得通”交付给网页授权配置时翻车现象工具测出的正常域名配置到网页授权回调域名后公众号网页授权仍然报错“redirect_uri 参数错误”或“该域名无权限”。原因微信服务器回调你的服务器和用户访问你的域名是两条完全不同的路径。大多数草根工具检测的是“用户用微信打开这个页面会不会被拦”但没做“微信服务器能否访问你的回调接口”的验证。前者测的是访问链路后者测的是回调链路。一个域名即使访问完全正常也可能因为 ICP 备案问题、服务器白名单没配、或接口地址路径对不上导致回调失败。解决在 v8.0 里单独加一个“回调自检模式”。流程是填一个待验证的域名工具自动拼接一个测试用的随机路径用微信服务器的 DNS 解析结果去请求这个地址检查是否返回 200以及响应体是否符合微信要求的文本格式。这个模式没法完全模拟真实的微信回调但能提前暴露大部分配置问题域名没备案、服务器屏蔽了非浏览器 UA、路径映射错误都能在这一步暴露。真机验证时再用公众号后台的“修改配置”页面去提交一次看微信给出的具体报错码。工具不是万能的但至少能帮你把六成问题在上线前拦住。6. 真机与微信开发者工具复核把检测结果收敛成可配置清单批量检测跑出来的结果只能作为候选清单不能直接拿去配置白名单。我最后一步习惯用微信开发者工具和真机做复核把工具结果收敛成一份能直接提交给后台配置的清单。操作上分三步。第一步把blocked.txt和review_required.txt里的 URL 逐个粘贴到微信开发者工具的模拟器地址栏观察页面是不是微信安全提示页。开发者工具模拟器虽然不完全等同于真机但对拦截页的渲染和真机一致性很高这一步能快速剔除掉工具误报。第二步对仍然显示拦截页的域名再用普通浏览器开一遍如果普通浏览器能正常打开就确认是微信侧的应用层拦截把这条域名标记为“确认拦截”。第三步抽几个 normal 状态的域名用手机微信扫码在聊天中打开确认没有经过任何中间跳转就直接展示真实页面。我在这个环节有个习惯复核时全程开着抓包工具或者至少盯着开发者工具的请求列表。如果发现某个本来正常的页面在微信里被 302 到一个可疑域名那这个域名多半已经被人举报过且正在被观察期我会把它从可配置清单里暂时拿掉等下一轮巡检再看。配置网页授权回调域名这类白名单时宁可少配也不能配一个有隐患的域名因为白名单一旦进了黑名单处理起来比普通域名麻烦得多。早期我踩过不少坑最深刻的教训就是太信任脚本输出。工具只能告诉你这个域名在检测那一刻、从检测节点看过去是正常的不能保证它在用户手机上、在晚上八点的流量高峰里依然正常。后来我把工具定位从“检测工具”改成了“筛选工具”所有结果都默认加上“需人工复核”的保留意见反而交付出去的清单没再出过批量翻车。想让工具替你判断就先把特征词库喂够想让工具替你省时间就千万别省那两步复核。希望这篇实战记录能帮你把 v8.0 真正用起来少走我走过的弯路。本文还有配套的精品资源点击获取