curl_cffi实战：破解Cloudflare 403的TLS指纹识别难题

做爬虫最头疼的事，往往不是网页结构多复杂，而是你把代码写得清清楚楚、信心满满地一跑，对面反手甩你一个 403。打开页面看，浏览器里一切正常，换成脚本却处处碰壁。这正是 Cloudflare 这类防护体系最典型的招数：它不看你的 IP，不看你的 UA，它盯上的是你 HTTP 客户端在建立连接时暴露出来的"长相"——也就是 TLS 指纹。过去处理 403，大家习惯加 headers、换代理、慢慢调重试，费劲不说，效果还不稳定。直到我试了 curl_cffi，才发现很多 403 其实根本不用硬刚，把指纹切换成浏览器的样子，问题自然就化解了。

这篇文章要讲的就是这套完整的解法：从 TLS 指纹到底是什么、为什么 requests 和 httpx 容易被识别，到 curl_cffi 的安装、用法、指纹切换，再到图片防盗链的 Referer 处理，最后用一个完整案例把爬虫采集和图片落地串起来。整个过程不绕弯子，也不只给代码，我会把每一步背后的原理、我自己踩过的坑、以及实际项目中验证过的参数配置都讲清楚。适合被各类反爬 403 折磨过的爬虫开发者，也适合刚接触反爬对抗、想系统理解 HTTP 客户端识别机制的初学者。

1. 项目背景：403 盾到底拦的是什么

先说结论：当你的爬虫收到 403，大概率不是"网站拒绝你这个人"，而是"网站识别出你不是一个真人浏览器"。防爬体系发展到今天，早已不是查个 User-Agent 那么简单，它已经形成了一整套从网络层到应用层的识别链条。想真正解决 403，先得知道这堵墙是哪几块砖砌起来的。

1.1 防护体系的三个识别层次

第一层是 IP 信誉。数据中心 IP、频繁访问的 IP、被标记过的 IP，都会在请求到达时被直接判负。这一层最粗暴但最有效，很多爬虫死在这里，连后面两层的面都没见到。

第二层是行为特征。明明一个浏览器用户，怎么可能每 0.5 秒点一次页面？怎么可能一进来就是一堆连续请求？访问频率、访问路径、停留时间，这些行为统计会被风控系统当作重要的判据。这一层靠代理池和限速可以缓解，但治标不治本。

第三层也是最容易被忽略的一层，就是 TLS/HTTP 指纹。浏览器在和服务器建立 TLS 连接时，会发送一个 ClientHello 消息，里面包含了支持的加密套件列表、TLS 版本、扩展项顺序等信息。不同的客户端，比如 Chrome、Firefox、Safari，甚至同一个浏览器不同的版本，这些参数组合都是不一样的，如同每个人指纹都不相同。绝大多数编程语言自带的 HTTP 库，比如 Python 的 requests（底层是 urllib3）、Go 的 net/http，它们的 TLS 参数组合和浏览器有明显差异，服务器只看一眼握手包，就能在连接还没建立完的时候判断你根本不是浏览器。

1.2 为什么常规 headers 大法失效了

很多爬虫新手有一招"万能解法"：给 requests 加上一堆 headers，把 User-Agent 改成 Chrome，再带上 Accept、Accept-Language 之类，然后信心满满地重试。但结果往往是无情的 403。原因很简单：你骗过了服务器在 HTTP 层面的检查，却骗不过它在 TLS 层面对你的审视。请求头是明文，谁都能伪造；但 ClientHello 里的加密套件顺序、扩展列表、椭圆曲线偏好，是由你的底层库在编译时就写死的，改 headers 根本动不了这些东西。

我在实际项目中见过一个很典型的情况：同一个网页，浏览器访问一切正常，用某国产 HTTP 库请求就返回 403，就算把 headers 伪装到极致也一样。后来抓包对比 ClientHello，才发现两边发出去的指纹差异大到惊人。从那一刻起我就明白了，处理反爬不能只盯着应用层，得往底层走。

