HTTP 429 请求过多：网络爬虫的原因与预防

TL;DR:

• HTTP 429 请求过多意味着客户端在一段时间内超过了服务器选择的请求限制。 该限制可能根据账户、凭证、IP 地址、端点、区域或加权操作进行划分。
• 第一个响应是停止添加工作。 保留响应，识别限制范围，并在共享请求预算后保持新工作。
• 预防来自协调。 中央并发控制、缓存、去重、自适应调度和明确的停止条件减少了无效请求。
• Scrapeless Scraping Browser 可以集中浏览器并发和会话治理。 它应在目标规则、账户允许和明确的收集预算内操作。

HTTP 429 请求过多是流量控制信号：服务器将请求与调用者或资源范围关联，计算足够的工作来超过策略，并拒绝新的请求。因此，网页抓取中的 429 错误应在流量控制层进行诊断。

由每个调度程序和工作者共享的网页抓取请求预算提供了持久的解决方案。本指南解释如何找到限制范围，预防因意外压力导致的 429 错误，并负责任地操作管道。

HTTP 429 的意思是什么？

定义标准是 RFC 6585，第 4 节。它指出，429 状态表示用户在给定时间内发送了太多请求——速率限制。该标准留有空间让服务器选择如何识别用户以及如何计算请求。

这种灵活性解释了为什么单独的状态无法揭示完整规则。一个服务可能按 API 密钥计算请求，另一个可能按账户和端点计数，另一个可能按加权成本计数。在更改流量之前，请阅读响应体、文档头、服务仪表板和提供商指南。

HTTP 429 与 403 与 503

RFC 9110 将 403 定义为拒绝，将 503 服务不可用 定义为由于过载或维护而无法处理请求。一个平台可以实现自定义行为，因此保留主体和请求 ID，而不是仅仅从数字分类。

速率限制是如何应用的

网关或应用程序首先识别范围，然后计算在时间窗口或容量模型内的工作。

识别共享计数器的每个生产者。一个本地工作者看似保守，但一个车队可能会集体超过同一账户的允许。

抓取管道中的常见原因

最常见的原因是架构问题：

• 每个工作者维护独立的速率计数器；
• 调度程序在分发后发出重复的 URL；
• 即使页面未更改，轮询仍在继续；
• 分页没有项目、页面或时间边界；
• 开发和生产共享凭证；
• 并发没有目标级别的上限自动增长；
• 消费者的失败导致上游工作积累；
• 缓存键省略地方、身份或架构细节，造成不必要的未命中。

即使代码按设计运作，流量仍然可能超出产品计划或目标的文档政策。容量规划必须包括您的浏览器平台限制和所访问服务的规则。

开始使用 Scrapeless 抓取

利用 Scrapeless 提升您的网页抓取和自动化工作流程！
今天注册并获得 5 美元的免费信用 — 无需信用卡。

立即在 Scrapeless Dashboard 领取您的免费信用。

诊断限制范围

当出现 429 时，暂停对受影响目标的接入并保存证据。记录：

• 带时区的时间戳；
• URL 模板和 HTTP 方法；
• 凭证或账户标识符以隐藏形式显示；
• 源环境和出口组；
• 活跃并发数和队列深度；
• 响应头、有限主体和请求 ID；
• 按可能的范围计算的最近请求数量；
• 另一个应用程序是否共享相同的身份。

根据账户、密钥、端点、目标主机和源网络对 429 观察进行分组。在一个维度下的明显聚集通常会暴露计数。将证据与提供者的官方配额文档进行比较，或请服务拥有者识别请求 ID。

不要通过增加流量来探测确切的阈值。这会增加压力并可能违反目标的操作政策。

通过请求预算防止 429

请求预算是一个在工作到达网络之前应用的入场规则。根据目标和已知身份范围定义预算，然后让每个生产者从相同的预算中保留。

将工作表转变为集中队列政策。队列应了解目标、身份范围、优先级、截止日期、去重键和估计单位成本。它应在工作占用浏览器容量之前拒绝过时或重复的工作。

并发、缓存和去重

并发控制是活跃操作的数量，而不是较长时间内允许的数量。使用活跃会话上限和请求预算。将控制放置在单个工作者之上，以便水平扩展无法无声地增加流量。

在业务新鲜度窗口允许重用时，缓存消除了等效读取。 RFC 9111 解释了 HTTP 缓存如何减少响应时间和网络带宽，并设定了重用存储响应的条件。应用级缓存需要同样仔细的键：目标 URL、相关头、位置、授权身份和架构版本都可能影响等价性。

去重压缩了同时需求。如果几个消费者请求相同的产品和观察窗口，则发布一个集合事件给所有订阅者。保留内容哈希或源版本，以便未更改的观察不会触发昂贵的下游工作。

