最近接了个跨境数据采集的活跑到第三步就卡住了requests 头部伪装得严严实实cookie 也仔细核对过UA 换成了最新版 Chrome可对面那个海外电商平台就像长了眼睛一样每次请求都甩给我一个 403。我一度以为是 IP 被拉黑换了代理还是不行最后抓包对比才发现问题根本不在 HTTP 层而在 TLS 握手阶段——我的客户端指纹在服务端眼里等于在大街上举着“我是脚本”的牌子。这个案例不是个例。现在稍微正规一点的防护系统早就不只看 User-Agent 和 header 了。它们会通过 JA3/JA4 指纹识别你的 TLS 客户端特征判断你是真浏览器还是代码在跑。这篇文章我就把这套东西彻底拆开讲清楚JA3/JA4 到底是什么、为什么 Python 默认请求库容易中招、以及几种经过实战验证的 TLS 指纹伪装方案附完整可复现代码。适合爬虫开发、接口联调、网络分析爱好者参考。1. 从 403 说起反爬到底在拦什么1.1 你的 requests 到底哪里“一眼假”很多人有个误解只要把 Header 里的 User-Agent、Accept、Referer 全模仿一遍服务端就认不出你是脚本了。这在五年前还行现在早就不灵了。真正暴露身份的不是这些明面上的字段而是 TCP 连接建立之后、HTTP 请求发出之前的 TLS 握手过程。你可以把 TLS 握手理解成两个人见面时的“寒暄”。浏览器和服务器会先互相确认你支持什么加密方式、你认识哪些扩展协议、你偏好哪种椭圆曲线、你最高能用到哪个 TLS 版本。这些信息按固定顺序拼在一起就会形成一个独特的“指纹”。就像人的声纹一样Chrome 发出来的是一套组合Firefox 是另一套组合而 Python requests 基于 OpenSSL/urllib3 发出来的又是完全不同的组合。服务端只需要在收到 Client Hello 时把这个指纹算出来跟已知的浏览器指纹库对比一下。匹配不上直接就当成异常流量处理。这时候你 Header 伪装得再完美都没用因为指纹在更底层的 TLS 层就已经暴露了。我见过很多人排查 403 时第一反应是换代理、换 IP、加 cookie折腾一整天也没解决。实际上只要抓个包看一眼 Client Hello对比一下已知的浏览器 JA3 指纹问题立刻就能定位。1.2 JA3 指纹到底是怎么生成的JA3 是 2017 年由 Salesforce 的研究人员提出的一种 TLS 客户端指纹识别方法。它的原理并不复杂把 TLS 握手第一阶段 Client Hello 里的几个关键字段提取出来按固定顺序拼接再做一次 MD5 哈希得到一串 32 位的十六进制字符串。具体拼接顺序是这样TLS 版本号如 771 代表 TLS 1.2客户端支持的密码套件列表按 Client Hello 中的顺序客户端支持的扩展类型列表支持的椭圆曲线列表椭圆曲线点格式列表把这些字段用逗号连接最后对整串做 MD5结果就是 JA3 指纹。给你看一个实际计算的 Python 例子方便你理解整个流程import hashlib import struct def extract_ja3(tls_client_hello_hex): # 此处是从十六进制报文里解析 ClientHello 的简化示例 # 真实场景建议用 pyshark / tshark 直接解析 pcap data bytes.fromhex(tls_client_hello_hex) # 跳过 Record Layer 头(5字节) Handshake 头(4字节) # 剩下的就是 ClientHello 内容这里省略复杂解析细节 # 实际解析需要处理版本(2字节)、Random(32字节)、 # SessionID、Cipher Suites、Compression Methods、Extensions # 伪代码流程 # 1. 读取 TLS version # 2. 读取 cipher_suites先取长度2字节再按2字节拆分成ID列表 # 3. 读取 extensions先取长度2字节再逐个解析type # 4. 如果是 supported_groups 扩展解析其中的曲线ID # 5. 如果是 ec_point_formats 扩展解析点格式列表 # 拼接字符串示例真实解析后得到 ja3_str 771,4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172,0-23-65281-10-11-35-16-5-13-18-51-45-43-27-21,29-23-24-25-256-257-258,0 return hashlib.md5(ja3_str.encode()).hexdigest() # Chrome 122 在常见环境下的 JA3 指纹形如: # cd08e31494f9531f560d64c695473da9 # 不同系统/版本会有差异建议自己抓真浏览器包计算一次作为基准注意同一个浏览器在不同操作系统、不同版本下密码套件列表和扩展列表都会有细微差异所以指纹也不是完全固定的。比如 Chrome 120 和 Chrome 124 的 JA3 就不一样Windows 和 macOS 下的 Chrome 也不完全一样。这也是为什么防护系统需要维护一个庞大的指纹库而不是写死几个哈希值。1.3 JA4 指纹的演进逻辑JA3 虽然好用但存在明显缺陷它的拼接格式是公开的攻击者完全可以手工构造一个 Client Hello让 JA3 哈希精确等于某个浏览器的值。说白了JA3 只能证明“你的 TLS 参数组合接近某个浏览器”但无法防止有人照着模板伪造。2023 年左右业内提出了 JA4 指纹方案。它不是简单对字段做 MD5而是用一种更结构化、更“可读”的编码方式把 TLS 握手的特征分为多个维度比如 TLS 版本、加密策略、扩展特征、密码套件特征、ALPN 协议等。JA4 的格式看起来像这样t13d1516h2_8daaf6152771_02713d6af862三段式结构第一段表示 TLS 版本和加密策略第二段是扩展列表的哈希摘要第三段是密码套件特征的哈希摘要。相比 JA3 的“一把梭”式哈希JA4 给服务端提供了更细的比对维度。比如两份 Client Hello 的 JA3 恰好碰撞了但 JA4 的第二段扩展差异很大照样能区分出来。对爬虫开发者来说JA4 意味着单纯“模拟某个版本的 Chrome”可能不够了还得考虑 TLS 扩展的顺序、数量、以及字段的具体编码方式。这也就是为什么我不推荐自己手工造轮子去拼 Client Hello直接用成熟封装方案会更稳。2. 伪装 TLS 指纹的方案选型2.1 手工修改 ssl context 为什么不够先给一个最直观的尝试方案Python 的 ssl 模块允许你手动设置密码套件比如这样import ssl import socket context ssl.create_default_context() context.set_ciphersuites( TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384: TLS_CHACHA20_POLY1305_SHA256 ) # 再尝试启用 ALPN 等 context.set_alpn_protocols([http/1.1, h2]) with socket.create_connection((example.com, 443)) as raw: with context.wrap_socket(raw, server_hostnameexample.com) as ssock: print(ssock.version())这么做确实能改变一部分特征但问题是浏览器的 Client Hello 远不止“密码套件”这一个维度。扩展的顺序、扩展里携带的具体参数、supported_groups 的椭圆曲线列表、key_share 扩展里临时公钥的长度甚至 Client Hello 里那个 GREASE 随机值全部会参与指纹计算。靠 ssl 模块手工微调你只能改到五六成相似很难完全复刻 Chrome 的完整骨架。我个人的判断标准是如果目标站点只是普通防护手工调 ssl 可能就够用了但如果遇到上了 JA4 或者严格指纹库的站点手工方案就是给自己挖坑。与其花两天时间研究 TLS 协议细节不如直接用现成的模拟方案。2.2 常见的替代方案横向对比目前社区里用得比较多的方案有这么几类方案原理优点缺点适合场景curl_cffi封装 libcurl支持 impersonate 参数API 接近 requests几乎无缝替换同时模拟 TLS 和 HTTP2 指纹需要系统有对应动态库但 pip 安装一般能自动解决Python 爬虫首选tls-client基于 Go 实现的 TLS 客户端内置大量浏览器 Profile配置灵活可自定义 JA3 参数部署简单部分平台需要额外依赖API 设计比较独特需要精细控制指纹的场景pyhttpx专门针对 Chrome 指纹的 Python 库使用简单支持指定浏览器版本更新节奏不一定跟得上新浏览器版本快速验证用curl-impersonate独立命令行工具支持 Chrome/Safari/Firefox impersonate不依赖 Python适合 shell 脚本和调试不能在 Python 进程里直接调用非 Python 技术栈这里我要多说一句curl_cffi 是我目前最常用的方案因为它不只是改了 User-Agent而是通过底层绑定 curl 的实现把 Client Hello 的密码套件顺序、扩展顺序、ALPN、HTTP2 指纹全部按浏览器模板重放了。你在使用层面根本感知不到底层发生了什么但服务端看到的就不再是“Python 脚本”而是一个“标准 Chrome”。2.3 为什么这些库能模拟“真实浏览器指纹”核心原因是这些库不是“猜测”浏览器指纹而是把真实浏览器的 Client Hello 完整抓下来然后按模板复刻。你可以理解成有人拿了一个真实 Chrome 的 TLS 握手全过程把它变成了一个可复用的“动作模板”。具体到实现层级curl_cffi 底层通过 curl-impersonate 的能力绑定了 BoringSSL 或者修改过的 OpenSSL让密码套件的排列顺序、扩展字段的生成逻辑都和 Chrome 保持一致。tls-client 则是直接用 Go 重写了一套 TLS 栈通过 Profile 机制预置了不同浏览器的参数。这比“改几个 header”要靠谱得多。因为 TLS 握手是二进制协议层面的东西只要有一个字节的顺序和真实浏览器不一致指纹就会变。而这些库帮你把整条链路的细节都处理好了你在应用层只需要指定一个impersonatechrome124剩下的事它全包了。3. 核心实操三种方式实现 TLS 指纹伪装3.1 准备环境建议使用 Python 3.9 以上版本。我测试时用的是 3.10curl_cffi、tls-client、pyhttpx 这三个库都能正常安装。pip install curl_cffi tls-client pyhttpx如果有网络环境限制导致 pip 安装失败可以先装依赖库再重试。另外提醒一句curl_cffi 的版本迭代比较快隔几个月就会把新版 Chrome 指纹放进去所以尽量保持最新版本否则你用impersonatechrome124时可能提示该版本不可用。3.2 最快上手的 curl_cffi 方案curl_cffi 的 API 设计得非常接近 requests如果你有 requests 使用经验几乎零成本迁移。下面是一个最简单的例子from curl_cffi import requests resp requests.get( https://example.com, impersonatechrome124, timeout15 ) print(resp.status_code) print(resp.text[:200])第一次跑通这个例子之后你会明显感觉到原本 requests 直连直接 403 的站点curl_cffi 用impersonate参数请求就能正常返回 200。这个体验上的差异就是 TLS 指纹伪装的效果。如果是要保持登录态并且多接口请求建议用 Session 模式from curl_cffi import requests session requests.Session() # 首次请求建立 cookie resp session.get(https://example.com/login, impersonatechrome124) # 后续请求自动携带 cookie resp2 session.get( https://example.com/api/data, impersonatechrome124, headers{ Referer: https://example.com/login } ) print(resp2.status_code)session 会帮你自动管理 cookie和 requests.Session 的用法几乎一样。需要走代理时也很简单直接给 proxies 参数proxies { http: http://127.0.0.1:7890, https: http://127.0.0.1:7890, } resp session.get( https://example.com, impersonatechrome124, proxiesproxies )3.3 更细粒度的 tls-client 方案tls-client 的 API 和 requests 差别比较大但它支持自定义 Profile适合需要精细控制指纹的场景。最简单的用法是这样import tls_client session tls_client.Session( client_profilechrome_110, random_tls_extension_orderTrue ) resp session.get(https://example.com) print(resp.status_code)client_profile参数指定了伪装目标random_tls_extension_order可以在保持指纹簇的前提下随机调整扩展顺序这会让每次请求的 JA3 在允许范围内略有变化减少被关联的风险。如果你连底层 JA3 参数都要手动控制tls-client 也支持传自定义 JA3 字符串ja3 769,4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172,0-23-65281-10-11-35-16-5-13-18-51-45-43-27-21,29-23-24-25-256-257-258,0 session tls_client.Session( ja3_stringja3, h2_settings{ HEADER_TABLE_SIZE: 65536, MAX_CONCURRENT_STREAMS: 1000, INITIAL_WINDOW_SIZE: 6291456, MAX_HEADER_LIST_SIZE: 262144 }, h2_settings_order[ HEADER_TABLE_SIZE, MAX_CONCURRENT_STREAMS, INITIAL_WINDOW_SIZE, MAX_HEADER_LIST_SIZE ], supported_versions[GREASE, 1.3, 1.2], key_share_curves[23, 24, 25], global_extension_order[0, 23, 65281, 10, 11, 35, 16, 5, 13, 18, 51, 45, 43, 27, 21] )这种玩法适合你手里已经有一份抓包得到的真实 Chrome JA3 数据想完全照着复刻的情况。我建议初学者先去理解第 3.4 节的验证方法等你能看懂抓包数据了再考虑手动定制。3.4 验证指纹是否真的伪装成功了代码写完不能光看“能返回 200”就以为万事大吉。严格的做法是抓包对比 JA3/JA4。本地验证时最简单的方法是用 tcpdump 抓 TLS 包然后用 tshark 解析出 Client Hello 字段。先抓包sudo tcpdump -i lo0 -w client_hello.pcap port 443在另一个终端发起请求然后用 tshark 提取 JA3 所需字段tshark -r client_hello.pcap -Y tls.handshake.type 1 -T fields \ -e tls.handshake.version \ -e tls.handshake.ciphersuite \ -e tls.handshake.extensions.type \ -e tls.handshake.extensions.supported_group \ -e tls.handshake.extensions.supported_point_format这里的输出就是计算 JA3 需要的原始数据。你可以写个小脚本拼接并计算 MD5也可以搜网上的 JA3 计算器。把这串哈希和你真实浏览器抓包计算出的哈希对比一下如果一致说明伪装生效。我机器上跑出来的典型对比是这样请求方式JA3 特征表现requests套件列表短扩展顺序固定和浏览器差异明显curl_cffi impersonatechrome124套件列表、扩展顺序、曲线列表都和 Chrome 一致tls-client chrome_110指纹整体接近 Chrome但需验证 HTTP2 指纹建议你把“抓包-计算-对比”这三个步骤固化成一个本地测试流程。不要等线上 403 了再去翻日志而是在本地先把指纹验证跑通再上线使用。这一步真的能省掉大量排查时间。4. 常见问题与避坑技巧4.1 TLS 伪装成功后还是返回 403这是我被问得最多的问题。很多读者照着教程改完代码发现目标站点依然 403。先说结论TLS 指纹只是第一道门槛后面还有 HTTP2 指纹、IP 信誉库、行为检测、JS 验证等多道关卡。最典型的坑是只处理了 TLS没有处理 HTTP2 指纹。Chrome 在建立 HTTPS 连接之后会通过 HTTP2 的 SETTINGS 帧、HEADERS 帧顺序、伪头部字段大小写等细节继续暴露自己的身份。如果这些细节和真实浏览器对不上服务端一样能判断你不是 Chrome。解决方法是优先使用 curl_cffi 这类同时模拟 TLS 和 HTTP2 指纹的库而不要自己拼装 HTTP2 请求。另外如果请求频率过高、目标站点对某个 IP 段的风控特别严即使指纹伪装成功也可能因为 IP 信誉度低而被拦截。这时候要优先排查是否是频率问题可以在连续请求之间加随机延时并确保代理 IP 的稳定性。还有一个容易忽略的点某些站点会在首页下发一段 JS 挑战脚本等你的客户端执行完拿到合法 cookie 之后才会放行后续请求。这类防护跟 TLS 指纹无关纯靠 requests 直接请求是过不去的需要配合一个能执行 JS 的环境来做处理。4.2 握手报错或版本不匹配如果你看到这样的报错SSLError: [SSL: WRONG_VERSION_NUMBER] wrong version number大概率是因为目标站点根本不在 443 端口或者服务端强制要求 TLS 1.3 而你当前用的 Profile 只支持到 1.2。排查思路分两步第一步确认目标站点完整支持 HTTPS且端口真的对外开放。用浏览器直接访问一次如果浏览器能开而脚本报错说明是脚本的问题如果浏览器也开不了说明是目标站点的问题。第二步切换 Profile 试试。curl_cffi 里可以换不同的 Chrome 版本或者直接试 Firefox、Safari 的 impersonate。tls-client 里则可以调整supported_versions参数把1.3和1.2都加进去。另外如果你本机的 OpenSSL 版本过旧可能导致部分新密码套件无法使用。这种情况建议升级 Python 到新版本或者装一个带较新 OpenSSL 的发行版。实测下来Python 3.10 的 OpenSSL 版本基本够用。4.3 请求能通但容易被识别有些时候你的请求能返回数据但只要一深入访问比如执行搜索、加购物车等操作马上触发验证。这类问题通常不是 TLS 指纹没伪装好而是行为特征太明显。常见的反面例子有单 IP 每秒发几十个请求、请求间隔完全均匀、访问路径固定不变、从不加载静态资源。真实浏览器用户绝不会这么“准时”。我在做采集任务时会在请求之间加入随机抖动延迟并且模拟先访问首页、再访问列表页、最后进详情页的顺序。频率控制在目标站点可接受范围内比单纯伪装指纹重要得多。建议你在开发阶段就养成习惯所有请求统一走一个底层函数里面预留随机延迟、重试机制、请求头轮换的接口。这样后面被风控时调整成本会低很多。4.4 合规边界这个技术本身是中立的能力就像一把工具刀可以用于正当的接口调试和自动化测试也可能被用来做违规的数据采集。我在任何案例里都建议只在你拥有授权或有明确合法依据的站点上使用。开发调试阶段可以拿自己的测试服务器做实验真正做采集项目之前先仔细看一下目标平台的条款和政策。遵守目标站点的 robots 规则和服务条款、控制合理的请求频率、不以绕过对方明确禁止的技术措施为目的——这不仅是合规要求也是维持这个技术生态能长期良性发展的基础。5. 进阶探索从 JA3 到 HTTP2 指纹再到整体对抗5.1 HTTP2 指纹是藏在 TLS 后面的下一道线很多站点在 TLS 指纹一致后依然能看出访问者不是浏览器秘密就在 HTTP2 层。HTTP2 协议里客户端和服务器通过 SETTINGS 帧进行参数协商而 Chrome、Firefox、Edge 的 SETTINGS 默认值都不一样。更关键的是请求头在 HTTP2 帧里的发送顺序、首字母大小写、伪头字段排列每款浏览器都有自己固定的习惯。这里有一个真实的例子同样是一组请求头Chrome 可能发送的顺序是:method、:authority、:scheme、:path、user-agent、accept而某脚本库发送的是:method、:path、:authority、:scheme、accept、user-agent。后者就算 TLS 指纹伪造成功在 HTTP2 指纹这一步也会被打回原形。像 curl_cffi 这种库之所以推荐正是因为它把 HTTP2 指纹也一起处理了。你可以通过指定impersonatechrome124让库在内部同时重放 Chrome 的 HTTP2 参数和行为。用 tls-client 时则需要在 h2_settings、h2_settings_order 里手动配置比较繁琐但控制力更强。5.2 指纹伪装与请求行为结合只靠某一项技术打天下的时代已经过去了。我把这种对抗理解成一个“木桶效应”TLS 指纹、HTTP2 指纹、UA 一致性、行为频率、cookie 生命周期、代理 IP 质量每个维度都决定你的请求是不是会被识别。实际操作中我比较推荐的做法是“组合拳”import time import random from curl_cffi import requests session requests.Session() user_agents [ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36, Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36, Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36, ] def fetch(url): headers { User-Agent: random.choice(user_agents), Accept: text/html,application/xhtmlxml,application/xml;q0.9,image/avif,image/webp,*/*;q0.8, Accept-Language: en-US,en;q0.9, Referer: https://example.com/, } resp session.get( url, headersheaders, impersonatechrome124, timeout15 ) time.sleep(random.uniform(2, 5)) # 随机延迟避免机械感 return resp这套组合里没有哪一项是“银弹”但合在一起可以让你的请求在指纹和表面行为上都更贴近真实用户。5.3 未来指纹技术会怎么变JA3 刚出来时大家觉得已经很厉害了后来出现了 JA4再往后也许会有更复杂的多维指纹。现在已经有团队在研究通过 TLS 证书状态、OCSP 请求、QUIC 指纹等方式做进一步识别。对爬虫开发者来说这意味着不能只盯着某一个库的某个版本去更新而应该持续关注指纹方案的演进及时调整自己的请求链路。好消息是主流开源库的迭代速度也很快。curl_cffi 基本每个大版本都会跟随最新的浏览器指纹发布更新。tls-client 也维护了多种 Profile。只要你养成了“定期更新依赖库”的习惯大部分新指纹特征都能被覆盖到。最后分享一个小技巧我在实际项目中养成了一个习惯每接触一个新的目标站点第一步不是直接写请求代码而是先用真实浏览器打开一次同时在后台抓包保存一份“基准指纹”。然后写一个十几行的小脚本计算这个站点的 TLS 指纹归属、HTTP2 特征、cookie 生成逻辑。等心里有了底数再去写爬虫代码。这个方法帮我避免了很多无谓的返工。有一次遇到一个防护很强的站点我对比基准指纹后发现光模拟 Chrome 还不够它还会检测浏览器渲染环境。我直接在代码里接了一个无头浏览器方案让 TLS 指纹和浏览器环境都保持一致问题就迎刃而解了。记住一点403 并不可怕可怕的是连“它为什么拒绝你”都不知道。把 TLS 指纹这东西搞明白之后你会发现反爬对抗突然变得清晰很多——至少你知道下一刀该往哪儿切了。 
长河君 · 2026/10/19 4:53:11 · 阅读 1.2k TLS指纹伪装实战：破解JA3/JA4反爬，告别403
最近接了个跨境数据采集的活跑到第三步就卡住了requests 头部伪装得严严实实cookie 也仔细核对过UA 换成了最新版 Chrome可对面那个海外电商平台就像长了眼睛一样每次请求都甩给我一个 403。我一度以为是 IP 被拉黑换了代理还是不行最后抓包对比才发现问题根本不在 HTTP 层而在 TLS 握手阶段——我的客户端指纹在服务端眼里等于在大街上举着“我是脚本”的牌子。这个案例不是个例。现在稍微正规一点的防护系统早就不只看 User-Agent 和 header 了。它们会通过 JA3/JA4 指纹识别你的 TLS 客户端特征判断你是真浏览器还是代码在跑。这篇文章我就把这套东西彻底拆开讲清楚JA3/JA4 到底是什么、为什么 Python 默认请求库容易中招、以及几种经过实战验证的 TLS 指纹伪装方案附完整可复现代码。适合爬虫开发、接口联调、网络分析爱好者参考。1. 从 403 说起反爬到底在拦什么1.1 你的 requests 到底哪里“一眼假”很多人有个误解只要把 Header 里的 User-Agent、Accept、Referer 全模仿一遍服务端就认不出你是脚本了。这在五年前还行现在早就不灵了。真正暴露身份的不是这些明面上的字段而是 TCP 连接建立之后、HTTP 请求发出之前的 TLS 握手过程。你可以把 TLS 握手理解成两个人见面时的“寒暄”。浏览器和服务器会先互相确认你支持什么加密方式、你认识哪些扩展协议、你偏好哪种椭圆曲线、你最高能用到哪个 TLS 版本。这些信息按固定顺序拼在一起就会形成一个独特的“指纹”。就像人的声纹一样Chrome 发出来的是一套组合Firefox 是另一套组合而 Python requests 基于 OpenSSL/urllib3 发出来的又是完全不同的组合。服务端只需要在收到 Client Hello 时把这个指纹算出来跟已知的浏览器指纹库对比一下。匹配不上直接就当成异常流量处理。这时候你 Header 伪装得再完美都没用因为指纹在更底层的 TLS 层就已经暴露了。我见过很多人排查 403 时第一反应是换代理、换 IP、加 cookie折腾一整天也没解决。实际上只要抓个包看一眼 Client Hello对比一下已知的浏览器 JA3 指纹问题立刻就能定位。1.2 JA3 指纹到底是怎么生成的JA3 是 2017 年由 Salesforce 的研究人员提出的一种 TLS 客户端指纹识别方法。它的原理并不复杂把 TLS 握手第一阶段 Client Hello 里的几个关键字段提取出来按固定顺序拼接再做一次 MD5 哈希得到一串 32 位的十六进制字符串。具体拼接顺序是这样TLS 版本号如 771 代表 TLS 1.2客户端支持的密码套件列表按 Client Hello 中的顺序客户端支持的扩展类型列表支持的椭圆曲线列表椭圆曲线点格式列表把这些字段用逗号连接最后对整串做 MD5结果就是 JA3 指纹。给你看一个实际计算的 Python 例子方便你理解整个流程import hashlib import struct def extract_ja3(tls_client_hello_hex): # 此处是从十六进制报文里解析 ClientHello 的简化示例 # 真实场景建议用 pyshark / tshark 直接解析 pcap data bytes.fromhex(tls_client_hello_hex) # 跳过 Record Layer 头(5字节) Handshake 头(4字节) # 剩下的就是 ClientHello 内容这里省略复杂解析细节 # 实际解析需要处理版本(2字节)、Random(32字节)、 # SessionID、Cipher Suites、Compression Methods、Extensions # 伪代码流程 # 1. 读取 TLS version # 2. 读取 cipher_suites先取长度2字节再按2字节拆分成ID列表 # 3. 读取 extensions先取长度2字节再逐个解析type # 4. 如果是 supported_groups 扩展解析其中的曲线ID # 5. 如果是 ec_point_formats 扩展解析点格式列表 # 拼接字符串示例真实解析后得到 ja3_str 771,4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172,0-23-65281-10-11-35-16-5-13-18-51-45-43-27-21,29-23-24-25-256-257-258,0 return hashlib.md5(ja3_str.encode()).hexdigest() # Chrome 122 在常见环境下的 JA3 指纹形如: # cd08e31494f9531f560d64c695473da9 # 不同系统/版本会有差异建议自己抓真浏览器包计算一次作为基准注意同一个浏览器在不同操作系统、不同版本下密码套件列表和扩展列表都会有细微差异所以指纹也不是完全固定的。比如 Chrome 120 和 Chrome 124 的 JA3 就不一样Windows 和 macOS 下的 Chrome 也不完全一样。这也是为什么防护系统需要维护一个庞大的指纹库而不是写死几个哈希值。1.3 JA4 指纹的演进逻辑JA3 虽然好用但存在明显缺陷它的拼接格式是公开的攻击者完全可以手工构造一个 Client Hello让 JA3 哈希精确等于某个浏览器的值。说白了JA3 只能证明“你的 TLS 参数组合接近某个浏览器”但无法防止有人照着模板伪造。2023 年左右业内提出了 JA4 指纹方案。它不是简单对字段做 MD5而是用一种更结构化、更“可读”的编码方式把 TLS 握手的特征分为多个维度比如 TLS 版本、加密策略、扩展特征、密码套件特征、ALPN 协议等。JA4 的格式看起来像这样t13d1516h2_8daaf6152771_02713d6af862三段式结构第一段表示 TLS 版本和加密策略第二段是扩展列表的哈希摘要第三段是密码套件特征的哈希摘要。相比 JA3 的“一把梭”式哈希JA4 给服务端提供了更细的比对维度。比如两份 Client Hello 的 JA3 恰好碰撞了但 JA4 的第二段扩展差异很大照样能区分出来。对爬虫开发者来说JA4 意味着单纯“模拟某个版本的 Chrome”可能不够了还得考虑 TLS 扩展的顺序、数量、以及字段的具体编码方式。这也就是为什么我不推荐自己手工造轮子去拼 Client Hello直接用成熟封装方案会更稳。2. 伪装 TLS 指纹的方案选型2.1 手工修改 ssl context 为什么不够先给一个最直观的尝试方案Python 的 ssl 模块允许你手动设置密码套件比如这样import ssl import socket context ssl.create_default_context() context.set_ciphersuites( TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384: TLS_CHACHA20_POLY1305_SHA256 ) # 再尝试启用 ALPN 等 context.set_alpn_protocols([http/1.1, h2]) with socket.create_connection((example.com, 443)) as raw: with context.wrap_socket(raw, server_hostnameexample.com) as ssock: print(ssock.version())这么做确实能改变一部分特征但问题是浏览器的 Client Hello 远不止“密码套件”这一个维度。扩展的顺序、扩展里携带的具体参数、supported_groups 的椭圆曲线列表、key_share 扩展里临时公钥的长度甚至 Client Hello 里那个 GREASE 随机值全部会参与指纹计算。靠 ssl 模块手工微调你只能改到五六成相似很难完全复刻 Chrome 的完整骨架。我个人的判断标准是如果目标站点只是普通防护手工调 ssl 可能就够用了但如果遇到上了 JA4 或者严格指纹库的站点手工方案就是给自己挖坑。与其花两天时间研究 TLS 协议细节不如直接用现成的模拟方案。2.2 常见的替代方案横向对比目前社区里用得比较多的方案有这么几类方案原理优点缺点适合场景curl_cffi封装 libcurl支持 impersonate 参数API 接近 requests几乎无缝替换同时模拟 TLS 和 HTTP2 指纹需要系统有对应动态库但 pip 安装一般能自动解决Python 爬虫首选tls-client基于 Go 实现的 TLS 客户端内置大量浏览器 Profile配置灵活可自定义 JA3 参数部署简单部分平台需要额外依赖API 设计比较独特需要精细控制指纹的场景pyhttpx专门针对 Chrome 指纹的 Python 库使用简单支持指定浏览器版本更新节奏不一定跟得上新浏览器版本快速验证用curl-impersonate独立命令行工具支持 Chrome/Safari/Firefox impersonate不依赖 Python适合 shell 脚本和调试不能在 Python 进程里直接调用非 Python 技术栈这里我要多说一句curl_cffi 是我目前最常用的方案因为它不只是改了 User-Agent而是通过底层绑定 curl 的实现把 Client Hello 的密码套件顺序、扩展顺序、ALPN、HTTP2 指纹全部按浏览器模板重放了。你在使用层面根本感知不到底层发生了什么但服务端看到的就不再是“Python 脚本”而是一个“标准 Chrome”。2.3 为什么这些库能模拟“真实浏览器指纹”核心原因是这些库不是“猜测”浏览器指纹而是把真实浏览器的 Client Hello 完整抓下来然后按模板复刻。你可以理解成有人拿了一个真实 Chrome 的 TLS 握手全过程把它变成了一个可复用的“动作模板”。具体到实现层级curl_cffi 底层通过 curl-impersonate 的能力绑定了 BoringSSL 或者修改过的 OpenSSL让密码套件的排列顺序、扩展字段的生成逻辑都和 Chrome 保持一致。tls-client 则是直接用 Go 重写了一套 TLS 栈通过 Profile 机制预置了不同浏览器的参数。这比“改几个 header”要靠谱得多。因为 TLS 握手是二进制协议层面的东西只要有一个字节的顺序和真实浏览器不一致指纹就会变。而这些库帮你把整条链路的细节都处理好了你在应用层只需要指定一个impersonatechrome124剩下的事它全包了。3. 核心实操三种方式实现 TLS 指纹伪装3.1 准备环境建议使用 Python 3.9 以上版本。我测试时用的是 3.10curl_cffi、tls-client、pyhttpx 这三个库都能正常安装。pip install curl_cffi tls-client pyhttpx如果有网络环境限制导致 pip 安装失败可以先装依赖库再重试。另外提醒一句curl_cffi 的版本迭代比较快隔几个月就会把新版 Chrome 指纹放进去所以尽量保持最新版本否则你用impersonatechrome124时可能提示该版本不可用。3.2 最快上手的 curl_cffi 方案curl_cffi 的 API 设计得非常接近 requests如果你有 requests 使用经验几乎零成本迁移。下面是一个最简单的例子from curl_cffi import requests resp requests.get( https://example.com, impersonatechrome124, timeout15 ) print(resp.status_code) print(resp.text[:200])第一次跑通这个例子之后你会明显感觉到原本 requests 直连直接 403 的站点curl_cffi 用impersonate参数请求就能正常返回 200。这个体验上的差异就是 TLS 指纹伪装的效果。如果是要保持登录态并且多接口请求建议用 Session 模式from curl_cffi import requests session requests.Session() # 首次请求建立 cookie resp session.get(https://example.com/login, impersonatechrome124) # 后续请求自动携带 cookie resp2 session.get( https://example.com/api/data, impersonatechrome124, headers{ Referer: https://example.com/login } ) print(resp2.status_code)session 会帮你自动管理 cookie和 requests.Session 的用法几乎一样。需要走代理时也很简单直接给 proxies 参数proxies { http: http://127.0.0.1:7890, https: http://127.0.0.1:7890, } resp session.get( https://example.com, impersonatechrome124, proxiesproxies )3.3 更细粒度的 tls-client 方案tls-client 的 API 和 requests 差别比较大但它支持自定义 Profile适合需要精细控制指纹的场景。最简单的用法是这样import tls_client session tls_client.Session( client_profilechrome_110, random_tls_extension_orderTrue ) resp session.get(https://example.com) print(resp.status_code)client_profile参数指定了伪装目标random_tls_extension_order可以在保持指纹簇的前提下随机调整扩展顺序这会让每次请求的 JA3 在允许范围内略有变化减少被关联的风险。如果你连底层 JA3 参数都要手动控制tls-client 也支持传自定义 JA3 字符串ja3 769,4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172,0-23-65281-10-11-35-16-5-13-18-51-45-43-27-21,29-23-24-25-256-257-258,0 session tls_client.Session( ja3_stringja3, h2_settings{ HEADER_TABLE_SIZE: 65536, MAX_CONCURRENT_STREAMS: 1000, INITIAL_WINDOW_SIZE: 6291456, MAX_HEADER_LIST_SIZE: 262144 }, h2_settings_order[ HEADER_TABLE_SIZE, MAX_CONCURRENT_STREAMS, INITIAL_WINDOW_SIZE, MAX_HEADER_LIST_SIZE ], supported_versions[GREASE, 1.3, 1.2], key_share_curves[23, 24, 25], global_extension_order[0, 23, 65281, 10, 11, 35, 16, 5, 13, 18, 51, 45, 43, 27, 21] )这种玩法适合你手里已经有一份抓包得到的真实 Chrome JA3 数据想完全照着复刻的情况。我建议初学者先去理解第 3.4 节的验证方法等你能看懂抓包数据了再考虑手动定制。3.4 验证指纹是否真的伪装成功了代码写完不能光看“能返回 200”就以为万事大吉。严格的做法是抓包对比 JA3/JA4。本地验证时最简单的方法是用 tcpdump 抓 TLS 包然后用 tshark 解析出 Client Hello 字段。先抓包sudo tcpdump -i lo0 -w client_hello.pcap port 443在另一个终端发起请求然后用 tshark 提取 JA3 所需字段tshark -r client_hello.pcap -Y tls.handshake.type 1 -T fields \ -e tls.handshake.version \ -e tls.handshake.ciphersuite \ -e tls.handshake.extensions.type \ -e tls.handshake.extensions.supported_group \ -e tls.handshake.extensions.supported_point_format这里的输出就是计算 JA3 需要的原始数据。你可以写个小脚本拼接并计算 MD5也可以搜网上的 JA3 计算器。把这串哈希和你真实浏览器抓包计算出的哈希对比一下如果一致说明伪装生效。我机器上跑出来的典型对比是这样请求方式JA3 特征表现requests套件列表短扩展顺序固定和浏览器差异明显curl_cffi impersonatechrome124套件列表、扩展顺序、曲线列表都和 Chrome 一致tls-client chrome_110指纹整体接近 Chrome但需验证 HTTP2 指纹建议你把“抓包-计算-对比”这三个步骤固化成一个本地测试流程。不要等线上 403 了再去翻日志而是在本地先把指纹验证跑通再上线使用。这一步真的能省掉大量排查时间。4. 常见问题与避坑技巧4.1 TLS 伪装成功后还是返回 403这是我被问得最多的问题。很多读者照着教程改完代码发现目标站点依然 403。先说结论TLS 指纹只是第一道门槛后面还有 HTTP2 指纹、IP 信誉库、行为检测、JS 验证等多道关卡。最典型的坑是只处理了 TLS没有处理 HTTP2 指纹。Chrome 在建立 HTTPS 连接之后会通过 HTTP2 的 SETTINGS 帧、HEADERS 帧顺序、伪头部字段大小写等细节继续暴露自己的身份。如果这些细节和真实浏览器对不上服务端一样能判断你不是 Chrome。解决方法是优先使用 curl_cffi 这类同时模拟 TLS 和 HTTP2 指纹的库而不要自己拼装 HTTP2 请求。另外如果请求频率过高、目标站点对某个 IP 段的风控特别严即使指纹伪装成功也可能因为 IP 信誉度低而被拦截。这时候要优先排查是否是频率问题可以在连续请求之间加随机延时并确保代理 IP 的稳定性。还有一个容易忽略的点某些站点会在首页下发一段 JS 挑战脚本等你的客户端执行完拿到合法 cookie 之后才会放行后续请求。这类防护跟 TLS 指纹无关纯靠 requests 直接请求是过不去的需要配合一个能执行 JS 的环境来做处理。4.2 握手报错或版本不匹配如果你看到这样的报错SSLError: [SSL: WRONG_VERSION_NUMBER] wrong version number大概率是因为目标站点根本不在 443 端口或者服务端强制要求 TLS 1.3 而你当前用的 Profile 只支持到 1.2。排查思路分两步第一步确认目标站点完整支持 HTTPS且端口真的对外开放。用浏览器直接访问一次如果浏览器能开而脚本报错说明是脚本的问题如果浏览器也开不了说明是目标站点的问题。第二步切换 Profile 试试。curl_cffi 里可以换不同的 Chrome 版本或者直接试 Firefox、Safari 的 impersonate。tls-client 里则可以调整supported_versions参数把1.3和1.2都加进去。另外如果你本机的 OpenSSL 版本过旧可能导致部分新密码套件无法使用。这种情况建议升级 Python 到新版本或者装一个带较新 OpenSSL 的发行版。实测下来Python 3.10 的 OpenSSL 版本基本够用。4.3 请求能通但容易被识别有些时候你的请求能返回数据但只要一深入访问比如执行搜索、加购物车等操作马上触发验证。这类问题通常不是 TLS 指纹没伪装好而是行为特征太明显。常见的反面例子有单 IP 每秒发几十个请求、请求间隔完全均匀、访问路径固定不变、从不加载静态资源。真实浏览器用户绝不会这么“准时”。我在做采集任务时会在请求之间加入随机抖动延迟并且模拟先访问首页、再访问列表页、最后进详情页的顺序。频率控制在目标站点可接受范围内比单纯伪装指纹重要得多。建议你在开发阶段就养成习惯所有请求统一走一个底层函数里面预留随机延迟、重试机制、请求头轮换的接口。这样后面被风控时调整成本会低很多。4.4 合规边界这个技术本身是中立的能力就像一把工具刀可以用于正当的接口调试和自动化测试也可能被用来做违规的数据采集。我在任何案例里都建议只在你拥有授权或有明确合法依据的站点上使用。开发调试阶段可以拿自己的测试服务器做实验真正做采集项目之前先仔细看一下目标平台的条款和政策。遵守目标站点的 robots 规则和服务条款、控制合理的请求频率、不以绕过对方明确禁止的技术措施为目的——这不仅是合规要求也是维持这个技术生态能长期良性发展的基础。5. 进阶探索从 JA3 到 HTTP2 指纹再到整体对抗5.1 HTTP2 指纹是藏在 TLS 后面的下一道线很多站点在 TLS 指纹一致后依然能看出访问者不是浏览器秘密就在 HTTP2 层。HTTP2 协议里客户端和服务器通过 SETTINGS 帧进行参数协商而 Chrome、Firefox、Edge 的 SETTINGS 默认值都不一样。更关键的是请求头在 HTTP2 帧里的发送顺序、首字母大小写、伪头字段排列每款浏览器都有自己固定的习惯。这里有一个真实的例子同样是一组请求头Chrome 可能发送的顺序是:method、:authority、:scheme、:path、user-agent、accept而某脚本库发送的是:method、:path、:authority、:scheme、accept、user-agent。后者就算 TLS 指纹伪造成功在 HTTP2 指纹这一步也会被打回原形。像 curl_cffi 这种库之所以推荐正是因为它把 HTTP2 指纹也一起处理了。你可以通过指定impersonatechrome124让库在内部同时重放 Chrome 的 HTTP2 参数和行为。用 tls-client 时则需要在 h2_settings、h2_settings_order 里手动配置比较繁琐但控制力更强。5.2 指纹伪装与请求行为结合只靠某一项技术打天下的时代已经过去了。我把这种对抗理解成一个“木桶效应”TLS 指纹、HTTP2 指纹、UA 一致性、行为频率、cookie 生命周期、代理 IP 质量每个维度都决定你的请求是不是会被识别。实际操作中我比较推荐的做法是“组合拳”import time import random from curl_cffi import requests session requests.Session() user_agents [ Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36, Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.0.0 Safari/537.36, Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36, ] def fetch(url): headers { User-Agent: random.choice(user_agents), Accept: text/html,application/xhtmlxml,application/xml;q0.9,image/avif,image/webp,*/*;q0.8, Accept-Language: en-US,en;q0.9, Referer: https://example.com/, } resp session.get( url, headersheaders, impersonatechrome124, timeout15 ) time.sleep(random.uniform(2, 5)) # 随机延迟避免机械感 return resp这套组合里没有哪一项是“银弹”但合在一起可以让你的请求在指纹和表面行为上都更贴近真实用户。5.3 未来指纹技术会怎么变JA3 刚出来时大家觉得已经很厉害了后来出现了 JA4再往后也许会有更复杂的多维指纹。现在已经有团队在研究通过 TLS 证书状态、OCSP 请求、QUIC 指纹等方式做进一步识别。对爬虫开发者来说这意味着不能只盯着某一个库的某个版本去更新而应该持续关注指纹方案的演进及时调整自己的请求链路。好消息是主流开源库的迭代速度也很快。curl_cffi 基本每个大版本都会跟随最新的浏览器指纹发布更新。tls-client 也维护了多种 Profile。只要你养成了“定期更新依赖库”的习惯大部分新指纹特征都能被覆盖到。最后分享一个小技巧我在实际项目中养成了一个习惯每接触一个新的目标站点第一步不是直接写请求代码而是先用真实浏览器打开一次同时在后台抓包保存一份“基准指纹”。然后写一个十几行的小脚本计算这个站点的 TLS 指纹归属、HTTP2 特征、cookie 生成逻辑。等心里有了底数再去写爬虫代码。这个方法帮我避免了很多无谓的返工。有一次遇到一个防护很强的站点我对比基准指纹后发现光模拟 Chrome 还不够它还会检测浏览器渲染环境。我直接在代码里接了一个无头浏览器方案让 TLS 指纹和浏览器环境都保持一致问题就迎刃而解了。记住一点403 并不可怕可怕的是连“它为什么拒绝你”都不知道。把 TLS 指纹这东西搞明白之后你会发现反爬对抗突然变得清晰很多——至少你知道下一刀该往哪儿切了。