第15课：网页爬虫｜反爬策略全解析【看懂网站如何“认出”你，为对抗打下地基】

学习目标

学完这一课，你将能够：

1. 理解反爬的核心理念——知道网站为什么要反爬、反爬的基本思路是什么
2. 识别六大常见反爬策略——UA校验、Referer校验、Cookie校验、频率限制、访问频次封禁、设备与指纹检测
3. 掌握每种策略的原理——清楚触发器在哪个环节、识别逻辑是什么
4. 能判断自己触发了哪种反爬——看到403、封IP、验证码时，能定位是哪个环节出了问题
5. 建立对抗思维框架——为第16、17课具体反爬绕过技术打好理论基础

这一课不写任何绕过代码，只是做原理拆解和认知搭建。正所谓“知己知彼，百战不殆”，只有搞明白了网站怎么识别爬虫，你才能有的放矢地设计对抗策略。

一、通俗原理：反爬就是“门卫的十八般武艺”

1.1 网站也是“有脾气的”

想象一下：你开了一家奶茶店（网站），每天正常接待几百个顾客（真人用户）。突然有一天，门口来了一个机器人，它每隔0.1秒就伸进窗口要一杯奶茶，而且不要糖、不要奶，只是机械地重复“要一杯奶茶”。机器人不是来消费的，它就是来采集你的菜单价格和配方（爬数据）。

你会怎么做？你肯定不想让这个机器人影响正常顾客。于是你可能会：

• 看对方的“制服”（User-Agent），不是普通顾客的打扮就拦住
• 检查他是不是从隔壁店（Referer）过来的，来路不明的不搭理
• 让他每次出示“会员卡”（Cookie），没卡的不给进
• 如果一个人来得太频繁，就让他走远点站一会儿（频率限制）
• 记住他的长相（IP地址、设备指纹），下次见了直接轰走

反爬策略就是网站的这套“门卫系统”。它不是为了为难好人，而是为了维护网站稳定、保护数据资产、遵守法律法规（比如防止竞争对手低价抓取商品信息）。

1.2 反爬的“三层漏斗”模型

大多数网站的反爬采用分层过滤，像漏斗一样层层筛选：

• 第一层：请求级别—— 检查请求头中的User-Agent、Referer、Cookie、Accept等是否“像个正常人”。这个最容易触发，也最容易绕过（改个头就行了）。
• 第二层：访问行为级别—— 检查访问频率、访问间隔、请求顺序等是否符合人类行为特征。这一层能拦住绝大多数初级爬虫。
• 第三层：身份级别—— 通过IP、设备指纹、账号行为等长期跟踪。一旦你上了黑名单，换个IP、换台电脑可能都不管用（因为指纹能关联）。

下面我们逐层拆解。

1.3 反爬的“光谱”

按照严格程度，反爬策略可以分成三个梯度：

我们从最基础的开始讲起。

二、User-Agent校验：最基础的门卫

2.1 原理

User-Agent是HTTP请求头中的一个字段，告诉服务器“我是谁”——什么操作系统、什么浏览器、什么版本。

网站服务器接收到请求后，会检查User-Agent。如果它发现这个值不符合正常浏览器的格式（比如是python-requests/2.31.0、curl/7.68.0），或者是一个很老版本、很少见的浏览器，就可以判定为自动化程序，直接返回403拒绝访问。