注意：TLS 指纹识别不是防火墙或者安全软件，它是 CDN 服务商提供的一种自动化的客户端识别手段。它判断的不是"你是谁"，而是"你像不像一个正常访客"。这本身属于正常的站点防护机制，作为开发者，我们要做的是让自己的爬虫程序表现得像一个正常的浏览器客户端，而不是试图攻击或破坏任何站点的防护体系。

1.3 curl_cffi 在这个链条里解决什么问题

curl_cffi 是 Python 对 libcurl 的一个绑定库，它最核心的能力就是可以"借用"浏览器真实的指纹。它内置了 Chrome、Safari、Firefox 等浏览器的 TLS 参数组合，你在发起请求时指定一个 impersonate（模拟）目标，它就会使用和这个浏览器完全一样的指纹去建立连接。换句话说，它是在协议层把你的客户端"装扮"成浏览器，而不是在 headers 层面做表面功夫。

理解这一点很重要：curl_cffi 不是代理，不是协程框架，也不是万能钥匙。它只解决"客户端指纹与浏览器不一致"这一类问题。如果某个站点拒绝你的原因其实是 IP 被限制了，那换上 curl_cffi 也无济于事。所以我在下文的操作里，会把"什么样的 403 适合用 curl_cffi"和"什么样的 403 需要另想别的办法"讲清楚，避免大家盲目搬代码。

2. 核心原理：TLS 指纹是攻防的关键战场

TLS 指纹这个词，很多写爬虫的人听说过但没深究过。它到底是怎么形成的？为什么不同语言、不同库之间会有那么大的差异？curl_cffi 又是怎么做到伪装的？这一节我把这些底层细节讲透。

2.1 一个连接建立时的"自我介绍"

HTTPS 连接建立的第一步是 TLS 握手，而握手的第一个消息就是我们前面提到的 ClientHello。当你的浏览器访问一个网站时，它会发送一个 ClientHello 包，里面打包了客户端支持的 TLS 版本、加密套件列表（Cipher Suites）、扩展项（Extensions），以及每一类扩展下的具体参数。

这里的关键在于，这些参数不是随机的，而是由客户端实现决定的。Chrome 有一套固定的支持矩阵，Firefox 是另一套，Python 的 ssl 模块又是第三套。安全研发人员把这些参数提取出来、做哈希处理，就得到了一个"指纹"——只要是同一个客户端的同一个版本，指纹就完全一样。服务器端不需要做任何解密工作，光读握手包就能知道对面是什么客户端。

我打个生活化的比方：你去银行办业务，柜员不需要看你的身份证，光听你说话的口音、看你的肢体语言，就能大概判断你是哪个地方的人。TLS 指纹也是同理，服务器光看你的握手偏好，就能猜个七七八八。

2.2 为什么 Python 正统库容易暴露身份

用 Python 的 requests 发起 HTTPS 请求时，底层走的是 OpenSSL 或者系统自带的加密库，而这些库和浏览器的 TLS 配置差异很大。

具体差异在哪？我抓包对比过，以下几个方面是最悬殊的：

• 加密套件的顺序：Chrome 优先使用基于现代 AEAD 算法的套件，而 OpenSSL 默认配置中那些老旧的加密算法排序明显不同。服务器一眼就能看出"这不是浏览器的口味"。
• 支持的 TLS 版本范围：浏览器通常已经启用 TLS 1.3，且支持多种版本协商；一些老旧库的默认配置还停留在 TLS 1.0/1.1，信号特征极其明显。
• 扩展项列表：Chrome 会发送 application_layer_protocol_negotiation（ALPN）、key_share、supported_groups 等一系列扩展，排列顺序固定；而 Python 标准 ssl 模块的扩展列表短得多，而且顺序不一样。

