挑战
2026年6月，一项来自 ApplyArc 的基准测试对200次真实职位提取中的五款 LinkedIn 职位抓取工具进行了测试。在进行大约50次保存后，有三款工具导致账号被标记或被静默限流。只有两款工具完好无损地幸存下来。
该基准测试说明了一切。招聘网站过去曾是容易抓取的目标。现在，它们已成为公开网络上最难抓取的网站之一。
如果您正在构建任何依赖职位列表数据的应用（劳动力规划、薪酬基准分析、人才画像、作为股票研究雇佣信号的招聘数据），您的收集层正在与两年前尚不存在的一系列防御机制进行对抗。Indeed 会对不熟悉的会话抛出 CAPTCHAs。LinkedIn 会在 IP 轮换中关联浏览器端信号。Glassdoor 按照每个 ASN 进行 rate limit，而不是每个 IP。ZipRecruiter 将薪资范围和发布日期推送到 JavaScript 中，只有当您的 headers 看起来像真人而不是脚本时，该 JavaScript 才会渲染。
因此，50次保存墙并不是 LinkedIn 独有的问题。它是整个类别的共同特征。
为什么招聘网站变得越来越难抓取
在2026年，有三件事发生了变化，并且它们叠加在了一起。
第一点是机器人检测转向了行为分析。静态检查（User-Agent、IP 声誉、每秒请求数）过去足以阻止业余抓取者。现在不行了。如今的防御机制会观察您在网站上的移动轨迹：您以何种顺序加载哪些页面、停留了多长时间、是否重新获取真实浏览器会缓存的相同 JS 资源包。我们在机器人检测转向行为分析中写过这种转变。招聘网站很早就采用了这种方法，因为它们的访问者只执行少数可重复的操作（搜索、点击、阅读、保存），这使得脚本在跳过一半步骤时很容易被发现。
第二点是 proxy 池的大小不再重要。当防御机制是连接层的指纹关联加上 ASN 声誉时，一个拥有5000万个 IP 的住宅池也无济于事。我们在为什么 Proxy 池大小不再重要中讨论过这个问题。真正有效的是为目标网站选择正确的出口，而不是拥有比其他人都多的出口。
第三点是法律层面。Indeed 和 LinkedIn 都有会提起诉讼的法律团队。对于任何计划销售所收集数据的人来说，在家里用个人 IP 运行公开抓取工具的时代已经结束了。
现在的收集方式是什么样的
对于2026年的人才情报工作，持续有效的模式是分层架构：对受保护的网站进行真实的浏览器渲染获取，加上精细的出口选择，从而避免与所有其他机器人来自同一个服务商。
使用像 FourA 这样的平台，这就是两个产品之间的协同工作。
Browser 负责处理渲染端：发送带有 unblocker: true 的 URL，获取渲染后的 HTML、cookies 以及来自真实浏览器会话的截图。JS 被执行，懒加载字段被填充，并且 request 通过了能拦截大多数基础客户端的连接层检查。Proxy 选择在后台运行：平台为每个 request 选择一个出口，并在 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次保存墙主要是一个会话问题，而不是 IP 池的问题。一个经过周密轮换的真实浏览器会话，在触发 rate-limiter 之前，其持续时间远比原始 HTTP 客户端要长。而且 response 携带的是一个不透明的 proxy id，而不是原始出口，因此您的代码可以保持简洁，无需追踪哪个出口处理了哪个 request。
第二点是关于代码片段中没有包含的内容。跨网站去重（例如在 LinkedIn、Indeed 和公司自己的招聘页面上，同一个数据工程师职位有着三个略有不同的标题）是您需要解决的问题，而不是收集层的问题。我们看到过很多团队低估了这一点。数据规范化消耗的工程时间比数据获取还要多，而这正是大多数人才情报产品最终展开竞争的地方。
结果
一个在三个网站上追踪200家公司的人才情报团队，每周大约需要进行50000次页面获取：搜索结果、职位详情页以及偶尔的公司页面刷新。在这样的工作负载下，您希望达到的指标如下：
- 成功率达到95%以上在 Indeed 级别的目标上，这里的成功意味着获取到已填充薪资范围和发布日期的渲染后 HTML。
- 端到端每个职位的成本低于0.004美元，包括渲染和出口选择。
- 活跃职位的更新频率为6到12小时，这样您的招聘信号仪表盘就不会滞后于市场。
这些数字仅作说明之用，基于运行这种分层架构模式的团队所报告的数据。您的实际成本取决于您针对哪些招聘网站，以及您对新鲜发布职位的过滤力度。
核心要点
招聘网站现在的难度更接近于广告技术和票务网站，而不是普通的电子商务网站。这是一个真正的转变，也解释了为什么在2024年有效的抓取库在2026年总是会触发相同的限制墙。
成功突破这一限制的团队不再将“抓取工具”视为一个独立的工作单元。他们将会话、出口和去重视为三个独立的问题，并为前两者购买基础设施，以便他们的工程师可以将时间花在第三个问题上。最便宜的职位列表数据，就是您在被标记后无需重新收集的数据。