动态渲染反爬绕过全攻略：Selenium与Playwright防检测实战-代码聚汇网

动态渲染反爬绕过全攻略：Selenium与Playwright防检测实战

信浮沉·2026-09-01·阅读 24 GEO检测（免费）

动态渲染反爬Selenium

|难度：普通|阅读约 36 分钟

动态渲染页面反爬这个话题，这两年问的人特别多。核心原因在于，传统的requests大法在遇到这类页面时几乎全线失效——你肉眼看到的商品价格、订单状态、搜索结果，统统藏在JS异步请求里，直接抓HTML拿不到任何有效数据。而Selenium/Playwright这类浏览器自动化工具虽然能解决渲染问题，但很快就撞上了更硬的墙：网站的反爬系统能识别出你在用自动化工具，轻则弹验证码，重则直接封IP。这篇东西我会把动态渲染页面的反爬原理、Selenium和Playwright的防检测方案、以及我自己实操中踩过的坑都讲透，目标就是让你看完能直接上手，知道每一步为什么要这么做。

先说一下这篇文章适合谁。如果你已经会用requests写简单的静态爬虫，想进一步啃动态页面；或者你已经上了Selenium，但发现WebDriver暴露、被验证码拦住，不知道怎么处理；又或者你纯粹想了解头部大厂的反爬检测思路——这篇文章都适合你。我会尽量把原理讲明白，但更偏向实操，代码可以直接抄。

1. 动态渲染页面为什么难抓

1.1 动态渲染页面的反爬原理

先给没接触过动态渲染页面的朋友补个基础。一个页面从请求到完整展示，大致分两步：第一步，服务器返回一个HTML骨架，这里面通常只有静态容器和公共资源链接；第二步，浏览器解析HTML时执行内联或外部的JavaScript脚本，这些脚本去请求后端API接口，拿到JSON数据后渲染到DOM树上。你最终看到的"页面内容"，其实是由JS在浏览器里拼出来的。

这种架构对爬虫造成的麻烦在于，requests库只能拿到第一步的HTML骨架，里面根本不含实际数据。有些网站更绝，甚至把API接口地址也加密拼接在JS代码里，你连从Network面板找接口这条路都会被堵死。所以解决动态渲染最直接的办法，就是用无头浏览器模拟人的操作，让页面在浏览器里完整执行完JS，再从渲染后的DOM里提取数据。

但问题来了。网站方也清楚这一点，所以他们在动态渲染的基础上叠加了第二层防护——检测你是否在用真实浏览器。这种检测的逻辑很简单：真实用户通过Chrome/Firefox访问页面，浏览器的指纹特征、运行环境、行为特征都会呈现特定的模式；而自动化工具在这些维度上一定有破绽。只要破绽被识别到，后续的请求就会被重点标记。

1.2 与静态页面的本质差异

静态页面爬虫的对抗核心在于请求头伪装和IP管理：你只要把User-Agent、Referer、Cookie这些HTTP层参数弄得像真实浏览器，再控制好请求频率，大部分静态站点都能拿下。但动态渲染页面的反爬对抗，战场已经不在HTTP层，而在浏览器指纹层和行为层。

打个比方。静态页面反爬像门卫查证件，你伪造一个看得过去的证件就能进去；动态渲染反爬像过了安检门，门禁系统不仅看你的证件，还扫描你的体态特征、步态、甚至你身上带了什么违禁品。Selenium/Playwright就像你拿着一张"自动化工具"的身份证去过安检，正常情况下一眼就会被识别出来。

这就是为什么很多爬虫工程师一开始用Selenium觉得"挺简单"，但实际跑了几天后IP全被封完，因为检测系统识别到的是你的浏览器的自动化特征，而不是你的IP。IP封禁只是表面现象，根因在指纹暴露。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 工具选型：Selenium还是Playwright

2.1 核心差异分析

Selenium和Playwright是当前浏览器自动化领域两大主流框架。很多人纠结选哪个，我直接说结论：如果项目必须兼容老旧的浏览器版本、或者团队里有人只熟悉Selenium的API，选Selenium；其余情况我推荐直接上Playwright。

