企业官网建设流程全解析

简介：微信域名检测接口是一份面向开发者的、可直接运行的源码包，主要帮助需要监控域名在微信内可用性的开发者，解决域名被屏蔽后难以察觉的问题。核心机制是解析响应头：若服务器返回的重定向地址指向微信官方拦截提示页，则判定域名已被屏蔽；否则视为正常。资源共3个文件，包含HTML页面、inscode配置与gitignore文件，压缩包大小仅为7KB，结构精简，适合快速部署与学习，目前已有102人学习。除官方检测逻辑外，作者还提供了自建免费接口的调用方式，可免去自搭检测系统的繁琐。通过阅读这份可运行源码，开发者能获得域名状态判断的完整实现，包括响应头解析、页面调用示例等，并可在其基础上扩展批量监测、异常告警等功能，适配运维监控、安全风控等实际场景。

1. 微信域名检测接口到底是什么：一个被逼出来的自检需求

某开发者上线的活动 H5 刚放出去三个小时，群里就有人截图说"链接打不开了"。他第一时间用电脑浏览器打开，页面秒开；又用手机流量打开，也正常；最后拿另一台手机在微信里点，屏幕中间直接弹出一行灰色小字——"已停止访问该网页"。他一脸懵：域名没换、服务器没挂、备案也在，怎么就被抬走了？这正是微信域名检测接口存在的理由：在链接被用户看到之前，先把域名在微信侧的可用状态摸清楚。这类接口通常以可运行源码的形式流传，封装好请求构造、参数加密、状态解析三块逻辑，部署后变成一条 HTTP 接口或命令行工具，供业务方随时自检域名是否被拦截、被处罚、处于观察期。适合谁？凡是域名会出现在微信聊天、朋友圈、公众号菜单里的运营或开发者，都应该在发布流程里加一道这道检测。

2. 微信域名检测的判定机制与接口选型：为什么不能只靠 UA 伪装

2.1 微信拦截的判定链路：从举报触发到策略生效

很多人以为域名被封是"被人举报了一次就立刻封"。实际上微信侧有一套分层触发的逻辑：用户举报、系统内容识别、短时间分享异常，三类信号会汇总到策略引擎；达到阈值后域名先进观察期，此时部分用户访问会看到中间提醒页，其余用户仍可正常访问；观察期内继续触发才会升级为完整拦截，所有微信内访问都指向"已停止访问该网页"。这个链路意味着你没法用一个静态名单去判断域名状态，同一个域名在观察期前后返回的检测结果完全不同。

所以检测接口的本质，不是去查某个"黑名单数据库"，而是模拟一次微信内真实访问，让微信自带的安全检测通道返回该域名当前策略下的实时状态。这决定了接口的实现思路：必须让请求尽可能像真实用户，UA、来源、请求参数、时间戳都真实，结果才有参考价值。

2.2 两种检测来源：官方公示接口 vs 客户端内置检测通道

做域名检测有两条路。第一条是微信官方面向站长的申诉与公示入口，它可以查某个域名是否在封禁名单里，也能提交申诉。这条路的优势是权威、合规，缺点是实时性差，名单更新有延迟，而且只告诉你"封了"或"没封"，拿不到中间态信息，观察期这种最需要预警的状态完全看不到。另一条路是模拟微信客户端内置浏览器在打开链接前做安全预检时调用的检测通道，返回结果包含更细化的状态码，能区分正常、封禁、中间页、诱导分享受限等场景。社区中流传的"微信域名检测接口"源码，绝大多数都是第二条路。

为什么社区普遍选第二条？因为做业务的人真正需要的不是"事后知道被封"，而是"刚刚进入观察期就知道，赶紧收敛流量、准备申诉材料"。只有客户端检测通道能给出这种粒度。代价是这条路依赖微信内部接口的参数规则，参数结构一变，老源码立刻失效，这也是后面避坑章节要重点讲的。

2.3 选型结论：用内置检测通道，但必须控制模拟的真实度

我一般会给团队立一个规矩：检测接口只做自检和监控，不做对抗。所谓"不做对抗"，就是不要去模拟大量虚假分享、不要用检测通道去试探账号行为边界、不要用它批量探测别人家的域名。把它当成一个业务健康度自检工具，而不是攻击工具。真实度控制方面，一个请求里最重要的三件事是：UA 必须用真实的微信内置浏览器 UA、请求头里的加密参数必须由当前时间戳实时生成、Referer 要保持和正常访问一致。这三项有一项是假的，检测结果就可能失真，甚至触发对检测方 IP 的风控。