这些差异叠加在一起，产生的指纹是完全不同的。更麻烦的是，requests 的底层 urllib3 不具备自定义 TLS 参数的开关，你想改都不知道从哪下手。就算你给 urllib3 换一个 SSLContext，能用 OpenSSL 命令调出一套浏览器的参数组合，那也是一个工程级的大麻烦，远不如 curl_cffi 来得轻量。

2.3 从 libcurl 到 curl_cffi：一条性价比极高的实现路径

curl 是一个老牌的传输工具，它对 TLS 的处理很灵活，内部支持通过不同的 TLS 后端（如 OpenSSL、GnuTLS、NSS）来构造请求，而且它对 HTTP/2、TSL 的扩展支持做得非常细。curl_cffi 做的事情，就是把 libcurl 的能力通过 CFFI 暴露给 Python，并且内部内置了一套"浏览器指纹配置表"。

当你调用requests.get(url, impersonate="chrome")的时候，curl_cffi 会把 libcurl 的 TLS 参数配置成 Chrome 同款：同样的加密套件顺序、同样的扩展列表、同样的 ALPN 协议组合。这个"借用浏览器指纹"的逻辑并不复杂，难点在于要随着浏览器版本迭代更新指纹库，而 curl_cffi 这个项目一直在做这件事。

我在实际使用中明显感受到，它和传统方案的本质不同在于：以前我们是用 Python 库去"尽力模仿"浏览器，处处受限于底层能力；现在是用程序去"直接调用"浏览器同款参数，整条链路从建连那一刻起就和浏览器一样了。

3. curl_cffi 实操：从安装到指纹切换

原理讲完，该上手了。这一节我会从安装开始，到最简单的请求，再到 Session 保持、Cookie 管理、指纹切换和代理搭配，把这套工具的用法梳理完整。同时也会提到一些我从项目经验中总结出来的使用习惯，避免你踩我踩过的坑。

3.1 安装与环境准备

curl_cffi 的安装非常简单，直接用 pip 安装即可：

pip install curl_cffi -i https://pypi.org/simple

如果你的网络环境访问默认源比较慢，换成国内或公司的私有源也很方便。值得注意的是，curl_cffi 是带二进制依赖的库，某些精简版的 Docker 镜像里可能出现依赖缺失的问题。我个人推荐在官方标准 Python 镜像上直接安装，成功率最高。

装完之后验证一下版本：

import curl_cffi print(curl_cffi.__version__)

如果打印出版本号，说明安装成功。安装这块我踩过一个坑：在某个容器环境里，因为缺少 libcurl 相关运行库，import 阶段就报错。解决方案是安装系统级的依赖包，具体命令取决于你的操作系统。

3.2 最基础的请求：指定浏览器指纹

先看一个最简示例：

from curl_cffi import requests as curl_requests url = "https://example.com/some/protected/page" response = curl_requests.get(url, impersonate="chrome") print(response.status_code) print(response.text[:500])

与常规 requests 相比，唯一的区别就是多了impersonate="chrome"这个参数。别小看这个参数，它会让请求带上 Chrome 的完整 TLS 指纹。这行代码跑通之后，你会发现很多原本返回 403 的接口，现在一下子就通透了。

curl_cffi 支持多种指纹模式，主要分为几个系列：

我个人的使用习惯是：默认用chrome，如果遇到对 Chrome 检测特别严格的站点，再尝试firefox或edge。因为部分站点的防护策略会对某一类指纹的流量样本做特殊标记，换个指纹类型有时能解决意想不到的难题。

3.3 Session 管理与 Cookie 保持

如果一个页面需要先访问首页拿到 Cookie，再带着 Cookie 去请求数据接口，直接用单次get()是不行的。这时需要使用 Session 对象，用法和 requests 非常接近：

from curl_cffi import requests as curl_requests session = curl_requests.Session(impersonate="chrome") # 第一次请求页面，服务器会在响应中种下 Cookie resp1 = session.get("https://example.com/") print(resp1.status_code) # 再请求数据接口，Session 会带上第一次请求得到的 Cookie resp2 = session.get("https://example.com/api/data") print(resp2.status_code)

