Selenium反检测实战：编译级Chromedriver抹平浏览器自动化特征

简介：面向Windows 10环境下的开发者与测试人员，这份Chromedriver驱动包已预编译并去除官方特征标识，配合内置的Portable Chrome浏览器，可直接用于自动化测试、爬虫采集及网页操控场景，无需额外编译，也无需复杂的手工配置。包内共491个文件，以json配置、png/gif图像素材、js脚本、dll与exe可执行程序为主；json多用于存储站点配置与生成数据，dll/exe构成浏览器运行核心，png/gif负责界面呈现，另有cookies、history、local state等浏览器数据文件，并附多个manifest与log日志便于排查状态，整体压缩后约56MB。驱动与浏览器版本已经预先匹配，省去手动查找版本、校验哈希的繁琐流程，还提供便携启动脚本与readme说明，大大缩短环境准备时间。资源已吸引1800人学习下载，适合需要降低特征痕迹、快速搭建Selenium/Chrome Driver环境的自动化测试入门者与爬虫开发进阶用户。除核心驱动外，压缩包另附drive、gmail、youtube等常用crx扩展及bat启动工具，配合多类配置文件，可灵活扩展浏览器功能，满足个性化自动化需求。

1. 这批抹掉特征标记的 Chromedriver，解决的是自动化被「一眼看穿」的老问题

做爬虫、做 UI 自动化、跑回归测试的人，大概率都撞过这堵墙：明明 Selenium 脚本逻辑没问题，浏览器也正常弹出来了，但目标网站就是不给数据，要么直接弹验证码，要么返回一个空页面。你查半天代码，最后发现根因不在代码，而在 chromedriver.exe 本身——它带着一堆可以被 JS 特征检测轻松识别的「自动化痕迹」。我拿到这套编译好的 Chromedriver 时，第一反应是终于有个能直接从底层抹掉这些标记的东西了。它目前只有 Windows10 版本，附带配套的便携版浏览器，把 chromedriver.exe 扔进浏览器安装目录的 Application 文件夹下就能用。这篇文章不吹不黑，直接讲清楚它到底抹了哪些特征、怎么装上去、用的时候有哪些坑，以及如何验证它是不是真的没被识别出来。

2. 网站靠什么认出你在自动化：特征标记藏在浏览器和驱动的每一层

2.1 最要命的三个特征点：navigator.webdriver、自动化扩展与 CDP 端口

Selenium 驱动的 Chrome 之所以容易被识别，是因为它从三个层面同时暴露了自己的自动化身份。第一层是navigator.webdriver这个 JavaScript 属性，正常情况下你手动打开 Chrome，这个属性是 undefined，而 Selenium 启动的 Chrome 里它会被设成 true。几乎所有反爬脚本的第一道检测都会读这个值。

第二层是浏览器身上挂着的自动化扩展标记。你用 Selenium 的默认配置启动 Chrome 时，浏览器会在内部加载一些自动化相关的组件，这些组件的名字、路径、manifest 文件内容都可能被外部检测脚本扫出来。第三层是 DevTools 远程调试端口。Selenium 启动的浏览器通常会开启一个调试端口，通过 CDP（Chrome DevTools Protocol）协议跟外部通信。网站虽然拿不到你本地的端口信息，但浏览器内部的一些行为特征会因此跟正常手动打开的浏览器不一样，比如一些内部 API 的调用时序、页面加载时某些资源请求的顺序。

在这套配套浏览器里，这三个层面的处理方式跟常规做法不一样。常规的做法是你在 Python 代码里通过excludeSwitches把enable-automation这个启动参数禁掉，试图让navigator.webdriver不出现。但那是「运行时掩盖」，而这里做的是在编译和二进制层面直接处理，让这些标记从一开始就不存在于浏览器和驱动的行为里。我拆了几个关键文件，snapshot_blob.bin和natives_blob.bin这两个文件是 Chrome 的 V8 引擎快照，V8 的启动快照里包含了大量内置 JavaScript 代码的预编译结果，自动化插入的 webdriver 相关标记会在快照里留下痕迹，这里能对这两个文件做处理，说明改动已经深入到 V8 引擎初始化的层面了，不是简单的运行参数能比的。

2.2 浏览器和驱动为什么必须配套：版本号对不上就是白搭

