抓取招聘网站而不触发 50 次保存限制

挑战

2026 年 6 月来自 ApplyArc 的一份基准测试针对 200 次真实职位抓取评估了五款 LinkedIn 职位爬虫。其中三款在大约 50 次保存后导致账号被标记或被悄悄限流。最终仅有两款完好存活。

该基准测试说明了一切。招聘网站曾经是容易攻破的目标，如今却已成为公开网络中最难抓取的平台之一。

如果你正在构建依赖职位列表数据的业务（如劳动力规划、薪酬基准分析、人才画像、作为股票研究信号的招聘动态），你的数据采集层正在对抗一套两年前根本不存在的防御体系。Indeed 会向不熟悉的会话展示验证页面。LinkedIn 会在 IP 轮换期间关联浏览器端信号。Glassdoor 实行基于 ASN 而非单个 IP 的 rate limit。ZipRecruiter 将薪资范围和发布日期放在 JavaScript 中渲染，前提是你的 header 必须看起来像真人而非脚本。

因此，50 次保存的上限并不是 LinkedIn 独有的问题，而是整个行业类别的普遍特性。

为什么招聘网站的抓取越来越难

2026 年发生了三项变化，且这些变化产生了叠加效应。

首先是 Bot 检测转向了行为分析。静态检查（User-Agent、IP 声誉、每秒 request 数量）曾经足以拦截业余爬虫，但现在已不再奏效。如今的防御机制会监控你在网站内的行为轨迹：加载页面的先后顺序、停留时长、是否重复请求真实浏览器本应缓存的 JS bundle。我们曾在 Bot 检测转向行为分析中讨论过这一转变。招聘网站很早就引入了该机制，因为真实用户的行为是一组数量有限的可重复操作（搜索、点击、阅读、保存），当脚本跳过其中一半的流程时就会极易被识别。

其次是 proxy 池的规模不再重要。当防御手段演进为连接层的指纹关联加上 ASN 声誉时，拥有 5000 万 IP 的住宅 proxy 池也无济于事。我们在为什么 proxy 池规模不再重要中详细分析了这一点。真正起效的是为目标网站选择正确的出口，而不是比别人拥有更多出口。

第三点是法律层面。Indeed 和 LinkedIn 都拥有会提起诉讼的法务团队。对于任何打算将采集数据进行商业化变现的团队而言，直接使用家庭 IP 运行公开爬虫的时代已经结束。

如今的数据采集方案

在 2026 年进行人才情报相关工作，始终有效的模式是采用分层架构：对受保护的招聘网站使用真实浏览器渲染抓取，配合精细的出口选择，以确保你使用的出口不会与其他 bot 来自同一个供应商。

在像 FourA 这样的平台上，这意味着由两款产品协同工作。

Browser 负责渲染端：通过 unblocker: true 发送 URL，即可获取来自真实浏览器 session 的已渲染 HTML、cookie 以及截图。JS 会执行，懒加载字段会填充，且请求可以通过捕获大多数基础客户端的连接层检测。Proxy 选择在底层自动运行：平台会为每个请求挑选一个出口节点，并在 response 中返回其不透明的 base36 ID（Single/Browser 在顶层 r.proxy，Auto 在 r.session.proxy），以便在需要 session 连续性时后续调用可以复用相同的出口。对于大多数招聘网站任务，Auto 是最合适的入口，它会根据每个目标的需求协调调度 Single、Proxy 和 Browser，无需在代码中手动处理。

import requests

r = requests.post(
    "https://api.foura.ai/api/auto",
    headers={"Authorization": "Bearer pk_live_..."},
    json={
        "url": "https://www.example-jobs.com/search?q=data+engineer&l=Remote",
        "validate": {
            "status": {"accept": [200]},
            "data":   {"accept": ["data-testid=\"job-card\""],
                       "fail":   ["Just a moment", "captcha"]},
        },
    },
).json()

# r["data"] or r["body"]   — rendered content (Auto picks Single→"data" or Browser→"body" per host)
# r["session"]              — { "proxy": "<base36 id>", "cookies": [...], "userAgent": "..." }
# Reuse r["session"]["proxy"] on the next call to stick to the same exit, or pass it
# via `ignoreProxies: [<id>]` to force a different one.

关于这种方案实际能为你带来什么的两个说明。

类似 ApplyArc 的 50 次保存限制主要是一个 session 问题，而不是 pool 问题。合理轮换的真实浏览器 session，在触发 rate limit 之前的存活时间远长于原始 HTTP 客户端。而且 response 返回的是不透明的 proxy ID，而不是原始出口，因此你的代码可以保持简洁，无需追踪具体由哪个出口处理了哪个 request。

第二个说明与代码片段中未包含的内容有关。跨招聘网站的去重（例如 LinkedIn、Indeed 以及公司自家招聘页面上的同一个数据工程师职位，带有三种略微不同的职称）属于你的业务逻辑，而不是采集层的问题。我们看到很多团队低估了这一点。数据标准化消耗的工程时间远多于数据抓取本身，而这正是大多数人才情报产品最终展开竞争的地方。

结果

一个在三个招聘网站上追踪 200 家公司的人才情报团队，每周大约需要抓取 50,000 个页面：搜索结果、职位详情页以及偶尔的公司主页刷新。在该工作负载下你期望达到的指标：

在 Indeed 级别的目标上成功率超过 95%，这里的成功指的是获取到已渲染且包含薪资范围和发布日期的 HTML。
端到端单职位成本低于 0.004 美元，包含渲染和出口选择。
活跃职位的刷新周期为 6 到 12 小时，确保你的招聘信号仪表盘不会落后于市场。

这些数据仅供参考，基于运行这种分离架构模式的团队所报告的情况。你的实际成本取决于你针对的招聘网站以及筛选最新职位的激进程度。

核心结论

招聘网站当前的抓取难度已经更接近广告技术和票务平台，而不是普通电子商务。这是一个切实的变化，也解释了为什么在 2024 年有效的抓取库会在 2026 年频繁碰壁。

能够成功扩展规模的团队不再把“抓取器”当作单一工作单元来看待。他们将 session、出口和去重视为三个独立的关注点，并为前两者采购基础设施，以便其工程师能将精力集中在第三个方面。最便宜的职位列表数据，就是你在被标记后无需重新采集的那一份。