具体对比几个关键维度。从浏览器层面看，Selenium通过WebDriver协议驱动浏览器，会注入一个名为webdriver的全局属性，而且这个属性值被设为true——这是最经典的破绽，几乎所有反爬系统都会检测它。Playwright则是通过Chrome DevTools Protocol驱动的，默认不会暴露webdriver标记，在指纹伪装上有天然优势。另外，Playwright的API设计更现代，自带auto_wait机制，元素定位默认等待元素可交互，比Selenium的WebDriverWait写起来要省心很多。

2.2 项目选型建议

我整理了一个选型参考表，方便大家根据自己场景做判断：

场景	推荐工具	理由
需要兼容老旧浏览器（如IE）	Selenium	唯一能驱动旧浏览器的方案
大规模并发采集	Playwright	自带浏览器上下文隔离，单实例可开多上下文，资源占用低
项目里已有Selenium代码	Selenium	改造成本低于跨框架迁移
需要精细控制浏览器行为、反检测	Playwright	CDP级别控制能力更强
团队是Python新手	Playwright	API更简洁，错误提示更清楚

需要特别说明的是，工具选型只是起点，真正的较量在防检测方案的细节上。工具用的熟不熟、窗口特征掩盖得够不够干净，才是决定采集能否长期稳定跑下去的关键。下面两章，我从原理到实操，把防检测方案拆开讲。

3. 主流反爬检测手段与技术拆解

3.1 基础检测：WebDriver标记

先聊聊最基础的检测手段，也是绝大多数反爬系统的第一道关卡——WebDriver标记。当浏览器被自动化工具控制时，会在运行时环境里生成一些标志性的特征值。Selenium默认在全局window对象上挂一个navigator.webdriver属性，值为true；而正常浏览器这个值是undefined或false。

网站只需要一行JS代码，就能检测出你是不是自动化工具：

javascript复制if (navigator.webdriver) {
    // 标记为爬虫，拒绝访问
}

这种检测虽然入门，但拦截效率很高。我见过不少新手写的Selenium脚本，启动后什么都没干就被平台识别，连登录页都进不去。后面会讲到，基础的规避办法是在浏览器启动时注入一段JavaScript，把这个属性改掉。

3.2 进阶检测：CDP协议指纹

第二层检测要隐蔽得多，它发生在Chrome DevTools Protocol层面。简单解释一下：CDP是一条Chrome浏览器开放出来的调试通道，允许外部工具像“上帝视角”一样查看和操纵浏览器内部状态。Playwright就是基于CDP的。问题在于，当你通过CDP连接浏览器时，浏览器内部的一些运行时特征会发生变化，这些变化可以被网站端的JS脚本探测到。

比如，正常浏览器中navigator.webdriver是undefined，而自动化环境下即使你脚本修改了它，某些底层值依然存在。更隐蔽的是对浏览器对象行为进行校验：window.chrome对象的结构、Permissions API的响应模式、WebGL渲染器的指纹，这些细节组合在一起，能在不被觉察的情况下识别出自动化浏览器。

3.3 行为与特征检测

第三层是行为检测，也是目前大厂风控的标配。思路很简单：模拟人类用户的操作轨迹来判断你是真人还是机器人。

行为检测的关键维度包括：鼠标移动轨迹（真人会有加速减速和停顿，机器人的移动是一条匀速直线）、请求时间间隔（真人浏览页面会有思考和停留时间）、页面滚动模式（真人会分段滚动，不会一滚到底）、键盘输入速度（真人打字有快慢，不会匀速敲击）。另外，还有更高级的检测维度，比如检查浏览器的窗口尺寸是否为手机的默认尺寸（很多爬虫程序图省事不调整窗口大小）、检查系统时区与IP地区是否匹配（如果IP在北京但浏览器返回的时区是美国东部，大概率是机房机器）。

这层检测最大的特点是“叠加判定”。单个异常指标不会触发风控，但当多个维度的分项分数加起来超过阈值，风控系统就会自动升级防护等级，弹滑块验证码、限制登录、甚至封禁账号。

4. Selenium防检测方案与实操配置

4.1 修改浏览器指纹的基础操作

Selenium防检测的第一步，是使用一些成熟的开源工具来隐藏自动化特征。目前用得最多的是stealth.min.js，这是Selenium社区里一个专门用来规避反爬检测的脚本库。它通过注入JavaScript代码的方式，在页面加载前将一系列浏览器指纹特征伪装成真实浏览器。

我自己实际使用的Selenium启动配置大致是这样一个结构：

