如果您从事市场平台的解析、竞争对手价格监控或社交媒体的自动化工作，您一定遇到过错误 429 请求过多。网站将您的请求视为可疑请求并阻止它们，所有自动化工作都会中断。在本文中，我们将探讨这个问题的原因，以及如何通过正确的代理设置、IP 轮换和合理的负载分配来解决它。
我们将为不同的任务提供具体解决方案：解析 Wildberries 和 Ozon、竞争对手监控、社交媒体 API 工作、大规模数据收集。所有建议都基于实践经验，并在实际项目中有效。
什么是错误 429 请求过多，为什么会发生
错误 429 请求过多 是服务器返回的 HTTP 响应代码，当您在特定时间段内超过允许的请求数量时。它是网站防止过载和自动化数据收集的保护机制。
出现 429 的典型情况：
- 市场平台解析 — 您从 Wildberries、Ozon 或 Avito 收集价格，每分钟发出数百个请求。网站检测到来自同一 IP 的异常活动并将其阻止。
- 竞争对手监控 — 自动收集商品、价格、库存数据。频繁检查时会触发限制。
- API 工作 — 许多 API 有严格的限制：例如，Instagram API 每小时允许 200 个请求，Twitter — 每 15 分钟 300 个请求。
- 大规模注册或操作 — 创建账户、发送消息、点赞。平台很快识别出自动化并阻止 IP。
重要的是要理解：错误 429 并不仅仅是技术限制。这是一个信号，表明网站将您的活动识别为可疑。如果继续从同一 IP 进行攻击，可能会导致永久封禁。
重要： 一些网站会返回 403 Forbidden 或仅显示验证码，而不是 429。其本质是相同的 — 您超过了限制并被阻止。
网站如何识别可疑活动
要有效绕过封锁，您需要了解网站是如何识别您的。现代保护系统分析多个参数：
1. IP 地址和请求频率
最明显的参数。如果来自同一 IP 的请求每分钟达到 100 个，而普通用户每分钟只有 5-10 个 — 这显然是自动化。网站会设定限制：
- Wildberries：每个 IP 每分钟大约 60 个请求
- Ozon：每分钟大约 30-40 个请求
- Avito：严格的限制，尤其是对于搜索请求
- Instagram API：每个应用每小时 200 个请求
2. User-Agent 和浏览器头信息
如果您通过脚本发送请求而没有正确的 User-Agent，网站会立即识别出这不是一个真实的浏览器。头信息也会被分析：Accept、Accept-Language、Referer。这些头信息的缺失或不典型值 — 都是红色警报。
3. 行为模式
真实用户不会每 2 秒发出一次完美的请求。他们会滚动、点击、暂停。如果您的解析器像节拍器一样工作 — 这就很可疑。
4. IP 地址类型
许多平台会将数据中心的 IP 列入黑名单。如果您使用来自 AWS 或 Google Cloud 的廉价代理，封锁的可能性会更高。来自真实提供商的住宅 IP 会引起更少的怀疑。
代理轮换：绕过限制的主要方法
解决 429 问题的主要方法是 IP 地址轮换。与其所有请求都来自同一 IP，不如将负载分配到多个地址上。每个 IP 只发出少量请求，并且不会超过限制。
代理轮换类型
| 轮换类型 | 工作原理 | 何时使用 |
|---|---|---|
| 按请求轮换 | 每个请求都来自新的 IP。代理提供商会自动更改地址。 | 大规模解析，需要快速收集大量数据时 |
| 按计时器轮换 | 每 5-30 分钟更换 IP。您使用一个地址进行一系列请求。 | 与需要会话的网站（购物车、授权）工作时 |
| 静态代理池 | 您有一个 100-1000 个 IP 的列表。脚本为每个请求随机选择一个地址。 | 当需要完全控制轮换和负载分配时 |
实践示例：解析 Wildberries
假设您需要解析 10,000 种商品的价格。Wildberries 在每分钟 60 个请求后会阻止来自同一 IP 的请求。如何解决：
- 使用按请求轮换 — 每个请求都来自新的 IP。您大约需要 167 个不同的 IP（10,000 个请求 / 每分钟 60 个请求 = 167 分钟使用一个 IP，但通过轮换可以在 10-15 分钟内完成）。
- 设置延迟 — 即使使用轮换，也不应每秒发出 1000 个请求。最佳：每秒 5-10 个请求，使用不同的 IP。
- 添加随机化 — 延迟应为随机值：请求之间 0.5 到 2 秒。
对于这样的任务，住宅代理 与自动轮换非常适合 — 它们拥有数百万个 IP 池，并在每个请求中自动更改地址，无需您干预。
请求之间的延迟设置
即使使用代理轮换，也不能以最大速度轰炸网站。现代保护系统会分析服务器的整体负载，如果看到类似 DDoS 的活动，可能会阻止整个 IP 范围。
延迟设置规则
基本规则：模拟真实用户
- 最小延迟：请求之间 0.5-1 秒
- 推荐：1-3 秒，带有随机波动
- 对于复杂网站（市场平台、社交媒体）：2-5 秒
- 在发生错误时使用指数延迟
指数延迟 (exponential backoff)
如果您仍然收到错误 429，请不要继续攻击网站。使用指数延迟策略：
- 第一次尝试失败 → 等待 1 秒
- 第二次尝试失败 → 等待 2 秒
- 第三次尝试失败 → 等待 4 秒
- 第四次尝试失败 → 等待 8 秒
- 依此类推，直到达到最大值（例如 60 秒）
这种策略为服务器提供了“冷却”时间，并降低了永久封禁的可能性。许多 API（Google、Twitter）在其文档中推荐这种方法。
不同任务的设置示例
| 任务 | 请求之间的延迟 | 备注 |
|---|---|---|
| 解析 Wildberries | 1-3 秒 | 使用代理轮换可以加快到 0.5-1 秒 |
| 解析 Ozon | 2-4 秒 | Ozon 对自动化更敏感 |
| Instagram API | 18 秒 | 限制为 200 请求/小时 = 每 18 秒 1 个请求 |
| Google 搜索解析 | 5-10 秒 | Google 很快会封禁，需要较长的暂停 |
| Avito 监控 | 3-6 秒 | 严格的保护，尤其是搜索时 |
User-Agent 和头信息：模拟真实浏览器
代理轮换和延迟解决了请求频率的问题，但这还不够。网站会分析您发送请求的方式。如果头信息看起来可疑 — 封锁是不可避免的。
模拟浏览器的必需头信息
每个请求中必须包含的最小头信息集：
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: ru-RU,ru;q=0.9,en-US;q=0.8,en;q=0.7
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
Cache-Control: max-age=0User-Agent 轮换
不要对所有请求使用相同的 User-Agent。创建一个包含 10-20 个当前浏览器版本的列表，并随机更改它们：
- Chrome（Windows、macOS、Linux）
- Firefox（不同版本）
- Safari（macOS、iOS）
- Edge（Windows）
常见错误： 使用过时的 User-Agent（例如，2024 年的 Chrome 90）或将移动 User-Agent 用于桌面网站。这会立即暴露自动化。
Referer 和 Origin
许多网站会检查请求来源。如果您解析商品页面，Referer 头中应包含目录或搜索的链接。如果解析 API — 需要正确的 Origin。
解析 Wildberries 的示例：
Referer: https://www.wildberries.ru/catalog/0/search.aspx?search=笔记本电脑
Origin: https://www.wildberries.ru选择哪些代理来绕过 429
选择代理类型至关重要。廉价的数据中心代理通常已经被列入黑名单，即使请求频率较低，您也会收到 429。
绕过限制的代理类型比较
| 代理类型 | 优点 | 缺点 | 适合哪些任务 |
|---|---|---|---|
| 数据中心 | 高速、低价 | 经常被封禁，容易被识别 | 没有保护的简单网站 |
| 住宅代理 | 真实提供商的 IP，难以识别，地址池大 | 价格较高，有时速度较慢 | 市场平台、社交媒体、复杂网站 |
| 移动代理 | 移动运营商的 IP，最大信任度 | 价格高，池子有限 | Instagram、TikTok、Facebook 广告 |
选择建议
对于市场平台解析（Wildberries、Ozon、Avito）： 使用带有请求轮换的住宅代理。池子应该很大 — 至少 10,000 个 IP。这可以确保每个 IP 发出少量请求，不会触发限制。
对于社交媒体 API 工作： 移动代理是最佳选择。Instagram 和 TikTok 更信任移动运营商的 IP，而不是住宅代理。一个移动 IP 可以无问题地服务 5-10 个账户。
对于竞争对手价格监控： 使用带有计时器轮换的住宅代理（每 10-15 分钟）。这允许从一个 IP 发出一系列请求，同时保持会话，但不会超过限制。
对于简单任务（解析新闻、博客）： 如果网站没有严密的保护，数据中心代理可能适用。但要准备好应对周期性的封禁。
真实案例：市场平台和 API 的解析
案例 1：Wildberries 的价格监控（每天 10,000 种商品）
任务： 市场平台的卖家监控 10,000 种商品的竞争对手价格。需要每天收集数据 2 次。
问题： 使用一个 IP 时，在 50-60 个请求后会被封禁。解析 10,000 种商品需要几个小时，并且不断被封禁。
解决方案：
- 连接带有 50,000 个 IP 的住宅代理，并使用按请求轮换
- 设置请求之间的随机延迟，从 0.5 到 2 秒
- 添加 User-Agent 轮换（20 种 Chrome 和 Firefox 版本）
- 设置正确的 Referer 和 Accept 头信息
结果： 解析 10,000 种商品只需 15-20 分钟，没有任何封禁。每个 IP 最多发出 1-2 个请求，无法被识别为自动化。
案例 2：Instagram 自动化（50 个客户账户）
任务： SMM 代理管理 50 个客户的 Instagram 账户。需要发布内容、回复评论、收集统计数据。
问题： Instagram API 每个应用的限制为每小时 200 个请求。在处理 50 个账户时，限制在 10 分钟内就会耗尽。
解决方案：
- 创建 10 个不同的 Instagram API 应用（每个应用 5 个账户）
- 每个应用使用单独的移动代理
- 设置请求之间的延迟为 18 秒（200 请求/小时 = 每 18 秒 1 个请求）
- 在收到 429 时添加指数延迟
结果： 所有 50 个账户稳定运行。错误 429 极少发生（每周 1-2 次），并通过重试自动处理。
案例 3：Avito 的解析（全俄罗斯的广告）
任务： 房地产聚合器从 Avito 收集所有城市的广告，以便建立数据库。
问题： Avito 在俄罗斯网站中具有最严格的保护之一。即使来自不同的数据中心 IP，10-15 个请求后也会被封禁。
解决方案：
- 切换到具有地理位置的住宅代理（来自与解析相同城市的 IP）
- 将请求之间的延迟增加到 3-5 秒
- 使用无头浏览器（Puppeteer）而不是简单的 HTTP 请求
- 模拟用户行为：滚动、点击、鼠标移动
结果： 每天成功解析 50,000+ 条广告。封禁减少了 95%。剩余的 5% 通过重试新 IP 处理。
案例 4：竞争对手 API 监控（电子商务）
任务： 在线商店通过竞争对手的 API 监控商品的可用性和价格。
问题： 大多数竞争对手的 API 具有公共限制（每小时 100-500 个请求）。超过限制时返回 429。
解决方案：
- 创建带有优先级的请求队列（最重要的商品更频繁检查）
- 通过响应头监控限制（X-RateLimit-Remaining）
- 在达到 80% 限制时自动暂停
- 为每个竞争对手使用多个 API 密钥（在可能的情况下）
结果： 系统自动分配请求，以确保从不超过限制。数据以最大可能的频率更新，且没有封禁。
所有案例的共同教训：
错误 429 需要综合解决：代理轮换 + 正确的延迟 + 模拟真实行为。不能仅依赖一种方法。即使有一百万个 IP，如果以可疑的头信息每秒发出 1000 个请求，您也会被封禁。
结论
错误 429 请求过多是网站的保护机制，可以通过正确的方法绕过。解决问题的主要原则：
- IP 地址轮换 — 将负载分配到多个代理，以确保每个地址发出最少的请求
- 正确的延迟 — 模拟真实用户，随机暂停 1 到 5 秒
- 正确的头信息 — 使用当前的 User-Agent 和完整的浏览器头信息集
- 选择代理类型 — 对于复杂网站（市场平台、社交媒体），使用住宅或移动代理
- 错误处理 — 在收到 429 时应用指数延迟，不要重复攻击网站
请记住：目标不是以任何代价欺骗保护，而是让您的自动化看起来尽可能自然。现代保护系统变得越来越智能，粗暴的手段不再有效。
如果您计划从事市场平台解析、竞争对手监控或社交媒体自动化，建议尝试 住宅代理 — 它们提供大量的 IP 地址池、自动轮换和最低的封禁风险。对于 Instagram、TikTok 和其他移动平台，移动代理 更适合，因为它们使用真实的运营商 IP。