应对反爬的正确姿势不是硬扛，而是把请求做得「像真实浏览器，并且足够克制」：请求头成套且自洽、请求间隔随机化、按响应状态码主动退避、会话内保持 Cookie、动态页面才启用渲染。看到 403 与 429 时先降速再重试，而不是加大并发。热点监控（AI 热点监控工具）抓取公开榜单与检索结果时，把「优先走官方接口、其次限速直采、再不行才渲染兜底」这条降级链路铺好，采集稳定性比堆代理更有效。下面按信号类型给出处置方案与代码。
一、先分清四类反爬信号
反爬手段各自检测的维度不同，对策也不能混用：
| 反爬手段 | 检测依据 | 典型表现 | 对应处置 |
|---|---|---|---|
| 请求头校验 | User-Agent、Referer、Accept 系列字段缺失或矛盾 | 直接 403 或返回空壳页 | 补齐成套浏览器请求头 |
| 频率限制 | 单 IP 单位时间请求数 | 429、临时封禁、跳转验证页 | 随机间隔 + 令牌桶限速 |
| 动态渲染 | 内容由前端脚本二次加载 | 源码里没有目标数据 | 无头浏览器渲染或找数据接口 |
| 行为与指纹 | 鼠标轨迹、TLS 握手、浏览器指纹 | 反复弹人机校验 | 降低频率，改走公开接口 |
判断顺序有讲究：先看返回体里有没有数据，再看状态码，往后才轮到怀疑指纹。很多「抓不到」其实是选择器写错或页面改版，不是被反爬。
二、请求头要成套且内部自洽
默认的 HTTP 客户端会发一组稀疏请求头，有的甚至在 User-Agent 里写明库名，等于自报身份。补齐字段的同时要注意一致性——声明自己是 Chrome 却带着 Firefox 的 Accept 值，本身就是异常特征。
import random
UA_POOL = [
("Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 "
"(KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36"),
("Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 "
"(KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36"),
]
def build_headers(referer: str = "") -> dict:
headers = {
"User-Agent": random.choice(UA_POOL),
"Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
"Accept-Language": "zh-CN,zh;q=0.9,en;q=0.8",
"Accept-Encoding": "gzip, deflate, br",
"Cache-Control": "no-cache",
"Upgrade-Insecure-Requests": "1",
}
if referer:
headers["Referer"] = referer
return headersUA 在会话之间轮换，但同一个会话内要固定不变。一个会话里 UA 每次请求都变，比一直用同一个更可疑。Cookie 同理，用 requests.Session 承接服务端下发的会话状态，跨请求保持连续。
三、限速：随机间隔加令牌桶
速度本身就是暴露特征。没有真人能每秒打开三十个页面，因此匀速高频请求一眼可辨。两个手段叠加使用：请求间隔按正态分布随机化，整体吞吐用令牌桶压住上限。
3.1 状态码是站点给出的明确信号
| 状态码 | 含义 | 处置动作 |
|---|---|---|
| 200 但内容为空 | 触发软限流或页面改版 | 校验选择器，降速后重试一次 |
| 403 | 请求特征被拒 | 检查请求头与会话，暂停该出口 |
| 429 | 超出频率限制 | 读取 Retry-After，按值休眠 |
| 503 / 网关错误 | 目标站压力大或临时波动 | 指数退避，缩减并发 |
读取并遵守 Retry-After 是低成本高收益的做法，站点已经把期望的等待时长直接告诉你了。
3.2 退避与限速实现
import random
import time
import requests
class RateLimiter:
"""令牌桶：控制长期平均速率，允许小幅突发"""
def __init__(self, rate: float, capacity: float):
self.rate = rate # 每秒补充令牌数
self.capacity = capacity
self.tokens = capacity
self.ts = time.monotonic()
def acquire(self) -> None:
while True:
now = time.monotonic()
self.tokens = min(self.capacity,
self.tokens + (now - self.ts) * self.rate)
self.ts = now
if self.tokens >= 1:
self.tokens -= 1
return
time.sleep((1 - self.tokens) / self.rate)
limiter = RateLimiter(rate=0.5, capacity=2) # 平均每 2 秒一次请求
def fetch(url: str, session: requests.Session, retries: int = 3):
for attempt in range(retries):
limiter.acquire()
time.sleep(random.gauss(1.2, 0.4)) # 随机化间隔，抹平机械节奏
resp = session.get(url, headers=build_headers(), timeout=12)
if resp.status_code == 200 and resp.text.strip():
return resp.text
if resp.status_code == 429:
wait = int(resp.headers.get("Retry-After", 60))
time.sleep(wait)
continue
if resp.status_code in (403, 503):
time.sleep(min(2 ** attempt, 30) * random.uniform(0.8, 1.5))
continue
break
return Nonerandom.gauss 生成的间隔比固定 sleep(2) 更接近人的浏览节奏。并发方面，单个目标站控制在个位数并发即可，采集侧的瓶颈通常在解析而非网络。
四、出口 IP 轮换的取舍
跨出口分散请求能解决按 IP 计数的限流，但它对指纹识别、TLS 特征、脚本质询没有作用。换了新出口仍被拦，说明问题不在 IP 上。
选型上，机房出口便宜、速度快，网段归属容易被识别；家宽出口更接近普通访客，成本更高。务实做法是混用：低风险的列表页走机房出口，防御严格的页面留给家宽出口。轮换还有一条硬规则——涉及会话延续的流程（登录后路径、多步表单）必须把出口固定住，中途换 IP 会直接让会话失效。同时要监控出口健康度，持续返回错误的地址及时剔除。
五、渲染兜底与降级链路
内容由前端脚本加载时，普通 HTTP 请求拿到的只是骨架页。这时有两条路：一是打开开发者工具找到页面真正调用的数据接口，直接请求接口拿结构化 JSON，开销远低于渲染；二是用 Playwright 一类工具真实渲染，等元素出现后取 DOM。
采集失败时的处理顺序建议固定下来：
- 判定失败类型——空内容、状态码异常、还是解析异常；
- 空内容且状态码 200，先校验解析规则是否随页面改版失效；
- 命中 429 或 403，按 Retry-After 或指数退避休眠，缩减该数据源并发；
- 连续失败达阈值，把该数据源标记为降级，切换到官方接口或订阅源；
- 降级仍失败则暂停该源本轮任务，写入失败记录并触发一条聚合通知，避免逐条告警。
监控类系统尤其要区分「采集失败」和「确实没有新热点」。两者都表现为无数据，混在一起会让判断彻底失真，所以每轮采集都要落一条带状态码与耗时的执行记录。
六、合规边界不能省
技术上能做，不代表应该做。采集公开信息要守住几条线：读取并尊重目标站的 robots 协议与限速声明；只采集公开可见内容，不触碰需要授权才能访问的数据；不尝试破解人机验证与登录保护；控制请求速率，避免给目标站带来额外负载；采集到的数据在存储与使用环节遵守《网络安全法》《数据安全法》《个人信息保护法》的要求，涉及个人信息的字段不留存。把限速当成协作规则而非障碍，多数封禁问题会自然消失。
常见问题（FAQ）
Q1：换了代理还是 403 怎么办？
说明拦截点不在 IP。核对请求头完整性与会话 Cookie，再降低请求频率。
Q2：随机间隔设多大合适？
单目标站均值 1 至 3 秒、带正态波动即可，遵守站点返回的限速信号。
Q3：一定要用无头浏览器吗？
不必。先找页面调用的数据接口，拿不到再渲染，渲染开销高出一个量级。
