挑战
ApplyArc 在 2026 年 6 月的一项 基准测试 测试了五种 LinkedIn 职位抓取工具，执行了 200 次真实职位拉取。其中三种在保存约 50 次后被标记或被悄悄限流。只有两种安然无恙。
这项基准测试说明了一切。招聘网站曾经是容易的目标。现在它们是开放网络上最难的目标之一。
如果你正在构建依赖职位列表数据的产品 (劳动力规划，薪酬基准测试，人才盘点，以招聘为信号的股票研究)，你的收集层正面临两年前不存在的防御体系。Indeed 会向陌生的会话发送 CAPTCHA。LinkedIn 会跨 IP 轮换关联浏览器端信号。Glassdoor 根据 ASN 而不是 IP 进行限流。ZipRecruiter 将薪资范围和发布日期推送到 JavaScript 中，只有当你的 header 看起来像真人而不是脚本时才会渲染。
因此，50 次保存限制不是 LinkedIn 独有的问题。它是整个行业的普遍特性。
为什么招聘网站越来越难抓取
2026 年发生了三个变化，并且它们叠加在了一起。
首先是机器人检测转向行为分析。静态检查 (User-Agent，IP 信誉，每秒请求数) 过去足以阻止业余的抓取工具。现在不行了。今天的防御系统会观察你在网站上的行为模式：你以什么顺序加载哪些页面，你停留了多久，你是否重新获取了真实浏览器会缓存的相同 JS 包。我们在 机器人检测转向行为分析 中讨论过这种转变。招聘网站很早就采用了这种技术，因为它们的访客只执行少量可重复的操作 (搜索，点击，阅读，保存)，当脚本跳过一半序列时，就很容易被发现。
其次是 proxy 池大小不再重要。当防御机制是连接层的指纹关联加上 ASN 信誉时，拥有 5000 万 IP 的住宅代理池也无济于事。我们在 为什么 Proxy 池大小不再重要 中讨论过这一点。有效的方法是为目标网站选择正确的出口，而不是拥有比其他人都多的出口。
第三是法律风险。Indeed 和 LinkedIn 都有提起诉讼的法务团队。对于任何打算出售其收集的数据的人来说，用家庭 IP 运行公开抓取工具的时代已经结束。
现在的收集方式
对于 2026 年的人才情报工作，持续有效的模式是分离技术栈：对受保护的网站进行真实的浏览器渲染抓取，加上谨慎的出口选择，以确保你不会与所有其他机器人来自同一个提供商。
使用 FourA 这样的平台时，这是两个相互通信的产品。
Browser 处理渲染端：通过 unblocker: true 发送 URL，返回渲染后的 HTML，cookie，以及真实浏览器会话的截图。JS 会被执行，延迟加载的字段会被填充，请求会通过捕获大多数基础客户端的连接层检查。Proxy 选择在后台运行：平台为每个请求选择一个出口，并在 response 中返回其不透明的 base36 ID (位于 Single/Browser 的顶级 r.proxy，或 Auto 的 r.session.proxy)，以便后续调用在需要会话连续性时可以重用相同的出口。对于大多数招聘网站的工作，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 次保存限制主要是一个会话问题，而不是池问题。与原始 HTTP 客户端相比，经过周密轮换的真实浏览器会话在触发限流器之前能持续更长的时间。并且 response 带有不透明的 proxy ID 而不是原始出口，因此你的代码保持简单，无需追踪哪个出口处理了哪个请求。
第二点说明是关于代码片段中没有包含的内容。跨网站去重 (LinkedIn，Indeed 和公司自带招聘页面上的同一个数据工程师职位，有三个略微不同的头衔) 是你的问题，而不是收集层的问题。我们看到过许多团队低估了这一点。标准化消耗的工程时间比抓取更多，这也是大多数人才情报产品最终的竞争点。
结果
一个跨三个网站追踪 200 家公司的人才情报团队每周大约需要 50000 次页面抓取：搜索结果，职位详情页，以及偶尔的公司页面刷新。在这个工作负载上你需要达到的目标数据：
- 在 Indeed 级别的目标上成功率高于 95%，这里的成功意味着返回渲染后的 HTML，并填充了薪资范围和发布日期。
- 端到端单职位成本低于 0.004 美元，包括渲染和出口选择。
- 活跃职位的刷新频率在 6 到 12 小时之间，这样你的招聘信号仪表盘就不会滞后于市场。
这些数字仅作说明，基于运行这种分离技术栈模式的团队报告。你的实际成本取决于你针对的网站以及你过滤新帖子的激进程度。
关键总结
招聘网站现在的抓取难度更接近广告技术和票务系统，而不是一般的电子商务网站。这是一个真实的转变，它解释了为什么在 2024 年有效的抓取库在 2026 年总是触发同样的限制。
成功跨越这一障碍的团队不再将“抓取工具”视为一个工作单元。他们将会话，出口和去重视为三个独立的关注点，并为前两个购买基础设施，以便他们的工程师可以将时间花在第三个上。最便宜的职位列表数据是你在被标记后不需要重新收集的数据。