反爬机制全景图：从 UA 到风控

本文基于模型知识整理，建议核对官方文档（见 参考资料）。

一句话定义

反爬是站点按「身份 → 行为 → 频率 → 意图」分层的访问控制系统；读懂每一层在检测什么，才能在合规前提下做出正确的工程应对。

为什么重要

被拦截时的第一反应决定了效率：新手以为是「被反爬了」开始换 IP，高手先排查「是不是自己请求不像浏览器」。全景图帮你把拦截症状对号入座，避免用代理池去修一个缺 Referer 的 bug。

前置知识

kp-006、kp-012。

核心概念

反爬的五层阶梯（由浅入深）：

原理与机制

症状 → 归因 → 合规应对的映射：

403 + UA相关          → 补齐浏览器级请求头( kp-006 )
302 → /login          → 会话缺失, 走登录/storage_state( kp-013 )
429 / 临时黑名单      → 降低频率+退避, 评估Crawl-delay( kp-017 )
验证码偶发            → 降低频率常使挑战消失; 商用打码平台有合规风险( kp-034 )
环境一致性被识破      → 减少自动化痕迹; 明确合规边界( kp-035 )

防守视角的理解：反爬的本质是成本博弈——站点用递增的防御成本换取「劝退低价值流量」。你的应对也应递增：先修请求（成本最低），再调节奏，最后才考虑环境对抗；多数需求止步于前两层。

实例或案例

同一脚本上午正常、下午 403：逐层排查发现并非封 IP——Session 的 Cookie 过期后脚本仍带旧 Cookie 请求（第 2 层症状）。加上「响应含登录页特征则重新登录」的自动续期逻辑后恢复稳定。教训：先归因，再动手。

常见误区

• 误区一：一切拦截都归因于反爬。 大量「反爬」其实是自身 bug：缺头、Cookie 失效、参数顺序错、编码不一致。归因顺序应从自己查起。
• 误区二：第一反应上代理池。 代理不修复请求形态；高频换 IP 撞第 3 层只会加速封禁，且「绕过封禁」本身有合规风险。
• 误区三：对抗第 5 层。 设备指纹风控是平台核心安全资产，大规模对抗在国内已有刑事判例；识别到第 5 层信号应止损退出。

自测题

1. 五层反爬阶梯从浅到深依次是什么？

答：身份伪装校验 → 会话凭证 → 频率控制 → 人机验证 → 设备风控。

1. 收到 429 的正确动作？

答：立即停退避（尊重 Retry-After），降并发与频率；它属于第 3 层，换 IP 是错误应对。

1. 为什么「先归因再动手」？

答：多数拦截源于自身请求不完整；错误归因会导向昂贵且可能违规的对抗手段。

与其他知识点的关系

kp-017 是第 3 层的工程化解法；kp-020 的代理属高成本手段应最后启用；kp-034/035 对应第 4、5 层的边界讨论。

延伸阅读

MDN「HTTP 429 Too Many Requests」；本库 kp-017、kp-004。