429 请求过多:网页抓取和 AI API 的修复方法

设想一个爬虫通过 CyberYozh App 代理收集公开的产品页面,然后将提取的文本发送到 AI API 进行分析。在作业进行到一半时,它停止并显示"429 请求过多"。诱人的反应是重试,但首先你需要找出请求在哪里失败。

是网站、中间服务还是 AI API 返回了错误? 每个都可以执行不同的限制,因此更改错误的设置可能会使问题无法解决。

在收集期间,检查请求节奏、并发连接,以及限制是应用于 IP 还是会话。 CyberYozh App 允许你在此阶段控制代理 IP 更改和会话行为。在 AI 处理期间,应检查提供商的请求和令牌配额。本指南将引导你完成这两个阶段,以便你可以识别限制、应用正确的修复方法,并避免重复已经成功的工作。

简要总结

• 429 请求过多意味着服务正在执行速率或使用限制。 这并不自动意味着你的代理有缺陷或被永久封禁。

• 首先找到来源: 目标网站、中间服务或 AI API。检查响应正文和标头。

• 放慢速度并谨慎重试。 遵守 Retry-After,协调工作进程,减少并发,并使用带抖动和最大尝试次数的退避策略。

• 保存已完成的工作。 重试失败的收集或分析步骤,而无需重新启动整个工作流程。

• 单独检查 AI 请求限制、令牌配额和配额。 更改 IP 不会增加账户配额。

• 将代理基础设施与收集需求相匹配。 CyberYozh App 提供 地理定位、 粘性会话 (最长 24 小时)和无限流量。

429 请求过多是什么意思?

429 请求过多错误 意味着服务正在限制进一步的请求,因为你已达到其使用阈值之一。通常,这涉及在特定时间窗口内发送过多请求。仅凭响应本身无法告诉你达到了哪个限制或限制将持续多长时间。

要了解"429 请求过多"对你的工作流程意味着什么,请检查服务如何计算活动。正如 MDN 的 429 文档 所解释的,限制可能应用于整个服务器、特定资源,或根据 IP 地址、经过身份验证的用户或应用程序。因此,即使每个工作进程发送的请求相对较少,多个工作进程也可以共享一个配额。

429 本身并不能确定永久封禁或证明你的代理有缺陷。 连接可能正常工作,而目标拒绝额外的请求。更改 IP 不会重置绑定到同一经过身份验证账户的限制。

在选择下一步操作之前,检查响应正文和标头以了解有关限制的详细信息,包括任何 Retry-After 指令。

找出哪个服务返回了错误

回到产品页面示例:是在文本到达 AI API 之前采集失败,还是在页面保存后分析停止?

在浏览器中,打开开发者工具,选择 网络 面板,并检查状态为 429的请求。在 Postman 中,查看响应状态、标头和正文。在应用程序日志中,将失败与其时间戳和工作流步骤匹配。

在可用时记录主机名、响应正文、相关标头、时间戳和请求 ID。 在共享诊断记录之前,删除密码、API 密钥、授权值和会话 cookie。

如何修复错误 429 请求过多

一旦确定了返回 429 的服务,让响应详情指导修复。在重新启动完整作业之前,完成这些步骤。

1. 暂停重复尝试
   暂停受影响的作业,然后检查后台工作进程、计划任务和重复运行。如果它们共享同一配额,也要协调它们的暂停;停止一个脚本可能不会改变大部分流量。

2. 遵守 Retry-After 头
   Retry-After: 60 表示至少等待 60 秒。HTTP 日期格式指定何时重试。 MDN 的 Retry-After 文档 解释了这两种格式。当该头不存在时,请查阅服务的文档限制并使用递增的重试延迟,而不是假设一个通用的等待时间。

3. 降低请求频率和并发数
   频率是指随时间发送的请求;并发是指同时运行的请求。两者都要控制。共享配额的工作进程需要协调节奏,例如使用带速率限制器的共享队列,因为单独的延迟无法控制它们的总流量。

4. 使用带抖动的指数退避
   在重复失败后增加延迟,并添加抖动(一个小的随机变化,帮助工作进程避免同时重试)。设置最大尝试次数,并在添加另一个循环之前检查客户端或 SDK 的现有重试行为。永远不要缩短服务器要求的等待时间。

5. 移除不必要的请求
   对排队的 URL 去重,在允许的情况下缓存成功的响应,并在不需要新数据时减少轮询。保存已完成的页面,这样一个失败的请求就不会重启整个采集作业。

这个 Python GET 示例处理两种头格式,在缺失或格式错误的值时回退到退避策略,并在五次失败尝试后停止:

import random
import time
from datetime import timezone
from email.utils import parsedate_to_datetime

import requests


