简介HTTP 协议的可用性判断并不等于网络层连通性。批量存活探测关注的是 Web 服务能否正常响应业务请求而非仅依赖 ICMP 或端口扫描结果。通过并发请求、状态码分类、响应耗时与内容指纹的综合判定可以区分服务在线、业务可用与伪存活支撑资产盘点、可用性巡检和爬虫种子过滤等场景。面对几千个混杂域名、IP 与 URL 的资产清单如何设计清洗、并发调度、超时重试与指纹规则是工具能否沉淀为准的关键。本文从批量探测的原理、实现到参数调优完整拆解一套可落地的 Web 存活探测方案。1. 批量存活探测到底在解决什么别再把几千个URL扔给for循环拿到一份三千行的资产清单里面混着域名、IP、带路径的URL领导只丢给我一句话把这些 Web 服务全部过一遍看看哪些还活着。这是 Web 安全巡检、资产盘点或运维可用性检查里最常见的脏活。大多数人第一反应是写一个 for 循环 curl -I然后盯着屏幕滚二十几分钟最后按状态码统计出一堆 202、403还是说不清哪个算活。这里真正的痛点是基于 Web 批量请求存活探测工具做的不是“Ping 得通吗”而是用真实 HTTP/HTTPS 请求去问每一台服务——你还能不能正常响应业务请求。它要批量并发请求按状态码、响应耗时、页面指纹综合判断而不是只看网络通不通。适合三类人安全工程师做资产摸底、运维做 Web 可用性巡检、爬虫开发者做采集前的种子过滤。反直觉的一点是工具本身不复杂但“判定存活”的逻辑比想象中敏感。状态码 404 不一定死500 不一定活连超时也可能是环境变量污染导致的误报。这篇文章我会把从选型、实现、参数到排错的完整路径讲一遍每一段都能直接抄。2. 选型先搞清楚探测目标再决定用现成工具还是自己写2.1 Ping 和端口扫描为什么无效先泼盆冷水。很多人在做“Web 存活”时会顺手先 Ping 一圈用 ICMP 的结果当存活依据。这个习惯在内网环境还能勉强工作放到云上就完全失真。云防火墙和主机的安全组默认丢弃 ICMP很多业务机器根本 Ping 不通但 80/443 访问一切正常反过来也有主机 Ping 得通但 Web 服务已经挂了。四层网络可达和七层服务可用之间隔着状态码、证书、Host 路由和应用逻辑三层墙。端口扫描比 Ping 好一些能告诉我们某个 TCP 端口是否处于监听状态。但端口开放也不代表 Web 应用可用。我在内网遇到过一台服务器防火墙放行 8080但后面托管的 Tomcat 进程已经崩溃TCP 握手能完成请求发过去直接被重置。更常见的还有云负载均衡器后端所有节点都挂了LB 依然保持监听端口扫描显示“开放”实际请求永远得不到业务响应。没有直接复用 TCP 探测结果的另一个原因是Web 存活探测需要知道应用层的具体状态。端口扫描只能给出 open/filtered/closed而我们要的是“这个 URL 能不能作为后续系统可用性判断的输入”。这个语义差异决定了工具基础必须建在 HTTP 之上而不是 TCP 之上。2.2 现成工具与自研脚本的分界线现成工具有很多比如各类批量 URL 检测器、web 存活扫描器有的支持从文件读目标、多线程扫描、输出 CSV。它们的优势是默认参数调得比较合理拿来跑一遍就能看到一个粗糙的存活列表。如果目标只是一次性清单格式统一只需要知道“200 和 0”的粗粒度结果直接用现成工具是最高效的。但现实中的需求往往带尾巴判定逻辑要接内部资产库状态码语义要自己定义甚至要发送 POST 请求、指定 Cookie、匹配页面关键字。比如有些业务平台对所有请求统一返回 200但正文里写着“操作失败”有些系统根路径 302 到登录页302 本身不能代表失活也不能简单当成存活。要让探测结果可信就得能写自己的判定函数。现成工具往往只给你一个状态码字段没法做深度指纹匹配。所以我一般这样划线探测目标只有几百个、路径规则完全一致用现成工具一旦要嵌入定时巡检、对接告警平台、处理多套业务语义就必须自研或改造。而自研一个“基于 Web 批量请求存活探测工具”的成本其实只有几十行并发代码和一套判定逻辑比维护一个逆向过的黑匣子要可靠得多。2.3 技术栈选择Go、Python 和并发模型技术栈上我和身边同事最常用的两个方向是 Go 和 Python。Go 编译出来是一个静态二进制扔到服务器上不依赖解释器天然适合部署成常驻巡检任务它的 goroutine 并发模型写起来也顺手协程调度开销低能压出更高的吞吐。Python 的优势是生态和调试效率requests、aiohttp 用起来快结果也方便直接丢回 DataFrame 里做统计。如果这个工具只在自己机器上跑Python 是复现成本最低的。并发模型上我日常默认选择线程池而不是上来就上 asyncio。原因很简单这个工具绝大多数时间花在网络 IO 等待上响应还没回来时线程会主动让出 GIL所以 ThreadPoolExecutor 配合 requests在几十到两百并发内性能完全够用。asyncio 虽然能在更高并发下节省系统线程但代码里要处理事件循环、连接池、取消任务复杂度高了不少加进去之后很多人就懒得改了。针对标题里“批量请求”这个诉求我下面的完整演示用 Python 写因为读者里需要它是做安全扫描、打包进数据流程、快速改判定规则的人占多数。如果你生产环境跑的是 Go理解这套并发和超时思路后移植过去并不难。3. 从零搭一个探测工具输入、并发、存活判定三步走3.1 URL 列表的清洗补全协议、去重、处理端口第一步是把输入的资产文件变成标准 URL。文件名按惯例叫 assets.txt每行可能是baidu.com、http://192.168.1.1、https://example.com:8443/api这样混杂的内容。如果直接用这些字符串去 requests.get有的会因为没有协议头直接抛错。我一般先做一轮清洗核心动作是补协议、去锚点、过滤非 HTTP 协议。from urllib.parse import urlparse def normalize_url(raw: str, default_scheme: str http) - str | None: raw raw.strip() if not raw: return None # 没有协议前缀时补默认协议 if :// not in raw: raw f{default_scheme}://{raw} # 去掉锚点带#的URL在服务端请求中没有任何意义 if # in raw: raw raw.split(#, 1)[0] # 只保留 http/https其他协议直接丢弃 scheme urlparse(raw).scheme.lower() if scheme not in (http, https): return None return raw这段代码里有两个参数值得说明。default_scheme默认是http因为内网资产里很多 IP80 与 HTTPS 并存但证书可能过期直接上 https 会全部误报成“证书错误”。如果目标是公网资产大多数服务强制 HTTPS可以把这个参数改成https省掉一轮重定向。另一个细节是“去锚点”HTTP 请求永远不带 fragment不处理会导致后续对 URL 去重时出现http://a.com#1和http://a.com#2两个重复项。清洗完还要去重同时尽量保持原文件的顺序方便最后把结果对应回去。这里不建议只对 list 跑set()因为 set 会打乱顺序我用一个seen集合配合 list 保持原始顺序。seen set() urls [] for line in open(assets.txt, encodingutf-8): u normalize_url(line) if u and u not in seen: seen.add(u) urls.append(u) print(f输入共 {len(urls)} 个唯一 URL)3.2 并发请求线程池再加信号量并发部分用concurrent.futures.ThreadPoolExecutor这是 Python 里最容易讲清楚、也最容易上手的方式。核心思路是把所有 URL 提交给线程池每个线程独立发请求谁先回来谁先被处理。为什么不在 requests 外面再套一层 asyncio因为我们用同一个Session复用连接池线程池在这种网络等待型负载下的损耗很小代码也更直观。import time import requests from concurrent.futures import ThreadPoolExecutor, as_completed TIMEOUT (3, 6) # 连接超时3秒读取超时6秒 def probe_one(url: str, session: requests.Session): start time.time() try: resp session.get(url, timeoutTIMEOUT, allow_redirectsFalse, streamTrue) server resp.headers.get(Server, ) cost round(time.time() - start, 2) return url, resp.status_code, cost, server, except requests.RequestException as e: cost round(time.time() - start, 2) return url, 0, cost, , str(e) def batch_probe(urls, workers20): session requests.Session() session.trust_env False # 忽略系统转发配置避免请求被导向错误节点 with ThreadPoolExecutor(max_workersworkers) as pool: futures [pool.submit(probe_one, u, session) for u in urls] for f in as_completed(futures): yield f.result()这里有两个关键参数。第一个是TIMEOUT元组(3, 6)3 是连接超时6 是读取超时分开设置比一个总超时更有利于排除“连得上但响应极慢”的机器。第二个是workers20这个值不是越大越好我会在第四章专门讲怎么调。allow_redirectsFalse是刻意的探测存活时如果跟随 302工具会跟着跳转去访问第三个域名既拉长耗时还可能把“存活”和“可访问”混为一谈。另外注意session.trust_env False。requests 默认会读取系统环境变量里的 HTTP 转发配置这在某些机器上是灾难。一个失效的转发节点会让所有探测请求超时但浏览器却正常——我在这上面翻过车后面避坑章节还会展开。3.3 存活判定的完整逻辑状态码、响应头、内容指纹拿到状态码之后最忌讳的是简单写if code 200。一套完整判定逻辑要区分“服务在线”和“业务可用”这两个概念不同。对于存活探测我的口径是只要 HTTP 层能够完成交互不是网络层失败就算服务在线。所以 401、403、404 都不算死405 方法不允许也不该算死甚至连 500 都说明 Web 容器还活着只是后端报错。LIVE_CODES { 200, 201, 202, 301, 302, 303, 307, 308, 400, 401, 403, 404, 405, 410, 500, 502, 503 } def is_live_by_code(code: int) - bool: # 0 表示网络层失败其他未列出的4xx/5xx也可以按需补充 return code in LIVE_CODES但只有状态码还不够。很多虚拟主机提供商的默认站点对所有 Host 都返回 200正文却是同一套“网站正在建设中”模板。这种目标如果也算存活结果列表里会混进一大堆无效资产。我一般会再做一层内容指纹读取响应前 2KB 的正文匹配业务关键字。DEAD_FINGERPRINTS [404 not found, page not found, default web page, is not configured] def decide(url: str, code: int, body_prefix: str, redirect_to: str) - str: if code 0: return dead if not is_live_by_code(code): return unknown # 如果重定向到登录页或业务页说明服务在线 if code in (301, 302) and redirect_to: return live # 如果返回200但内容命中默认安装页特征标记为伪存活 low_body body_prefix.lower() for fp in DEAD_FINGERPRINTS: if fp in low_body: return dead_by_fingerprint return live这样设计之后输出就变成了四类状态dead、live、dead_by_fingerprint、unknown。后面做巡检报表时dead_by_fingerprint会被单独拆出来人工复核不会直接当成失活误报警。指纹列表里的内容一定要跟自己业务匹配有的系统首页就写着“404 Not Found”但实际是正常的 API 根路径这种情况下需要把该目标从指纹规则里排除。这就是为什么这个工具必须支持自定义判定规则而不是拿一个写死的现成二进制到处用。4. 参数调优这五个数字决定你能跑多快、多准4.1 并发数从 10 到 200 之间的选择并发数是整个工具里最容易拍脑袋设置的值也是最容易当场翻车的地方。开太高本机临时端口耗尽程序报错大量ConnectionResetError开太低三千个 URL 要跑半小时。我的经验值分三档公网资产、目的地在 WAF 后面并发控制在 10 到 20内网机房可信环境100 到 150 比较舒服跨区大规模互联网资产50 到 80 同时兼顾速度和安全。为什么不能无限往上开每个 TCP 连接都会占用一个本地临时端口Linux 默认可用范围大约两万多个。如果并发 300 且每个请求都新建连接TIME_WAIT 状态会迅速堆满端口表新连接直接被拒。即使复用 Session 里的连接池服务器端也会按 IP 做限流超过阈值后立刻返回 403。所以我默认先设 20跑一小批看平均耗时再按总目标数量和期望耗时换算# 期望时长约 target_seconds, 粗略估算并发数 estimated_workers int(total_urls / target_seconds) workers min(200, max(20, estimated_workers))这个公式不严谨但作为起步值够用。实际跑的时候观察两点CPU 是否打满、错误日志里是否频繁出现ConnectionRefused或Timeout。如果错误率高于 5%先砍一半并发再跑。4.2 超时设置TCP、TLS、总超时分开控制requests 的 timeout 参数很多人填一个数字就完事但这会导致连接建立慢的目标整体超时很短而读取慢的目标又等很久。正确姿势是传元组分别控制连接和读取两个阶段。一般来说连接超时 3 秒、读取超时 6 秒是一套比较可靠的默认值。参数默认建议场景调整说明connect_timeout3s公网跨运营商可到 5s包含 TCP 握手和 TLS 握手read_timeout6s大文件接口可到 10s首字节读取等待时间总请求上限10s无防止连接卡死占用线程重试次数2高可靠场景 3 次只对网络层失败重试TLS 握手的时间算在 connect 阶段。有些目标证书链特别长或者需要来回校验客户端证书3 秒会显得紧。但如果目标列表里有大量过期证书超时放宽到 5 秒又会拖慢整体速度。我的办法是先给 3 秒把 TLS 错误单独归类等这一批跑完再看有多少是CertificateError这部分和超时无关是证书问题。4.3 重试与退避失败后别急着连打探测命令出去连接超时了很多人的下意识操作是立刻重试。但这会造成一个恶性循环目标服务器本身已经满负载响应不过来你的重试又补了一脚最后所有请求都超时。正确做法是只对“网络层失败”做重试并且每次重试之间递增等待时间。def probe_with_retry(url: str, session: requests.Session, retries: int 2): for attempt in range(retries 1): result probe_one(url, session) # 状态码非0说明HTTP层已有响应没必要重试 if result[1] ! 0: return result if attempt retries: time.sleep(0.5 * (attempt 1)) # 0.5s, 1s return result注意这里没有对 5xx 做重试。因为 5xx 已经证明 Web 服务在线只是后端应用报错。对于存活探测来说我们拿到“在线”这个结论就够了只有在做业务可用性探测时才会对 5xx 重试并加上更长退避。重试参数retries2意味着最坏情况下一个不可达目标要花费3s(connect) 0.5s 3s 1s 3s ≈ 10.5s这个成本必须心里有数。如果目标总量上一万建议 retries 设为 1。4.4 限速和请求头避免被 WAF 误伤企业级 Web 开发环境里几乎所有对外服务前面都挂着 WAF。WAF 的限速策略通常按单 IP 每秒请求数算一旦超过阈值不是返回 406 就是让请求进入验证页。如果你的探测工具 3 秒内打出 200 个请求结果就是一大批 406存活列表瞬间失真。解决方式之一是加一个令牌桶限速器控制每秒平均请求数。import threading class RateLimiter: def __init__(self, rate: float): self.min_interval 1.0 / rate self.last_time 0.0 self.lock threading.Lock() def wait(self): with self.lock: now time.time() if now - self.last_time self.min_interval: time.sleep(self.min_interval - (now - self.last_time)) self.last_time time.time()这个限速器的参数rate代表每秒最多放行多少个请求。跑探测时我会根据对方规模来定普通企业内部系统 10 到 20 是安全的对高并发互联网平台可以调到 50但要结合并发数一起控制。注意last_time被线程锁保护因为多个探测线程会同时调用 wait不加锁会失去限速效果。请求头方面至少要设置一个真实的 User-Agent。requests 默认的python-requests/x.y.z太扎眼很多 WAF 直接把这个 UA 加入黑名单。我一般会准备一个小 UA 列表每个线程随机选一个。另外加上Accept-Language: zh-CN,zh;q0.9让后端返回值更接近普通用户会话。5. 常见问题与避坑我的每次误判都来自这四类情况5.1 现象全部超时但浏览器能正常打开第一次跑批量探测时我遇到过最荒诞的情况代码在服务器上跑所有 URL 返回超时但用同一台机器的浏览器访问却完全正常。排查到最后才发现requests 库会主动去读环境变量里的 HTTP 转发配置而服务器上那块配置指向了一个早已下线内网节点。请求全被扔进了黑洞浏览器因为不走这个配置反而没受影响。原因就是 Session 默认信任环境变量特别是http_proxy、https_proxy这类全局网络设置。解决方式很简单在初始化 Session 后加一行session.trust_env False或者在执行命令前清空相关环境变量。我最终选择在代码里固定关闭 trust_env因为命令行清变量的方式容易忘而且换了台机器就复发。5.2 现象IP 能连上请求却卡在 TLS 握手有一种常见场景你用 IP 去探测一个反向代理后面的 Web 服务TCP 连接能建立但发请求之后就一直在等直到超时。原因多半是目标 nginx 按域名路由 Virtual Host而你的请求头里 Host 写的却是 IP。nginx 没有对应 server_name请求落到了默认站点默认站点可能配置了完全不匹配的证书或直接丢弃会话。解决方法是手动构造 Host 头探测时仍然连 IP但请求头里写目标域名。注意 TLS 的 SNI 也要跟着域名走requests 在session.get(https://192.168.1.10/, headers{Host: example.com})时SNI 默认取自 URL 的 Host也就是 IP这会导致证书验证失败。正确做法是先把域名解析到 IP然后请求这个域名地址让 requests 自动带上域名的 SNIresolved socket.gethostbyname(domain) url fhttps://{resolved}/ headers {Host: domain} resp session.get(url, headersheaders, verifyFalse)verifyFalse是为了绕过证书与 IP 不匹配的问题。生产环境里我不建议彻底关掉证书校验可以给 trust store 加上目标内网 CA。这种 Host 头问题的坑只靠日志很难定位特征就是“用 IP 扫描全军覆没换成域名就正常”。5.3 现象返回 200 的全指向同一个默认安装页云服务器新开实例之后默认会有一个 Web 服务建站页面。有些主机商甚至会在你未绑定域名时自动对任意 Host 返回 200 默认页。批量探测之后报表里一堆 200看起来非常漂亮但你点进去全是同一套模板根本没有业务价值。原因就是只靠状态码判断存活而默认页把状态码这门课给“作弊”了。解决必须靠内容指纹。第三章节里我引入了DEAD_FINGERPRINTS这里会把“default web page”“welcome to nginx”“is not configured”这类模板特征加进去。更直接的信号是如果一批目标里有大量响应的页面标题相同、body 长度完全相同基本可以断定是默认页或统一拦截页。遇到这种情况不要急着把指纹加到规则里先跑一轮统计。我先跑一遍导出status_code body_length title三列筛出 body_length 重复率超过 80% 的组把这些页面的 title 和特征字符串提取出来再反哺到指纹列表。5.4 现象内存涨到几个 G程序被 OOM 杀掉大量资源文件所在的静态服务器或者流媒体接口响应体可以大到几百 MB。如果代码里用了resp.contentrequests 会把整个响应 body 一次性读进内存。并发 50 个目标同时触发大文件响应内存很快爆掉。这类问题往往出现在探测带/download路径的 URL 列表时。解决的思路是不要读取完整响应体只取头部和少量正文。请求时加streamTrue参数然后手动按字节读取前缀。with session.get(url, timeoutTIMEOUT, streamTrue, allow_redirectsFalse) as resp: body_prefix resp.raw.read(2048, decode_contentTrue)这里2048就是读取字节数对内容指纹判断完全够用。读完前 2KB 后with 块会关闭响应流该连接的底层 socket 会归还连接池后续请求可以复用。如果你还需要页面标题可以再配合resp.headers大多数 HTTP 服务会在响应头里给出Content-Type和页面编码不需要读更多正文。6. 从单次探测到持续值班定时扫描、结果回放与效果验证6.1 定时任务与状态变更通知单次跑一遍只能说明某个瞬间的存活情况真正的资产盘点需要一个持续观察的状态基线。我习惯把探测脚本放到 crontab 里每 6 小时跑一次输出带日期的文件。关键不是每次扫描而是和上一次结果对比状态变化——从 live 变成 dead 的目标才值得触发告警。0 */6 * * * cd /opt/probe python3 probe.py --input assets.txt --output /data/health/$(date \%Y\%m\%d_\%H).json脚本里维护一个“上次状态”文件发现状态翻转后调用企业微信或钉钉的 Webhook 发送一条通知。注意这里的告警要带“连续失败次数”条件避免目标临时重启造成误报。我自己是把连续两次扫描都失败才定义为失活能过滤掉大部分抖动。6.2 结果结构化输出与回放为了下一步对比输出格式我建议统一用 JSON每条记录包含 url、status_code、cost、server、fingerprint_status、redirect_location 六个字段。CSV 虽然直观但遇到带逗号的 URL 和响应头字段时要处理转义JSON 更干净。回放式排查时直接按 URL 做索引翻历史记录能快速回答“这个站点什么时候开始不可达的”这类问题。6.3 用已知样本验证工具本身工具写完之后先别急着跑全量。我会准备 100 条确定在线的 URL 和 100 条确定失活的 URL混合后作为验证集。跑完统计准确率和召回率准确率判定为活的样本里真正活的比例召回率真正活的样本里被找出来的比例。这个数字低于 95% 就说明判定逻辑有问题要么是超时太短把慢业务判死了要么是默认页指纹没生效。做验证这件事让我养成了一个习惯每次改判定逻辑时都先把验证集跑一遍对比上次报表里的误报数有没有下降。要相信工具的价值不在于代码能跑而在于它给出的结论经得起抽查。这条经验帮我在实际项目里避免了无数个“看起来全绿、实际一堆坑”的假象。希望帮到你。本文还有配套的精品资源点击获取