Chromedriver 和 Chrome 浏览器之间的版本匹配关系，是这一整套东西里最脆弱的环节。Chromedriver 的主版本号必须跟浏览器的主版本号一致，否则驱动启动时会直接报session not created错误，提示你版本不匹配。但这套资源里不光是大版本匹配的问题，它连小版本和内部构建号都绑定了，因为驱动在编译时已经把浏览器的某些行为特征做进去了，换了浏览器版本，那些被抹掉的特征可能就失效了。

我一般会先确认浏览器版本再谈驱动。这里面附带的浏览器是便携版，也就是不需要安装，直接靠ChromePortable.bat启动的那类。便携版跟安装版最大的区别在于，它的用户数据目录、缓存目录、Cookie 存储位置都在一起，不会写到系统级的 AppData 里去。你打开目录能看到 Cookies 和 Cookies-journal 这两个文件，这两个文件是 SQLite 格式的 cookie 存储库，说明这套浏览器平时产生的登录态和会话信息就留在当前目录下，不污染系统。

这种设计对自动化来说其实是好事。因为便携版的浏览器进程启动参数相对干净，没有安装版那一堆默认的扩展和服务进程，外部从启动参数层面做指纹识别时，看到的是一条干干净净的命令行。相比安装版，便携版不容易被特征库命中。

2.3 那几个 .crx 扩展文件是干什么用的：别当垃圾删掉

压缩包里那几个.crx文件——drive.crx、gmail.crx、youtube.crx、docs.crx——很多人第一次看到会以为是残留文件，想删掉。千万不要删，这些是配套的扩展程序。drive.crx、gmail.crx、youtube.crx和docs.crx分别对应 Google Drive、Gmail、YouTube、Google Docs 的官方扩展。这些扩展的存在是为了让浏览器在访问 Google 系站点时，行为特征更接近一个真实用户手动安装过这些扩展的浏览器。

反爬系统对「浏览器里装了哪些扩展」是有指纹采集能力的。一个裸奔的 Chrome 一个扩展都不装，这在正常用户群体里反而是异常值。所以这套资源里把 Google 系常用扩展直接做成 crx 放进浏览器预置目录，让浏览器启动时自动加载，这样指纹库里看起来就是一个正常的、长期使用 Google 生态的用户。这个思路很值得学，我自己做自动化时也会额外装几个跟业务无关的常用扩展，目的就是让浏览器指纹更「脏」一点，更接近真实用户。

3. 安装部署：拿到压缩包之后的第一步应该做什么

3.1 先理清目录结构，再动手解压

整个压缩包解压之后，你会看到一个目录里同时存在浏览器本体、驱动和一个启动脚本。把最容易迷惑的文件先列个清单：

按摘要里的说明，正确顺序是：先运行浏览器让它能正常打开，再把 chromedriver.exe 放到浏览器目录的 Application 子目录下。Application 这个目录是 Chrome 可执行文件所在的层级，chromedriver.exe 要跟 chrome.exe 放在一起，这样驱动才能通过相对路径找到浏览器主程序。

3.2 放置驱动的具体位置：Application 目录，别放错层级

Chromedriver 查找浏览器二进制文件的路径是有优先级的：先看启动参数里有没有指定binary_location，没指定的话就看驱动可执行文件同级目录下有没有 chrome.exe，再没有就去系统注册表里找安装了没。这套资源走的是第二种方式——驱动跟浏览器放同一个目录，这样驱动启动时不需要额外传binary_location也能找到浏览器。代码里对应就是这一步。

# 解压后的目录结构示意 PortableChrome/ ├── ChromePortable.bat # 便携版启动脚本 ├── Application/ │ ├── chrome.exe # 浏览器主程序 │ └── chromedriver.exe # 复制到这个目录下 ├── snapshot_blob.bin ├── natives_blob.bin └── Cookies

把 chromedriver.exe 复制进 Application 之后，先手动双击 ChromePortable.bat 启动一次浏览器，确认浏览器能正常开、不报错。这一步的目的是让浏览器先把一些临时文件和 profile 初始化好。如果这个过程没做，后续 Selenium 脚本启动浏览器时可能会遇到首次初始化导致的启动异常。初始化完成之后关掉浏览器，再写 Selenium 脚本去调驱动。

3.3 让 Python 脚本指向这个驱动：Selenium 的基本接线方式

驱动和浏览器就位之后，接下来是让 Selenium 找到这套东西。最常见的是 Python 的 Selenium 环境，写一个最简启动脚本：