python复制from selenium import webdriver
from selenium.webdriver.chrome.options import Options

def create_driver():
    options = Options()
    # 启动参数：禁用自动化控制标志
    options.add_experimental_option("excludeSwitches", ["enable-automation"])
    options.add_experimental_option('useAutomationExtension', False)
    # 隐藏webdriver属性（部分版本需配合下面JS处理）
    options.add_argument("--disable-blink-features=AutomationControlled")
    options.add_argument("--lang=zh-CN")
    
    driver = webdriver.Chrome(options=options)
    
    # 执行stealth脚本
    with open('stealth.min.js', 'r', encoding='utf-8') as f:
        js = f.read()
    driver.execute_cdp_cmd("Page.addScriptToEvaluateOnNewDocument", {"source": js})
    
    return driver

这里有一个关键点想单独强调：--disable-blink-features=AutomationControlled这个参数能隐藏源码中部分自动化标志，但它不解决navigator.webdriver属性的问题。真正起决定性作用的是stealth.min.js里的Page.addScriptToEvaluateOnNewDocument注入逻辑。

4.2 stealth.min.js的作用边界

stealth.min.js能处理的基础指纹项包括：

移除navigator.webdriver属性
修正window.chrome对象的结构（保证其完整性和属性类型与真实浏览器一致）
重写navigator.plugins和navigator.languages，让它们返回真实浏览器的值
替换Function.prototype.toString方法，防止被检测出自动化工具的特征报错

但我要提醒的是，这个脚本并非万能。它默认情况下只能应对常规的反爬检测，遇到高度定制化的风控系统（比如头条系、抖音的滑块，或者某些金融机构的WebView检测），仅靠stealth.min.js依旧会被识别。而且新版Chrome浏览器不断更新指纹特征，脚本可能出现兼容性问题，你需要定期更新或者结合其他方案，比如undetected-chromedriver。

4.3 结合undetected-chromedriver的增强方案

我实际用下来，Selenium系防检测的最终形态大多是undetected-chromedriver加stealth.min.js。undetected-chromedriver这个库会把Chrome启动过程中的自动化参数再“洗白”一遍，对某些平台的WebDriver检测有一定压制效果。代码上只是一个包，替换起来很方便：

python复制import undetected_chromedriver as uc

def create_undetected_driver():
    options = uc.ChromeOptions()
    options.add_argument("--window-size=1920,1080")
    return uc.Chrome(options=options)

这里只展示基础用法，更复杂的行为模拟（比如引入真人的鼠标轨迹）则需要配合ActionChains或更底层的人机模拟库。如果你能接受切框架，我建议重点看下一章的Playwright方案——它在对抗检测方面已经换了一条更高级的路线。

5. Playwright防检测方案与实操配置

5.1 Playwright的原生防检测优势

Playwright从架构设计上就规避了Selenium最明显的软肋——不需要额外装ChromeDriver，不通过WebDriver协议通信，而是直接用CDP和浏览器内核对接。这意味着它暴露的自动化特征比Selenium少一个量级。但这不是说Playwright天生就防检测，它只是“基因更好”，后续的伪装仍然要靠我们自己。

Playwright的另一个核心优势是浏览器上下文，英文叫BrowserContext。你可以把它理解成浏览器里的一个独立用户档案。每个Context有自己独立的存储、Cookie、缓存和User-Agent，互不干扰。一个浏览器实例能同时开几十个Context，每个Context伪装成不同的用户——这让采集端能轻松做到IP轮换之外的“身份轮换”。

5.2 Playwright初始化浏览器时的配置要点

看代码。我用Playwright启动浏览器的标准配置是这样的：

python复制import asyncio
import random
from playwright.async_api import async_playwright

async def create_playwright_context(playwright):
    browser = await playwright.chromium.launch(
        headless=False,
        args=[
            '--disable-blink-features=AutomationControlled',
            '--disable-dev-shm-usage',
        ]
    )
    
    context = await browser.new_context(
        viewport={'width': 1920, 'height': 1080},
        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',
        locale='zh-CN',
        timezone_id='Asia/Shanghai',
        permissions=['geolocation'],
        color_scheme='light',
    )
    
    # 注入初始脚本
    await context.add_init_script("""
        // 覆盖webdriver属性
        Object.defineProperty(navigator, 'webdriver', {
            get: () => undefined
        });
        // 修正chrome对象
        window.chrome = {
            runtime: {}
        };
        // 覆盖languages
        Object.defineProperty(navigator, 'languages', {
            get: () => ['zh-CN', 'zh', 'en-US']
        });
    """)
    
    return browser, context