明确了选型之后，下面进入正题：把这套检测逻辑用 Python 跑起来。源码层面我按最常见的工程组织方式来拆，你拿到任何一份别人的源码，也能按同套结构快速定位关键模块。

3. 用 Python 把检测接口跑起来：最小可运行源码拆解

3.1 工程结构与依赖准备

一份可运行的微信域名检测源码，不管作者怎么组织，核心模块就那么几个：请求构造、参数加密、状态解析、调度入口。我习惯的最小工程结构是这样：

wechat-domain-check/ ├── requirements.txt ├── config.py # 网关地址、超时、并发数等配置 ├── crypto_utils.py # 加密参数生成 ├── checker.py # 核心检测函数 ├── batch_check.py # 命令行批量检测入口 └── server.py # HTTP 接口服务

依赖只保留三个，避免环境问题：

requests==2.31.0 flask==3.0.0

其中 requests 负责发请求，flask 用来把检测能力封装成可以被其他语言或系统调用的 HTTP 接口。如果你只在命令行用，flask 可以去掉。这个结构的好处是，无论拿到谁的源码，先去crypto_utils.py看加密算法，去checker.py看状态解析，五分钟就能定位到和你预期不一致的地方。

3.2 核心检测函数：请求构造、加密参数与状态解析

import hashlib import time import requests from config import GATEWAY_URL, SALT, TIMEOUT def _sign(url: str, timestamp: str) -> str: raw = f"{url}{SALT}{timestamp}" return hashlib.md5(raw.encode("utf-8")).hexdigest() def check_domain(url: str) -> dict: timestamp = str(int(time.time())) sign = _sign(url, timestamp) payload = { "url": url, "timestamp": timestamp, "sign": sign, } headers = { "User-Agent": ( "Mozilla/5.0 (iPhone; CPU iPhone OS 16_6 like Mac OS X) " "AppleWebKit/605.1.15 (KHTML, like Gecko) " "Mobile/15E148 MicroMessenger/8.0.49" ), "Referer": "https://wx.qq.com/", } resp = requests.post( GATEWAY_URL, data=payload, headers=headers, timeout=TIMEOUT, ) resp.raise_for_status() data = resp.json() return { "url": url, "status_code": data.get("status"), "status_text": data.get("msg", ""), "checked_at": timestamp, }

这段代码是整套源码的心脏。_sign函数做的事是把待检测域名、固定盐值、当前时间戳拼接后做 MD5，得到签名参数。这个签名的作用是让网关认为请求来自合法的客户端调用，而不是手工构造的探测请求。check_domain内部用 POST 把参数发给网关地址，网关返回 JSON，里面至少包含status字段，表示当前域名在微信侧的策略状态。

参数说明：SALT是每个源码版本都不一样的固定字符串，存在于config.py里；拿到别人的源码先核对这个盐值和你抓包拿到的是否一致——不一致时结果会全军覆没，这属于高频踩坑。GATEWAY_URL是网关地址，同样在配置里改。TIMEOUT我一般设 5 秒，检测服务响应慢时立刻超时报错，防止批量任务卡死。注意Referer我用了wx.qq.com，这是常见做法，让请求来源看起来是从微信相关页面发出的；如果你的抓包版本里来源不同，以你自己抓到的为准。

3.3 批量检测：并发控制与结果落盘

实际使用中很少只测一个域名。运营手里的域名可能几十上百个，逐个跑太慢，我一般用线程池把并发控制在 3 到 5 之间：

from concurrent.futures import ThreadPoolExecutor, as_completed import csv def batch_check(urls: list[str], concurrency: int = 3) -> list[dict]: results = [] with ThreadPoolExecutor(max_workers=concurrency) as pool: futures = {pool.submit(check_domain, u): u for u in urls} for future in as_completed(futures): try: results.append(future.result()) except Exception as exc: results.append({ "url": futures[future], "status_code": -1, "status_text": str(exc), "checked_at": "", }) return results if __name__ == "__main__": urls = [ "https://example.com/page1", "https://example.com/page2", ] rows = batch_check(urls) with open("result.csv", "w", newline="", encoding="utf-8") as f: writer = csv.DictWriter(f, fieldnames=["url", "status_code", "status_text", "checked_at"]) writer.writeheader() writer.writerows(rows)

