1. 项目概述当爬虫遇上Cloudflare 5秒盾做爬虫的朋友尤其是搞数据采集的这两年估计没少被Cloudflare的“5秒盾”搞得头疼。你精心写的脚本信心满满地发了个请求结果返回的不是你想要的数据而是一个让你等待5秒的页面页面里还运行着一堆复杂的JavaScript代码用来验证你的浏览器环境是不是“真人”。这个机制业内俗称“5秒盾”或者更正式一点叫“浏览器完整性检查”。它的目的很明确就是要把那些简单的、模拟HTTP请求的爬虫脚本挡在门外只放行真实的浏览器流量。我最近接手了一个数据采集项目目标网站就部署了这套防护。直接用requests库秒弹5秒盾。上Selenium或Playwright模拟浏览器确实能过但资源开销巨大速度慢得像爬对于需要高并发、高效率的采集任务来说基本不可行。于是研究的重点就转向了“补环境”这个方向。简单说就是不再启动一个完整的浏览器而是用Python模拟出一个足够真实的浏览器运行环境包括JS引擎、DOM、BOM、Canvas指纹等让Cloudflare的验证脚本在我们模拟的环境里顺利执行并得出正确的验证结果。网上关于“补环境”的讨论和框架不少但要么过于零散要么只讲原理不给完整实战。这次我决定用Python下一个比较成熟的补环境框架从头到尾彻底撕开这个5秒盾。整个破解过程从发起请求到最终拿到数据我的脚本一共发出了13次HTTP请求。这13次请求每一次都不是多余的它们清晰地勾勒出了Cloudflare验证的完整链条。下面我就把这13次请求的来龙去脉、背后的JS逻辑、以及如何用补环境框架一步步应对做个彻底的解析。你会发现绕过5秒盾本质上是一场对浏览器环境和Cloudflare验证逻辑的深度模仿。2. 核心思路与工具选型为何是补环境框架在决定动手之前我们先理清思路。对抗Cloudflare 5秒盾主流有几种路径浏览器自动化工具如Selenium, Playwright, Puppeteer。这是最“笨”但最可靠的方法因为这就是一个真实的浏览器。缺点也极其明显资源消耗大每个线程/进程都要带一个浏览器实例、速度慢、容易被检测虽然Playwright等可以隐藏自动化特征但开销依旧。使用现成的反反爬虫API服务市面上有一些服务商提供接口你把目标URL给他们他们负责绕过并返回页面数据。这对于商业项目、不想折腾技术的团队是快速方案但需要付费且数据经过第三方有安全与合规考量。逆向JS纯算法还原这是最高阶也是最难的方法。你需要完全逆向Cloudflare的挑战算法通常是不断变化的然后用Python或Go等语言重新实现。这需要顶级的JS逆向功底且维护成本极高因为Cloudflare一更新算法你的破解就可能失效。补环境JS解释器嵌入这是我们本次采用的方法。其核心思想是在Python进程中嵌入一个JavaScript解释器如PyExecJS, js2py或更专业的node_vm2然后精心构造一个与浏览器高度相似的全局对象window,document,navigator等让Cloudflare的验证JS代码在这个模拟环境中运行并计算出正确的答案通常是cf_clearanceCookie的值。为什么选择补环境框架因为它平衡了效率、可靠性和可维护性。它不像纯算法逆向那样脆弱也不像浏览器自动化那样笨重。通过精准地模拟关键环境我们可以在Python层面高效地完成JS计算。本次实战我选择了一个在GitHub上活跃度较高、对Web API模拟比较全面的Python补环境框架为了避嫌这里不直接提具体名字但思路通用。它底层通常基于pyppeteer或playwright的核心协议但剥离了图形界面专注于环境模拟。注意补环境是一个“猫鼠游戏”。Cloudflare会不断升级其检测点因此你使用的补环境框架也需要持续更新。选择社区活跃、更新及时的项目至关重要。3. 环境准备与框架初始化工欲善其事必先利其器。我们的战场是Python所以首先需要一个干净的Python环境。我推荐使用Python 3.8的版本太老的版本可能会遇到依赖库兼容性问题。3.1 创建虚拟环境与安装依赖为了避免污染系统环境第一步永远是创建虚拟环境。# 使用 venv 创建虚拟环境命名为 cf_challenge python -m venv cf_challenge_env # 激活虚拟环境 # Windows: cf_challenge_env\Scripts\activate # Linux/MacOS: source cf_challenge_env/bin/activate激活后你的命令行提示符前会出现(cf_challenge_env)表示已经进入该虚拟环境。接下来安装核心的补环境框架。由于这类框架通常不在PyPI官方仓库或者有特定的安装方式我们需要从GitHub或其他源安装。这里以假设框架名为cf_env_simulator为例请替换为你实际使用的框架名或GitHub地址。# 假设框架在PyPI上 pip install cf_env_simulator # 更常见的是从GitHub安装 pip install githttps://github.com/某个用户名/某个补环境框架.git除了核心框架通常还需要一些辅助库比如用于发送HTTP请求的httpx或aiohttp它们比requests对异步支持更好且更易自定义用于解析HTML的parsel或lxml以及用于处理Cookie的browser_cookie3可选。pip install httpx parsel3.2 补环境框架的初始化与核心配置安装好后我们开始初始化框架。补环境框架的核心是创建一个“浏览器环境”的实例但这个实例没有UI。import asyncio from cf_env_simulator import Simulator # 请替换为实际类名 async def main(): # 1. 初始化模拟器通常可以配置一些参数 # 例如是否启用headless模式虽然无UI但有些框架保留此概念、用户代理、视口大小等 simulator await Simulator.create( headlessTrue, user_agentMozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, viewport{width: 1920, height: 1080} ) # 2. 创建一个新的“页面”上下文。这类似于浏览器打开了一个新标签页。 context await simulator.new_context() # 3. 通常我们需要在这个上下文中注入一些基础的环境补丁。 # 框架一般会提供 page.add_init_script 或类似方法来预先执行一些JS代码 # 用于覆盖或定义 navigator.webdriver, window.chrome 等容易被检测的属性。 await context.add_init_script( Object.defineProperty(navigator, webdriver, { get: () undefined }); window.chrome { runtime: {} }; // 其他需要补的环境变量... ) return simulator, context # 运行异步函数 simulator, context asyncio.run(main())这个初始化过程至关重要它奠定了我们后续所有操作的基础。user_agent要使用常见的、更新的浏览器标识。viewport设置一个常规的桌面分辨率。最重要的是add_init_script中的代码这是补环境的第一步直接抹掉了一些自动化工具留下的明显痕迹。实操心得不同的网站和不同时期的Cloudflare挑战检测点可能不同。上述补丁是基础款。在实际遇到挑战失败时你需要通过分析挑战失败后返回的JS代码或者用真实浏览器执行对比找出还需要补哪些属性。常见的还有navigator.plugins,navigator.languages,Notification.permission,WebGL渲染器等。4. 13次请求全流程解析现在让我们进入最核心的部分看看这13次请求是如何发生的。我将它们分成了几个阶段并用一个表格来总览这样脉络会更清晰。请求序号阶段发起方目标关键载荷/响应目的解析1初始访问我们的脚本目标网站首页返回302重定向或包含5秒盾JS的页面触发Cloudflare防护获取初始挑战页面。2获取挑战我们的脚本重定向后的挑战URL返回一个HTML内含核心验证JS代码及参数拿到需要执行的JavaScript挑战内容。3-10JS环境计算Python补环境框架内部JS引擎执行复杂的算术、字符串操作或生成Canvas指纹在模拟环境中执行挑战JS计算出答案通常是一个长字符串或一组值。11提交答案我们的脚本Cloudflare验证端点携带计算出的答案作为表单数据jschl_vc,pass,jschl_answer等将JS执行的结果提交给Cloudflare进行校验。12验证通过Cloudflare我们的脚本返回302重定向并在Set-Cookie头中设置cf_clearance服务器确认答案正确下发通行证Cookie。13最终访问我们的脚本最初的目标页面返回正常的网站HTML内容携带有效的cf_clearanceCookie成功获取数据。接下来我们分阶段进行详细拆解。4.1 第1-2次请求触发与获取挑战我们的脚本首先向目标网站发起一个普通的GET请求。这看起来和正常浏览器访问无异。import httpx async def fetch_challenge(): target_url https://目标网站.com headers { User-Agent: Mozilla/5.0 ..., # 与模拟器设置一致 Accept: text/html,application/xhtmlxml,application/xml;q0.9,image/webp,*/*;q0.8, Accept-Language: zh-CN,zh;q0.9,en;q0.8, } async with httpx.AsyncClient(follow_redirectsFalse) as client: # 注意不自动跟随重定向 # 请求1: 访问目标URL resp1 await client.get(target_url, headersheaders) print(f第一次请求状态码: {resp1.status_code}) print(f响应头Location: {resp1.headers.get(location)}) # 通常如果触发5秒盾会返回503状态码或者302重定向到一个包含__cf_chl_参数的URL。 if resp1.status_code in [503, 302]: # 获取挑战页面的真实URL。可能是Location头里的也可能是当前URL503时。 challenge_url resp1.headers.get(location) or target_url # 可能需要拼接基础URL if challenge_url.startswith(/): from urllib.parse import urljoin challenge_url urljoin(target_url, challenge_url) # 请求2: 获取挑战页面内容 resp2 await client.get(challenge_url, headersheaders) print(f第二次请求状态码: {resp2.status_code}) # 此时 resp2.text 里就包含了那个著名的“正在验证浏览器”的页面以及核心的JS代码。 return resp2.text, resp2.cookies, challenge_url else: # 如果没有触发5秒盾直接成功了可能性较小 return resp1.text, resp1.cookies, target_url challenge_html, initial_cookies, challenge_url asyncio.run(fetch_challenge())关键点解析follow_redirectsFalse这很重要。Cloudflare经常使用302重定向来引导流量到挑战页面我们需要手动处理这个重定向以捕获中间过程的URL和Cookie。响应内容challenge_html是一个HTML页面里面包含了一个或多个script标签。这些标签里的JS代码就是我们要破解的核心。代码里通常会定义几个关键变量如s,t,chk,k等用于混淆的字符数组。一个非常长的、被混淆的JavaScript函数比如名字叫cf_chl_opt这个函数包含了主要的验证逻辑。一些隐藏的表单字段如jschl_vc,pass它们的值是固定的需要随答案一起提交。一个最终需要计算出的变量比如jschl_answer。4.2 第3-10次请求内部计算解析与执行挑战JS这是最复杂的一步。我们不能直接执行页面里的JS因为它是被严重混淆的而且严重依赖浏览器环境。我们的补环境框架就在这里派上用场。首先我们需要从challenge_html中提取出关键的JS代码和参数。这通常需要一些HTML解析技巧。from parsel import Selector def extract_challenge_data(html): sel Selector(texthtml) # 提取核心的JS脚本内容。通常它在一个具有特定id的script标签里比如 #cf-chl-widget-xxx # 或者包含 cf_chl_opt 函数。 script_text for script in sel.xpath(//script/text()).getall(): if cf_chl_opt in script or jschl_answer in script: script_text script break # 提取隐藏的表单输入值这些是提交答案时必须的。 jschl_vc sel.xpath(//input[namejschl_vc]/value).get() pass_value sel.xpath(//input[namepass]/value).get() # 有时还需要 challenge_id 或其他参数 challenge_id sel.xpath(//input[namechallenge_id]/value).get() return { script: script_text, jschl_vc: jschl_vc, pass: pass_value, challenge_id: challenge_id, # 可能还有其他参数... } challenge_data extract_challenge_data(challenge_html)现在我们有了混淆的JS代码 (challenge_data[script]) 和必要的参数。接下来我们要在之前创建的补环境context中执行这段代码。这里有一个巨大的坑Cloudflare的JS挑战里经常包含对document.getElementById、window.location、setTimeout等浏览器API的调用甚至还有对DOM元素的操作比如计算某个div的offsetHeight。纯的JS解释器如js2py无法提供这些API。因此我们的补环境框架必须已经模拟了这些API。async def solve_challenge(context, challenge_data): script challenge_data[script] # 1. 将挑战页面JS注入到模拟环境。 # 注意我们不是直接执行它而是让它定义函数如cf_chl_opt和变量。 await context.evaluate(f // 首先确保一些基础对象存在 if (typeof window undefined) {{ window this; }} if (typeof document undefined) {{ document {{ getElementById: function() {{ return {{ offsetHeight: 100 }}; }} }}; }} // 然后执行挑战脚本。这行代码会让 script 变量里的所有代码在这个模拟上下文中执行。 {script} ) # 2. 触发挑战计算。挑战脚本通常会导出一个全局函数或变量。 # 我们需要调用它或者等待它计算完成。有时它被封装在setTimeout里。 # 这里是一个通用模式直接尝试获取 jschl_answer 的值。 # 但通常需要先执行一些初始化比如调用 cf_chl_opt()。 answer await context.evaluate( (function() { try { // 尝试调用可能存在的初始化函数 if (typeof cf_chl_opt function) { cf_chl_opt(); } // 关键计算最终答案。原JS代码通常会修改 window.jschl_answer 或一个类似变量。 // 我们需要模拟浏览器等待几秒因为原页面有倒计时。 // 这里简化处理直接返回当前值。更复杂的需要模拟等待和DOM交互。 return window.jschl_answer; } catch(e) { console.error(Eval error:, e); return null; } })(); ) # 3. 答案可能需要进一步处理。原JS中经常是 answer 12345;但提交时需要的是 12345.123456789 这种格式。 # 有时答案是一个表达式计算的结果。 if answer is not None: # 可能需要对answer进行取整、格式化等操作具体规则需分析JS代码。 # 例如 answer parseFloat(answer.toFixed(10)); pass return answer # 使用我们之前创建的 context jschl_answer await solve_challenge(context, challenge_data) print(f计算出的 jschl_answer: {jschl_answer})这个过程context.evaluate可能在内部涉及多次对JS引擎的调用对应表格中的请求3-10因为JS代码本身可能包含多个步骤、循环或异步操作。补环境框架会将这些操作在内部的JS运行时中执行。核心难点与技巧等待时间真实的5秒盾页面有一个倒计时。挑战JS里可能包含setTimeout或基于Date.now()的时间差校验。你必须在模拟环境中也实现“等待”但不能是简单的time.sleep()因为JS引擎里的时间可能没走。通常的作法是在注入的JS代码里重写Date.now和performance.now等时间函数返回一个受控的时间值或者直接模拟等待逻辑。DOM操作JS可能会读取document.body.offsetHeight或某个特定元素的值。你必须在模拟的document对象里提供合理的返回值。这些值有时是固定的有时需要根据URL或其他参数动态计算例如offsetHeight可能和window.location.hostname.length有关。这需要你仔细分析混淆后的JS逻辑。环境检测除了基础的webdriverJS还可能检测Notification,WebGL,AudioContext,屏幕分辨率等。一个健壮的补环境框架会预先填充好这些属性。如果框架没提供你就需要在add_init_script里自己补。4.3 第11-13次请求提交答案与获取通行证计算出jschl_answer后我们还需要之前提取的jschl_vc和pass参数。然后向一个特定的验证端点提交POST请求。这个验证端点的URL通常可以通过分析挑战页面的表单action属性获得或者是一个固定的路径如/cdn-cgi/challenge-platform/h/b/...。async def submit_answer(challenge_url, jschl_vc, pass_value, jschl_answer, initial_cookies): # 构造验证端点URL。通常是在挑战URL的基础上修改路径。 # 需要从挑战页面的HTML里解析表单的action这里假设我们解析到了。 # 如果没解析到常见模式是 challenge_url 的 path 部分加上 /submit 或直接就是 challenge_url 本身。 from urllib.parse import urlparse, urlunparse parsed urlparse(challenge_url) # 假设验证端点路径是固定的模式实际情况请分析HTML submit_path /cdn-cgi/challenge-platform/h/b/submit submit_url urlunparse((parsed.scheme, parsed.netloc, submit_path, , , )) # 准备提交的数据 form_data { jschl_vc: jschl_vc, pass: pass_value, jschl_answer: str(jschl_answer), # 确保是字符串 # 可能还有其他字段如 challenge_id, r 等 } headers { User-Agent: Mozilla/5.0 ..., Content-Type: application/x-www-form-urlencoded, Referer: challenge_url, # Referer很重要通常需要设置为挑战页面的URL } async with httpx.AsyncClient() as client: # 请求11: 提交答案 resp_submit await client.post( submit_url, dataform_data, headersheaders, cookiesinitial_cookies, # 携带初始请求获得的Cookie follow_redirectsFalse # 不自动重定向我们要捕获Set-Cookie头 ) print(f提交答案状态码: {resp_submit.status_code}) # 关键从响应头中获取 cf_clearance Cookie clearance_cookie resp_submit.cookies.get(cf_clearance) if clearance_cookie: print(f成功获取 cf_clearance: {clearance_cookie}) # 请求12: 服务器验证通过返回302。我们通常不需要手动处理这个重定向的响应体 # 因为 httpx 在 follow_redirectsFalse 时会停在这里。 # 我们已经从响应头里拿到了关键的Cookie。 # 现在用这个Cookie去访问最初的目标页面请求13 final_headers headers.copy() # 更新Cookie携带 cf_clearance final_cookies initial_cookies.copy() final_cookies.update({cf_clearance: clearance_cookie}) resp_final await client.get( https://目标网站.com, headersfinal_headers, cookiesfinal_cookies ) print(f最终请求状态码: {resp_final.status_code}) if resp_final.status_code 200: print(成功绕过5秒盾获取到目标页面内容) return resp_final.text else: print(最终请求失败可能Cookie无效或已过期。) return None else: print(提交答案失败未获得 cf_clearance Cookie。) print(resp_submit.text) # 打印响应内容有助于调试 return None final_html await submit_answer( challenge_url, challenge_data[jschl_vc], challenge_data[pass], jschl_answer, initial_cookies )至此第13次请求完成我们成功拿到了被保护页面的真实HTML内容。cf_clearanceCookie 通常有一定有效期比如15分钟到几小时在此期间内你可以用这个Cookie直接访问网站的其他页面而无需再次挑战。5. 常见问题排查与实战技巧理论很美好实战中却处处是坑。下面是我在多次尝试中总结出来的常见问题及其排查思路。5.1 挑战计算失败jschl_answer为None或错误可能原因1环境补得不够。这是最常见的原因。Cloudflare的JS代码检测到了模拟环境与真实浏览器的差异。排查在浏览器的开发者工具控制台里执行挑战JS中的关键检测代码例如打印navigator.webdriver,window.chrome等。然后在你的Python脚本里通过context.evaluate(“console.log(navigator.webdriver)”)打印对比。补齐缺失或不同的属性。技巧使用补环境框架提供的“调试模式”或“快照”功能将执行挑战JS前后的全局对象状态导出与真实浏览器对比。可能原因2DOM依赖未满足。JS代码尝试访问不存在的DOM元素或属性。排查仔细阅读混淆的JS可以尝试用jsbeautifier.org去格式化一下找到所有document.getElementById,document.querySelector,element.offsetWidth等调用。在注入的初始化脚本中预先创建这些元素并赋予合理的属性值。技巧有时元素ID是动态生成的但规律往往与window.location.hostname的长度或其他固定参数有关。可以通过分析JS逻辑推导出来。可能原因3时间差问题。答案计算依赖于Date.now()或setTimeout。排查在模拟环境中重写时间函数使其返回一个可控的、与挑战逻辑预期相符的时间戳。// 在 add_init_script 中注入 Date.now function() { return 1678886400000; }; // 一个固定的时间戳 // 或者更高级一点模拟时间流逝 let fakeNow Date.now(); Date.now function() { return fakeNow 100; };5.2 提交答案后返回4xx错误或没有cf_clearance可能原因1答案格式错误。jschl_answer可能需要是特定精度的小数或者需要经过一个编码函数如parseInttoFixed处理。排查用浏览器手动过一遍挑战。在浏览器中当挑战通过、页面即将跳转时在开发者工具的Network面板找到提交答案的那个请求查看其Form Data里jschl_answer的具体值。与你脚本计算的值进行对比。技巧在计算答案的JS代码最后不要直接返回window.jschl_answer而是复制浏览器中最终提交的那个值的计算过程。可能类似于(window.jschl_answer window.location.hostname.length).toFixed(10)。可能原因2请求头缺失或错误。Referer,Origin,Content-Type或User-Agent不正确。排查同样用浏览器抓包对比你的脚本请求和浏览器请求的Headers有何不同。确保完全一致特别是Referer必须指向挑战页面URL。可能原因3Cookie 缺失。初始请求获得的 Cookie如__cf_bm没有在提交答案时携带。排查确保你的HTTP客户端如httpx.AsyncClient在多次请求间保持了Cookie会话。或者手动管理Cookie jar将初始请求的Cookie传递给后续的提交请求。5.3 性能与并发考量补环境计算相比浏览器自动化快很多但JS执行本身仍有开销。在高并发场景下需要注意模拟器实例复用不要为每个请求都创建和销毁一个模拟器。可以创建一个模拟器池。上下文隔离每个并发任务应该使用独立的context页面上下文避免状态污染。答案缓存cf_clearanceCookie 有有效期。可以为每个域名或用户会话缓存Cookie有效期内直接使用避免重复计算挑战。错误重试与降级网络波动或Cloudflare策略临时变化可能导致单次失败。实现重试机制。对于非常重要的采集任务可以准备一个备用的浏览器自动化方案作为降级策略。5.4 框架的维护与更新你选择的补环境框架是这场战斗的“武器库”。Cloudflare会更新其挑战机制你的武器也需要打磨。关注上游更新定期关注你所用框架的GitHub仓库看是否有新的版本或Issue讨论。理解原理而非死记硬背本文解析的13次请求流程是一个通用模型但具体细节会变。掌握“触发挑战-获取JS-补环境执行-提交答案-获取Cookie”这个核心链条比记住某个具体的JS变量名更重要。自己动手补环境当框架失效时最根本的解决方法是自己分析JS找出新的检测点然后扩展框架的补环境脚本。这需要一定的JavaScript和浏览器知识。绕过Cloudflare 5秒盾是一场持久战没有一劳永逸的解决方案。通过补环境框架我们获得了一个在效率和可靠性之间取得较好平衡的工具。这次对13次请求的完整解析希望能为你提供一个清晰的作战地图。记住关键在于细致地模仿浏览器耐心地分析每一次请求和响应以及不断地调试和适应变化。
 锋哥原创出品，必属精品)
![[GESP202606 四级] 扫雷](http://pic.xiahunao.cn/yaotu/[GESP202606 四级] 扫雷)
