做了多年工业数据采集与反爬对抗,见过最多的新手操作就是:抓接口先F12复制浏览器全套请求头,User-Agent、Cookie一股脑全贴上,能跑就跑,跑不通就乱换值。问他每个字段什么作用、反爬系统在校验什么,全说不上来。遇到封控、Cookie失效、会话过期,完全找不到根因,只会反复复制新的Cookie继续试。
其实反爬对抗的第一层,永远是User-Agent、Cookie、Session这三个基础要素。绝大多数入门级反爬,本质上就是围绕这三者做身份和行为校验;绝大多数新手踩的坑,也都是没搞懂三者的原理和边界。看似简单的三个字段,实则贯穿了身份识别、会话维持、行为校验整个反爬体系,是所有进阶对抗的根基。
一、先理清定位:身份、凭证、状态
在深入原理之前,先把三者的核心定位讲清楚,避免混淆:
- User-Agent:客户端的身份名片,告诉服务端你用的什么浏览器、什么系统、什么内核,是最表层的身份标识。
- Cookie:服务端下发的本地凭证,存在客户端,每次请求自动携带,是身份和状态的数据载体。
- Session:服务端维护的会话状态,存在服务器上,客户端通过Cookie里的SessionID关联对应状态。
简单说:UA标识你的设备环境,Cookie携带你的随身凭证,Session存储服务端的你的行为记录。三者配合,完成“身份识别→权限校验→行为校验”的完整反爬闭环。
二、User-Agent:最基础的身份标识
UA是所有HTTP请求的标准字段,也是反爬系统的第一道防线。
2.1 本质与作用
User-Agent本质是客户端的环境描述字符串,包含操作系统版本、浏览器品牌与版本、渲染内核、设备类型等信息。正常浏览器的UA有固定的格式和特征,而爬虫工具的默认UA特征极其明显。
反爬系统对UA的校验,核心逻辑就是:识别非正常客户端的UA特征,直接拦截。
2.2 常见的UA反爬校验层级
基础存在性校验
最简单的反爬策略:校验请求有没有UA字段。大量爬虫新手写脚本忘记加UA,直接被第一层拦截,还找不到原因。特征库匹配
反爬系统维护有常见爬虫库的UA特征库,比如python-requests、Scrapy这类默认UA,命中直接拦截。这也是为什么用默认配置的采集脚本,很多站点直接返回403。一致性校验
高阶一点的校验,会把UA和其他请求头、行为特征做交叉比对。比如UA标识是Chrome浏览器,但Accept、Accept-Language等字段却是Firefox的特征;或者UA是桌面端,但请求的是移动端接口,都会被标记异常。设备指纹关联
UA会和屏幕分辨率、时区、插件列表等其他环境字段组合,生成设备指纹。同一个UA搭配不同的环境特征,会被识别为多设备风险,触发风控。
2.3 实战技巧
- 永远不要使用爬虫库的默认UA,这是最低级的特征,必被拦截。
- 优先使用真实浏览器的UA,按系统、浏览器版本维护UA池,批量请求随机切换。
- 不要随意伪造UA组合,比如Windows系统配Safari浏览器、安卓系统配IE,特征矛盾反而更容易被识别。
- 同一个会话内保持UA固定,不要频繁切换,不符合真实用户行为。
三、Cookie:客户端的身份凭证
Cookie是反爬对抗的核心载体,绝大多数登录态、鉴权、风控标记,都通过Cookie传递。
3.1 工作原理
Cookie的核心机制是服务端写入,客户端自动带回:
- 客户端访问服务器,服务器通过响应头
Set-Cookie字段,下发Cookie数据 - 浏览器将Cookie按域名存储在本地
- 后续每次请求同域名的接口,浏览器自动在请求头带上对应的Cookie
整个过程对用户透明,不需要手动处理,这也是正常浏览器的标准行为。
3.2 反爬中的核心作用
登录态维持
用户登录后,服务端会生成会话标识存入Cookie,后续请求通过Cookie识别登录用户。这是需要登录的采集场景的核心凭证,没有有效的登录Cookie,就无法访问权限接口。访问计数与频率标记
很多反爬系统会在Cookie中埋入访问次数、首次访问时间、请求间隔等字段。同一个Cookie请求频率过高、数量超阈值,直接触发限流或拦截。签名与防篡改校验
关键接口的Cookie中会携带签名参数,和请求参数、时间戳绑定。篡改Cookie值、或者直接复制Cookie调用其他接口,签名校验不通过直接拒绝。风险标记
检测到异常行为(比如高频请求、参数篡改),系统会在Cookie中打上风险标记。打上标记的Cookie,后续所有请求都会被严格校验,甚至直接返回错误数据。
3.3 常见对抗点
- 时效性:Cookie都有过期时间,会话Cookie关闭浏览器就失效,持久Cookie到时间自动失效。过期的Cookie必须重新获取,不能一直复用。
- IP绑定:部分系统会将Cookie和登录IP绑定,切换IP后Cookie直接失效,需要重新建立会话。
- 设备绑定:Cookie和浏览器设备指纹绑定,换环境、换浏览器,Cookie都会失效。
- 动态刷新:每次访问页面都会刷新Cookie值,旧Cookie立即失效,不能复用之前的单个Cookie值。
3.4 实战技巧
- 采集流程遵循正常访问顺序:先访问首页获取基础Cookie,再访问列表页、详情页,不要直接上来就调用数据接口。
- 保持会话内Cookie的连贯性,不要东拼西凑不同页面的Cookie值,容易出现签名不一致。
- 遇到动态Cookie机制,完整模拟页面跳转流程,跟着服务端的Set-Cookie更新,不要硬抠单个Cookie字段。
- 批量采集做好会话隔离,每个账号、每个IP对应独立的Cookie池,避免交叉污染。
四、Session:服务端的会话状态
很多人会把Cookie和Session混为一谈,其实两者完全不是一个层面的东西:Cookie是存在客户端的载体,Session是存在服务端的状态。
4.1 本质与关系
Session是服务端为每个访问者维护的独立会话空间,存储用户的登录状态、访问路径、操作记录、权限信息等。每个Session有唯一的SessionID,这个ID通过Cookie下发给客户端,客户端后续请求带上SessionID,服务端就能找到对应的会话数据。
简单说:Cookie是箱子,Session是箱子里装的东西。你能看到Cookie,但Session的内容你看不到,都存在服务端。
4.2 反爬中的核心作用
Session是反爬行为校验的核心,绝大多数流程类反爬,本质上都是Session层面的校验。
访问流程校验
服务端在Session中记录用户的访问路径。正常用户是首页→列表页→详情页,爬虫直接跳过前面步骤,直接请求详情接口,Session里没有前置访问记录,直接拦截。这就是常说的“必须先过页面才能调接口”。请求频率控制
基于Session统计单位时间内的请求次数、请求间隔,超过阈值就限流或封禁。很多时候你换了IP还是被限,就是因为Session已经被标记了。步骤完整性校验
多步操作的场景(比如查询→验证→获取结果),每一步的状态都存在Session里。跳过中间步骤,直接请求最后一步,Session里没有中间状态,直接失败。CSRF令牌校验
服务端生成CSRF令牌存在Session中,每次请求需要带上对应的令牌。没有令牌、令牌不匹配,都会被拒绝。这也是非常常见的接口反爬手段。
4.3 实战技巧
- 模拟真实用户的访问路径,按页面流程逐步访问,不要直接深链调用接口。
- 控制单个Session的请求频率,符合人类操作节奏,不要秒级连续高频请求。
- 遇到步骤校验,完整走完全部流程,不要试图跳过中间环节。
- 被限流封禁时,有时候换一个全新的Session(清空Cookie重新访问),比换IP效果更好。
五、三者协同:反爬校验的完整闭环
实际的反爬系统,从来不是单独校验某一个字段,而是三者交叉验证,形成完整的身份行为校验闭环。
完整的校验逻辑:
- 通过UA初步判断客户端类型,拦截明显的爬虫特征
- 通过Cookie携带的SessionID,找到服务端对应的会话
- 校验Session里的访问路径、操作记录、频率是否正常
- 校验Cookie、UA、IP、设备指纹是否和会话绑定一致
- 全部符合,放行;任意一项异常,触发风控或拦截
很多新手疑惑:为什么我Cookie也复制了、UA也换了,还是被拦截?核心原因就是只复制了字段,没对齐三者的关联关系,Session里的行为状态不对,或者字段之间特征矛盾。
六、新手高频踩坑总结
- 用默认UA跑脚本:还没开始真正对抗,就被第一层UA特征拦截,浪费大量时间排查。
- Cookie复制就万事大吉:只复制Cookie值,不理解Cookie的时效性、绑定关系,跑着跑着就失效,找不到原因。
- 跳过流程直接调接口:忽略Session的流程校验,直接请求目标接口,返回403还以为是Cookie不对。
- Cookie和IP混用:同一个Cookie在多个IP上使用,触发绑定校验,直接被标记风控。
- 混淆Cookie和Session:以为改了Cookie值就能改状态,其实核心数据都存在服务端Session,改Cookie没用。
- 单UA高频请求:同一个UA大量连续请求,特征极其明显,很容易被识别封禁。
最后
反爬对抗从来不是靠堆砌请求头字段,而是理解每一层的校验逻辑,知道对方在查什么,才能针对性应对。
User-Agent、Cookie、Session是反爬的第一道门槛,也是所有进阶对抗的基础。签名、验证码、设备指纹、人机验证这些高阶反爬,本质上也都是建立在这三者的基础之上。把基础原理吃透,再去看复杂的对抗手段,才能抽丝剥茧,找到核心突破口