简介：WebBatchRequest 是一款适合网站维护、网络监控和数据分析场景的批量探测工具，核心作用是快速检查大量目标地址是否存活，并自动抓取网页标题，便于用户快速了解站点状态与内容主题。资源定位偏向个人学习与网络技术研究，网络工程师、开发者和安全分析爱好者均可借此熟悉 Java 网络请求与响应处理流程。压缩包共 12 个文件，以 Java 源文件为主，共 6 个；另有 3 个 zbak 备份文件、1 个 zip 附赠包、1 个 md 说明文档和 1 个 xml 配置文件，整体 608KB，结构精简。从包内组成看，源码部分涵盖批量请求逻辑、图形界面入口和 HTTP 交互模块，配合说明文档与配置信息，可帮助读者理解地址列表读取、请求发送、HTTP 状态判断以及标题提取等实现细节。已有 406 人学习下载，适合作为 Java 网络编程和站点可用性检查的入门实践参考；使用时也应注意控制请求频率，避免对目标服务器造成负担或触发反爬限制。
1. WebBatchRequest 批量探测：先搞清楚目标活没活，再谈别的
做资产梳理、网站巡检或者安全评估的时候，我经常面对一堆目标地址。几十个还好说，一个一个 curl 能忍；几百上千个的时候，手工操作就是灾难。WebBatchRequest 这种批量探测工具，核心就干两件事：并发请求一堆 URL，判断每个目标是否存活，再把页面的 title 抓下来。这里“存活”不是简单指网络通不通，而是指目标能不能正常返回 HTTP 响应、响应是否符合预期。标题则是快速识别目标用途的最直观标记——看到“后台登录”和看到“404 Not Found”，下一步动作完全不同。这套工具适合谁？运维巡检、安全测试前期打点、SEO 批量看站点状态的人都会用到。我拆这个项目，重点不是教你怎么跑一条命令，而是把背后的判定逻辑、请求参数怎么调、并发开多大、遇到超时和乱码怎么处理讲清楚。
2. 存活判定逻辑：为什么不能只看状态码
2.1 三次握手通了不代表业务是活的
网络层通、TCP 层通，HTTP 层未必通。最常见的情况是：目标地址能 ping 通，但 curl 过去直接 connection refused，或者一直卡在 TLS 握手。反过来也一样，某些负载均衡器对不存在的后端会返回 503，但 TCP 连接始终能建立。所以批量探测的第一原则是：以 HTTP 响应为准，不以 ICMP 为准。这也是为什么 WebBatchRequest 这类工具直接走 requests 而不是用 ping 做预判。
另一个坑是重定向。一个地址返回 301/302，算不算存活？要看场景。如果目标只是一个跳转入口，那它确实是存活的，但如果你本来想探测的是跳转后的资源，就得决定要不要跟随重定向。我一般建议把重定向行为做成参数开关，默认跟随，但保留关闭选项，因为有些安全探测场景下，你需要记录“原始状态码”而不是最终状态码。
2.2 三个核心判断参数的具体设定
判定一个目标存活与否，我习惯用三个维度叠加：HTTP 状态码、响应体大小、响应时间。只看状态码的缺陷很明显——很多框架对不存在的路由统一返回 200，用前端路由做的 SPA 应用尤其如此。这种情况下，响应体大小就成了关键信号。
我常用的判定逻辑是：
- 状态码在 200~399 区间，且响应体大于某个阈值（比如 512 字节），判定为存活；
- 状态码在 400~499，判定为“可能存在但访问受限”，单独标记；
- 状态码在 500~599，判定为“服务异常”，单独标记；
- 响应体小于阈值，即便返回 200 也标记为“可疑存活”，因为可能是空白页或者静态错误页。
超时设置也是存活判定的一部分。默认超时我习惯设为 8 秒，超过这个时间直接算失败。时间设太短，慢速业务站会大面积误报；设太长，整个批量任务会被几个慢站点拖死。8 秒是个折中值，如果你探的是内网资产，可以压到 3 秒；如果是公网，10 秒更稳。
提示：批量探测的“存活”定义没有绝对标准，工具给出的只是参考判定。真正在做资产盘点时，你还需要对可疑结果做二次确认，这一点我在进阶章节会展开。
3. 请求引擎实现：从单线程脚本到并发探测
3.1 先写一个基础请求函数
整个工具的核心是请求函数，它决定了每一个目标怎么被访问。下面这个版本是我常用的基线，基于 Python requests，做了超时、重试和响应内容截断。
import requests from requests.adapters import HTTPAdapter from urllib3.util.retry import Retry def probe_url(url, timeout=8, max_retries=1, headers=None): """ 探测单个 URL 的存活状态与标题 :param url: 完整 URL，包含协议头 :param timeout: 单次请求超时时间（秒） :param max_retries: 失败后的重试次数，建议 1~2，不宜过多 :param headers: 自定义请求头，默认为常见浏览器 UA :return: dict，包含 url、status_code、title、elapsed、error """ if headers is None: headers = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36" } session = requests.Session() # 配置重试策略：只对连接错误和 5xx 状态码重试 retry = Retry( total=max_retries, connect=max_retries, read=0, status=max_retries, backoff_factor=0.5, status_forcelist=[500, 502, 503, 504], allowed_methods=["GET"], ) adapter = HTTPAdapter(max_retries=retry) session.mount("http://", adapter) session.mount("https://", adapter) try: resp = session.get(url, timeout=timeout, headers=headers, stream=True) # stream=True 只读一部分响应体，避免大文件把内存打满 content = resp.content[:4096] return { "url": url, "status_code": resp.status_code, "final_url": resp.url, "elapsed": resp.elapsed.total_seconds(), "content_length": len(content), "title": extract_title(content), "error": None, } except requests.exceptions.RequestException as e: return { "url": url, "status_code": None, "final_url": url, "elapsed": 0, "content_length": 0, "title": None, "error": str(e), }这个函数的几个关键点：stream=True配合resp.content[:4096]，只读取前 4KB 响应体。这样做有两个好处——第一，目标站点如果返回的是个大文件或者视频流，不会因为读完整响应而浪费时间；第二，提取 title 只需要<head>区域的 HTML，4KB 基本够用，少数页面 title 标签靠后，我后面会说怎么处理。重试逻辑用 urllib3 的 Retry，只对连接错误和 5xx 做重试，4xx 不重试——因为 404 和 403 重试多少次结果都一样。
参数说明：timeout是整个请求的完成时限，不是连接时限；max_retries我默认给 1，也就是最多重试一次，批量场景下重试代价很高，一个慢目标重试一次会把整体耗时拉长；backoff_factor=0.5表示第一次重试前等待 0.5 秒，第二次等待 1 秒，公式是backoff_factor * (2 ** (retry_number - 1))。
3.2 用 ThreadPoolExecutor 做并发
单线程跑几百个 URL 会很痛苦，但并发开太大又容易被封 IP 或者把目标打挂。批量探测的并发数默认 20 是我比较舒服的一个值——对大多数中小企业站点不会构成压力，同时速度也够快。如果你探的是自己的资产，开到 50 没问题；如果是第三方授权测试，20 以下更稳妥。
from concurrent.futures import ThreadPoolExecutor, as_completed from urllib.parse import urlparse def load_urls(file_path): """ 从文件读取 URL 列表，自动补全缺失的协议头 """ urls = [] with open(file_path, "r", encoding="utf-8") as f: for line in f: url = line.strip() if not url: continue # 没有协议头时默认补 https，避免漏探 if not url.startswith(("http://", "https://")): url = "https://" + url urls.append(url) return urls def batch_probe(url_file, max_workers=20, timeout=8): """ 批量探测入口 :param url_file: URL 列表文件路径，每行一个 :param max_workers: 并发线程数 :param timeout: 请求超时 """ urls = load_urls(url_file) results = [] with ThreadPoolExecutor(max_workers=max_workers) as executor: # 提交所有任务，但用 as_completed 边完成边收结果，避免堆积 future_map = { executor.submit(probe_url, url, timeout): url for url in urls } for future in as_completed(future_map): url = future_map[future] try: result = future.result() results.append(result) # 实时打日志，方便观察进度 status = result["status_code"] or "ERR" title = result["title"] or "-" print(f"[{status}] {url} -> {title}") except Exception as e: results.append({ "url": url, "status_code": None, "title": None, "error": f"unexpected: {e}", }) return results这个并发模型有几个值得说的边界。第一，executor.submit提交的是全量任务，as_completed边完成边取结果，所有任务都进内存，如果 URL 文件有几十万行，这种做法不太稳妥，需要改成生产者-消费者队列模式。第二，ThreadPoolExecutor 的线程数不是越大越好——Python 的 GIL 对网络 I/O 影响有限，但每个请求持有连接和内存，线程太密会产生大量 TIME_WAIT 连接，影响目标端口的接受队列。
参数设置上，max_workers默认 20，目标性能好可以调到 50，目标脆弱就降到 5。判断目标脆弱有个土办法：先跑一批看响应时间，如果大量请求耗时接近 timeout 上限，说明目标已经扛不住了，赶紧降并发。
注意：并发探测速度快，副作用也快。对没有防护的站点，20 个线程同时请求一个路径，日志会瞬间刷屏。如果是授权测试，建议在低峰期执行，并控制单目标请求频率。这不是道德问题，是基本的操作纪律。
4. 标题提取与编码处理：容易翻车的地方
4.1 正则提取是保底方案，不能用 BeautifulSoup 硬解析
标题提取看似简单，翻车点却不少。很多页面 HTML 不规范，<title>标签可能带属性、跨行、大小写混用，或者根本没闭合。BeautifulSoup 对标准 HTML 好用，但对畸形 HTML 偶尔会给出意外结果，而且依赖第三方库。做批量探测时，我优先用正则提取，写得更宽容：
import re def extract_title(content): """ 从 HTML 片段中提取 title 文本 兼容：大小写混用、属性、跨行、未闭合等情况 """ if not content: return None # 先尝试标准闭合标签 m = re.search(rb"<title[^>]*>(.*?)</title>", content, re.IGNORECASE | re.DOTALL) if m: title = m.group(1) else: # 兼容未闭合的情况，截取到 <body 或内容末尾 m = re.search(rb"<title[^>]*>(.*?)(?:<body|<head|$)", content, re.IGNORECASE | re.DOTALL) if not m: return None title = m.group(1) # 清理内部 HTML 标签 title = re.sub(rb"<[^>]+>", b"", title) title = title.strip() # 空标题统一返回 None if not title: return None return title[:200].decode("utf-8", errors="replace")这里用了字节串操作而不是字符串操作，原因是：响应内容还没确定编码，直接用str可能因为解码错误抛异常。先保留bytes格式做正则提取，最后在 decode 时用errors="replace"，遇到非法编码替换成占位符，不会中断整个探测流程。
errors="replace"是保命设计。如果页面声明的编码和实际内容不一致，直接.decode("utf-8")会在遇到非法字节时抛UnicodeDecodeError，导致整个线程的任务崩溃。替换成本低，先保证探测流程不断，再去解决乱码问题。
4.2 编码识别：在 requests 的 apparent_encoding 和手工判断之间做选择
requests 自带的response.encoding用的是 HTTP 头里的 charset，response.apparent_encoding则基于内容推断。这两个值经常不一致。HTTP 头说 utf-8，实际页面用 gb2312 的站非常多——老旧的政府站、企业站尤其如此。
def smart_decode(content_bytes): """ 智能解码策略： 1. 检查 HTML 中的 meta charset 2. 检查 UTF-8 BOM 3. 尝试 UTF-8 严格解码 4. 回退到 gb18030（覆盖简体/繁体中文） """ # meta charset 优先 m = re.search(rb"charset=[\"']?([a-zA-Z0-9-]+)", content_bytes[:1024], re.IGNORECASE) declared = m.group(1).decode("ascii", errors="ignore").lower() if m else None if declared and declared not in ("utf-8", "utf8"): for enc in (declared, "gb18030", "utf-8"): try: return content_bytes.decode(enc, errors="strict"), enc except UnicodeDecodeError: continue # 默认按 UTF-8 处理，失败后回退 gb18030 try: return content_bytes.decode("utf-8"), "utf-8" except UnicodeDecodeError: try: return content_bytes.decode("gb18030"), "gb18030" except UnicodeDecodeError: return content_bytes.decode("utf-8", errors="replace"), "utf-8"gb18030是中文场景下的兜底编码，它兼容 GB2312 和 GBK，而且不会像 GBK 那样在某些生僻字上报错。用strict模式解码是为了检测编码是否真的是声明的那样——如果声明说 gb2312 但实际是乱码，通常会在解码过程中抛异常，然后回退。如果声明了windows-1252或iso-8859-1这类西文编码，而实际内容是中文，解码结果会是一堆乱码但没有异常，这种情况下只能靠使用者人工抽样检查。
4.3 结果导出：CSV 比 Excel 更省心
批量探测的结果最后一定要落到文件里，否则下一次还得重跑。CSV 格式跨工具兼容性最好，Excel 直接用，脚本也能解析。导出时要注意列顺序固定，别今天一个列序明天一个列序，后面分析的时候光是对齐列就够烦的。
import csv def export_results(results, output_file): """ 导出探测结果到 CSV """ with open(output_file, "w", encoding="utf-8-sig", newline="") as f: writer = csv.writer(f) writer.writerow(["url", "status_code", "final_url", "title", "elapsed", "content_length", "error"]) for r in results: writer.writerow([ r["url"], r["status_code"] if r["status_code"] is not None else "", r["final_url"], r["title"] if r["title"] else "", round(r["elapsed"], 3), r["content_length"], r["error"] if r["error"] else "", ])用utf-8-sig而不是utf-8，是为了让 Excel 打开时正确识别编码。如果文件里含中文标题，用纯utf-8导出，Excel 打开会乱码，但记事本打开正常——这种“换个软件看就乱码”的问题，都是编码 BOM 缺失导致的。newline=""是 Python 写 CSV 的固定姿势，不写的话 Windows 上每行后面会多一个空行。
5. 探测工具血泪排查：常见问题与避坑指南
5.1 TLS 握手卡死：连接建立不了却一直挂着
现象：批量任务卡在某个 URL 上，超时设置为 8 秒，但实际等了 30 秒才失败。
原因：requests 的超时参数只覆盖连接建立和读取数据两个阶段之间，如果你没有设置connect_timeout，TCP 连接阶段可能会被系统级别的超时兜住，那个值通常是 120 秒。特别是目标 IP 被防火墙 DROP 而不是 REJECT 时，TCP SYN 包发出去毫无响应，连接超时要等到系统报错才结束。
解决：把超时拆开设置，连接超时短一点，读取超时稍长。requests.get(url, timeout=(3, 8))这种写法下，3 秒连接建立，8 秒读取数据。我在probe_url函数里直接传一个tuple就是这个用途——注意不要传成timeout=(8, 3)，顺序反了会频繁误报。
5.2 标题乱码无法修复：源头是 HTTP 头声明了错误编码
现象：某个站点的标题输出为ä¸æ–‡æ ‡é¢˜，明显是 UTF-8 字节被按 Latin-1 解码了。但我的smart_decode函数明明会检查 meta charset，为什么没生效？
原因：这个站点在 HTTP 响应头里带了Content-Type: text/html; charset=iso-8859-1，但页面里没有 meta charset 标签，实际内容却是 UTF-8 编码的中文。我的函数优先检查了 HTML 内部声明，却没检查 HTTP 头。requests 的response.encoding已经被设置为 iso-8859-1，但resp.content拿到的是原始字节，编码判断逻辑没有拿到 HTTP 头的信息。
解决：判断编码的顺序应该是 HTTP 头 charset > HTML meta charset > BOM > 自动探测 > 兜底编码。HTTP 头声明的可信度其实并不高，但要承认它是页面作者的“第一声明”，你可以在probe_url里把resp.headers.get("Content-Type")传进解码函数，让该函数优先校验 HTTP 头声明，不吻合再回退到 meta charset。
5.3 并发一高就大量超时：目标连接数被打满
现象：并发线程从 10 加到 30，结果超时数量从 1% 飙升到 30%，降回 10 又恢复正常。
原因：目标服务器的最大并发连接数受限。Nginx 的事件模型通常能扛几千并发，但很多老旧的 Apache prefork 模式每个连接占一个进程，默认 MaxClients 只有 150，瞬间打满之后直接不响应新连接。这暴露了一个问题：批量探测工具的超时和并发参数必须联动调整，不能只调其中一个。
解决：遇到这种情况，先降低并发到原来的 1/4，观察超时数量是否回落。与其猛开并发硬拼，不如用稍低并发 + 精细超时控制。另外，单目标连接数限制是另一个隐藏瓶颈，如果你同一个域名下探测很多路径，连接会被目标限流，最好的做法是对相同域名做串行或低并发处理。
5.4 结果文件里 URL 多了协议头不识别
现象：导出的 CSV 里 URL 列显示https://example.com，但某些工具打开后没法访问链接。
原因：Excel 识别 URL 链接需要单元格内容以http://或https://开头，这没问题——真正的问题是有些站点只有 IP 没有域名，导出的https://192.168.1.1在浏览器里访问会被证书警告拦截，但工具本身没做任何标记。
解决：在load_urls时把原始输入和补全后的 URL 都保留下来，导出时增加一列raw_url。用户看到结果时能知道这个地址最开始的写法是什么——如果原来就是 IP，那访问时得自己处理证书和 SNI 问题。这不是脚本 bug，是使用场景的边界：批量探测能告诉你目标活着，但活着的目标能不能被你访问，那是另一层问题。
5.5 重定向导致标题不匹配
现象：目标地址返回 302，跟随重定向后页面标题是“欢迎访问”，但原始 URL 和标题对应的根本不是同一个服务。
原因：默认跟随重定向时，resp.url已经变成了跳转后的地址。如果把原始 URL 和跳转后页面的标题放在一起，会造成资产信息归属错误——这个“标题”根本不是你探测的那个地址的。
解决：在结果中同时记录url（原始请求地址）和final_url（最终落地地址）。分析时先看两者是否一致，不一致的目标单独处理。实际上，final_url本身就是非常有效的资产扩展线索——你可能会在这里发现原本没有列入探测范围的子系统和域名，这在安全测试前期打点时很有价值。
6. 进阶验证：探测结果别全信，做一次轻量级二次确认
批量探测的输出是一堆“疑似存活”的目标，直接用来做后续操作之前，我习惯跑一遍轻量二次确认。方法很简单：对判定为存活的目标重新发一次请求，这次不只看状态码，记录请求耗时的变化、响应头里的 Server 字段和 Content-Type。关键看三点：第一，第一次抓到的内容和第二次抓到的内容是否一致，如果不一致说明目标动态渲染或者有负载均衡，得标记为“内容不稳定”；第二，TLS 证书是否过期或自签名，这个用ssl模块就能查；第三，延迟波动如果超过 50%，说明目标网络环境比较差，后续操作要激进一点就得掂量掂量。
第二遍确认还能解决一个问题——第一遍因为超时被判为“疑似失败”的目标里有真有假。假失败在公网环境很常见：某个节点恰好高负载、中间链路抖动、本地 DNS 解析超时。简单做法是单独重试这些失败项，重试时把超时放宽到 15 秒，并且关闭流式读取（stream=False），因为有些场景下流式连接本身会引入额外开销。我一般把这套重试写成一个独立函数，不跟主逻辑混在一起——主探测是广撒网，二次确认是精准复查，两者职责不同，混在一起代码反而难维护。
关于输出结果，还有一个容易被忽略的细节：把耗时列按从小到大排序，能快速发现异常。绝大多数正常站点的首页响应在 0.2~2 秒之间，如果某个目标耗时 0.01 秒，大概率是 CDN 缓存或者静态错误页；如果耗时 7.9 秒，接近超时阈值，那这个目标可能只是“勉强活着”，业务访问体验已经很差了。响应体的大小分布也能看出端倪——内容长度在 1KB 以下的“存活”目标，基本都是空壳站或反爬拦截面，真正有业务内容的页面很少会小于 1KB。这两类目标，我会在结果文件里单独打标签，后续人工再看。
还有一类结果需要睁大眼睛看：status_code为 200、标题却是空白的记录。前面正则提取不到标题就返回None，但返回 200 的页面没有 title 标签，这本身就是一个值得关注的现象——要么页面是靠 JavaScript 异步渲染的（Vue/React 单页应用很常见），要么是接口返回 JSON 而不是 HTML，要么就是真的没有设置标题。对这类目标，我会追加检查Content-Type是否为text/html，如果不是，那它就不是一个“网页”，后续处理方式完全不同。这一步操作谈不上复杂，但它能拦住一大半误判——很多新手拿到批量探测结果，看到 200 就觉得万事大吉，实际上响应内容可能是一段 JSON 或者一张图片，这种情况下“获取标题”本身就是无意义的操作。从那以后我每次跑批量探测都强制走一遍这套二次确认流程，先从超时失败里召回可能存活的遗漏目标，再做 200+空白标题的 Content-Type 复核。这两步加起来多花一两分钟，但换来的结果可信度是质的差别。希望帮到你。
本文还有配套的精品资源，点击获取
