限速的工作原理
网站、API 网关、CDN 或 Web 应用防火墙会按配额统计请求数量。服务可以通过 IP 地址、API 密钥、账号、Cookie 或多种信号的组合来识别客户端。限额也可以只针对特定端点，例如 /api/search 或 /login。
配额用尽后，服务通常会返回 429 Too Many Requests，并可能通过 Retry-After 标头说明何时可以重试：
HTTP/1.1 429 Too Many Requests
Retry-After: 60常见的计数方式包括：
- **固定窗口：**按固定周期重置计数器，例如每分钟重置一次。
- **滑动窗口：**统计当前时刻之前指定时段内的请求数。
- **令牌桶：**随时间补充令牌，允许短时间突发请求，同时限制平均请求速率。
为什么使用代理仍会触发限速
代理会改变网站看到的来源 IP，但不会改变 API 密钥、账号、Cookie、浏览器指纹或请求模式。轮换可以把彼此独立的请求分散到多个 IP，但无法重置与其他身份信息绑定的限额。
共享 IP 可能反而更容易触发限速。多个用户的活动可能计入同一个 IP 的配额，导致 429 响应比预期更早出现。为绕过明确限额而反复切换 IP，还可能触发更严格的反机器人控制。
如何应对限速
- 查看公开规则。 自动发送请求前，阅读 API 文档、条款和 robots.txt。
- 遵守
Retry-After。 按指定秒数暂停，或等到指定的 HTTP 日期再重试。 - 降低请求压力。 减少并发，缓存重复响应，并把任务加入队列，避免集中发送大量请求。
- 延长重试间隔。 每收到一次 429，就增加下一次重试前的等待时间，并加入少量随机变化，避免多个工作进程同时重试。
- 申请更多容量。 如果工作负载已获授权，可使用官方 API 套餐，或联系网站所有者申请更高配额。
限速与 IP 封禁
| 限速 | IP 封禁 | |
|---|---|---|
| 目的 | 控制请求量 | 拒绝来自某个地址的请求 |
| 持续时间 | 通常是临时的 | 可能长期持续 |
| 典型响应 | 429，并给出重试等待时间 | 通常是 403，或直接丢弃请求 |
短暂暂停后，IP 封禁通常仍会持续；限速一般会在计数器重置后解除。
常见问题
“限速”是否总指同一种机制？
不一定。限速通常是设置请求上限或拒绝请求，也可能是降低处理速度或把请求加入队列。服务方经常混用这两种含义。
代理能防止限速吗？
不能。代理只会改变网站看到的 IP。基于账号、API 密钥、Cookie 或行为的限制仍然有效，也不应通过轮换 IP 规避网站明示的规则。
限速会持续多久？
具体取决于服务和配额窗口。如果响应中包含 Retry-After，应按其要求等待；否则请查阅 API 文档，并逐步延长重试间隔。