维基百科代理采集：2026 年科研数据实操

TL;DR: 高效采集维基百科数据，先用官方 API 或数据转储减少请求，再按需引入代理；通过连接复用、明确超时、缓存、断点续采和全局限速提高有效数据产出。收到限流响应时暂停任务，不通过换 IP 继续请求。

先选数据渠道，再决定是否使用代理

如果研究目标是城市人口、条目分类或修订历史，先确定字段、语言版本和时间范围。人口数据至少拆成“数值、单位、统计年份、引用来源”四列；缺失值不能记为零，不同年份的数据也不能直接横向比较。

按任务规模选择入口，避免把所有需求都变成逐页下载：

Wikimedia 官方数据转储提供离线数据入口；MediaWiki API 使用规范建议批量请求、串行处理，并对非交互任务使用 maxlag 参数。代理只是额外的网络中转，不会让页面字段更完整，也不会自动解决版本不一致。

每条记录保存语言版本、页面标识、修订标识和采集时间。跨语言合并时核对实体对应关系，不要只按标题去重。

代理能解决什么问题

代理适合需要固定网络出口、区分不同作业连接故障，或验证不同地区访问结果的任务。例如，两台研究服务器可以分别记录出口与失败日志，便于定位某一条网络路径的问题。

代理不能替代访问许可，也不保证匿名或免于限流。它增加了一个流量中转方，因此应保留 HTTPS 证书校验，审查服务商的数据处理政策，并避免向不必要的第三方发送研究账户凭据。

按任务选择代理类型

不要预设住宅代理一定更快。用同一批页面、同一请求预算对比候选方案，记录成功写入的记录数、耗用流量和重试次数，而不是只测代理端口是否连通。

EProxies 提供覆盖 195+ 个国家的 72M+ 住宅 IP，支持 HTTP(S) 和 SOCKS5；住宅代理起价为 $0.25/GB，ISP SOCKS5 代理起价为 $0.95/IP。按流量计费与按 IP 计费不能直接比较，应先估算下载量和所需出口数。

配置一个可验证的采集环境

先创建虚拟环境，再安装依赖：

python -m venv .venv
pip install "requests[socks]"

将完整代理地址存入环境变量 PROXY_URL，不要写进代码仓库。代理用户名或密码包含 @、: 等字符时，需要先进行 URL 编码。

下面的示例只获取一个条目的修订元数据，用于验证代理、响应与字段结构；运行前替换联系方式：

import os
import requests

with requests.Session() as session:
    proxy = os.environ["PROXY_URL"]
    session.proxies.update({"http": proxy, "https": proxy})
    session.headers["User-Agent"] = (
        "ResearchCollector/1.0 (contact: [email protected])"
    )

    response = session.get(
        "https://zh.wikipedia.org/w/api.php",
        params={
            "action": "query",
            "format": "json",
            "formatversion": 2,
            "prop": "revisions",
            "titles": "北京市",
            "rvprop": "ids|timestamp",
            "maxlag": 5,
        },
        timeout=(5, 30),
    )
    response.raise_for_status()
    data = response.json()
    if "error" in data:
        raise RuntimeError(data["error"])
    print(data["query"]["pages"])

这里的 5 秒连接超时和 30 秒读取超时是起步配置，不是官方性能承诺。Requests 的读取超时限制等待数据的时间，并非整个下载的总时长；需要任务级截止时间时，应由调度器另行控制，参见 Requests 超时说明。

HTTP 状态正常也不等于采集成功：还要检查 API 错误、页面是否存在、目标字段是否齐全。不要把返回的代理错误页或空记录直接写入正式数据表。

如何优化代理设置与请求流程

复用连接，减少无效切换

同一批任务使用 requests.Session()，并在服务支持时保持代理出口稳定。Requests 的会话支持连接池与连接复用，但响应内容需要读完或显式关闭，连接才能回到池中，见 Requests 连接复用文档。

对只提取文本或表格的任务，不必启动浏览器下载图片、字体和视频。确实需要浏览器渲染时，先验证禁用这些资源不会破坏目标字段，再阻止加载。