Session 对象一旦创建时指定了指纹，后续所有请求都会沿用同一套 TLS 配置和 Cookie 状态。这一个特性在模拟真实用户访问路径时特别重要，因为很多防护系统会把"没有 Cookie 就直接访问深层页面"的行为判定为高风险，有 Cookie 的链路明显更可信。

另外，Session 对象的cookies属性支持手动注入和读取：

# 手动设置 Cookie session.cookies.set("session_id", "abc123") # 读取当前所有 Cookie for cookie in session.cookies: print(cookie.name, cookie.value)

需要强调的是，某些站点在首次访问时会执行一段 JS 生成动态 Cookie，此时单靠第一次请求是不够的，可能还需要把页面里出现的计算逻辑用 Python 复现。不过这类情况相对少见，绝大多数场景 Session 自动管理就够用了。

3.4 代理搭配与指纹组合

curl_cffi 支持代理参数，和 requests 的用法保持一致，但这里有一个隐藏的技巧：指纹和代理必须组合得当，否则效果打折扣。

proxies = { "http": "http://proxy_ip:port", "https": "http://proxy_ip:port", } response = curl_requests.get( "https://example.com/", impersonate="chrome", proxies=proxies, timeout=15 )

为什么说"组合得当"很重要？因为如果你用了某个数据中心的 IP，而这个 IP 段早已被站点标记为高风险，那么不管指纹多像浏览器，请求依旧会被拦。反过来，如果你用了住宅代理但指纹是 Python 标准库的，也会被识别。两人必须同时达标，缺一不可。我习惯把代理可行性测试和指纹测试分开做，先用一个不重要的测试接口验证代理连通性，再打开目标页验证指纹效果。

4. 图片防盗链实战：Referer 的前因后果

403 解决之后，另一个高频问题就来了：页面 HTML 能拿到，图片却下载不下来。服务器返回的通常也是 403，或者是一张带水印的占位图。这就是图片防盗链在起作用。解决思路比 TLS 指纹简单得多，但细节同样容易踩雷。

4.1 防盗链的原理：Referer 是入场券

防盗链的全称是 HTTP Referer 防盗链，它的逻辑非常朴素：服务器检查请求头里的 Referer 字段，如果 Referer 属于本站域名，就允许加载图片；如果 Referer 是空的、或者是外部域名，就拒绝。

为什么会有这种机制？因为很多站点的图片存储和流量带宽是付费资源，不希望被其他站点直接引用，导致自己白白承受流量成本。对于爬虫开发者来说，只要在请求图片时加上正确的 Referer，等于告诉服务器"我是从你站内页面点过来的"，就能绕过这道检查。

这个机制的关键在于：Referer 必须是目标图片所在网站的域名，而不是你自己服务器的域名。比如你正在抓取 https://example.com 的图片，那么图片请求的 Referer 就应该设置为https://example.com/或者页面所在的 URL。

4.2 请求头配置细节：别漏掉 Host

加 Referer 的方式很简单，构造 headers 即可：

headers = { "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36", "Referer": "https://example.com/", "Accept": "image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8", "Accept-Language": "zh-CN,zh;q=0.9,en;q=0.8", } resp = curl_requests.get("https://example.com/images/cover.jpg", headers=headers, impersonate="chrome")

