简介这是一款面向网站维护、网络监控与个人技术学习的批量探测工具资源包解决了快速判断目标地址存活状态并抓取网页标题的常见需求。资源共12个文件压缩包仅608KB主要包含 Java 源码、XML 配置与 Markdown 说明文档其中 Java 源码覆盖主程序、GUI界面、HTTP请求与数据处理等核心模块可直接导入开发环境查看或二次修改。目前已有406人学习下载适合网络工程师、Web开发者及对HTTP协议感兴趣的学习者。通过阅读源码可以了解多线程批量请求的实现思路、响应状态判定以及标题解析方法配合README文档和项目配置文件有助于快速搭建运行环境并掌握工具的使用流程。整个资源包体积小巧、结构清晰既可作为个人学习网络请求处理的参考样例也能为实际批量地址探测提供可验证的脚本基础。1. WebBatchRequest 批量探测一条命令看清上百个目标地址的生死接手过授权范围内资产盘点的人几乎都经历过这种场面手里捏着几百上千个 URL第一次目标地址存活判断靠人工开浏览器逐个点点到最后手酸眼干还不确定哪个是 302 跳转、哪个是证书过期、哪个其实根本没解析。WebBatchRequest 这类批量探测工具解决的就是这个原始问题——把「逐个打开看」变成「并发请求 批量判定」顺带把每个存活目标的网页标题抓下来让结果列表一眼就能看出这个地址是什么系统、什么业务。它的核心价值不在技术多深而在把「目标地址存活」这个看似简单的问题工程化并发控制、超时管理、标题提取、结果排序。适合的受众很明确做过资产梳理的安全测试人员、需要巡检大量站点的运维、以及接了「帮我看下这些网址哪些还能打开」这种需求但不想写 200 行脚本的开发。工具本身不玄学但并发参数、超时阈值、编码处理这些细节才是它好不好用的分水岭。2. 先搞懂探测原理为什么「能 ping 通」不等于「地址存活」很多人一开始会把目标地址存活和 ICMP ping 混为一谈这是第一个要纠正的认知。WebBatchRequest 做的是应用层探测走 TCP 和 HTTP不是网络层的 ICMP。这两者的差别直接决定了工具的设计逻辑。2.1 HTTP 状态码与「存活」的定义边界一个地址在 WebBatchRequest 里算不算存活通常看三件事TCP 连接是否建立成功、是否收到 HTTP 响应、状态码是否落在「可接受」范围内。默认情况下200、301、302、403 都算存活因为这些状态码说明 Web 服务在正常工作只是资源位置或访问权限不同。而 404、500、502、503 这类服务虽然回了包但业务侧可能已经不可用默认会被当作「异常」处理。这里有个容易被忽略的边界连接被拒绝connection refused和超时timeout是两种完全不同的失败。连接被拒绝说明端口是关的地址「死」得很明确但超时可能是网络丢包、防火墙丢包、服务器负载过高三者之一不一定代表目标真的不在。所以靠谱的探测工具会把超时和连接拒绝分开记录而不是统一归为「不通」。我自己一般会把超时阈值设在 5 到 8 秒之间——太短误杀率高太长批量任务会被个别慢速站点拖死。2.2 为什么不建议用 requests 串行请求来做批量探测用 Python 的 requests 写一个 for 循环逐个请求这在目标地址只有十几个的时候没问题但到了几百上千的量级串行请求的总耗时是「所有请求耗时之和」一个站点响应 10 秒一百个站点就是 1000 秒起步。这是完全不可接受的等待时间。所以 WebBatchRequest 这类工具的做法必然是并发。常见实现是线程池ThreadPoolExecutor或者异步 IOasyncio aiohttp。线程池的好处是代码直观、requests 库生态成熟、遇到 SSL 证书校验、代理等需求时好处理asyncio 的优势是并发上限更高单机开几千个并发连接也不吃力但代码调试相对复杂。下面是一个最小可用的线程池批量探测脚本也是我觉得最接近 WebBatchRequest 核心逻辑的参考实现import requests import concurrent.futures from urllib.parse import urlparse requests.packages.urllib3.disable_warnings() headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36, Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8, } def probe(url: str, timeout: int 5) - dict: result {url: url, status: dead, code: 0, title: } try: resp requests.get(url, headersheaders, timeouttimeout, allow_redirectsTrue, verifyFalse) result[code] resp.status_code if resp.status_code 400: result[status] alive elif resp.status_code in (400, 401, 403): result[status] alive else: result[status] abnormal # 标题提取放在后面做粗略匹配 text resp.text[:5000] if title in text.lower(): start text.lower().find(title) 6 start text.find(, start) 1 end text.find(/title, start) if end start: result[title] text[start:end].strip()[:80] except requests.exceptions.ConnectTimeout: result[status] timeout except requests.exceptions.ConnectionError: result[status] refused except Exception: result[status] error return result def batch_probe(urls: list[str], max_workers: int 20, timeout: int 5): with concurrent.futures.ThreadPoolExecutor(max_workersmax_workers) as pool: futures {pool.submit(probe, url, timeout): url for url in urls} for future in concurrent.futures.as_completed(futures): yield future.result() if __name__ __main__: url_list [https://example.com, http://192.168.1.1, https://www.baidu.com] for item in batch_probe(url_list, max_workers10, timeout5): print(f{item[url]} - {item[status]} [{item[code]}] {item[title]})这段代码里值得解释的几个参数timeout5是单个请求的超时秒数包含连接和读取两阶段的总上限max_workers20是并发线程数控制了同时打开的请求数量而不是无限并发verifyFalse关掉了 SSL 证书校验因为批量探测的目标里经常有自签名证书或过期证书的站点开着校验会把这类站误判为失败。allow_redirectsTrue表示跟随 302 跳转拿最终页面的状态码。2.3 Session 复用与连接池批量请求的性能关键requests 库每一次requests.get()都会新建 TCP 连接这在批量场景下是巨大的浪费。HTTP 协议本身支持 Keep-Alive 连接复用同一个目标地址的多个请求应该共享连接。把上面的例子改成使用requests.Session()实例连接会被缓存复用尤其是针对同一个域名做多次探测时性能提升非常明显。session requests.Session() adapter requests.adapters.HTTPAdapter(pool_connections20, pool_maxsize50, max_retries1) session.mount(http://, adapter) session.mount(https://, adapter) def probe_with_session(url: str, timeout: int 5) - dict: # 逻辑同上面的 probe但使用全局 session 替代 requests.get resp session.get(url, headersheaders, timeouttimeout, allow_redirectsTrue, verifyFalse)pool_connections控制连接池缓存的不同主机数量如果探测的目标五花八门这个值要大于目标主机数pool_maxsize是每个主机的最大连接数并发高时可调大。max_retries1表示对失败的请求最多自动重试一次重试太多会让整体耗时被放大。3. 把并发与超时参数调明白批量探测的吞吐量就藏在这几个数字里3.1 线程数、超时与重试的最佳实践值从经验来看并发线程数 CPU 核心数 × 4是一个保守而稳妥的起点。web 请求是 IO 密集型操作线程大部分时间在等待网络响应所以可以开比 CPU 核心数更多的线程。但开太多有两个副作用本地 socket 文件描述符耗尽报Too many open files可能被目标防火墙判定为扫描而在授权环境外部引发告警。千级地址的批量探测20 到 50 个并发线程是常见区间上万地址则起身用 asyncio单线程事件循环能支撑数百并发。超时参数要区分「连接超时」和「读取超时」。timeout(3.05, 6)这样的元组形式分别控制连接阶段和读取阶段连接 3 秒没建立 TCP 就是失败连接成功后 6 秒没收到完整响应也是失败。这个拆分比单一标量超时更合理因为连接失败通常说明地址不可达而读取超时可能是服务响应慢两种情况需要不同的处理逻辑。重试策略建议只在「连接被拒绝」和「连接超时」这两种情况做一次重试读取超时不做重试。原因很简单连接失败可能是瞬时的网络抖动重试值得读取超时往往是目标服务器本身处理能力的问题重试大概率还是超时只会白白增加总耗时。3.2 响应内容的截断与标题提取的编码陷阱网页标题获取看起来简单——正则匹配title标签即可但实际落地满是坑。第一个坑是title标签内容可能跨行title\n 首页-某某系统\n/title这种格式很常见正则需要用re.S标志或者BeautifulSoup才能正确匹配。第二个坑是编码问题服务器返回 GBK 编码的页面但脚本按 UTF-8 解码标题就成了乱码。import re def extract_title(resp) - str: # 优先从响应头拿 charset拿不到再依赖页面内 meta 标签 encoding resp.encoding or utf-8 if resp.encoding is None: meta_charset re.search(rbcharset[\]?([\w-]), resp.content[:2048]) if meta_charset: encoding meta_charset.group(1).decode() try: text resp.content.decode(encoding, errorsreplace) except LookupError: text resp.content.decode(utf-8, errorsreplace) match re.search(rtitle[^]*(.*?)/title, text, re.S | re.I) return re.sub(r\s, , match.group(1)).strip() if match else 这段代码的处理逻辑resp.content拿原始字节先看响应头是否声明了 charset没有再搜页面前 2KB 里的 meta 标签声明最后兜底用replace容错替换非法字节。拿到标题后把连续的空白字符折叠成单个空格避免换行导致的排版混乱。注意errorsreplace只能保证解码不报错不能保证结果可读。如果目标站点编码声明是错的标题依然乱码——这是无解的黑匣子问题只能靠人工复核。3.3 结果落盘与排序存活列表要能直接喂给下一环节批量探测的最终产出应该是一个结构化文件不只是在终端打一行日志。常见格式是 TSVTab 分隔或者 JSONL每行一条记录。排序规则建议「状态码优先、URL 次之」先按状态码的类别分组alive、timeout、refused、abnormal组内再按 URL 做字典序这样拿到文件的人一眼能看到重点目标。import json from collections import defaultdict def save_results(results: list[dict], output_path: str) - None: buckets defaultdict(list) for res in results: buckets[res[status]].append(res) with open(output_path, w, encodingutf-8) as f: for status in [alive, abnormal, timeout, refused, error]: for res in sorted(buckets[status], keylambda x: x[url]): f.write(f{res[url]}\t{res[code]}\t{res[title]}\t{res[status]}\n) save_results(all_results, probe_result.tsv)这样落盘之后可以直接用grep -P ^https?://[^\t]\t200\t probe_result.tsv把某个状态码的地址筛出来交给下一个环节。如果后续要做 Web 截图或者中间件指纹识别这份 TSV 就是干净的输入清单。4. 批量探测的完整落地从 URL 清单到结果报表的一站式流程4.1 输入格式的归一化省去手写 URL 的麻烦实战中拿到的 URL 清单往往惨不忍睹有的带http://前缀有的不带有的带路径、有的只有域名还有的混了空行、注释和重复项。在送进并发探测之前输入清洗这一道工序不能省。from urllib.parse import urlparse def normalize_url(raw: str) - str | None: raw raw.strip() if not raw or raw.startswith(#): return None if :// not in raw: raw http:// raw parsed urlparse(raw) if not parsed.netloc: return None # 统一去掉默认端口保留非默认端口 host parsed.hostname or port parsed.port scheme parsed.scheme.lower() base f{scheme}://{host} if port and not ((scheme http and port 80) or (scheme https and port 443)): base f:{port} return base归一化函数处理了三类情况补全 scheme、去除默认端口、过滤无效行。保留路径还是去掉路径取决于使用场景——探测「地址存活」只关心站点根路径但如果目标是检测某个特定接口是否在用路径就得保留。这个选择可以在工具里做成一个--keep-path开关默认关闭。4.2 并发瓶颈看什么任务进度、失败队列与断点续跑千级地址的探测跑起来最怕的是跑到一半程序崩了结果全丢。所以流程里必然要加两样东西进度日志和增量落盘。每完成一批请求就把结果追加写入结果文件而不是全部跑完再统一写。终端输出按固定时间间隔打印完成数和存活数。import time completed 0 alive_count 0 start_time time.time() with open(probe_result.tsv, a, encodingutf-8) as f: for item in batch_probe(url_list, max_workers30, timeout5): completed 1 if item[status] alive: alive_count 1 f.write(f{item[url]}\t{item[code]}\t{item[title]}\t{item[status]}\n) if completed % 100 0: elapsed time.time() - start_time print(f[{elapsed:.1f}s] {completed}/{total} done, alive: {alive_count}, flushTrue)flushTrue保证日志及时写到终端避免输出缓冲导致看不到进度。断点续跑的做法是把探测前的 URL 清单和已完成的 URL 集合做差集只跑未完成的——这要求 URL 清单在清洗后先落盘一份作为断点的基准。4.3 探测结果怎么验证抽样人工核对与二次确认自动工具的结果必须经过抽样验证才有可信度。我一般会在探测完成后按状态码分层抽样从 alive 里抽 10 个、从 timeout 里抽 5 个、从 refused 里抽 5 个手动用浏览器打开核对。这个步骤看着土但实际效果比任何测试断言都好用——它能发现脚本本身的编码判断错误、正则匹配失误、以及目标站对 requests 默认 UA 返回异常响应等真实问题。5. 避坑指南批量探测地址存活时最容易翻车的 5 个真实案例5.1 误判一目标站对非浏览器 UA 返回 403但浏览器访问正常现象脚本把所有带路径的 URL 都判定为abnormal403人工用浏览器打开却完全正常。原因目标站配置了 WAF 或反爬规则对非浏览器 UA 直接拦截。requests 默认 UA 是python-requests/2.x特征太明显。解决把默认 headers 里的 User-Agent 改成完整浏览器 UA并同时补上Accept-Language和Accept-Encoding头。如果对方校验更严格需要额外处理 TLS 指纹那就不是这个工具能覆盖的域了建议换用浏览器内核的采集方案。5.2 误判二HTTPS 证书过期被拦截地址其实活着现象一批https://地址全部报error查看详情发现是 SSL 证书验证失败。原因verifyTrue时 requests 会对证书做完整校验证书过期、域名不匹配、自签名都会抛异常。解决批量探测场景默认verifyFalse并在日志里记录证书异常状态。如果目标地址来自资产清单证书过期本身就是一条值得输出的情报单列一栏而不是直接归为失败。5.3 误判三并发过高导致本地端口耗尽现象跑到一半开始大量报ConnectionError: [Errno 99] Cannot assign requested address前 500 个 URL 明明一切正常。原因线程并发数过高本地临时端口默认范围 32768-60999被占满新连接无法分配端口。解决调低max_workers如果必须跑高并发在 Linux 上检查sysctl net.ipv4.ip_local_port_range和net.ipv4.tcp_fin_timeout把tcp_fin_timeout调小能加快端口回收。注意这会影响到主机上其他服务的网络行为改系统参数前要走变更流程。5.4 误判四重定向链上的中间状态码被当成最终结果现象某些地址状态码显示 302但浏览器打开显示的是 200 页面。原因闭合了allow_redirectsTrue后拿到的是最终状态码但如果工具实现里用了allow_redirectsFalse抓到的就是中间跳转的状态码。部分站点还会做 JavaScript 跳转——HTTP 层只能看到 200页面内容里是meta refresh或者window.location。解决HTTP 探测只认协议层的最终状态码JS 跳转需要浏览器渲染才能追踪不在 HTTP 批量探测的范围内。如果业务上必须判断这类地址的最终去向需要引入无头浏览器代价是探测速度从分钟级降到秒级量级上要重新评估。5.5 误判五标题里嵌套了转义符和多余空白现象获取到的标题包含title内部的\\n字面量或者amp;实体数据不干净。原因标题提取只做了正则截取没有反转义源站标题里混入了换行符或 HTML 实体。解决提取后用html.unescape()处理实体再用re.sub(r\\s, , title)把所有空白统一为空格。这两步都加在标题提取函数的末尾是成本最低的净化方案。6. 进阶技巧给 WebBatchRequest 加上异步提速与失败回补针对上千乃至上万级别的目标地址线程池方案会逐步逼近瓶颈线程切换开销和 GIL 调度开始显现。asyncio 在这里能带来数倍的吞吐提升。网络上并没有我亲测的 aiohttp 极限值但一个大致判断是在 4 核 8G 的普通云主机上健康的异步探测脚本维持 200 到 500 量级的并发请求是可以预期的尤其适合那些响应时间本身偏长、线程池做不到高占用的场景。import asyncio import aiohttp SEMAPHORE asyncio.Semaphore(100) async def probe_async(session: aiohttp.ClientSession, url: str): async with SEMAPHORE: try: async with session.get(url, sslFalse, max_field_size81920) as resp: body await resp.text() title extract_title_from_html(body) return {url: url, code: resp.status, title: title} except (asyncio.TimeoutError, aiohttp.ClientError): return {url: url, code: 0, title: } async def run(urls: list[str]): timeout aiohttp.ClientTimeout(total8, connect3) async with aiohttp.ClientSession(timeouttimeout, headers{User-Agent: Mozilla/5.0}) as session: tasks [asyncio.create_task(probe_async(session, url)) for url in urls] return await asyncio.gather(*tasks)Semaphore(100)把并发限制在 100 个同时请求ClientTimeout区分了连接和总体超时。异步的难点在于调试不如线程池直观某个协程挂起可能拖慢整个事件循环所以要在每轮任务里加asyncio.wait_for兜底防止个别目标把任务池拖死。另一项值得投入的进阶是「失败回补」把第一次探测中 timeout 和 error 的地址放入重试队列间隔 5 秒后用更宽松的超时比如 12 秒再跑一遍。这能在不显著增加总耗时的前提下把因瞬时网络抖动造成的误杀捞回来。做法是在主循环结束时检查结果统计如果 timeout 数量超过已探测总数的 2%优先怀疑本地网络或目标防火墙一致性而不是盲目加大重试次数。如果目标地址量级不大但你对格式整洁有要求TSV 输出后接一个数据校验步骤能省很多麻烦用awk -F\\t NF4 probe_result.tsv检查每行字段数字段数不是 4 的行说明地址里带了制表符或者标题里混进了换行需要单独处理。这类细节不处理干净结果文件喂给下游工具时大概率还是会踩坑。批量地址存活探测这件事做完一轮并不算结束。我现在的习惯是每次扫完把结果存一份带日期的快照两个月后再跑一轮做对比新增、下线、状态码变化的地址自然浮出水面。这套方法的价值不在某次探测本身而在它能持续稳定地产出可信数据——希望这次的参数与避坑经验对你有用。本文还有配套的精品资源点击获取