简介：这是一份面向爬虫开发者与自动化测试人员的Chromedriver资源，针对反爬检测场景，提供已抹除自动化特征的Windows 10专用驱动，并配套完整浏览器环境，解决常规驱动易被识别、导致脚本失效的问题。压缩包共491个文件，约56MB，以json配置、png图标、js脚本、html页面、dll动态库及crx扩展等为主，涵盖浏览器运行所需的各类资源与数据文件，结构完整。使用前先安装配套浏览器，再将chromedriver.exe放入Application目录即可完成部署。目前已有1800人学习下载，适合需要稳定绕过特征检测、搭建可控浏览器环境的爬虫与自动化从业者参考使用。
1. 编译好的Chromedriver，特征已经被抹除，配套浏览器：这套组合到底在解决什么问题
做过浏览器自动化的工程师大概率都遇到过这种场景：本地跑得好好的脚本，一上目标站点就返回空数据，或者干脆弹出一个验证页。排查半天，代码逻辑没问题，请求头也没问题，最后发现是navigator.webdriver这个属性暴露了身份。Chromedriver 作为 WebDriver 协议的标准实现，本身会往浏览器里注入一批可被检测的痕迹，这不是 bug，是设计使然。
标题里说的「编译好的 Chromedriver，特征已经被抹除」，本质上就是有人把 Chromedriver 的源码拉下来，改掉了那些会暴露自动化身份的字符串和属性，重新编译出一个二进制文件，再配一个版本严格对齐的浏览器。这套组合的价值在于：你不需要自己搭编译环境、不需要啃 Chromium 的构建文档，拿到就能用。适合谁？适合做数据采集、自动化测试、页面监控的从业者，尤其是那些被反自动化策略卡住、又不想上重型方案的人。但要注意，特征抹除和反检测是持续对抗的过程，今天能过不代表下个月还能过，这是心理预期。
2. 特征抹除到底抹了什么：从navigator.webdriver到 CDP 痕迹
2.1 检测方最常盯的几个信号
要理解「抹除」这件事，得先知道对方在看什么。最常见的检测点有这么几类：第一类是navigator.webdriver，标准 WebDriver 模式下这个值是true，正常浏览器是false或undefined；第二类是 CDP（Chrome DevTools Protocol）相关的痕迹，比如window.cdc_adoQpoasnfa76pfcZLmcfl_这种随机前缀的变量，是 Chromedriver 注入的；第三类是权限查询的异常，比如Notification.permission在自动化环境下返回denied而正常浏览器是default；第四类是 User-Agent 里带HeadlessChrome字样。
这些信号单独看都不致命，但组合起来就是一个高置信度的自动化指纹。抹除特征的核心思路就是把这些信号逐个改掉，让浏览器在 JS 层面看起来和真人操作的一致。
2.2 源码级修改和运行时注入的区别
市面上有两种做法。一种是运行时注入，用Page.addScriptToEvaluateOnNewDocument在页面加载前执行一段 JS，覆盖掉那些属性。这种做法的优点是灵活，缺点是时序敏感——如果注入晚了，检测脚本已经跑完了，就白搭。另一种是源码级修改，直接改 Chromedriver 的 C++ 源码，把注入的变量名改掉、把navigator.webdriver的返回值改掉，重新编译。标题里说的「编译好的」就是后者。
源码级修改的优势是彻底，因为它在二进制层面就不存在那些特征字符串了，检测方拿不到任何可匹配的常量。缺点是编译门槛高，Chromedriver 依赖 Chromium 的构建体系，一个版本编译下来动辄几小时，还得处理各种依赖。所以有人编译好了直接分享，省掉了最痛苦的一步。
2.3 配套浏览器为什么必须版本对齐
这里有个血泪经验：Chromedriver 和 Chrome 的版本必须严格对应，大版本号差一个就可能连不上。你拿一个 120 版本的 driver 去驱动 119 的浏览器，大概率报session not created错误。标题里强调「配套浏览器」，就是因为抹除特征后的 driver 往往改了内部通信协议的一些细节，只有配套的那个浏览器版本才能正常握手。
我一般会这样做版本核对：
# 查看 Chromedriver 版本 ./chromedriver --version # 输出示例：ChromeDriver 120.0.6099.109 (3419140ab665...) # 查看浏览器版本（Linux 下） /path/to/chrome --version # 输出示例：Chromium 120.0.6099.109两个版本号的主版本和次版本必须一致，构建号最好也一致。如果构建号不同但主次版本相同，通常还能用，但遇到诡异问题时优先怀疑这里。
2.4 一个最小可跑的验证脚本
拿到这套组合后，第一件事不是跑业务脚本，而是验证特征是否真的被抹掉了。下面这段 Python 代码可以快速检查几个关键信号：
from selenium import webdriver from selenium.webdriver.chrome.service import Service from selenium.webdriver.chrome.options import Options # 指定配套的 driver 路径和浏览器路径 chrome_options = Options() chrome_options.binary_location = "/path/to/配套浏览器/chrome" service = Service(executable_path="/path/to/编译好的/chromedriver") driver = webdriver.Chrome(service=service, options=chrome_options) # 逐项检查特征 checks = { "navigator.webdriver": driver.execute_script("return navigator.webdriver"), "cdc 变量": driver.execute_script( "return Object.keys(window).filter(k => k.includes('cdc_')).length" ), "Notification.permission": driver.execute_script( "return Notification.permission" ), "UA": driver.execute_script("return navigator.userAgent"), } for name, value in checks.items(): print(f"{name}: {value}") driver.quit()逻辑说明：navigator.webdriver期望返回False或None；cdc 变量期望返回0；Notification.permission期望返回default；UA 里不应该出现HeadlessChrome。如果这几项都符合预期，说明特征抹除是生效的。参数上，binary_location必须指向配套浏览器的可执行文件，executable_path指向编译好的 driver，两个路径写错一个都会启动失败。
3. 从零跑通一套自动化流程：环境、参数与第一个页面
3.1 环境准备和目录结构
假设你拿到的是一个压缩包，解压后应该包含 driver 二进制和浏览器目录。我习惯的目录结构是这样的：
auto_env/ ├── chromedriver # 编译好的 driver ├── chrome/ # 配套浏览器 │ └── chrome ├── scripts/ # 业务脚本 │ └── main.py └── user_data/ # 持久化用户目录user_data这个目录很关键。默认情况下每次启动都是全新的临时 profile，没有 cookie、没有 localStorage，这本身就是一种异常特征——真人不会每次访问都是空白的。指定一个持久化的用户目录，可以让浏览器保留历史记录、cookie 和缓存，更接近真实使用状态。
3.2 启动参数怎么设才不露馅
启动参数是另一个容易翻车的地方。很多人为了图快，直接上--headless，结果 UA 里带HeadlessChrome，一秒被识别。如果确实需要无头模式，用--headless=new，新版无头模式的 UA 和正常模式一致。下面是一组我常用的参数：
chrome_options = Options() chrome_options.binary_location = "/path/to/chrome/chrome" # 持久化用户目录，保留 cookie 和缓存 chrome_options.add_argument("--user-data-dir=/path/to/user_data") # 新版无头模式，UA 不带 Headless 字样 chrome_options.add_argument("--headless=new") # 禁用自动化提示条 chrome_options.add_argument("--disable-infobars") # 窗口尺寸，避免默认的 800x600 异常值 chrome_options.add_argument("--window-size=1920,1080") # 禁用 GPU，服务器环境常用 chrome_options.add_argument("--disable-gpu") # 关键：排除自动化开关 chrome_options.add_experimental_option("excludeSwitches", ["enable-automation"]) chrome_options.add_experimental_option("useAutomationExtension", False)参数说明：--user-data-dir指向持久化目录，注意这个目录不能被多个实例同时占用，否则会报锁冲突；--headless=new是 Chrome 112 之后的新无头模式，老版本没有这个选项；excludeSwitches和useAutomationExtension这两个实验性选项能去掉一部分自动化提示，但注意它们对源码级抹除的 driver 来说可能是多余的，加上也无害。
3.3 页面加载策略和超时设置
默认的加载策略是normal，会等所有资源加载完，遇到慢资源容易卡死。我一般改成eager，等 DOM 就绪就返回，后续用显式等待处理具体元素：
from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC from selenium.webdriver.common.by import By driver = webdriver.Chrome(service=service, options=chrome_options) # 页面加载策略改为 eager driver.set_page_load_timeout(30) driver.implicitly_wait(0) # 关掉隐式等待，避免和显式等待冲突 driver.get("https://example.com") # 显式等待某个元素出现，最多等 15 秒 try: element = WebDriverWait(driver, 15).until( EC.presence_of_element_located((By.CSS_SELECTOR, "#content")) ) print(element.text[:200]) except Exception as e: print(f"等待超时: {e}")逻辑说明：set_page_load_timeout控制页面加载的总超时，超过就抛异常；implicitly_wait(0)关掉全局隐式等待，因为隐式等待和显式等待混用会导致等待时间不可预测，这是很多人踩过的坑；WebDriverWait配合expected_conditions是更可控的等待方式，超时时间按目标站点的实际响应速度调整，一般 10 到 20 秒比较稳妥。
3.4 验证页面是否真的「干净」
跑通第一个页面后，别急着上业务逻辑，先做一轮特征自检。除了前面提到的navigator.webdriver和 cdc 变量，还可以检查window.chrome对象是否存在、plugins数组是否为空、languages是否合理。正常浏览器的navigator.plugins至少有 PDF 相关的几个条目，如果返回空数组，就是一个明显的异常信号。
# 检查 plugins 和 languages plugins_count = driver.execute_script("return navigator.plugins.length") languages = driver.execute_script("return navigator.languages") chrome_obj = driver.execute_script("return typeof window.chrome") print(f"plugins 数量: {plugins_count}") # 期望 > 0 print(f"languages: {languages}") # 期望 ['zh-CN', 'zh', ...] print(f"window.chrome: {chrome_obj}") # 期望 'object'如果plugins返回 0，说明浏览器启动参数里可能带了--disable-plugins之类的选项，或者配套浏览器本身被裁剪过。这种情况需要回到启动参数排查，把禁用插件相关的选项去掉。
4. 避坑指南：特征抹除后仍然被识别的五种情况
4.1 现象：页面能打开但数据是空的
原因：目标站点用了 JS 挑战，在页面加载后执行一段脚本采集浏览器指纹，如果指纹异常就不渲染真实内容。特征抹除只解决了静态属性，但指纹采集还会看 Canvas 渲染、WebGL 参数、字体列表、时区等。
解决：先确认是哪个环节被拦。打开开发者工具的 Network 面板，看有没有一个返回 403 或 200 但内容为空的 XHR 请求。如果有，把那个请求的 URL 和参数记下来，单独用driver.execute_script复现，看返回什么。常见做法是补上时区和语言的一致性——如果 IP 在国内但navigator.language是en-US，这就是矛盾点。
4.2 现象：启动时报session not created
原因：driver 和浏览器版本不匹配，或者 driver 没有可执行权限。
解决：先chmod +x chromedriver给权限，再核对版本号。如果版本号一致还报错，检查是不是有多个 Chrome 进程残留占用了用户目录。Linux 下用pkill -f chrome清理，Windows 下在任务管理器里结束所有 chrome 进程。另外，--user-data-dir指向的目录如果被上一个实例锁住，也会报这个错，换个目录或者等几秒重试。
4.3 现象：跑一段时间后突然全部失败
原因：目标站点更新了检测规则，或者你的 IP 被限流了。特征抹除不是一劳永逸的，对抗是动态的。
解决：先换 IP 测试，如果换 IP 后恢复，说明是 IP 层面的限流，需要控制请求频率。如果换 IP 也不行，大概率是检测规则更新了，需要重新检查特征。我一般会保留一个「基线检测脚本」，每次出问题先跑一遍，看哪个信号变了。这个脚本就是前面 2.4 节那段代码，存下来定期跑。
4.4 现象：无头模式下正常，有头模式反而失败
原因：有头模式下浏览器会加载真实的插件和扩展，某些扩展会注入额外的变量，反而增加了指纹维度。另外有头模式的窗口尺寸、屏幕分辨率如果和常见设备差异太大，也会被标记。
解决：有头模式下把窗口尺寸设成常见分辨率，比如 1920x1080 或 1366x768。如果不需要看到界面，优先用--headless=new。如果业务必须用有头模式，考虑用虚拟显示（Xvfb）跑在服务器上，这样既有头又不需要物理显示器。
4.5 现象：execute_script返回的结果和预期不符
原因：页面里有 iframe，脚本执行在了顶层文档而不是目标 iframe 里。或者页面用了 CSP，阻止了某些脚本执行。
解决：先driver.switch_to.frame()切到目标 iframe 再执行脚本。如果是 CSP 问题，检查响应头里的Content-Security-Policy，看是否限制了unsafe-eval。这种情况一般不影响正常的元素操作，只影响execute_script，可以改用driver.find_element加get_attribute的方式获取信息。
5. 进阶技巧：把特征抹除做成可复用的检测基线
5.1 建立一套自动化的特征巡检脚本
前面反复提到「基线检测」，这里给一个完整实现。思路是把所有已知的检测点写成一个字典，每次启动后自动跑一遍，输出差异报告。这样当目标站点更新规则时，你能第一时间知道是哪个信号出了问题，而不是盲目地换 driver。
import json from selenium import webdriver from selenium.webdriver.chrome.service import Service from selenium.webdriver.chrome.options import Options # 期望的基线值 BASELINE = { "webdriver": None, # navigator.webdriver 应为 None 或 False "cdc_count": 0, # cdc 变量数量应为 0 "plugins_count_min": 3, # plugins 至少 3 个 "chrome_type": "object", # window.chrome 应为 object "ua_has_headless": False, # UA 不应含 Headless } def inspect(driver): result = {} result["webdriver"] = driver.execute_script("return navigator.webdriver") result["cdc_count"] = driver.execute_script( "return Object.keys(window).filter(k => k.includes('cdc_')).length" ) result["plugins_count"] = driver.execute_script( "return navigator.plugins.length" ) result["chrome_type"] = driver.execute_script( "return typeof window.chrome" ) result["ua"] = driver.execute_script("return navigator.userAgent") result["ua_has_headless"] = "Headless" in result["ua"] return result def compare(result): issues = [] if result["webdriver"] not in (None, False): issues.append(f"webdriver 暴露: {result['webdriver']}") if result["cdc_count"] > 0: issues.append(f"存在 {result['cdc_count']} 个 cdc 变量") if result["plugins_count"] < BASELINE["plugins_count_min"]: issues.append(f"plugins 数量异常: {result['plugins_count']}") if result["chrome_type"] != BASELINE["chrome_type"]: issues.append(f"window.chrome 类型异常: {result['chrome_type']}") if result["ua_has_headless"]: issues.append("UA 含 Headless 字样") return issues if __name__ == "__main__": options = Options() options.binary_location = "/path/to/chrome/chrome" options.add_argument("--headless=new") options.add_argument("--user-data-dir=/path/to/user_data") service = Service(executable_path="/path/to/chromedriver") driver = webdriver.Chrome(service=service, options=options) driver.get("about:blank") result = inspect(driver) issues = compare(result) print(json.dumps(result, indent=2, ensure_ascii=False)) if issues: print("发现问题:") for i in issues: print(f" - {i}") else: print("所有基线检查通过") driver.quit()逻辑说明：inspect函数负责采集，compare函数负责比对基线。基线值不是死的，plugins_count_min可以根据实际浏览器调整，webdriver的期望值在不同 driver 实现下可能是None也可能是False，两个都算通过。这个脚本的价值在于可重复——每次换 driver、换浏览器、换目标站点，先跑一遍，心里有底。
5.2 参数调优的几个经验值
跑久了会积累一些经验值。窗口尺寸用 1920x1080 或 1366x768，这两个是统计上最常见的分辨率；page_load_timeout设 30 秒，WebDriverWait设 15 秒，这两个值覆盖了绝大多数正常站点；请求间隔不要低于 2 秒，同一域名下的并发不要超过 3 个。这些不是硬性规定，但偏离太多就容易触发风控。
还有一个容易忽略的点：--user-data-dir目录要定期清理。跑久了里面会积累大量缓存和日志，体积膨胀不说，还可能因为某些状态文件损坏导致启动失败。我一般每周清一次，只保留 cookie 和 localStorage 相关的文件。
5.3 什么时候该放弃这套方案
说句实在话，特征抹除加配套浏览器这套方案，适合的是中等强度的反自动化场景。如果目标站点上了商业级的风控系统，比如要求通过复杂的 JS 挑战、采集几十个维度的指纹、还结合行为分析，那这套方案的投入产出比就不高了。这时候要么上更重的方案，要么换数据源。
我自己的判断标准是：如果基线检测全部通过、请求频率也控制住了，但连续三天数据获取率低于 30%，那就说明对抗升级了，该考虑换思路了。死磕一套方案不如把精力花在找替代数据源上，这是踩过几次坑之后的习惯。
希望帮到你。
本文还有配套的精品资源，点击获取