并发数为什么压到 3？我踩过并发太高导致整个 IP 被网关临时限流的坑，网关那边有明显的时间窗口计数，10 个并发持续跑一分钟，后面所有请求都会返回"频率超限"。用 3 个线程跑 100 个域名，单轮耗时大概几十秒，且不容易触发风控。结果落成 CSV 是为了后续比对，第一次检测结果作为基线存起来，之后每次检测都和基线对比，状态变化一目了然。

3.4 封装成 HTTP 接口：让其他系统也能调用

命令行工具只方便开发自己用。业务侧的活动系统、监控系统要接这个能力，就得把检测逻辑包成一个 HTTP 接口：

from flask import Flask, request, jsonify from checker import check_domain app = Flask(__name__) @app.route("/check", methods=["POST"]) def check(): data = request.get_json() url = data.get("url", "").strip() if not url: return jsonify({"error": "url is required"}), 400 result = check_domain(url) return jsonify(result) @app.route("/check_batch", methods=["POST"]) def check_batch(): data = request.get_json() urls = data.get("urls", []) if not urls or len(urls) > 50: return jsonify({"error": "urls must be 1-50 items"}), 400 results = [check_domain(u) for u in urls] return jsonify({"results": results, "count": len(results)}) if __name__ == "__main__": app.run(host="0.0.0.0", port=8000)

接口设计上，/check处理单条检测，/check_batch处理批量，单批上限 50 条，防止外部调用方一次塞几百个域名把网关请求频率打爆。这里没有加鉴权，是因为它通常跑在内网或本机；如果部署到公网，务必在前面加一层 token 校验，否则这个接口会成为别人刷检测的免费入口，你的 IP 也会被网关牵连。app.run的参数里 host 设成0.0.0.0是为了让同网段的其他机器能访问，端口用 8000 避开常见冲突。

4. 检测结果的状态码与误判处理：封禁、中间页、正常之外的第三种情况

4.1 状态码语义对照表

不同源码版本返回的status字段取值略有差异，但主流的语义大致如下：

这个表看起来简单，真正容易翻车的是 status 为 3 的观察期。很多团队只看 1 和 2，观察期状态被当成"正常"忽略，结果两天后观察期升级成封禁，投放早就炸了。我这边在状态解析逻辑里会额外加一条规则：status为 3 时，在结果里强制标记为WARN，并且让它触发告警，和正常状态严格区分。

4.2 误判的三个来源：UA、请求频率、签名时效

排查误判时，优先怀疑三件事。第一，UA 太假——有些源码把 UA 写死成旧版微信，网关升级校验后，旧 UA 会被直接判为可疑请求，返回一个恒定的错误状态。判断方法很简单：同一个域名，换用你手机微信里实际使用的 UA 字符串再测一次，结果从"封禁"变成"正常"，就是 UA 过期导致的误判。第二，请求频率——批量检测时线程池并发太高或循环调用没有 sleep，导致 IP 被临时限流，此时所有域名都返回"异常"或"-1"，不是域名真的被封。第三，签名时效——timestamp参数如果和服务器时间偏差超过一定窗口，签名校验会失败，返回的结果是"正常"还是"封禁"完全随机，看起来像状态漂移。遇到这种情况，先校准服务器时间，再检查_sign函数的拼接顺序和源码里的盐值是否匹配。

4.3 用小流量灰度验证准确率

一个检测接口拿到手，不能立刻全量信任，先做一轮灰度验证。找 30 个域名，其中包含确定正常的、确定被封的、在观察期的各若干，先用微信客户端人工确认一次真实状态，再用检测接口跑一遍，得出准确率。低于九成说明请求构造有问题，高于九成再接入监控流程。这一步是血泪经验换来的——有人在第三方买的接口跑一次全绿，上线两天后域名被封，才发现第三方接口只是"能通"而不是"测得准"。灰度验证的脚本比较简单，就是把 30 个域名放 CSV 里，跑批量检测，再手工比对，半小时出结论，别跳过。