真实案例：百度搜索的UA检测很严格，你用requests.get(‘https://www.baidu.com’)默认UA会被拦住，但换成Chrome的UA就放行。

2.2 触发条件

• User-Agent缺失（有些库不自动添加）
• User-Agent是明显的爬虫标识（python-requests、Go-http-client、Java/）
• User-Agent是搜索引擎爬虫（如Googlebot），但你的IP又不是Google的IP（这种伪装很容易被识破）

2.3 识别方式

作为爬虫开发者，当你收到403状态码，或者页面内容提示“请使用Chrome浏览器访问”，基本可以判断是UA问题。

查看响应头中的X-Frame-Options、X-XSS-Protection等不一定，最直接的是：换一个主流浏览器UA试试，如果问题消失，那就确诊了。

2.4 真实案例：豆瓣的UA检测

豆瓣的公开页面（如电影Top250）对UA非常敏感。用默认UA请求：

importrequests response=requests.get(‘https://movie.douban.com/top250’)print(response.status_code)# 418 或 403

换一个Chrome UA：

headers={‘User-Agent’:‘Mozilla/5.0(Windows NT10.0;Win64;x64)…’}response=requests.get(‘https://movie.douban.com/top250’,headers=headers)print(response.status_code)# 200

这就是最简单的反爬。

2.5 绕过思路（预告）

• 随机轮换User-Agent池，每次请求换一个主流浏览器UA
• 模拟真实浏览器的完整UA字符串（不要简写）
• 注意UA要和操作系统、语言环境匹配（比如Windows上跑Mac UA也显得假）

三、Referer校验：你的来路是否清白

3.1 原理

Referer（引荐来源）告诉服务器：你是从哪个页面跳转过来的。比如你在百度搜“爬虫”，点了一个链接，那个请求的Referer就是百度的搜索结果页地址。

网站可以检查Referer：只有从它信任的域名或自身域名来的请求，才允许访问。如果Referer缺失或来源不对，就拒绝。

为什么要校验Referer？

• 防盗链：防止其他网站直接引用你的图片、视频资源（对方直接把<img src=你的图片地址>放在自己网站上，消耗你的带宽）
• 防CSRF攻击：防止恶意网站诱导用户发请求
• 确保访问路径正常：例如购物网站的商品详情页，只允许从列表页或搜索结果页进入，不允许直接访问

3.2 触发条件

• Referer为空（直接从书签、命令行工具、代码发起的请求）
• Referer是第三方网站（不是本站域名）
• Referer的路径不符合业务逻辑（比如提交订单的请求Referer却是首页）

3.3 识别方式

当你发现：

• 图片、视频等资源返回403，但直接在浏览器地址栏访问又能打开
• 某个数据接口返回“非法请求”或“请从正规渠道访问”

那很可能是Referer校验。

真实案例：很多网站的图片CDN会做Referer白名单。比如微博的图片，如果你在自己的网站用<img src=微博图片链接>，图片可能无法显示。因为微博服务器检查Referer，如果不是来自weibo.com或*.sinaimg.cn，就拒绝。

3.4 绕过思路（预告）

• 在请求头中伪造Referer，设置为网站自身的域名或允许的域名
• 注意：某些网站会严格校验Referer的格式，比如必须完整带协议和路径，不能只给个域名

四、Cookie校验：你有入场券吗？

4.1 原理

Cookie是服务器存放在客户端的一小段文本，用于维持会话、记录状态。网站可以通过Cookie来判断：

• 你是否曾经访问过（新用户 vs 老用户）
• 你是否正常通过了某些前置步骤（比如先访问了首页，获取了session_id，然后才能访问详情页）
• 你是否有合法的登录凭证（登录态）

反爬场景中，网站可能要求每个请求都必须携带特定的Cookie，这些Cookie是通过执行JavaScript生成的，或者在前一个请求的响应中通过Set-Cookie下发的。

爬虫的常见问题：

• 直接请求目标URL，没有携带任何Cookie → 被拒绝
• Cookie过期（比如设置了很短的失效时间） → 被要求重新获取

4.2 触发条件

• 请求中完全没有Cookie
• Cookie缺失某个必须的键值（如token、sessionid）
• Cookie的值不正确（比如签名错误、时间戳过期）

4.3 真实案例：知乎的Cookie校验

知乎的某些API接口，需要先访问首页获得一个名为z_c0的Cookie（登录态），然后才能请求数据。如果你直接请求API且不带这个Cookie，会返回401 Unauthorized。

更高级的：有些网站会在Cookie中加密存储用户的行为轨迹，如果爬虫只是简单复制一个Cookie而不模拟真实行为轨迹，也会被识别。

4.4 绕过思路（预告）

• 使用requests.Session()自动管理Cookie
• 先访问首页或其他前置页面，让服务器下发必要的Cookie
• 分析Cookie的生成逻辑（可能涉及JS加密），用代码模拟生成

五、频率限制与访问频次封禁

5.1 原理

真人用户访问网站，不可能做到“每0.5秒精准访问一次，连续访问1000次”。爬虫通常因为追求效率而忽略这一点。

频率限制（Rate Limiting）是反爬最常用、最有效的手段之一。服务器会记录每个IP（或每个用户）在单位时间内的请求次数，超过阈值就：

• 暂时封IP（几秒到几小时不等）
• 返回429 Too Many Requests状态码
• 弹出验证码（验证你是不是真人）

5.2 触发条件

• 请求间隔过于规律（比如固定1秒一次）
• 单位时间内请求次数超过阈值（例如1分钟超过60次）
• 并发连接数过多

阈值因网站而异。有的网站宽松（每秒10次），有的严格（每秒2次）。

5.3 识别方式

• 状态码返回429（Too Many Requests）
• 页面提示“访问过于频繁，请稍后再试”
• 突然出现验证码（尤其Google reCAPTCHA）
• IP被临时封禁，换个IP或等一段时间恢复

真实案例：豆瓣的公开接口限制比较严格，单个IP在短时间内请求超过一定次数，就会返回418（I’m a teapot，别笑，这是真的），或者直接封IP几小时。

5.4 绕过思路（预告）

• 降低请求频率，增加随机延迟（例如1-3秒随机间隔）
• 使用代理IP池，分散请求压力
• 避免固定频率：每次请求前time.sleep(random.uniform(0.5, 2))
• 对于需要高频率的场景，采用分布式爬虫

六、访问模式与行为分析

6.1 原理

频率限制只能防住“量”，但防不住“质”。更高级的反爬系统会分析你的访问模式（pattern），即使你频率很低，但行为明显不像人，也可能被封。

什么是不像人的行为？

• 访问路径单调：真人用户访问网站是随机的，可能会点击链接、后退、刷新。而爬虫往往按照固定的顺序遍历页面（比如从第1页→第2页→第3页…）。
• 不加载资源：真人浏览器会同时请求HTML、CSS、JS、图片、字体等。爬虫通常只请求HTML或JSON，不请求静态资源。
• 没有鼠标移动、滚动等交互：有些网站会记录鼠标轨迹、滚动事件，缺少这些特征就是机器人。
• 请求间隔完全相等：人类有思维停顿，两次点击间隔不可能是精确的1.000秒。
• 访问时间异常：在凌晨3点到5点人类活动低谷期，爬虫却在疯狂爬取。

6.2 触发条件

• 请求顺序和页面结构与真实用户偏差太大
• 只请求数据接口，不请求页面（真用户会先加载HTML页面，然后才触发接口）
• 缺少Referer链（比如直接访问深度页面，而不是从首页一步步点进去）

6.3 识别方式

服务器会通过日志分析、机器学习模型来识别行为异常。作为爬虫开发者，你可能不会直接看到“你的行为异常”的提示，而是发现：

• 数据开始出现乱序、被篡改（蜜罐数据）
• 请求偶尔返回假数据
• 你的IP虽然没有被封，但拿到的内容质量下降

6.4 绕过思路（预告）

• 模拟完整访问路径：先请求首页，再请求列表页，最后请求详情页
• 随机加载一些CSS、JS、图片（但会降低效率）
• 设置随机等待间隔（指数分布更接近人类行为）
• 使用浏览器自动化（Selenium、Playwright）来模拟真实浏览器的资源加载

七、IP封禁与代理检测

7.1 原理

IP是最基础的标识。一旦某个IP被判定为爬虫，最简单的办法就是封掉它——通过防火墙或应用层拒绝来自该IP的所有请求。

• 临时封禁：几分钟到几小时，作为警告
• 永久封禁：加入黑名单，几乎不再解封

更高级的网站还会检测代理IP的特征：

• 代理IP的归属地是数据中心（阿里云、AWS、DigitalOcean等机房IP），而不是普通家庭宽带
• 代理IP的端口特征明显（如8080、3128）
• 代理IP的请求头中包含X-Forwarded-For等字段

7.2 触发条件

• 单个IP请求频率超过阈值（见第五点）
• 使用了公开免费代理（这些IP早就进了黑名单）
• IP段被标记为机房IP（很多网站会允许家庭宽带IP，但禁止云服务器IP）

7.3 识别方式

• 状态码403 Forbidden，或者连接直接被拒绝（Connection refused）
• 更换IP后恢复正常
• 访问一些IP检测网站（如ip.cn），发现自己的IP是机房IP

7.4 绕过思路（预告）

• 使用高质量住宅代理IP（成本较高）
• 轮换IP池，每个IP发送少量请求后更换
• 使用ADSL拨号服务器（每次拨号换IP）
• 不要使用免费代理

八、设备指纹与浏览器指纹

8.1 原理

IP可以被换，User-Agent可以改，Cookie可以清。但是每个浏览器、每个设备有一系列特征组合起来，几乎是唯一的。这就是设备指纹。

网站通过JavaScript收集以下信息：

• 浏览器特征：User-Agent、平台、语言、插件列表、字体列表、时区、屏幕分辨率、色深
• 硬件特征：CPU核心数、内存大小、显卡信息（通过WebGL渲染指纹）
• 网络特征：IP、DNS
• Canvas指纹：用Canvas绘制一个图形，不同设备、不同操作系统、不同显卡驱动渲染出来的图像有细微差异，可以被哈希成唯一指纹
• WebGL指纹：类似Canvas，利用3D渲染差异
• AudioContext指纹：音频处理器的细微差异

把这些特征组合起来，计算出一个哈希值，就是设备指纹。即使你清除了Cookie、换了IP，只要指纹不变，网站仍能认出你。

真实案例：很多广告联盟通过设备指纹追踪用户跨网站行为。对于爬虫，你哪怕用无头浏览器，指纹也和普通Chrome有差异，可以被检测到。

8.2 触发条件

• 使用无头浏览器（如Headless Chrome）时，某些指纹特征会暴露
• 使用Selenium、Playwright默认配置时，会有一些自动化特征（如navigator.webdriver为true）
• 使用自定义HTTP库（如requests）时，完全没有浏览器指纹特征（因为不是真正的浏览器）

8.3 识别方式

当你的爬虫明明用了浏览器（如Selenium），但网站依然能阻挡你，或者要求你滑动验证码，很可能是指纹被识别了。

你可以通过访问一些指纹测试网站（如https://bot.sannysoft.com/、https://amiunique.org/fp）查看自己的指纹特征和正常浏览器的差异。

8.4 绕过思路（预告）

• 使用专门的指纹伪装库（如puppeteer-extra-plugin-stealth）
• 修改浏览器指纹特征（通过注入JS，覆盖navigator.webdriver、plugins等属性）
• 使用真实用户浏览器（通过远程控制真实设备，方案复杂）

九、验证码挑战

9.1 原理

当其他反爬手段都无法100%确定你是爬虫时，网站会祭出最终武器——验证码。验证码的核心设计目标是“人机鉴别”——计算机程序无法（或很难）自动完成的任务。

常见类型：

9.2 触发条件

• 请求频率过高（触发隐形阈值）
• 设备指纹可疑
• 访问了敏感页面（如登录、注册、下单）
• 单个IP请求量突然暴增

9.3 识别方式

• 返回的页面中包含验证码输入框、图片
• API接口返回“需要验证”的标识
• 请求被重定向到验证码页面

9.4 绕过思路（预告）

• 降低频率，避免触发
• 使用机器学习识别图形验证码（OCR）
• 使用打码平台（人工或AI破解）
• 对于滑动验证码，分析轨迹模拟（需要深度学习）
• 使用Cookie池（绕过验证码后的Cookie复用）

十、JavaScript挑战与前端加密

10.1 原理

很多网站会返回一段加密的HTML或JS，要求浏览器执行后才能获得真实内容。爬虫如果不执行JS，就无法拿到数据。

常见形式：

• Cloudflare的“5秒盾”：返回一个等待页面，浏览器执行JS计算挑战，几秒后自动跳转到真实页面。
• 前端加密：数据接口返回的JSON是加密的，需要前端JS解密后再渲染。
• 动态Token：每次请求需要携带一个由JS计算生成的Token（例如时间戳+加密签名）。

10.2 触发条件

• 直接使用requests请求，返回的内容是一个小HTML，里面只有<script>标签
• 响应内容中包含cf-browser-verification、__cf_chl等Cloudflare特征
• 请求参数中需要sign、token、_sig等看起来不固定的字段

10.3 识别方式

• 浏览器访问正常，但爬虫获取的HTML大量包含JS或不可读
• 状态码503 Service Unavailable（Cloudflare常见）
• 浏览器开发者工具中看到发起了一个“挑战”请求

10.4 绕过思路（预告）

• 使用浏览器自动化（Selenium、Playwright），让浏览器执行JS
• 逆向JS，用Python重写加密逻辑（高级）
• 使用Cloudflare绕过服务（如scrapy-cloudflare-middleware）

十一、真实场景案例综合演练

案例1：某新闻网站的UA+Referer双检

小王写爬虫爬取某新闻网站的文章列表。他发现用浏览器访问完全正常，但用Python的requests直接请求却返回403。

他尝试加入User-Agent伪装成Chrome，状态码变成200但内容是空的。进一步分析发现，还需要添加Referer为网站自己的域名。他照做后，成功拿到HTML。

这是一个典型的初级反爬：UA + Referer。

案例2：豆瓣的418“茶壶”与频率限制

小李爬取豆瓣电影Top250，一开始能成功，但连续跑了10页后，突然返回418（I’m a teapot）。他查阅资料得知这是豆瓣的反爬，意思是“你太快了，去喝杯茶吧”。

解决方案：每请求一页后time.sleep(random.uniform(2, 5))，问题解决。

案例3：知乎的动态请求签名

小张想爬取知乎某个问题下的所有回答。他发现直接请求API接口需要一个x-zse-96签名，这个签名是由JS动态计算的。他不懂逆向，于是改用Selenium模拟浏览器滚动加载，虽然慢一点，但能稳定拿到数据。

案例4：某电商网站的设备指纹

小陈用Playwright爬取某电商网站的商品价格，他设置了headless=True（无头模式），还改了User-Agent。但每次访问10个商品后，网站就会弹出验证码。

他测试用普通Chrome浏览器（有头模式）爬取，验证码频率大大降低。原因：无头浏览器被设备指纹检测了。他改用有头模式，并添加了stealth插件伪装，基本能稳定运行。

案例5：Cloudflare的5秒盾

小刘想爬取某个使用Cloudflare的小众网站。用requests请求时，返回的HTML内容是“Checking your browser before accessing…”，里面全是JS。他改用Selenium，并设置等待5秒，成功绕过。

十二、新手常见误区

误区1：“只要加了延时，网站就不会封我”

延时可以减少频率被封的风险，但解决不了设备指纹、行为模式、前端加密等问题。

误区2：“换了IP就万事大吉”

如果网站使用了设备指纹，你换IP没用，因为它认的是浏览器特征。另外，如果IP质量不好（机房IP），照样被封。

误区3：“把UA改成百度蜘蛛就能横行无阻”

很多网站会验证UA和IP是否匹配。你的IP是家庭宽带，UA却是Baiduspider，服务器一查反向DNS发现不是百度机房，直接封。

误区4：“Selenium不会被反爬”

Selenium默认特征很明显（navigator.webdriver=true），很多网站直接拦截。需要配合隐身插件使用。

误区5：“免费代理池可以解决IP问题”

免费代理池的IP绝大多数已经被网站拉黑，且质量极差（速度慢、失效快）。真正的生产环境需要购买高质量住宅代理。

误区6：“反爬是一场单向战争，攻方永远被动”

实际上是猫鼠游戏。反爬太严会影响正常用户体验，所以网站必须在安全和用户体验之间平衡。爬虫开发者可以利用这种平衡。

十三、总结

反爬策略全景图

爬虫与反爬的博弈本质

• 成本博弈：网站希望让爬虫的成本高于收益，而不是完全禁止。
• 误伤博弈：反爬太严格会误伤真实用户，网站必须容忍一定程度的爬虫。
• 技术迭代：没有一招鲜的爬虫，也没有万无一失的反爬。

为下一课铺垫

你现在已经了解了网站反爬的招式。接下来两课，我们会学习：

• 第16课：高级反爬对抗技术——代理IP池、指纹伪装、验证码处理
• 第17课：JS逆向与接口破解——从浏览器中抢回数据

十四、课后作业

作业1：观察网站的反爬行为（必做）

选择一个你常访问的网站（如知乎、豆瓣、微博），用以下方式分别访问，记录现象：

1. 用浏览器正常访问，查看Network中的请求头（UA、Referer、Cookie等）
2. 用requests不加任何头请求同样的URL，记录状态码和返回内容
3. 用requests加Chrome UA请求，对比结果
4. 快速连续请求20次（间隔0.1秒），观察是否触发429或验证码

提交一份简单的实验报告，指出这个网站用了哪些反爬策略。

作业2：分析豆瓣418状态码（必做）

1. 用requests默认设置请求https://movie.douban.com/top250，记录状态码和响应头
2. 设置时间间隔循环请求该URL，看多久触发418
3. 搜索资料了解豆瓣418的含义和触发机制

作业3：检测自己的设备指纹（选做）

访问https://fingerprintjs.com/demo/，查看自己的浏览器指纹。然后尝试：

• 开启浏览器的隐私模式，刷新页面，指纹是否变化？
• 切换不同的浏览器（Chrome vs Firefox），指纹差异大吗？
• 安装一个随机化指纹的扩展插件（如Chrome的“Canvas Blocker”），重新检测指纹有何变化？

作业4：阅读Cloudflare的“5秒盾”原理（选做）

搜索资料，了解Cloudflare的“I’m Under Attack”模式和“5秒盾”的技术原理。写出你的理解（至少200字），并思考如何绕过。

作业5：思考题（必做）

假如你要设计一个反爬系统保护自己网站的新闻内容。你会使用哪些策略？如何平衡用户体验和反爬效果？请列出你的设计思路（至少3条策略）。

提示：可以参考本课讲到的多层漏斗模型。

结束语：

反爬是一面镜子，照出的是你对网络协议、浏览器原理、网站架构的理解深度。不要畏惧它，把它当成一个有趣的解谜游戏。

今天你只是看清了对手的招式。下一课，我们将学习如何见招拆招——从代理IP池到指纹伪装，从验证码处理到JS逆向。你已经走在成为一名真正爬虫工程师的路上。

第16课见。

🔗《20节课精通网页爬虫》系列课程导航

GO

🌟 感谢您耐心阅读到这里！
💡 如果本文对您有所启发欢迎：
👍 点赞📌 收藏 📤 分享给更多需要的伙伴。
🗣️ 期待在评论区看到您的想法, 共同进步。
🔔 关注我，持续获取更多干货内容～
🤗 我们下篇文章见～