以下本地示例在固定预算内接受唯一工作，并在容量耗尽时停止：

jobs = ["/a", "/a", "/b", "/c", "/d", "/e"]
request_budget = 4
seen = set()
admitted = []

for path in jobs:
    if path in seen:
        continue
    if len(admitted) >= request_budget:
        break
    seen.add(path)
    admitted.append(path)

print({"admitted": admitted, "remaining": len(jobs) - len(admitted)})

输出接受 /a、/b、/c 和 /d，而重复的 /a 则不消耗网络分配。在生产中，在所有工作者使用的基础设施中持久化共享计数器。

监控和停止条件

在系统达到拒绝之前进行监控。 有用的度量包括被接受的工作、被抑制的重复、缓存命中、活跃会话、队列年龄、请求单位、按范围统计的 429 次数，以及数据的新鲜度。

OpenTelemetry 将指标描述为带有时间戳和元数据的运行时度量。它的 度量指导 支持适合请求预算、队列延迟和并发的计数器和直方图。

在配置中定义停止条件，而不是在操作员的记忆中：

• 针对目标的任何 429 会关闭该范围的新入场；
• 未记录的限制将在审核之前关闭自动收集；
• 超过业务截止日期的队列年龄会丢弃过时工作；
• 升高的错误比率会减少或关闭入场；
• 缺少授权、条款冲突或机器人政策会停止收集；
• 成本上限会在必要工作之前停止可选工作负载。

目标是立即减轻压力并保留证据以作出控制决策。 429 不应启动自动创建另一个请求的循环。

Scrapeless Scraping Browser 的适用位置

Scrapeless Scraping Browser 为动态、授权的目标提供托管浏览器执行。集中会话创建使浏览器并发性可见且可管理，同时位置和会话输入使应用程序能够定义观察上下文。

Scrapeless 不会替代目标的速率政策。将浏览器连接放置在共享入场队列后面，限制并发会话，并在目标或您自己的预算指示停止时关闭工作。请查阅 Scraping Browser API 文档 获取当前连接详细信息。

负责任的爬虫检查清单

• 确认目标、账户和数据已授权自动化。
• 阅读目标的条款、官方 API 指导和文档配额。
• 获取并遵循可解析的 robots.txt 规则（如适用）。 RFC 9309 定义了爬虫规则的标准化访问和解析行为。
• 在服务间共享一个目标级请求预算。
• 去重 URL 并在新鲜度窗口内缓存等效观察结果。
• 限制分页、项目数量、经过时间和支出。
• 将开发、测试和生产凭据与预算分开。
• 记录请求 ID 和政策范围，而不存储机密信息。
• 当出现 429 或授权冲突时停止新的工作。
• 当合法需求超过文档允许时，联系服务所有者。

结论

HTTP 429 请求过多最好视为一个容量和治理问题。确定计数器，协调每个生产者使用一个请求预算，消除重复工作，重用合适的缓存结果，限制并发，并使停止条件自动化。

Scrapeless Scraping Browser 可以作为依赖浏览器的收集的受控执行层，而队列和政策层决定什么是被允许的。在确定会话容量时，请查看 Scrapeless 定价。

将浏览器工作纳入预算

使用 Scrapeless Dashboard 来评估托管的浏览器会话，并查看 如何在网络爬虫中处理分页 而不进行无限制的页面遍历。加入 Discord 或 Telegram 社区。

常见问题

问：在网络爬虫中，什么导致 429 错误？

当服务器将客户端与请求范围关联，并决定该范围已超出速率政策时，会发出 429。重复作业、共享凭据、协调不当的工作者和过度并发是常见的管道原因。

问：HTTP 429 和 503 是一样的吗？

不是的。429 将拒绝与调用者在选定政策下的请求量相关联。503 表示由于过载或维护，服务当前无法处理请求。

问：轮换代理可以防止 429 错误吗？

轮换代理不应用于规避目标的配额或流量政策。诊断文档范围，减少工作，协调合法允许，并在需要时向服务所有者请求额外的容量。

问：缓存如何防止 429 错误？

缓存允许等效需求重用合适的观察结果，而不是创建另一个网络请求。缓存键和新鲜度窗口必须反映 URL、位置、身份、模式和源政策。

问：如何控制浏览器并发？

将会话创建放在集中队列后面。实施目标级上限，为有价值的工作保留容量，测量队列年龄，防止个别工作者独立增加舰队。

问：一旦出现 429 应该采取什么措施？

停止接纳受影响范围的新工作，保存响应和请求 ID，识别共享计数器，并在收集恢复之前与服务所有者或内部平台团队沟通。