这里有几个参数值得展开说。viewport不一定是越大越好，但必须和user_agent里的屏幕分辨率逻辑匹配，不要出现UA是iPhone但视口是1920宽这种怪异组合。timezone_id也需要注意，如果目标站点的业务逻辑有时区判断（比如按发货地显示库存），这里的配置直接影响数据的准确性。

5.3 高级用法：拦截改写XHR响应

Playwright有一个Selenium无法比拟的能力——page.route()拦截网络请求。这个能力在绕反爬时能派上大用场。举个例子，某网站的搜索接口返回的数据加密了，直接在浏览器里渲染，但你想拿到解密前的原始报文，就可以用路由拦截，把响应体截获下来做二次处理。又或者接口里返回的数据某个字段是风控用的token，你可以在每次请求时动态替换掉，让后端始终认为你是同一个正常用户。

python复制async def intercept_response(route, request):
    response = await route.fetch()
    body = await response.text()
    # 在这里对body做二次处理
    body = body.replace('"code": 403', '"code": 200')
    await route.fulfill(
        response=response,
        body=body,
        headers=dict(response.headers)
    )

await context.route('**/api/**', intercept_response)

这种“改包”的操作，是纯requests或Selenium很难优雅完成的。在接口有加密、有签名校验的场景里，route拦截往往能成为破局的关键。因为你在真实浏览器环境里改包，签名校验、加密逻辑都已经由网站自己的JS执行完了，你只是对结果做了一层转发，从根本上规避了“重放攻击”式的风控判断。

6. 实战案例：完整跑通一个动态页面采集

6.1 案例分析

光讲概念没用，拿一个具体案例走一遍完整流程才有感觉。我以采集某个电商平台的搜索结果页为例，目标是把搜索结果列表里的商品名称、价格、月销量抓下来，存成CSV。

这个页面的特点是：商品列表是动态渲染的，请求搜索结果后至少需要2-3秒才能加载完成，而且网站的风控会在访问时自动检测浏览器环境。

6.2 目标站点分析与反爬识别

我打开这个页面的开发者工具，发现几个明显的特征：

页面的商品数据都放在window.__INITIAL_STATE__这个全局变量里
异步接口的请求头里带有动态的X-Sign签名，每次请求都会变化
首屏会注入一个检测脚本，如果检测到webdriver=true，发送请求时会直接返回空数据

针对这三条特征，我确定的采集策略是：用Playwright模拟正常用户打开搜索页，等页面渲染完成后直接从window.__INITIAL_STATE__里拿数据，不用去解析DOM，也不用去逆向签名算法。关键点在于：签名已经由页面自己的JS执行完成，我只需要在浏览器环境下操作，签名自动生成，无需手动处理。

6.3 核心代码实现

python复制import asyncio
import csv
from playwright.async_api import async_playwright

async def crawl_search(keyword):
    async with async_playwright() as p:
        browser = await p.chromium.launch(
            headless=True,
            args=['--disable-blink-features=AutomationControlled']
        )
        context = await browser.new_context(
            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',
            viewport={'width': 1920, 'height': 1080},
            locale='zh-CN',
            timezone_id='Asia/Shanghai'
        )
        await context.add_init_script("""
            Object.defineProperty(navigator, 'webdriver', {
                get: () => undefined
            });
        """)
        
        page = await context.new_page()
        
        # 打开搜索页面
        await page.goto(f'https://example.com/search?q={keyword}', wait_until='networkidle')
        
        # 等待商品数据加载完成
        await page.wait_for_function(
            "window.__INITIAL_STATE__ && window.__INITIAL_STATE__.searchResult"
        )
        
        # 提取数据
        data = await page.evaluate("""
            () => {
                const list = window.__INITIAL_STATE__.searchResult;
                return list.map(item => ({
                    title: item.title,
                    price: item.price,
                    sales: item.sales
                }));
            }
        """)
        
        # 写入CSV
        with open('data.csv', 'a', newline='', encoding='utf-8') as f:
            writer = csv.DictWriter(f, fieldnames=['title', 'price', 'sales'])
            writer.writerows(data)
        
        print(f"抓取完成，共{len(data)}条数据")
        await browser.close()