5. 微信域名检测的避坑指南：参数失效、频率限制与申诉节奏

5.1 踩坑一：加密参数过期导致全线返回"正常"

现象：源码刚部署时检测一切正常，某天开始所有域名都返回状态码 1（正常），连一个明显在微信里打不开的域名都显示正常。原因：网关升级了签名算法或盐值，旧源码的加密参数已经不被认可，网关对非法签名走"默认放行"逻辑，不拦截但也不返回真实状态。解决：重新抓包获取最新的盐值和签名拼接方式，更新crypto_utils.py，然后重新做第 4 章的灰度验证。这个坑很难发现，因为接口"完全正常"，只有拿已知被封域名去测才会现出原形。

5.2 踩坑二：请求频率过高被风控，全部返回"检测失败"

现象：批量跑 200 个域名，前 50 个正常出结果，第 60 个开始所有域名都返回类似"请求频繁"或"-1"的错误。原因：网关对来源 IP 有滑动窗口计数，超过阈值后直接拒绝服务。解决：把并发降到 2～3，每批次之间加time.sleep(1)，同时把单次批量上限控制在 100 以内。如果已经触发风控，换 IP 或等 10 分钟再跑，硬顶没有任何意义。

5.3 踩坑三：UA 不一致导致结果漂移

现象：同一个域名，今天测是"正常"，明天测是"封禁"，后天又变回"正常"，来回跳。原因：不是域名真在封禁边缘反复横跳，而是检测请求的 UA 和其他参数组合发生了细微变化，比如某些源码会在请求头里带动态 token，token 刷新后语义变了，导致结果不稳定。解决：固定 UA 和请求头模板，申请参数变化时，拿已知样本重新灰度验证。结果漂移时先怀疑自身请求，再怀疑域名真实状态。

5.4 踩坑四：没有保留请求快照，申诉时拿不出证据

现象：域名被封，团队准备申诉，但微信侧要求提供"检测记录、拦截截图、访问时间"等证明材料，团队拿不出来，申诉被驳回。原因：检测接口只输出了最终结果，没有保存原始请求和响应。解决：在代码里把每次检测的完整请求头、响应 JSON、时间戳落盘或入库，一旦域名正式被封，这些记录就是申诉的辅助材料。快照习惯的细节放到下一章展开，但结论先立在这：检测不只是拿一个状态码，它更是申诉的准备过程。

6. 落地技巧：把检测接口接进域名监控与告警流程

6.1 定时任务与结果入库

检测接口的价值在持续监控，而不是临时用一次。部署完成后，我一般用系统的计划任务每 30 分钟跑一轮批量检测，结果写进 SQLite。库表是最简单的三张：domains记录待检测域名，check_results记录每次检测结果，status_changes记录状态变化事件。表结构不复杂，但能支撑后续的告警、报表和申诉追溯。

6.2 状态变化触发告警

监控的核心不是"当前状态"，而是"状态变化"。一个域名一直处于封禁状态，告警没有意义；域名从正常变为观察期，才是需要立刻介入的时刻。在代码里用一个字典维护每个域名上一次检测结果，当前结果与上次不一致时，触发告警推送。告警通道我优先用企业微信机器人：构造一个 JSON POST 请求发到 webhook 地址就行。如果团队有更完整的监控系统，直接把状态变化事件以指标形式上报，规则判断交给监控系统处理。

6.3 一个习惯：每次检测都留快照

最后分享一个我保持了很多年的习惯：每次检测，无论结果正常还是异常，都把完整请求响应存一份。存这个不是为了好看，而是在申诉场景里能让效率差出数倍。域名被封之后，最快的解封路径是走官方申诉通道提交材料；材料里有一份"检测快照"，能证明域名在被封之前一直由合规团队监控，而且能定位到封禁发生的确切时间点，申诉受理速度明显不同。这个细节是我翻了两次车之后才总结出来的：第一次域名被封，手里只有一句"测出来异常"，申诉被驳回；第二次带着检测快照和状态变化时间线去申诉，弯路少走很多。也是从那时起，我把快照写进了接口默认行为，所有调用方不需要额外配置就自动保存。做域名监控这件事，宁可多存垃圾数据，也不要到用时才发现没留证据。希望这个习惯对你的接入也有实际帮助。

本文还有配套的精品资源，点击获取