做公开资讯采集这几年Cloudflare绝对是绕不开的一道坎。前两年碰上海外一批技术博客和资讯站清一色套了Cloudflare防护原生requests上去直接403连页面HTML都摸不到。一开始想当然觉得是IP的问题前前后后换了三家代理供应商钱花了小两千结果新IP撑不过三个请求就进挑战页整体通过率不到30%。后来抓包逐层拆才反应过来根本不是IP的锅——我们的请求从TCP握手那一刻起TLS指纹就已经明明白白写着“我是Python程序”对方根本不用看请求内容协议层一对就直接打回。前后折腾了两周从纯HTTP客户端摸到无头浏览器摸透了不同防护等级的应对逻辑总结出三套分层方案。不用上来就砸钱买高端住宅代理普通防护的站点零代理费用就能做到90%以上的通过率。一、先搞清楚你面对的是哪个等级的防护很多人上来就问“怎么过Cloudflare”其实它的防护是分级的不同等级对应的方案天差地别搞错了就是白费力气。先判断清楚类型再选对应方案效率能高好几倍。一级防护协议层指纹检测最轻的一档只校验TLS指纹、HTTP头完整性、请求特征没有JS挑战。典型表现浏览器直接访问正常原生requests/httpx请求直接返回403没有“Just a moment”的等待页面。常见场景个人博客、普通资讯站、技术文档站。应对成本极低改个客户端就能解决。二级防护5秒盾JS挑战最常见的一档返回包含JS的挑战页面客户端执行完JS计算、生成cf_clearanceCookie后才能正常访问。典型表现打开页面先显示“正在验证浏览器”5秒左右自动跳转页面源码里有大量混淆JS。常见场景中小型社区、内容站、普通企业官网。应对成本中等需要能执行JS的环境过挑战。三级防护托管式人机挑战最高的一档结合浏览器环境检测、行为分析可能弹出Turnstile无感人机验证甚至滑块、点选。典型表现频繁弹出验证、IP稍一频繁就出挑战页、纯脚本环境完全通不过。常见场景大型社区、电商平台、高价值数据站点。应对成本较高需要完整浏览器环境行为优化。绝大多数人日常碰到的都是前两档根本用不着最重型的方案。先定位清楚等级再对症下药性价比最高。二、方案一轻量级curl_cffi对齐协议指纹搞定一级防护这是性价比最高的方案改两行代码就能解决80%的基础防护站点也是我日常用得最多的。为什么原生requests永远403很多人以为改了User-Agent就等于模拟浏览器了其实差得远。TLS握手的时候客户端会发送加密套件列表、扩展列表、椭圆曲线参数等信息。Python requests、httpx这类库的底层网络栈和真实浏览器完全不同生成的JA4指纹差异极大。Cloudflare只需要看一眼握手指纹就能准确判断你是Python程序还是真实Chrome你上层头改得再像都没用。这就是为什么很多人百思不得其解我UA、Referer、Cookie全抄浏览器的怎么还是403问题出在更底层的协议层。解决方案curl_cffi一键对齐浏览器指纹curl_cffi基于 curl-impersonate 封装底层直接复刻Chrome、Firefox等浏览器的完整TLS栈JA3/JA4指纹和真实浏览器完全一致协议层直接和真实浏览器无差别。安装和使用都非常简单pipinstallcurl_cffi基础会话封装fromcurl_cffiimportrequestsimportrandomimporttime# 直接指定模拟的浏览器版本TLS指纹自动对齐sessionrequests.Session(impersonatechrome128)# 请求头要和模拟的浏览器版本完全对应一个都别漏headers{Accept:text/html,application/xhtmlxml,application/xml;q0.9,image/avif,image/webp,*/*;q0.8,Accept-Language:zh-CN,zh;q0.8,zh-TW;q0.7,en-US;q0.5,en;q0.3,Accept-Encoding:gzip, deflate, br,Referer:[https://example.com/](https://example.com/),User-Agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:128.0) Gecko/20100101 Firefox/128.0,Connection:keep-alive,Upgrade-Insecure-Requests:1,Sec-Fetch-Dest:document,Sec-Fetch-Mode:navigate,Sec-Fetch-Site:none,Sec-Fetch-User:?1}deffetch_page(url):try:respsession.get(url,headersheaders,timeout10)resp.raise_for_status()returnresp.textexceptExceptionase:print(f请求失败:{e})returnNone实测效果与踩坑提醒普通技术博客、资讯站这类一级防护站点原生requests通过率20%左右换成curl_cffi之后直接拉到95%以上连代理都不用开。几个必踩的坑提前说不是万能的。它只能解决协议层检测带JS挑战的二级防护站点过不去因为它不会执行JS拿不到cf_clearance。指纹版本要和UA对应。你模拟Chrome 128UA就必须写Chrome 128版本对不上反而会因为特征矛盾拉高风险分。要维护会话Cookie。不要每次请求都新建会话正常用户是有连续Cookie的。空会话、空Cookie天生高风险。三、方案二中阶浏览器拿Cookie HTTP客户端复用兼顾速度与通过率碰到带5秒盾的二级站点纯HTTP客户端就不够用了——它跑不了JS拿不到通关用的cf_clearanceCookie。很多人这时候就全程上Playwright硬爬慢得要死还占资源其实完全没必要。浏览器只用来过挑战拿Cookie真正采集数据交给HTTP客户端通过率和真实浏览器一致速度却能快好几倍。核心思路用Playwright启动浏览器访问目标站首页等待5秒盾自动完成挑战拿到完整Cookie把Cookie、UA等信息同步到curl_cffi会话中后续所有采集请求都用HTTP客户端发速度和纯原生请求一致Cookie过期前再用浏览器刷新一次即可不用全程挂着浏览器完整实现代码fromplaywright.sync_apiimportsync_playwrightfromcurl_cffiimportrequestsdefget_cf_cookies(url):用浏览器过5秒盾拿到有效Cookiewithsync_playwright()asp:browserp.chromium.launch(headlessnew,# 必须用新无头模式旧无头很容易被检测channelchrome)contextbrowser.new_context(user_agentMozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36,viewport{width:1920,height:1080},localezh-CN,timezone_idAsia/Shanghai)pagecontext.new_page()# 访问首页等待挑战自动通过page.goto(url,wait_untilnetworkidle)# 额外等待几秒确保挑战完成、Cookie写入page.wait_for_timeout(6000)# 提取所有Cookiecookiescontext.cookies()browser.close()returncookiesdefbuild_session(cookies):把浏览器Cookie同步到HTTP会话sessionrequests.Session(impersonatechrome128)forcookieincookies:session.cookies.set(cookie[name],cookie[value],domaincookie[domain])returnsession# 使用流程if__name____main__:target_url[https://example.com](https://example.com)# 1. 浏览器拿Cookiecookiesget_cf_cookies(target_url)# 2. 构建HTTP会话sessionbuild_session(cookies)# 3. 后续批量采集全走HTTP速度拉满foriinrange(100):respsession.get(f{target_url}/page/{i})# 解析数据...关键注意点必须用新无头模式。旧版无头的环境特征非常明显很容易被检测出来headlessnew模式底层就是真实Chrome特征差异极小。不要刚打开就抓Cookie。等页面跳转完成、cf_clearance写入之后再取不然拿到的是无效Cookie。Cookie有有效期。一般几个小时到一天不等失效了就重新用浏览器刷一次不用频繁刷。这套方案应对中等防护的站点非常稳通过率接近真实浏览器采集速度却是全程无头浏览器的5-10倍性价比极高。四、方案三高阶行为优化会话预热应对高强度防护碰到防护等级高的站点比如大型社区、内容平台光有指纹和Cookie还不够。你环境是对的但行为全是爬虫特征照样会频繁出验证、被限流。很多人觉得过了5秒盾就完事了结果爬个三五页就又弹挑战核心原因就是行为太反常。小红书、知乎这类国内内容平台的逻辑也高度相似重点从来不是破解什么盾是把风险分压在阈值以下。分享几个经过验证的行为优化思路做完之后验证码出现频率能降80%1. 完整访问路径不要直奔目标真实用户一定是从首页、列表页、搜索页一步步进到详情页的。直接请求深层接口、跳过所有前置路径风险分直接拉满。采集前先访问首页初始化会话先走2-3页列表页模拟浏览翻页再逐步进入详情页Referer和上一页严格对应中途穿插返回列表、翻下一页的动作不要一条路走到黑2. 频率随机化不要固定节拍固定间隔、匀速请求是最典型的程序特征。真人操作的节奏一定是波动的看长文章停得久看短文章翻得快偶尔还会停下来干点别的。用正态分布生成请求间隔不要用均匀随机更不要固定值每请求10-15页插入一次10-20秒的长停留模拟用户阅读、喝水的间隙高峰期适当降速不要半夜猛冲正常用户不会凌晨三点每分钟刷十几页3. IP、指纹、会话三者绑定不要交叉混用同一个IP对应一套Cookie、一套指纹、一个浏览器环境。频繁换IP、同IP乱换Cookie、同Cookie换不同指纹都会触发异常检测。稳定的IP比频繁换IP更安全。同一个IP稳定跑正常行为比十分钟换八个IP的风险分低得多。不要一个IP跑多个不相关的业务。不同站点、不同类型的任务分开用不同的IP段。4. 错误降级不要硬冲碰到挑战页、403不要立刻疯狂重试越重试风险分越高。第一次出挑战先停30秒再刷新一次连续两次失败就换会话重新过挑战不要死磕整体失败率上升时主动降速而不是加并发五、最容易踩的五个误区误区1换IP就能解决一切这是新手最容易陷进去的坑。403了就换IP换了还封就买更贵的IP结果钱花了不少问题没解决。很多时候封的根本不是IP是你的客户端指纹。指纹不对换多少IP都是刚上去就被识别白费钱。先把底层特征对齐了再考虑IP的事。误区2curl_cffi是万能的网上很多文章吹“curl_cffi秒过Cloudflare”都是标题党。它只能解决协议层的检测带JS挑战的站点根本过不去更别说三级的人机验证了。对它的定位要准是基础层的优化不是万能钥匙。误区3全程用无头浏览器采集很多人为了稳全程Playwright跑结果速度慢、并发低、服务器成本高。浏览器只应该用来过挑战、拿Cookie。真正的批量数据采集交给HTTP客户端效率高得多。能轻量就不要重型架构越简单越稳。误区4只改UA其他头全丢请求头是一个整体不是改个UA就完事了。Accept、Accept-Language、Sec-Fetch系列、Referer缺一个或者格式不对都会拉高风险分。最稳妥的方式从浏览器DevTools里把请求头原封不动抄下来一个字段都别改顺序也尽量保持一致。误区5追求速度忽略稳定性很多人总想着一秒钟爬多少页结果跑十分钟就全封了一天下来没多少有效数据。采集这个事稳永远比快重要。慢一点但能24小时不间断跑产出量远高于猛冲半小时就全军覆没。把频率降下来行为做正常长期产出反而更高。最后总结Cloudflare的对抗从来不是单点突破是分层匹配的游戏。一级防护对齐TLS指纹就够了curl_cffi两行代码解决零成本二级防护浏览器拿Cookie HTTP复用兼顾速度和通过率三级防护再加上行为优化和会话预热把风险分压到阈值以下不要上来就买最贵的代理、上最重的浏览器方案先判断防护等级从最轻的方案开始试。能用低成本解决的问题就没必要堆资源。最后还是要提醒一句本文仅讨论公开数据采集的请求优化技术所有数据采集行为请严格遵守《网络安全法》及目标网站的robots协议只爬取公开允许的内容不得用于非法商业用途。