服务器端通过配置限流规则主动返回429状态码，本质是按IP、Token或接口路径等维度限制单位时间请求频次，并推荐Retry-After重试时机。
服务器端通过配置连接数限制来主动返回 429 状态码，本质是实施速率控制（Rate Limiting），不是简单“限制连接数”本身，而是限制单位时间内来自同一客户端（IP、Token、会话等）的请求数。触发后由服务端明确返回 HTTP 429 Too Many Requests，并推荐重试时机。
理解限流对象与粒度
直接限制“TCP 连接数”对 HTTP 爬虫效果有限，真正起作用的是对逻辑请求的频次管控。常见限流维度包括：
-
IP 地址级：如 Nginx 的
limit_req_zone $binary_remote_addr zone=perip:10m rate=5r/s;，每秒最多 5 个请求 - 用户凭证级：基于 API Key、Bearer Token 或登录态 Cookie 做计数，适合有鉴权的接口
-
接口路径级：对
/api/v1/items和/api/v1/search设置不同阈值，避免高开销接口被刷爆 -
组合维度：如
$binary_remote_addr$uri，实现“每个 IP 每个接口”独立限流
主流服务端配置方式
无需自研逻辑，用成熟中间件即可生效：
-
Nginx（最常用）：配合
limit_req指令，支持令牌桶算法；添加响应头Retry-After: 60需手动在 error_page 中注入 - Cloudflare：在 Dashboard 中设置 Rate Limiting 规则，可按字段匹配、自定义响应（含 429 + Retry-After）
- API 网关（如 Kong、Apigee）：提供可视化策略配置，支持滑动窗口、漏桶等多种算法，自动注入标准限流头
-
应用层（如 Flask/FastAPI）：使用
flask-limiter或slowapi，基于 Redis 计数，灵活绑定装饰器到具体路由
确保 429 被正确识别与响应
只返回状态码不够，需让爬虫能解析并退避：
- 必须返回标准
HTTP/1.1 429 Too Many Requests状态行，不能用 200 包裹错误信息 - 建议设置
Retry-After响应头，值为整数秒（如Retry-After: 30），便于客户端 sleep 精确时长 - 避免同时返回大量 429 却无 Retry-After——这会让爬虫只能靠指数退避，效率低且易误判
- 响应体可附简短提示（如 JSON：
{"error": "rate_limited", "retry_after": 30}），但非必需
验证与调试要点
上线前务必实测是否真能稳定触发并返回预期行为：
- 用 curl 或 Python 快速压测：
for i in {1..10}; do curl -s -o /dev/null -w "%{http_code}\n" https://api.example.com/data; done - 检查响应头是否含
Retry-After，且值合理；用httpbin.org/headers对比原始请求头是否被透传 - 确认日志中限流计数器是否递增（Nginx 的
limit_req_log_level设为 warn 可捕获） - 测试跨时段（如凌晨 vs 白天）是否触发不同时段阈值，验证时段分级限流是否生效
