Python爬虫反爬实战：请求头伪装、节奏控制与动态渲染

被反爬折磨过的人大概率都见过这样的页面明明浏览器里一切正常requests 一上去就给你一个 403或者状态码 200返回内容却是一堆看不懂的 JavaScript 拼接逻辑再或者采集脚本刚跑几十条滑块验证就弹了出来。这些情况我刚开始写 Python 爬虫的时候全部踩过每一种都让我怀疑自己是不是入错了行。后来被虐的次数多了慢慢沉淀出三个实测有效的处理思路请求头伪装、请求节奏控制、动态渲染兜底。这篇文章把这套方法完整拆开每一步都带上可直接参考的代码和踩坑记录。需要先说明的是这里讨论的所有内容都只面向公开的正常数据采集动手之前建议先看目标网站的 robots.txt同时把请求频率控制在合理范围内不要给目标服务器造成压力。1. 别急着上方案先判断反爬到底拦在哪里1.1 同样是反爬背后的拦截逻辑完全不一样反爬不是一套统一的系统而是由各种检测逻辑组合出来的结果。我习惯把常见的拦截方式分成三类。第一种是请求头检测目标服务器会检查 User-Agent、Referer、Accept-Language、Accept 等字段只要发现请求头里的内容跟真实浏览器的差距太大就直接拒绝。第二种是频率限制服务器统计某个 IP 在单位时间内的请求次数超过阈值就会触发 403、429 或者验证码。第三种是动态渲染页面关键数据并不是直接写在 HTML 源码里的而是通过 JavaScript 请求接口后动态拼装出来的这种场景下你用 requests 看到的 HTML 只是一个空壳。这三类反爬经常会叠加出现所以第一步不是急着写代码而是先判断当前遇到的是哪一类。判断错了后面所有优化都是白费。比如你用很长一段代码实现了随机延时结果问题出在请求头没有伪装那封禁依然会持续。反过来也是一样你花了很多时间去做渲染结果页面只是简单做了 UA 校验反而把采集速度拖慢了几十倍。这也是为什么我在项目里会先做一轮探测而不是直接套模板。判断反爬类型时还可以顺手记录一个细节返回内容里有没有明显的验证页面关键字。比如captcha、verify、slider这类单词出现频率越高说明目标站点的风控策略越重。不要试图去破解验证码只要识别到这些特征就先停下来降低频率或者考虑换一个入口。技术上能绕过去是一回事规则上能不能做是另一回事。1.2 用最小探测代码摸清目标底细我建议所有爬虫项目都先写一个最小探测脚本把目标 URL 的响应状态、响应头、响应体长度和内容片段全部打印出来。这样你才能根据实际反馈做判断而不是靠感觉。下面这段代码可以直接抄走import requests url https://example.com/list headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36 } resp requests.get(url, headersheaders, timeout10) print(状态码:, resp.status_code) print(Content-Type:, resp.headers.get(Content-Type)) print(响应体长度:, len(resp.text)) print(响应体前500字:, resp.text[:500])跑完这段代码后你可以按下面几个关键特征去归类。如果状态码直接是 403 或者 418大概率是请求头部检测没有通过。如果状态码是 200但响应体里没有任何跟目标数据相关的关键字而是出现大段script标签那就说明数据是动态渲染的。如果状态码先是正常跑了一会儿之后突然变成 429 或者 503那就是触发了频率限制又或者你的出口 IP 已经被临时封禁。出口 IP 这个概念需要单独说一下它指的是你当前访问目标服务器所用的公网地址。同一个公网地址在一段时间内发出太多请求很容易被服务商标记。换一个公网地址往往能解决一部分问题但这不是银弹后面第三部分会展开讲。现阶段你只需要先理解判断反爬的核心思路是“差异比对”用命令行请求一次再用浏览器打开同一个地址对比返回结果差异在哪里差异就是反爬的切入点。另外我强烈建议把浏览器开发者工具里看到的真实请求头完整保存下来。做法是打开 Network 面板刷新页面找到第一个文档请求右键复制为 cURL然后把它转成 Python 字典。这样做的好处是你能拿到浏览器真实的 Header 顺序和值而不是网上抄来的旧模板。反爬系统对 Header 的匹配程度通常很敏感真实请求作为对照标准比自己拍脑袋写得要准确得多。2. 第一个实用技巧把请求头伪装得像真人而不是代码2.1 基础请求头不是只改一个 User-Agent很多初学爬虫的朋友一提到反爬第一反应就是改 User-Agent。这个方向没错但只做这一件事远远不够。目标服务器除了看 User-Agent还会看请求头里有没有奇怪的字段缺失以及字段值的组合是否符合真实浏览器的行为。这里我列一个日常爬虫中比较常见的基础请求头配置你可以根据自己的场景调整。Header推荐值作用User-Agent当前主流浏览器的 UA标识客户端类型Accepttext/html,application/xhtmlxml,application/xml;q0.9,image/avif,image/webp,/;q0.8告诉服务器可接受的响应类型Accept-Languagezh-CN,zh;q0.9,en;q0.8声明语言偏好Accept-Encodinggzip, deflate, br表示支持压缩响应Referer目标页面来源地址模拟从浏览器页面跳转过来Connectionkeep-alive保持长连接Sec-Fetch-Destdocument 或 empty表示请求目标类型Sec-Fetch-Modenavigate 或 cors表示请求模式Sec-Fetch-Sitesame-origin 或 none表示请求来源关系Upgrade-Insecure-Requests1表示优先 HTTPS把这些字段都带上之后你的请求从“看起来像代码”变成了“看起来像浏览器”。但要注意这些字段不是万能的部分网站会校验收紧关系比如 Referer 必须匹配当前页面域名或者 Sec-Fetch-Site 值与实际跳转路径不一致就拒绝。所以第一次写请求时最好先打开浏览器开发者工具切到 Network 面板找到真实请求的 Headers 区域然后把自己 request 里的 headers 调整成和浏览器完全一致。这里我提醒一个容易忽略的细节不要每次都随机更换 User-Agent尤其是没有维护合理 UA 列表的时候。随机拼接出来的 UA 经常会因为没有版本对不上号而更可疑。更好的做法是准备五到十个真实浏览器的 UA 字符串然后在需要切换时轮换使用。这样既不会因为同一个 UA 太显眼也不会因为 UA 格式乱套触发额外检测。还有一个不少教程不会提的小点请求头的顺序。在 HTTP 协议层面头部顺序理论上不重要但不少网站会把请求头发送给后端的风险控制组件做模式匹配而风险控制组件可能直接按“浏览器常见顺序”来判断。你可以在前面保存的 cURL 命令里看到浏览器发送 Header 的真实顺序然后用一个OrderedDict或 Python 3.7 以上的字典结构来维持这个顺序。实测中这种细节有时候能帮你在某些严格网站上少踩很多坑。2.2 用 Session 保持 Cookie先访问首页再访问目标页很多反爬逻辑会校验 Cookie 的有效性尤其是你直接请求一个内页地址而服务器认为你没有经历从首页跳转过来这个流程Cookie 缺失就会拒绝。解决办法很简单用requests.Session()创建一个会话对象先请求一次首页拿到初始化 Cookie再带着同一个会话请求目标页。代码大概是下面这样。import requests session requests.Session() session.headers.update({ User-Agent: Mozilla/5.0 ..., Accept-Language: zh-CN,zh;q0.9, }) # 先访问首页让服务端种下基础 Cookie home_url https://example.com/ session.get(home_url, timeout10) # 再访问目标页面 target_url https://example.com/list resp session.get(target_url, timeout10) print(resp.text[:300])这种做法的本质是模拟真实用户从入口进入站点的浏览路径。有些网站还会根据浏览路径生成加密标识如果一上来就直捣黄龙缺少前置页面访问即便 Cookie 里多了几个字段也可能因为某个参数的时间戳对不上而被识破。用 Session 统一管理 Cookie可以避免很多不必要的头疼。需要留意的是Session 对象默认会帮你保存 Cookie但如果你在中间使用了session.cookies.clear()或者重新创建了 Session就必须重新走一遍首页访问流程。我在实际项目里会写一个init_session()函数专门负责创建 Session 并完成前置访问。这样后面不管重试多少次都能保证每次重试都带着完整的 Cookie 状态而不是拿一个残缺的会话去请求。2.3 进阶TLS 指纹和 HTTP/2 指纹请求头伪装做到一定程度你会发现有些网站依然能识别出你是脚本。这种时候往往不是 Headers 的问题而是底层连接指纹的问题。正常浏览器在建立 TLS 连接时会有一套特定的加密套件顺序和扩展列表requests 底下的 urllib3 库则有另一套顺序。这种差异被称为 TLS 指纹。服务器可以在不解析请求头的情况下仅凭连接握手阶段的指纹判断对方不是浏览器。遇到这种情况我平时的做法是引入curl_cffi这个库它能模拟 Chrome 等浏览器的 TLS 指纹并且支持 HTTP/2。安装命令是pip install curl_cffi一个简单的请求示例是from curl_cffi import requests as cffi_requests resp cffi_requests.get( https://example.com/list, impersonatechrome, timeout10 ) print(resp.status_code) print(resp.text[:300])impersonatechrome会直接模拟 Chrome 浏览器的连接特征很多普通 requests 搞不定的网站换成这个库之后就能正常返回。不过我不会一上来就建议你用它因为你得先确认基础 Headers 和 Cookie 都已经处理正确。如果前面没有做好直接换库也只是把问题往后推了一级。总之这个技巧属于第二梯队它解决的是更底层的问题在日常项目中可以作为备用招数。这里也要插一句curl_cffi的模拟能力并不是无限期的浏览器版本更新后旧的指纹模拟可能失效。所以使用这类库时要关注它的更新日志定期升级到支持新浏览器版本的版本。爬虫本身就是一场持久战工具也要跟着环境走。3. 第二个实用技巧控制请求节奏让服务器觉得你不是机器3.1 固定延时和随机延时的本质区别爬虫采集数据时最容易犯的一个错误就是把循环写得非常紧凑每一条请求之间只间隔 0.1 秒甚至更快。这样采集速度虽然好看但服务器端的数据模型非常容易识别出规律。固定延时虽然会好一点比如每次 sleep(1)但在模型看来这种间隔太规律了同样有特征。真实用户浏览页面的速度有快有慢不可能每次都精确卡在同一个时间点上。所以更合理的做法是让延时服从一个随机区间。比如每次请求后等待random.uniform(1.5, 4.5)秒。这样服务器看到的请求间隔会呈现出自然波动不容易被简单规则一下子判断出来。下面这段代码演示了在循环里抓取多页时的基础节奏控制。import time import random for page in range(1, 11): url fhttps://example.com/list?page{page} resp session.get(url, timeout10) print(f第{page}页状态码{resp.status_code}) time.sleep(random.uniform(1.5, 4.5))这里有一个很有意思的细节区间两端最好不要选整数。比如random.uniform(1, 3)虽然也是区间但看起来还是太规整。我一般会写成random.uniform(1.7, 4.3)这类带小数的上下限让随机出来的数更自然。另外随机函数每次运行之间的间隔会有一定概率出现连续两次很短或很长的情况这种波动其实是好事因为人类行为本身就充满了突发性。如果你的目标站点是内容型网站用户浏览一页很可能要花几秒甚至十几秒那么延时设置在 1 到 3 秒之间其实是偏快的长期跑一样会被识别。可以适当把区间放大到 3 到 8 秒。如果只是临时抓取几十条数据那就无所谓重点别一口气把几千个请求全砸出去。延迟不是越慢越好而是越真实越好。跑完一轮后把实际耗时记录下来能帮你判断当前节奏是否符合要求。3.2 带退避的重试机制反爬不是每次都直接给你返回 403 让你发现更多时候是偶尔成功、偶尔失败甚至会在返回内容里夹带一个怪异的验证页面。所以请求函数里必须包含重试和异常处理逻辑。重试不是简单的“失败就再来一次”而是要带上退避策略也就是第一次失败后等 2 秒再试第二次失败后等 4 到 6 秒第三次失败后等待更久。这样一方面给服务器留出恢复时间另一方面也避免失败后立刻疯狂重试导致被封得更狠。下面是我常用的一个带退避重试的请求函数。import requests import time import random def get_with_retry(session, url, max_retries3): for attempt in range(max_retries): try: resp session.get(url, timeout10) if resp.status_code in (403, 429): wait_time random.uniform(2, 5) * (attempt 1) print(f请求被限流状态码{resp.status_code}{wait_time:.1f}秒后重试) time.sleep(wait_time) continue return resp except requests.RequestException as exc: wait_time random.uniform(1, 3) * (attempt 1) print(f请求异常{exc}{wait_time:.1f}秒后重试) time.sleep(wait_time) return None注意这个函数里对 403 和 429 做了特殊处理。如果返回 200就直接返回响应对象如果返回其他状态码比如 404说明不是反爬问题没有重试必要直接返回即可。很多新人喜欢对所有异常都重试结果网站明明没有该页面还在那里反复请求效率非常低。正确做法是只对限流和具有临时性的连接异常做重试。退避间隔为什么要乘上(attempt 1)本质上是让等待时间随重试次数指数增长。第一次等 2 到 5 秒第二次等 4 到 10 秒第三次等 6 到 15 秒。这个设计借鉴了网络领域里的指数退避思想目的是在“不放弃请求”和“不给服务器加压”之间找一个平衡点。如果重试到第三次仍然失败我会认为当前出口 IP 可能已经被重点关照这时候再继续重试意义不大应该进入换 IP 流程。3.3 什么时候需要换出口 IP以及怎么换频率控制做到位之后依然有可能会碰到 IP 被临时封禁的情况。判断标准其实不难当你的请求一直返回 403 或 429而且换了不同的 User-Agent、清了缓存、等了很久都没恢复大概率就是出口 IP 被目标服务器限制了。这种情况下最直接的办法是换一个出口 IP。具体怎么操作常见做法是准备一组出口 IP 资源在请求失败时自动切换下一个。你可以在云服务商那儿购买按量计费的弹性公网 IP也可以使用拨号服务器在每次拨号后获得新地址还可以找专门提供住宅 IP 资源的服务商。不过这里必须提醒一句任何 IP 切换方案都要在法律和平台规则允许的范围内使用如果你抓取的是公开数据并且目标网站没有明确禁止控制好频率和量级通常问题不大。如果目标网站服务条款明确禁止采集那就不要抱有侥幸心理。代码层面你可以在get_with_retry外面再包一层逻辑当重试次数用尽时调用一个“切换 IP”的函数然后用新的出口地址重新请求。这个切换函数根据你的资源类型来实现比如调用云服务商的 API 更换公网地址或者重启拨号网络。把这个动作和重试逻辑分开代码会清晰很多也不会因为频繁切换而误伤正常请求。提示IP 资源池不是越多越好。你发出请求的出口 IP 如果频繁变化反而容易被更高层级的风险控制盯上。保持每个 IP 的请求量在合理范围比单纯拥有大量 IP 更重要。还要记住一个容易踩的坑切换出口 IP 之后原来 Session 里保存的 Cookie 不一定还能继续使用。因为 Cookie 里可能包含了 IP 维度的绑定信息如果 IP 变了而 Cookie 没变部分网站会直接判定为异常。所以切换 IP 后我通常也会重新建立 Session重新走一遍首页访问流程确保新 IP 和新的 Cookie 状态是匹配的。这样看起来才像是一个全新的用户而不是同一个脚本换了个马甲。4. 第三个实用技巧动态渲染页面就让浏览器替你干活4.1 当 requests 拿不到数据时别急着啃 JS动态渲染的反爬方式在很多现代网站里非常常见。你打开浏览器能看到完整列表但用 requests 抓回来的 HTML 里根本没有这些数据只有一段又一段的 script。原因是数据通过接口异步加载然后由 JavaScript 动态创建 DOM 节点。面对这种情况很多人的第一反应是去逆向分析 JS找到加密函数然后手动模拟生成参数。这个方法不是不行但成本很高而且一旦目标网站更新 JS 逻辑之前的破解代码立刻作废。更高效、也更不容易出错的思路是让一个真正的浏览器去加载并渲染这个页面渲染完成后再从 DOM 里取数据。这就是无头浏览器的用途。所谓无头浏览器就是一个没有界面的完整浏览器内核它会像真实浏览器一样执行 JavaScript、发送异步请求、等待资源加载。我们只需要通过自动化库去控制它打开页面、等待内容出现、然后提取 HTML。网络请求层面的反爬大多数情况下对它无效因为服务器看到的就是一个标准浏览器。怎么判断一个页面是不是动态渲染最简单的方法是在 Network 面板里勾选 Fetch/XHR刷新页面看有没有额外的异步接口为页面提供数据。如果有并且这些接口返回的数据格式不是直接的 JSON而是经过加密的内容那就别费劲分析了直接上浏览器渲染。当然如果接口返回的是干净的 JSON那直接用 requests 请求这个接口会快得多没必要上浏览器。判断的核心是“成本对比”哪种方式实现的成本低、维护简单就用哪种。4.2 Playwright 最小可用流程在几个浏览器自动化库里面我用得最多的是 Playwright。相比 Selenium它的 API 更现代等待机制更可靠启动速度也更快。安装其实很简单只需要执行两行命令pip install playwright playwright install chromium第一行是安装 Playwright 库第二行是下载 Chromium 浏览器内核。下载过程中可能会稍微慢一点耐心等待即可。装完之后下面这段代码就可以跑起来打开一个动态页面并输出渲染后的 HTML。from playwright.sync_api import sync_playwright def render_page(url): with sync_playwright() as p: browser p.chromium.launch(headlessTrue) page browser.new_page() page.goto(url, timeout60000) # 等待某个关键元素出现比固定 sleep 更可靠 page.wait_for_selector(.list-item, timeout10000) html page.content() browser.close() return html html render_page(https://example.com/list) print(html[:500])这段代码里最核心的是wait_for_selector。它会让页面一直等待指定的 CSS 选择器出现最多等 10 秒。如果页面数据是异步加载的这个等待机制可以有效避免你拿到还没渲染完成的空白页面。不要让程序盲目地 sleep 几秒就开抓那样既浪费时间又容易在目标页面网络变慢时抓不到数据。等待选择器比任何固定延时都更符合真实渲染时序。如果你想从渲染后的页面里提取具体内容可以继续用 Playwright 的 locator 接口。比如抓一个列表里所有条目的标题可以这样写items page.locator(.list-item) for i in range(items.count()): title items.nth(i).locator(.title).inner_text() print(title)这种取值方式比正则表达式解析 HTML 要稳定得多。只要页面结构不变代码基本不用改。如果你需要翻页可以在循环里调用page.goto也可以点击页面底部的“下一页”按钮。一般来说直接修改 URL 参数翻页更快也更不容易被前端逻辑干扰。4.3 渲染模式下的降速与异常处理用浏览器渲染抓取虽然能解决动态内容的问题但效率通常比纯 requests 低很多。因为浏览器要加载图片、样式、脚本资源消耗非常大。所以我在实际项目中一般遵循一个原则能用 requests 拿到的数据绝不轻易上浏览器只有确认数据是异步渲染或者接口请求需要复杂的 JS 生成参数时才把 Playwright 请出来。如果你确实需要循环抓取多个页面那要注意浏览器的资源管理。下面的示例里我不会每次循环都重新启动浏览器而是复用同一个浏览器实例只新建或切换页面这样速度会快很多。from playwright.sync_api import sync_playwright with sync_playwright() as p: browser p.chromium.launch(headlessTrue) page browser.new_page() for page_num in range(1, 6): url fhttps://example.com/list?page{page_num} try: page.goto(url, timeout60000) page.wait_for_selector(.list-item, timeout10000) items page.locator(.list-item).count() print(f第{page_num}页抓到 {items} 条数据) except Exception as exc: print(f第{page_num}页出错{exc}) # 适当停顿给浏览器和服务器一点喘息时间 page.wait_for_timeout(2000) browser.close()这里我用了固定 2000 毫秒的停顿目的是给目标服务器和本地浏览器一个缓冲。你也可以在循环里随机 sleep 更长的时间。遇到单页异常时try/except可以保证整个循环不会因为一个页面报错就中断。把错误信息打出来方便后续排查。还有一个细节如果使用 Playwright 自动打开开发者工具或用headlessFalse的非无头模式调试请避免在正式运行环境中长期这样操作因为在有界面的浏览器里可能出现人工干预弹窗、无法自动关闭等问题。我通常只在调试阶段用headlessFalse正式采集全部切回headlessTrue。此外用 Playwright 连续抓取几十个页面后浏览器进程可能会吃掉大量内存。如果发现系统越来越卡可以在循环里定期关闭当前页面再开一个新页面或者直接重启浏览器实例。不要觉得这是浪费内存溢出导致的半途而废往往比慢一点更耽误时间。5. “90%都能绕过”是错觉但这三点能让你少被虐5.1 为什么不存在一个万能技巧你可能在不少文章里看到过“90% 的反爬都能轻松绕过”这种说法。我自己写爬虫这么多年对这种话基本是打折扣看的。反爬是一个持续对抗的过程目标网站会根据攻击特征不断调整检测策略。你今天靠请求头伪装绕过了明天对方可能加入 TLS 指纹校验你今天用无头浏览器渲染解决了动态内容明天可能对方的脚本开始检测浏览器自动化特征。不存在一个一劳永逸的技巧能让你永远不碰到反爬。但反过来讲上面这三个技巧组合起来确实能覆盖绝大多数常见反爬场景。请求头伪装解决的是“你是不是脚本”的问题请求节奏控制解决的是“你是不是太贪心”的问题动态渲染解决的是“你能不能拿到渲染后页面”的问题。三者对应着不同层面的拦截组合使用时能处理掉我日常遇到的大部分反爬情况。我更愿意把它理解成一个基础工具箱而不是“万能钥匙”。我见过不少新人的做法是遇到反爬就疯狂找开源库想把所有反爬都“绕”过去。这种心态反而容易陷入工具竞赛。反爬技术升级的速度永远比单一工具快真正有效的策略是把你手头的这几个基础能力打磨好然后根据目标网站的反馈灵活组合。有时候最简单的 Headers 伪装加合理延时就能解决根本不需要上浏览器。技术选型越贴近问题本质后期维护就越省心。5.2 爬取前的合规自检清单无论标题怎么吸引人我都建议在动手之前先按下面的清单过一遍。这不是为了让你束手束脚而是为了让你长期跑数据的过程中少一些风险也更尊重目标网站。检查项建议动作robots.txt访问/robots.txt查看是否明确禁止爬取路径网站服务条款确认是否能接受自动采集行为请求频率控制到真实用户不会触发的级别数据类型不碰个人隐私、账号信息、支付相关数据数据用途仅用于学习研究或授权允许的场景验证码处理不破解验证码遇到就停止或降低频率这张表是我每次接手新采集需求时都会对照的。尤其是 robots.txt 这一项很多人会忽略但它能帮你避开很多不必要的麻烦。如果目标网站明确禁止爬取那就换公开数据集或者寻找其他合法来源。技术上能做到的事不代表你应该去做。另外采集到的数据如果用于发布文章、做数据分析、训练模型还要注意数据的版权归属和用户隐私。就算数据本身是公开的也不代表你可以随意二次传播。特别是在做数据清洗和存储的时候建议只保留必要的业务字段不要把所有原始内容一股脑存下来。减少数据冗余既是对他人的尊重也是给自己降低合规压力。5.3 一条写在最后的个人经验如果你是一个刚开始学爬虫的开发者我的建议是不要一上来就追求最复杂的对抗方案。先把前面三个技巧练熟在日常项目里积累对反爬特征的判断能力。遇到问题时用最小脚本去探测根据响应状态和返回内容逐步调整而不是盲目叠加各种库和参数。写爬虫真正的乐趣不是“破解”某个网站而是通过观察、分析、验证找到一套符合自己使用场景的可持续方案。我的经验是带着“尽量不给服务器添麻烦”的心态去写代码反而能在反爬对抗中走得更远。最后再分享一个小技巧每次采集任务结束后把当时的反爬特征、应对方案、响应状态码和最终效果记到一个简单的日志文件里。下次再碰到类似网站翻一翻历史记录很多问题都能直接找到参考方案。我靠这个习惯省下过大量重复排查的时间也慢慢锻炼出了对反爬策略的判断直觉。希望这篇分享也能帮你少走一些弯路。