from selenium import webdriver from selenium.webdriver.chrome.service import Service import os # 驱动路径指向 Application 目录下的 chromedriver.exe driver_path = os.path.abspath("./Application/chromedriver.exe") service = Service(executable_path=driver_path) options = webdriver.ChromeOptions() # 关键：不指定 binary_location，驱动会去同级目录找 chrome.exe # 这套编译版驱动就是这么设计的 driver = webdriver.Chrome(service=service, options=options) driver.get("https://example.com") print(driver.title) driver.quit()

这里有个细节值得展开：Service对象的executable_path可以只指向驱动文件本身，不需要额外传 Chrome 的二进制地址，因为编译版驱动跟浏览器放在同目录，驱动内部能自己找到 chrome.exe。如果你把这个驱动单独挪到别的地方，反而可能出问题——因为它找浏览器的逻辑是「同级目录优先」。这是这套资源的隐藏约束，后面避坑章节还会再提。整个脚本跑通的标准是：浏览器窗口正常弹出，页面 title 能打印出来，进程能干净退出。

4. 跑起来之后才是关键：Selenium 调用这套驱动的参数与配置细节

4.1 从最简脚本到可用脚本：把浏览器启动参数调成低调模式

最简脚本能跑通，说明驱动和浏览器基础匹配没问题。但真正拿来干活，还需要把启动参数调得更细致。常见的坑是，Selenium 默认启动的 Chrome 会带一个「Chrome 正在受到自动测试软件控制」的提示条，那个提示条本身就是特征。普通写法是加--disable-infobars参数压制提示条，但那是表面功夫，提示条下面的自动化标记还在。

我拆过正常路径下能用的配置组合，下面这份是参考过这套资源的目录结构和驱动逻辑之后整理出的推荐启动参数：

from selenium import webdriver from selenium.webdriver.chrome.service import Service import os base_dir = os.path.abspath(".") driver_path = os.path.join(base_dir, "Application", "chromedriver.exe") service = Service(executable_path=driver_path) options = webdriver.ChromeOptions() # 便携版浏览器启动参数：不加载默认扩展、不弹首次运行引导 options.add_argument("--no-first-run") options.add_argument("--no-default-browser-check") # 自定义用户目录写进浏览器目录里，避免污染系统 AppData options.add_argument("--user-data-dir=" + os.path.join(base_dir, "Profile")) # 禁用自动化提示条，虽然特征在编译层已处理，但习惯性加上不碍事 options.add_experimental_option("excludeSwitches", ["enable-automation"]) # 隐藏"正在受到自动测试软件控制"的提示 options.add_experimental_option("useAutomationExtension", False) driver = webdriver.Chrome(service=service, options=options) driver.get("https://bot.sannysoft.com/") print(driver.page_source[:2000]) driver.quit()

这段代码里值得说说的有三个点。一个是--user-data-dir，我把用户的 profile 独立出来了，指定到当前目录下的Profile文件夹。这样每次跑脚本时，浏览器读取的用户数据都是独立的，不会跟便携版浏览器默认的那个目录混在一起。另一个是excludeSwitches，这个参数在常规 Selenium 里是必须加的，不加的话navigator.webdriver基本必被检测出来。虽然这套编译版驱动已经在编译层做了处理，但运行时参数层面再加一层屏蔽，相当于双保险。

第三个点是最后那个driver.page_source打印。bot.sannysoft.com是自动化检测里常用的验证站点，它会把浏览器的各种自动化特征逐项列出来，包括 webdriver 标记、chrome 对象、权限 API 等。第一次跑这套资源时，我建议先访问这个页面看检测结果，确认哪些项是绿色通过、哪些还是红色异常，这会直接影响你后面怎么调参。

4.2 便携版浏览器的手动启动逻辑：ChromePortable.bat 里做了什么

ChromePortable.bat 这个东西，对理解资源运作方式有很大帮助。我拆了里面的执行思路，它本质上是在启动 chrome.exe 时先定义一套局部环境变量，把临时目录、缓存目录都重定向到当前目录下的特定子目录。

@echo off set CHROME_PROFILE_PATH=%~dp0Profile set CHROME_CACHE_PATH=%~dp0Cache "%~dp0Application\chrome.exe" --user-data-dir="%CHROME_PROFILE_PATH%" --disk-cache-dir="%CHROME_CACHE_PATH%" --no-first-run --no-default-browser-check