用小样本调整超时与并发

先串行采集 50—100 个代表性页面，记录完整响应耗时的中位数、P95、失败类型及每条有效记录的流量。这个样本量是测试起点，不代表维基百科允许的请求速率。

如果大量请求在读取阶段超时，先检查页面大小与目标响应时间；如果代理鉴权失败，则修复凭据或白名单。增加超时不能修复错误密码，增加出口也不能修复解析规则。

所有出口共享限速预算

将多个工作进程接入同一任务队列或全局限速器，避免每个代理各自增加请求压力。收到 HTTP 429 时遵循 Retry-After；对于 API 的 maxlag 错误，即使 HTTP 状态为 200，也应暂停并稍后重试。

没有明确等待提示的临时连接故障，可以采用有上限的指数退避，例如等待 2、4、8 秒并加入小幅随机抖动，最多重试 3 次。这是客户端配置示例；遇到明确拒绝访问，不应套用该策略反复请求。

缓存成功结果，保留失败断点

按“语言版本＋页面标识＋修订标识”保存原始响应，另存解析规则版本。任务恢复时只处理未完成项；解析器升级后先重处理本地原始数据，不重新下载全部页面。

至少记录以下四项：

• 有效记录率：成功校验并写入的记录数 ÷ 尝试采集数。
• 单位流量产出：有效记录数 ÷ 代理耗用 GB。
• 重试比例：重试请求数 ÷ 总请求数。
• 失败类别：代理鉴权、连接超时、目标限流、API 错误、解析失败。

例如，100 次响应中只有 60 条字段完整，就不能按“100 次请求成功”评价性能。扩容前可参考大规模数据集采集的扩展方法。

保留来源与许可，控制采集边界

启动任务前检查目标语言站点的 robots.txt、接口规范和服务条款；使用稳定、可识别的 User-Agent，注明项目和联系方式。日志应隐藏代理密码，记录暂停原因及恢复时间。

发布内容或数据集前，依据 Wikimedia 使用条款核对署名、许可与再分发要求。图片等媒体文件需要逐项检查许可，不能默认与条目正文相同；用户页、讨论页及在世人物信息还需评估隐私与传播风险。

相关阅读

• 代理服务器如何支持数据挖掘
• 电商数据采集最佳实践

常见问题

使用代理采集维基百科数据有哪些实际好处？

代理可以为作业提供独立、可记录的网络出口，便于定位连接问题或验证地区访问差异。它不会提高数据完整性，也不赋予额外访问权限；全站研究通常应先评估官方转储。

如何为维基百科采集脚本配置代理？

在 requests.Session().proxies 中设置 http 和 https，并从环境变量读取代理地址。采用 IP 白名单时，登记运行脚本的服务器出口；先验证一个公开条目的响应和字段，再启动批量任务。

维基百科可以采集哪些类型的数据？

可以获取条目正文、表格、信息框、分类、内部链接及修订元数据，但不同入口提供的字段不同。每条记录保留来源与修订标识；人口等数值同时保存单位和统计年份。

采集维基百科数据有哪些法律与合规风险？

公开可访问不等于可以无条件转载，发布前需要核对内容许可、署名与再分发条件。媒体文件应单独检查许可，涉及个人信息时还需评估隐私风险；代理不会改变这些责任。

如何优化代理设置以提高性能？

先复用连接并保持批次内出口稳定，以连接 5 秒、读取 30 秒作为测试起点，再根据小样本的延迟与超时情况调整。缓存已成功采集的数据，记录单位流量产出和重试比例，而不只比较连接速度。所有出口共享限速预算；收到限流或 maxlag 错误时暂停任务，不通过换 IP 继续发送。

如何让采集到的维基百科数据可复现？

保存页面标识、修订标识、采集时间、原始响应和提取规则版本；使用转储时记录文件名称与日期。将原始层与清洗层分开存储，修改单位转换或缺失值规则时直接重新处理本地数据。