asyncio.run(crawl_search("手机"))

这段代码在演示环境里跑通没问题，但在真实场景中需要注意，不同网站的初始状态变量名不同，渲染完成时机也不同。实际开发时，先用wait_for_function测试确认数据出现的条件，再写死等待逻辑，会少走很多弯路。

6.4 常见反爬应对途径

跑项目时遇到反爬拦截，优先检查这几个方向：

确认webdriver属性是否被正确覆盖
检查浏览器的navigator.plugins、navigator.languages是否与UA匹配
确认启动参数里没有遗留enable-automation之类的标记
大幅降低请求频率，模拟真实用户的浏览节奏

如果以上都排查完了还是被识别，那大概率是行为层检测起了作用，需要引入鼠标轨迹模拟、行为延时等更复杂的方案。这里不展开，但方向是明确的——把机器人“行为”再画得跟人一样。

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

7.1 典型问题速查表

问题现象	大概率原因	解决方案
能打开页面但无法获取数据	数据埋在JS渲染后的接口中	检查`window.__INITIAL_STATE__`变量；或拦截XHR请求查看接口返回格式
页面能打开但弹出滑块验证	浏览器指纹暴露	检查`navigator.webdriver`、`window.chrome`，注入stealth脚本；降低启动时的特征
页面会被重定向到验证页	驱动被检测	换用Playwright或undetected-chromedriver；确认UA和timezone匹配
偶尔能跑通，但长时间运行后IP被封	请求频率过高或行为异常	加入随机延时，模拟滑动轨迹，使用代理池轮换
Playwright无头模式无法通过验证	无头与有头在指纹上有差异	先尝试`headless=False`；再用`headless=True`对比，看具体差异在哪

7.2 独家避坑经验

第一条经验，无头模式不要一上来就用。调试阶段务必用headless=False把浏览器窗口显示出来，观察页面实际渲染情况。真实环境跑一段时间后，再切换成无头模式去压测稳定性。我见过太多人一头扎进无头模式，结果连页面长什么样都不知道，定位问题全靠猜。

第二条经验，headless模式下Canvas指纹容易暴露。新版本Playwright的headless=True已经不是老版“自动化无头”的形态了，但仍可能被Canvas指纹识别。如果遇到这种情况，可以在launch时加channel: "chrome"，使用系统安装的Chrome而不是Chromium。

第三条经验，所有的防检测脚本都只是“概率提升”。没有任何方案能保证100%绕过去，只要你的采集频率过高、行为过于“脚本化”，风控系统总会有办法识别你。所以合理的做法是：把防检测当成一个“降低暴露、延缓被识别”的手段，而不是“彻底隐身”的工具。控制采集速率和规模，才是长期稳定运行的基础。

7.3 合法合规提醒

最后想认真说一点，爬虫技术本身是中性的，但使用它时需要尊重目标网站的Robots协议和服务条款。个人学习研究、抓取公开数据，在合理频率范围内，一般不会有法律风险；但如果大规模抓取受版权保护的商业数据、绕过登录访问非公开信息，或者抓到的数据用于商业牟利，就可能涉及法律问题。我写这些防检测技巧，是希望大家在合法合规的范围内解决技术问题，而不是鼓励去攻击别人的系统。技术上能做的，不代表法律上就该做。

我做动态渲染页面爬虫这三年，最大的体会是：反爬对抗是一个“道高一尺、魔高一丈”的循环，不存在一劳永逸的方案。真正稳定可持续的采集方案，核心在于三点——低调的请求频率、完善的指纹伪装、以及一套快速响应风控升级的监控机制。工具选型只是第一步，脚本注入只是第二步，最重要的其实是养成“像用户一样思考”的习惯。你平时手动怎么浏览页面、怎么操作搜索、怎么翻页，就把那些习惯的节奏、时长和鼠标轨迹，尽量用代码复刻出来。做到这一步，大部分反爬系统对你来说就已经不是阻碍了。

最后再分享一个小技巧：每次上线新采集任务前，先在目标站用真实浏览器手动操作一遍完整流程，把每一步间隔时间记下来，然后把这些间隔数据化，作为自动操作的时间基准。这样比你凭空猜延时靠谱得多。爬虫这条路没有捷径，唯有多跑、多观察、多积累。