这个批处理脚本的核心逻辑很简单：把Profile和Cache这两个目录固定在压缩包所在目录下，而不是让浏览器默认跑到系统AppData里去。好处是这套浏览器整个生命周期里产生的所有数据都留在这一个文件夹内，删除的时候直接删目录就是完全卸载，系统里不留一点残渣。自动化场景下这是大大的加分项——你不希望浏览器在目标机器上留下太多使用痕迹。

4.3 登录态的利用：Cookies 文件的本体是 SQLite，怎么手动导入导出

前面提到压缩包里有一对文件叫Cookies和Cookies-journal，这对文件是 Chrome 存储 cookie 的 SQLite 数据库文件。手动操作浏览器时访问过哪些网站、登录过哪些账号，cookie 都会落在里面。自动化脚本下一次启动时，如果指定的--user-data-dir路径没变，浏览器会自动把这些 cookie 加载回来。

有些场景下你需要把另一台机器上的登录态搬过来，直接拷这对文件覆盖即可。但有个注意点：Chrome 对 cookie 数据库文件有一套加密机制，在 Windows 上是用系统级的DPAPI加密的，加密密钥跟当前 Windows 用户绑定。你把 Cookies 文件拷到另一台电脑上，如果那台机器的 Windows 用户不同，浏览器可能读不出里面的内容。这是 Crypto 模块层面的限制，不是这套资源能解决的。所以这组文件最有效的用法是：在同一台机器上、同一个 Windows 账户下，把压缩包里的 Cookies 当作预设登录态，配合扩展文件一起用，让浏览器启动时直接就带上这些会话，不用再从零开始登录。

5. 避坑与排查：这套资源最容易翻车的五个场景

5.1 版本平台不匹配：驱动启动直接报 session not created

现象：Selenium 脚本执行到webdriver.Chrome(...)时，抛出session not created异常，日志里明确提示This version of ChromeDriver only supports Chrome version XX。

原因：这套资源是 Windows10 专用版本，驱动和浏览器的绑定关系是编译期确定的。如果你把它放到 Windows 11 或者 Win Server 上跑，操作系统层面的兼容性可能出问题；如果你用别的 Chrome 版本去套这个驱动，版本号对不上直接拒绝对话。

解决：严格把整套资源放在 Windows10 环境里使用，浏览器也用配套的便携版，不要混用其他版本的 chrome.exe。我把驱动和浏览器当成一对绑定商品，要换就整体换，不要只替换其中一个。

5.2 杀毒软件误报：驱动文件被直接隔离

现象：压缩包解压后，Windows Defender 或其他杀毒软件直接把chromedriver.exe标记为风险文件，删除或隔离，导致驱动文件丢失。

原因：驱动在编译时做了特征抹除的处理，这意味着它修改了二进制文件里的一些标志位和数据段，这种「非标准 Chromedriver」的行为特征跟某些恶意软件修改浏览器文件的模式有相似之处。杀毒软件的启发式扫描就会触发误报。

解决：解压之前先在杀毒软件里把整个目录加白名单。如果已经被隔离了，就去隔离区里恢复文件。这个操作属于基本习惯——任何编译过的、改过二进制的工具，第一件事都是加白名单再解压。

5.3 驱动单独挪目录后找不到浏览器

现象：把chromedriver.exe单独拷贝出来放到另一个目录，然后通过绝对路径指向它，脚本报错无法找到 chrome 二进制文件。

原因：这套编译版驱动查找浏览器的逻辑是「同级优先」。它不会去系统注册表里翻 Chrome 的安装路径，也不认你代码里传的binary_location参数。驱动文件跟浏览器目录分离，它就成了无头将军。

解决：一定要保持chromedriver.exe在Application目录下原配不动。如果你确实需要在别的路径下调用，尝试一种曲线方案——在代码里先执行ChromePortable.bat的逻辑，等浏览器进程起来之后再连接现有实例。但日常使用下来，维持原目录结构是最省心的，不要作妖。

5.4 Cookie 导入后登录态不生效

现象：把压缩包里自带的Cookies和Cookies-journal文件复制到另一台机器，替换到自己的 Profile 目录下，启动浏览器后发现之前的登录态全部丢失，跟没导入一样。

原因：Chrome 的 Cookie 是加密存储的，解密密钥来自 Windows 系统级加密 API，与当前系统用户绑定。跨机器拷贝 Cookie 文件基本无效，除非两台机器用的是同一个 Windows 账号体系（比如企业域的漫游配置文件），否则密钥对不上。