这里容易忽略的一个细节是Accept字段。浏览器请求图片时，Accept 的值是图片相关的 MIME 类型列表；如果你用爬虫默认的*/*，部分严格的服务器也会根据这个差异拒绝。虽然这类情况比 Referer 检查少见，但补全了总没坏处。

另一个值得注意的点是，有些图片服务器会同时校验 Referer 和 Host。Host 只需要保持目标域名不变即可，一般不需要手动设置，requests 和 curl_cffi 都会自动填充。但如果经过了一层代理转发，有些代理会改写 Host 头，这时反而需要你手动固定一下。

4.3 图片落地：流式下载与重试

拿到图片响应之后，很多人的第一反应是response.content一把梭。但如果图片很大，或者服务器传输不稳定，这么做容易占用大量内存，甚至中途失败。更稳妥的做法是流式下载：

from pathlib import Path def download_image(session, url, referer, save_path): headers = { "Referer": referer, "Accept": "image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8", } with session.stream("GET", url, headers=headers, impersonate="chrome") as resp: if resp.status_code != 200: print(f"下载失败: {resp.status_code} {url}") return False save_path.parent.mkdir(parents=True, exist_ok=True) with open(save_path, "wb") as f: for chunk in resp.iter_content(chunk_size=8192): if chunk: f.write(chunk) print(f"已保存: {save_path}") return True

我实际项目中使用的是 8192 字节的块大小，这个值兼顾了 IO 效率和内存占用。如果你下载的是超大文件，比如几百 MB 的视频或压缩包，可以考虑扩大到 65536，减少磁盘写入次数。

下载环节还有一个实战技巧：并发下载时，不要对同一个站点开太多线程，否则很容易触发服务器的限流。我用过一个比较稳妥的比例，单站点并发控制在 5 个以内，同时每个请求之间加一个随机的小延迟，比如 1 到 3 秒。这种手法模拟的是多人浏览，而不是单机器轰炸。

5. 综合案例：从 403 拦截到图片全部落地

单独的技术点讲多了，容易只见树木不见森林。这一节我把前面所有内容串起来，做一个完整的模拟项目：目标是抓取一个虚构站点 https://example.com 的图片列表页面，解析出图片地址，然后逐一下载到本地。整个流程包括了环境配置、Session 管理、TLS 指纹伪装、防盗链处理，以及重试机制。这个项目可以推而广之，适配到大量同类型的采集需求上。

5.1 项目整体流程设计

整个采集过程分成四个阶段：

第一阶段，创建带 chrome 指纹的 Session，访问目标列表页，拿到 HTML 并确认响应码为 200。这一步的核心目的是建立有 Cookie 的会话状态。 第二阶段，解析 HTML 中的图片链接。根据项目需要，我通常会先解析出图片的原文链接（可能是相对路径），再拼接成绝对 URL。 第三阶段，带着伪造的 Referer 请求图片，做下载。 第四阶段，加入失败重试和频率控制，收集监控日志。

5.2 页面解析与链接提取

页面解析我习惯用 BeautifulSoup，简单直接。如果目标站点是复杂的单页应用，数据通过 JSON 接口返回，那我就会换成解析 JSON 的方式。

import time import random from pathlib import Path from bs4 import BeautifulSoup from curl_cffi import requests as curl_requests target_url = "https://example.com/gallery" referer = "https://example.com/" session = curl_requests.Session(impersonate="chrome") resp = session.get(target_url, timeout=15) print("列表页状态码:", resp.status_code) if resp.status_code != 200: print("列表页加载失败，请检查指纹配置或代理状态") exit() soup = BeautifulSoup(resp.text, "html.parser") img_tags = soup.select("img.pic-item") img_urls = [] for img in img_tags: plain_url = img.get("src") or img.get("data-src") if not plain_url: continue if plain_url.startswith("//"): plain_url = "https:" + plain_url elif plain_url.startswith("/"): plain_url = "https://example.com" + plain_url img_urls.append(plain_url) print(f"共解析到 {len(img_urls)} 张图片")

这里有三处细节值得展开。第一，图片链接很多时候不在src而在>import threading from concurrent.futures import ThreadPoolExecutor, as_completed lock = threading.Lock() download_count = 0 def worker(img_url): global download_count for attempt in range(3): try: headers = { "Referer": referer, "Accept": "image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8", } with session.stream("GET", img_url, headers=headers, timeout=20) as resp: if resp.status_code == 200: filename = img_url.split("/")[-1].split("?")[0] save_path = Path("./downloads") / filename with open(save_path, "wb") as f: for chunk in resp.iter_content(chunk_size=8192): if chunk: f.write(chunk) with lock: download_count += 1 return True, img_url else: print(f"第 {attempt+1} 次请求返回 {resp.status_code}: {img_url}") except Exception as e: print(f"第 {attempt+1} 次请求异常: {img_url} -> {e}") time.sleep(random.uniform(1, 2)) return False, img_url with ThreadPoolExecutor(max_workers=4) as pool: futures = [pool.submit(worker, url) for url in img_urls] for future in as_completed(futures): ok, url = future.result() if not ok: print(f"最终失败: {url}") print(f"完成，成功下载 {download_count}/{len(img_urls)}")

这个下载模板我在多个项目里复用过，核心经验有三条。

第一条，重试之间必须加随机延迟。我见过不少人写重试，三个pass之后再空空重试，结果那三秒内连续打三次，照样被限流。我的习惯是每次重试之间休息 1 到 3 秒，加一点随机抖动，让请求时间分布看起来更自然。

第二条，线程数要克制。对大多数图片站点来说，4 到 6 个并发的下载线程已经够了。如果目标站点有自己明显的风控偏好（比如响应偶尔变慢），那就调低到 2。比起下载速度，稳定地不被封掉才是长期收益最大的策略。

第三条，下载失败的图片要留日志。日志里记录 URL、状态码和失败原因，方便后续单独补下。我在项目里看到过不少半途而废的采集任务，就是因为失败的图片没有记录，错过了几十张之后就懒得追溯了。

5.4 合规与频率控制

写到这里，我特别想强调一点：上面这套组合方案的效果虽然好，但必须建立在合法合规使用的前提下。

使用爬虫技术时，务必遵守目标站点的服务条款和 robots.txt 声明。如果站点明确禁止爬虫，或者采集的数据涉及个人信息、版权内容，就不要强行采集。我自己的操作习惯是：

• 请求频率主动控制，宁可慢也别冒进
• 只采集公开数据，不触碰需要登录或明确加密的内容
• 下载图片等资源时，不让并发线程数超过个位数
• 不把采集内容用于商业变现，除非已获得授权

爬虫是一门技术，技术本身没有立场，但使用技术的人要有边界。批量下载图片不能无限制地消耗对方服务器资源，也不能用于侵害他人权益。这也是我在团队里反复强调的红线。

6. 常见问题与排查技巧实录

curl_cffi 用起来整体顺手，但实战中依然会碰到不少奇奇怪怪的问题。这一节我把实际踩过、以及身边同事反馈过的高频问题整理成表格，再补充几个排查经验和调试技巧。

6.1 高频问题速查表

表格里每一个问题，我都在实际开发里见过不止一次。这里挑三个重点展开讲。

第一个是impersonate模式不匹配的问题。有段时间我总是执着于用特定版本的 Chrome 指纹，结果某站点就是死活 403。后来同事提醒我换了个思路，试了一下 Firefox 模式，瞬间通过。后来我想明白了，部分防护系统并不是按"浏览器版本新旧"来识别，而是对某一类占比过高的指纹流量做了重点标记。遇到这种场景，切换指纹模式往往比换 IP 更有效。

第二个是 IP 问题。即使指纹完全正确，如果你的出口 IP 在目标站点看来是一个高风险 IP，照样逃不掉 403。这个时候要做的不是反复调 curl_cffi，而是去检查代理。我在测试代理质量时通常会同时校验两个指标：连通延迟和出口匿名度。连通延迟很好理解，出口匿名度则用来确认代理是否会把你的真实 IP 暴露在 X-Forwarded-For 等字段里。

第三个是文件校验。图片下载回来之后打不开，或者打开是一张空白图，这个情况我碰过。最稳妥的做法是下载完成后校验文件头部。JPEG 的前三个字节是FF D8 FF，PNG 的前八个字节是固定的签名，只要头部对得上，基本可以断定文件完整。如果发现文件损坏，多半是写入中断或者响应本身就异常，这时候把文件删掉重新下载即可。

6.2 抓包对比：如何验证指纹是否生效

遇到"指纹配了但还是 403"的情况，最有效的排查手段就是抓包。我常用的工具有 Wireshark 和浏览器开发者工具自带的功能。当你打开浏览器的开发者工具，切到"网络"标签，任何 HTTPS 请求都有一个"安全"或者"连接"详情，可以看到 TLS 握手的相关参数。用同样的方式对比脚本发出的请求，差异一目了然。

如果条件允许，可以用 Wireshark 抓本机出口流量，或者直接在代理出口抓包。重点看 ClientHello 里的三块内容：加密套件序列、扩展列表、TLS 版本号。只要这三块和浏览器一致，指纹层面的问题就基本排除了。剩下的 403 大概率是 IP 或者行为层的问题。

抓包对比这个方法的价值在于，它能帮你把"看起来没问题"变成"确凿地没问题"。我以前调反爬时最容易犯的错，就是凭感觉认为 headers 对了、指纹对了，结果还是 403，绕来绕去走了好多弯路。后来装了抓包工具，每一步偏差都能定位到具体字段，效率提升非常明显。

6.3 踩坑经验：别陷入参数堆叠的怪圈

最后分享一个我在项目带教时经常说的经验，也是我自己当初交过的学费：排查 403 时，不要一步步盲目堆参数。很多人一看 403，就疯狂加 headers、换代理、换指纹，把所有能想到的参数一次性都加上，结果问题不但没解决，反而连排查方向都丢了。

正确的排查顺序应该是：

1. 先把"裸请求"的响应打印出来，看返回体里的错误信息，有些站点的 403 页面会直接写明拒绝理由。
2. 确认自己的指纹和出网 IP 是否正常，两者分开测试，不要混在一起。
3. 检查会话状态，是不是因为没有 Cookie 导致被拦截。
4. 最后才是调整 headers、添加延迟、换代理、降并发。

这样一层层排下去，问题出在哪一层，就在哪一层解决。跳过前面直接堆参数的坏习惯戒掉了，排查周期会缩短一半以上。

我个人还有一个习惯，就是把常用的请求配置写成一个可复用的函数，统一管理指纹、超时、重试和代理。这样不管项目怎么换，配置逻辑都是一套，出问题时排查起来也比较方便。

7. 写在最后：一条更稳定的爬虫研发路径

回到最初的问题：Cloudflare 403 盾真的难缠吗？刚接触的时候确实会觉得无从下手，因为传统的 requests 方案在 TLS 指纹这一关就输了。但理解了指纹识别的原理之后，你会发现 curl_cffi 给出的是一条非常清晰的路径——不用逆向、不用破解，只需要让脚本在底层协议层面表现得和浏览器一致，就能跨过大部分 403 门槛。

根据我个人的实操体会，curl_cffi 这类工具真正厉害的地方不只是"能解决 403"，而是它把爬虫开发的底层技术选型往前推了一大步。以前我们做采集，遇到反爬只能用浏览器渲染、打码平台、代理池这些重型工具；现在有了一款轻量的、可以精确控制客户端指纹的 HTTP 客户端，很多原本复杂的项目，一行参数就搞定了。而且它的 API 设计和 requests 很接近，迁移成本极低，这也是我特别愿意在团队里推广它的原因。

最后再分享一个经验：爬虫项目里，真正让程序稳定的不是某一个单点技巧，而是一套包含指纹模拟、会话管理、频率控制、异常重试、日志监控在内的完整工程体系。无论你以后遇到的是 403、验证码、还是 JS 脚本加密，只要把底层结构搭好，上层再怎么变化，你都有足够的底气去应对。希望这篇文章能帮你少走一些弯路，少加几个无用的请求头。