踩坑Cloudflare两周：从一请求就403到90%通过率，三套分层方案亲测可用（不用付费代理）

原创于 2026-10-28 06:56:55 发布 · 37 阅读

本内容遵循CC 4.0 BY-SA版权协议

本文系统解析Cloudflare三级防护机制：一级协议层指纹检测、二级5秒JS挑战、三级托管式人机验证。提出三套分层应对方案——curl_cffi对齐TLS指纹解决一级防护；Playwright过盾+HTTP客户端复用应对二级；叠加行为优化（访问路径模拟、频率随机化、IP-指纹-会话绑定、错误降级）攻克三级防护。强调避免换IP万能论、curl_cffi局限性、无头浏览器滥用等五大误区，聚焦信息技术领域中的反爬对抗核心策略。

做公开资讯采集这几年，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_clearance Cookie后才能正常访问。

典型表现：打开页面先显示“正在验证浏览器”，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指纹和真实浏览器完全一致，协议层直接和真实浏览器无差别。

安装和使用都非常简单：

pip install curl_cffi

基础会话封装：

from curl_cffi import requests
import random
import time

# 直接指定模拟的浏览器版本，TLS指纹自动对齐
session = requests.Session(impersonate="chrome128")

# 请求头要和模拟的浏览器版本完全对应，一个都别漏
headers = {
    "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8",
    "Accept-Language": "zh-CN,zh;q=0.8,zh-TW;q=0.7,en-US;q=0.5,en;q=0.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"
}

def fetch_page(url):
    try:
        resp = session.get(url, headers=headers, timeout=10)
        resp.raise_for_status()
        return resp.text
    except Exception as e:
        print(f"请求失败: {e}")
        return None

实测效果与踩坑提醒

普通技术博客、资讯站这类一级防护站点，原生requests通过率20%左右，换成curl_cffi之后直接拉到95%以上，连代理都不用开。

几个必踩的坑提前说：

不是万能的。它只能解决协议层检测，带JS挑战的二级防护站点过不去，因为它不会执行JS，拿不到cf_clearance。
指纹版本要和UA对应。你模拟Chrome 128，UA就必须写Chrome 128，版本对不上反而会因为特征矛盾拉高风险分。
要维护会话Cookie。不要每次请求都新建会话，正常用户是有连续Cookie的。空会话、空Cookie天生高风险。

三、方案二：中阶，浏览器拿Cookie + HTTP客户端复用，兼顾速度与通过率

碰到带5秒盾的二级站点，纯HTTP客户端就不够用了——它跑不了JS，拿不到通关用的cf_clearance Cookie。

很多人这时候就全程上Playwright硬爬，慢得要死还占资源，其实完全没必要。浏览器只用来过挑战拿Cookie，真正采集数据交给HTTP客户端，通过率和真实浏览器一致，速度却能快好几倍。

核心思路

用Playwright启动浏览器，访问目标站首页，等待5秒盾自动完成挑战，拿到完整Cookie
把Cookie、UA等信息同步到curl_cffi会话中
后续所有采集请求都用HTTP客户端发，速度和纯原生请求一致
Cookie过期前，再用浏览器刷新一次即可，不用全程挂着浏览器

完整实现代码

from playwright.sync_api import sync_playwright
from curl_cffi import requests

def get_cf_cookies(url):
    """用浏览器过5秒盾，拿到有效Cookie"""
    with sync_playwright() as p:
        browser = p.chromium.launch(
            headless="new",  # 必须用新无头模式，旧无头很容易被检测
            channel="chrome"
        )
        context = browser.new_context(
            user_agent="Mozilla/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},
            locale="zh-CN",
            timezone_id="Asia/Shanghai"
        )
        page = context.new_page()
        
        # 访问首页，等待挑战自动通过
        page.goto(url, wait_until="networkidle")
        # 额外等待几秒，确保挑战完成、Cookie写入
        page.wait_for_timeout(6000)
        
        # 提取所有Cookie
        cookies = context.cookies()
        browser.close()
        return cookies

def build_session(cookies):
    """把浏览器Cookie同步到HTTP会话"""
    session = requests.Session(impersonate="chrome128")
    for cookie in cookies:
        session.cookies.set(cookie['name'], cookie['value'], domain=cookie['domain'])
    return session

# 使用流程
if __name__ == "__main__":
    target_url = "[https://example.com](https://example.com)"
    # 1. 浏览器拿Cookie
    cookies = get_cf_cookies(target_url)
    # 2. 构建HTTP会话
    session = build_session(cookies)
    # 3. 后续批量采集全走HTTP，速度拉满
    for i in range(100):
        resp = session.get(f"{target_url}/page/{i}")
        # 解析数据...