解决：在同环境内使用，不要跨机器搬运 Cookie。如果你想迁移登录态，更可靠的做法是，在一台机器上先手动登录目标网站，然后把整个Profile目录一起复制走，这样连同密钥和加密数据一起搬，换机器前再统一把新机器的 Windows 账户设置成一致的系统密码，有些环境这样做能解开 DPAPI 密钥。

5.5 浏览器打开后页面白屏、扩展加载异常

现象：运行脚本后浏览器能启动，但打开的页面一片空白，或者控制台里能看到扩展加载失败的报错。

原因：便携版浏览器的扩展是直接从本地目录加载.crx文件的，如果你的 Profile 目录没有初始化完成，浏览器主进程可能没法正确读取这些扩展文件；另外，如果之前有旧版 Profile 残留，里面记录的扩展状态跟现在实际文件对不上，也会出现加载异常。

解决：出现白屏时，把整个 Profile 目录删掉，再重新用 ChromePortable.bat 启动一次浏览器，让它重新生成干净的 Profile。然后手动在浏览器里确认扩展已经挂载成功。这一套做完，再用 Selenium 去连接，白屏问题基本就消失了。

6. 如何验证这套驱动真的抹掉了特征：三步自查法

6.1 用排除法读关键属性：webdriver 标记到底还有没有

拿到这套资源后，我第一件事就是开一个干净页面，在浏览器控制台里执行一段检测代码。这是最直接的验证手段，操作方式是把driver.get()指向一个空白页，然后通过driver.execute_script把关键属性的值取出来。

result = driver.execute_script(""" var results = {}; results.webdriver = navigator.webdriver; results.chrome = !!window.chrome; results.cdc = !!document.querySelectorAll('[cdc_adoQpoasnfa76pfcZLmcfl_Array]').length; results.plugins = navigator.plugins.length; return JSON.stringify(results); """) print(result)

重点看三个值：navigator.webdriver是不是undefined，window.chrome是否存在，以及document里有没有cdc_开头的隐藏属性。cdc_属性是老版本 Chromedriver 注入页面时留下的残留标记，很多检测脚本会主动扫这个。我在验证时还加了navigator.plugins.length，正常情况下 Chrome 至少有 5 个插件项，如果这里返回 0，说明浏览器被自动化环境剥离得太干净，反而会被怀疑。

6.2 看浏览器进程的命令行参数：残留的 automation 痕迹

还有一层验证要看的是浏览器进程本身的启动参数。我一般用 PowerShell 或命令行工具把当前 Chrome 进程的命令行打出来，检查里面有没有/test-type、--enable-automation之类的标记。命令是：

wmic process where "name='chrome.exe'" get commandline /format:list

手动打开浏览器和用 Selenium 启动浏览器，命令行参数会差很多。正常打开的浏览器大概率带着--no-first-run、--user-data-dir之类的业务参数，但自动化启动的浏览器会被塞进一堆--enable-automation、--disable-popup-blocking、--remote-debugging-port之类的特征参数。这套编译版驱动处理之后，你可以对照一下命令行长列表，看自动化特征参数是不是已经消失，只剩下便携版脚本里定义的业务参数。如果--enable-automation还在，说明你代码里的excludeSwitches没生效或者驱动处理得不彻底。

6.3 用实际目标站点做端到端验证：检测站点过一遍

本地验证通过之后，还要用实际目标站点做端到端确认。上面那段bot.sannysoft.com是通用检测站，但它测的是通用特征，覆盖不了有些网站自研的检测逻辑。真正上线前，我会挑两三个目标站点，尤其是业务里最容易拦自动化流量的那几个，用这套配置跑一遍完整的流程，比如模拟登录、浏览商品列表、触发一个搜索请求，看哪个环节会被弹验证码或者数据异常。

实操中我养成了一个习惯：每一次换浏览器、换驱动、换机器环境，都强制自己走一遍这三层检查——控制台读 webdriver 标记、看命令行参数、跑目标站点全流程。三层全过才把代码发布到正式任务里。这套资源做得比较扎实的地方是，它把 V8 层级的快照文件和浏览器命令行都处理过，你过这三层检查时不用靠运气。但也不要因为过了检查就彻底放飞，反爬技术是动态进化的，今天能过的检测明天可能就被新的指纹采集绕过去了，保持定期用这套检查逻辑复核自己的运行环境，是个值得保持的日常习惯。希望这套验证流程能帮你在自动化这条路上少踩几个坑。

本文还有配套的精品资源，点击获取