def get_with_backoff(url):
    for attempt in range(5):
        response = requests.get(url, timeout=30)
        if response.status_code != 429:
            response.raise_for_status()
            return response
        if attempt == 4:
            response.raise_for_status()

        value = response.headers.get("Retry-After", "").strip()
        delay = 2 ** attempt
        try:
            if value.isascii() and value.isdigit():
                delay = max(delay, int(value))
            elif value:
                retry_at = parsedate_to_datetime(value)
                if retry_at.tzinfo is None:
                    retry_at = retry_at.replace(tzinfo=timezone.utc)
                delay = max(delay, retry_at.timestamp() - time.time())
        except (ValueError, TypeError, OverflowError):
            pass  # Invalid header: keep the backoff delay.

        response.close()
        time.sleep(delay + random.uniform(0, 1))

修复网页抓取中的重复 429 错误

重复出现的 429 错误需要审查采集作业的整体计划。统计针对同一网站的所有工作进程的请求数,特别是当它们共享 IP 地址、账户或 API 凭证时。通过公共速率限制器协调共享限制的工作进程,并在发生限流时对受影响的组应用冷却时间。

浏览器自动化可能产生比脚本显示的更多流量。打开一个产品页面可能触发对图像、脚本、推荐和后台更新的请求。检查浏览器的网络面板以查看实际到达目标的内容。仅在保留所需页面行为和数据的情况下跳过不必要的资源。

对排队的 URL 去重,同时保留有意的差异,例如区域店面或产品变体。保存成功的响应并记录哪些项目已完成。在开头的产品页面示例中,如果采集在目录中途停止,在所需等待后从失败的项目恢复。已采集的页面应保持可用于 AI 处理,无需再次下载。

当相关请求依赖于相同的 cookie、账户或 IP 地址时,保持会话连续性。根据任务的连接要求和识别的限制来进行代理轮换;仅仅出现 429 并不是更换地址的理由。围绕目标的文档配额安排采集,并在产品信息不需要频繁更新时减少轮询。

修复 AI API 和代理工作流中的 429 错误

您的抓取器可能成功采集每个产品页面,然后在发送结果进行分析时遇到 429。完成一批采集可能触发大量模型调用,每次调用都消耗 AI 提供商的请求或令牌配额的一部分。

检查您达到了哪个配额。 Claude 的速率限制文档 区分每分钟请求数、每分钟输入令牌数和每分钟输出令牌数。令牌是模型用于处理文本的单位。因此,即使请求数量看起来不多,少数大型输入也可能达到令牌限制。检查适用于您账户和模型的限制。

将分析作业排队并以受控的速度释放它们。如果多个代理共享组织或项目配额,请协调它们的总使用量。减少不必要的输入和请求简洁的输出也可以减少令牌消耗,而节奏控制可防止已完成的抓取批次压垮处理阶段。

诸如 last status: 429 too many requests 之类的日志条目记录了最终的 HTTP 状态;诊断仍然依赖于底层响应。检查提供商的错误类型、消息、请求 ID 和限制头,然后将它们与使用情况和账单信息进行比较。临时速率限制和耗尽的配额需要不同的操作。例如,Claude 记录了一个月度层级支出上限响应,该响应会持续失败直到访问恢复。

将采集的页面独立于分析作业保存。当 AI 请求失败时,在解决限制后仅重试该处理步骤。检查 SDK 的现有重试行为,以便外部工作流不会重复重启客户端已在重试的调用。

如果响应与观察到的使用情况冲突,请检查提供商的服务状态页面并调查共享配额的其他工作负载。保留时间戳和请求 ID 以供支持。更改抓取器的代理 IP 不会增加 AI 账户的请求或令牌限制。

CyberYozh App 在抓取工作流中的位置

一旦诊断确定需要区域访问、会话连续性或更好地控制采集连接,CyberYozh App 提供多种基础设施选项。将连接与任务匹配,包括相关请求需要保持相同 IP 的时长。

• 移动代理: 无限流量 的真实 LTE/4G/5G 套餐使持续采集的带宽成本可预测。专用套餐为您的工作负载预留移动通道,而共享套餐与其他客户共用一个通道。专用连接提供手动和基于 API 的 IP 更换,允许您围绕任务边界安排更换时间。 

• 轮换住宅代理: 使用区域定位来采集依赖位置的列表或价格。为独立采集任务选择轮换,或在相关请求需要临时 IP 一致性时选择 粘性会话 长达 24 小时。流量按使用量计费, 未使用的流量可结转 至下一个计费月。

• 静态 ISP 代理: 租用期内的固定地址适合需要相同 IP 的重复采集会话。这在不依赖临时粘性会话的情况下提供跨独立运行的连续性。

• 专用数据中心代理: 这些为目标接受该网络类型的工作负载提供固定的数据中心连接。它们适合不需要住宅或移动连接的常规采集作业。

CyberYozh App 支持在 Scrapy、 Postman、 Playwright、 Puppeteer和 Selenium中使用代理连接。完整的 API 访问权限让脚本可以在现有采集代码的同时管理支持的代理操作。