用Python写Selenium自动化的人，几乎都会在某个时间点遇到同一个尴尬：本机调试时一切正常，脚本一旦部署出去，或者连续跑上几十次，目标网站就开始给你脸色看。轻则多出几道滑块验证码，重则直接把会话标记为异常，返回一堆没有意义的数据。很多人第一反应是“我用了无头模式，应该很隐蔽了吧”，但实际情况恰恰相反——无头模式本身就是最显眼的破绽之一。
“Python用Selenium怎么规避检测”这个问题，本质上要解决的是：让一个由Selenium驱动的浏览器实例，在各种网络环境下表现得和一个普通用户的真实浏览器足够接近，从而不被风控体系单独拎出来。这篇内容会按照“先知道对方怎么认你、再把可识别的特征一个个去掉、最后在行为上装得像真人”这个顺序来展开，全程用Python示例，兼顾刚上手的人和已经写了很久脚本但总被拦截的人。同时我也会垫一句：这类手段请只用于你自己有测试权限的站点、或者明确授权过的数据采集场景，别拿去做任何违法或破坏性的事。技术本身是中性的，边界得靠自己把控。
1. 网站到底靠什么认出Selenium
1.1 最经典的一行JavaScript：navigator.webdriver
先讲流传最广，也是最容易理解的一个检测点：navigator.webdriver。正常情况下，用户用Chrome手工打开任意网页，在开发者工具里输入navigator.webdriver，拿到的值是undefined或false。但在Selenium驱动起来的浏览器里，这个属性几乎总是true。
为什么Selenium会让这个值变成true？因为WebDriver规范里定义了这个属性，用来告诉页面“当前浏览器正被自动化工具控制”。规范的目的本来是方便网站开发者识别自动化会话、做兼容性处理，但后来它成了反爬的第一道关卡。几乎所有的风控脚本都会先查它一眼：如果是true，后面的验证码、人机校验、甚至直接拉黑就都来了。
单看这个特征很好解决，后面第2章会给出具体代码。但我要先提醒一句：只改navigator.webdriver是远远不够的。现在稍微成熟一点的风控系统，早就不靠单一特征下结论了。它们会收集十几个甚至几十个维度的信号，然后综合打分。所以第1章先把整套识别逻辑讲清楚，后面再逐个破。
1.2 CDP协议和浏览器实例在网络层留下的痕迹
第二个检测方向很多人会忽略，是Chrome DevTools Protocol（CDP）层面的痕迹。Selenium之所以能控制Chrome，本质上是Chrome启动时开启了调试端口，Selenium通过这个端口和浏览器通信。只要走这条通道，有些信号是藏不住的。比如：
- 浏览器启动时带有
--remote-debugging-port参数，这个参数在页面的navigator.userAgentData或某些WebRTC接口中可能被间接探到。 - 自动化工具和浏览器之间的WebSocket连接特征，跟普通用户完全不同。
- 页面里某些只有调试模式下才会暴露的JavaScript执行环境差异。
这里我不展开到底怎么探测WebSocket，因为不同反爬系统的实现差异很大，但方向是明确的：你不仅要让JavaScript层的属性看起来正常，还要让浏览器本身的运行方式看起来是“被用户双击启动”的，而不是“被一段代码拉起”的。这也是为什么后面第3章要介绍更底层的管线替代方案。
1.3 无头模式、User-Agent和其他指纹破绽
第三个识别维度是浏览器指纹。Selenium跑的Chrome和真实用户跑的Chrome，在指纹上会有不少可量化的差异。
最明显的是无头模式。老版本的--headless会让User-Agent里带上HeadlessChrome字样，几乎等于直接举牌自首。Chrome 109之后推出了--headless=new，UA里的Headless标志去掉了，但别高兴太早——它在字体列表、Canvas渲染结果、GPU信息、navigator.plugins这些细节上跟有头模式仍然有细微差别，识别难度虽然提高了，但远没到“隐形”的程度。
除了UA，还有几个常见指纹位：
navigator.plugins：真实Chrome里有PDF插件等条目，某些自动化环境里是空数组。navigator.languages：真实用户一般有浏览器语言列表，自动化环境可能是["zh-CN", "zh", "en-US"]，手动设定时容易和UA的Accept-Language不一致。window.chrome：真实Chrome窗口上有window.chrome对象，部分WebDriver环境下这个对象缺失或内容不完整。WebGL渲染器信息、字体枚举结果、Canvas指纹稳定性：这些属于高级指纹，普通教程提得少，但真正难缠的网站会在这些地方做关联分析。
把这一章总括成一句话：网站识别Selenium，不是靠某一个神奇的特征，而是靠一整套环境快照的一致性。你改了navigator.webdriver，但如果UA、插件列表、语言设置、渲染结果彼此矛盾，风控系统照样能把你从好人堆里挑出来。
2. 第一步先抹掉最明显的自动化特征
2.1 关闭自动化提示条和相关开关
先动手处理最基础的一层。用Selenium启动Chrome时，页面上经常会看到一个黄色条幅：“Chrome正在受到自动测试软件的控制”。这个提示条本身就是自动化身份的标志。关掉它的标准写法是：
from selenium import webdriver from selenium.webdriver.chrome.options import Options options = Options() # 去掉“Chrome正在受到自动测试软件的控制”提示条 options.add_experimental_option("excludeSwitches", ["enable-automation"]) # 禁用自动化扩展 options.add_experimental_option("useAutomationExtension", False) # 禁用Blink层级的自动化控制功能 options.add_argument("--disable-blink-features=AutomationControlled") driver = webdriver.Chrome(options=options) driver.get("https://example.com")excludeSwitches里的enable-automation是ChromeDriver注入的一组自动化开关，去掉之后提示条没了，部分自动化标志也会被弱化。--disable-blink-features=AutomationControlled则是在Chromium的Blink渲染引擎层面关掉自动化控制相关的特性，可以避免一些JavaScript特征被检测到。
新版Selenium和Chrome组合下，提示条可能已经不出现了，但这两行配置保留下来没有坏处。它属于成本最低、收益最明确的第一层防护。注意：这只是去掉了浏览器UI层面的提示，JavaScript世界里那个navigator.webdriver还没改，接着看下一节。
2.2 在页面加载前注入JavaScript，提前抹掉webdriver属性
要用JavaScript修改navigator.webdriver属性，这个操作必须在目标页面的脚本执行之前完成。Selenium提供了一种机制：通过CDP命令注册一段“每次新文档开始解析时都先执行的脚本”。用execute_cdp_cmd调Page.addScriptToEvaluateOnNewDocument，就能做到这一点。
driver = webdriver.Chrome(options=options) driver.execute_cdp_cmd("Page.addScriptToEvaluateOnNewDocument", { "source": """ Object.defineProperty(navigator, 'webdriver', { get: () => undefined }); """ }) driver.get("https://example.com")这段代码的关键点是执行顺序：先注册注入脚本，再driver.get加载页面。顺序反了就白搭。为什么？因为Page.addScriptToEvaluateOnNewDocument的意思是“在每个新文档加载的一开始就运行”，你如果先get再注入，页面已经加载完了，属性改动触发不了页面里的风控逻辑。
修改navigator.webdriver的原理并不复杂：Object.defineProperty直接重新定义了那个属性的getter，让它永远返回undefined。效果等同于页面里查navigator.webdriver时得到“这个属性不在了”。这一步是基础中的基础，但也只是基础。
2.3 补齐navigator对象上的其他指纹破绽
只改一个webdriver属性，就好比换了上衣但裤子还是工作服，安检员一眼就能看出来。接下来要顺手把旁边的几个可疑属性一起修掉。
driver.execute_cdp_cmd("Page.addScriptToEvaluateOnNewDocument", { "source": """ Object.defineProperty(navigator, 'webdriver', { get: () => undefined }); Object.defineProperty(navigator, 'languages', { get: () => ['zh-CN', 'zh', 'en-US', 'en'] }); Object.defineProperty(navigator, 'plugins', { get: () => [1, 2, 3, 4, 5] }); // 真实Chrome环境里通常有这个对象 window.chrome = window.chrome || { runtime: {} }; """ })navigator.plugins的这段处理有点“作弊”：它返回一个长度为5的数组，但数组里没有真实元素，因为直接访问数组项会得到undefined。这不是完美方案，却在很多场景下足够骗过那些只判断navigator.plugins.length > 0的低级检测。
navigator.languages要跟User-Agent里的Accept-Language搭配。UA如果是zh-CN,zh;q=0.9,en;q=0.8，那languages列表也应该以zh-CN开头，保持一致才可信。至于window.chrome，真实Chrome里它带着一堆子对象，光是{ runtime: {} }比较简陋，但对付常见脚本也够了。
这一层做完，你的Selenium脚本已经从“一眼假”进步到“仔细看才假”了。但离“真人”还有距离，因为浏览器的启动方式、底层渲染特征仍然和真实用户有差异，这就轮到第3章登场的方案。
3. 隐藏指纹不够时：换掉整条运行管线
3.1 undetected-chromedriver到底改了什么
如果目标网站的反爬强度比较高，光靠ChromeOptions和注入JS可能还是过不了。这时候就该考虑换掉Selenium默认驱动和标准ChromeDriver之间的“配合方式”。社区里的方案比较成熟的是undetected-chromedriver这个库，安装后用法非常简单：
pip install undetected-chromedriverimport undetected_chromedriver as uc import time driver = uc.Chrome() driver.get("https://example.com") time.sleep(2) print(driver.title) driver.quit()这个库到底改了什么？它做的事情不只是改一个属性，而是从ChromeDriver的层面做了patch。具体来说有几层：
- 去掉ChromeDriver在Chromium内部留下的自动化相关标记。
- 重写和新版浏览器之间的握手流程，让浏览器启动的形式更接近真实用户双击Chrome。
- 自动处理
navigator.webdriver等常见检测项。 - 规避了直接通过
--remote-debugging-port启动的明显特征。
很多开发者从标准Selenium切换到uc后的第一反应是“居然这么顺利”。这个库解决的是“整条管道有问题”这个事实，而不是靠表面补丁。
不过也要泼一盆冷水：undetected-chromedriver不是银弹。它跟Chrome和ChromeDriver的版本绑定比较紧，新版Chrome发布后，如果库还没跟上，很可能会报版本不兼容的错。所以用之前建议先确认它支持你本机Chrome的版本，或者锁定一个已知稳定的Chrome版本。
3.2 stealth.min.js的作用与使用位置
另一个常用的方案是stealth.min.js。这本来是给Puppeteer用户准备的，但Selenium同样可以通过CDP注入使用。它的作用是集中抹掉常见自动化指纹，比如补全window.chrome、修正navigator.plugins、去掉webdriver属性、清理权限描述符等。GitHub上可以找到开源的版本，下载下来读取成字符串，注入方式和前面一致。
import pathlib stealth_js = pathlib.Path("stealth.min.js").read_text() driver.execute_cdp_cmd("Page.addScriptToEvaluateOnNewDocument", { "source": stealth_js })执行顺序还是那句老话：注入必须在driver.get之前。很多人把stealth.min.js塞进去之后发现没效果，十有八九是顺序写反了。
stealth.min.js和undetected-chromedriver不是互斥关系，可以叠加使用。但叠加不是无脑的：如果uc自己已经处理了一部分属性，你再注入一遍stealth，有极小概率出现重复定义导致的异常。实际使用中建议先用stealth.min.js做基础隐藏，再用uc接管浏览器实例，两者冲突的情况很少，但值得知道。
3.3 版本匹配是最大的稳定性问题
这个方法最大的坑在于版本。undetected-chromedriver要匹配当前机器上的Chrome版本，如果版本相差太远，要么创建实例时卡住，要么跑着跑着浏览器突然崩溃。而Chrome的自动更新又是默认开启的，这会让“昨天还好好的，今天怎么不行了”的事故反复上演。
处理思路有两条：
- 锁定Chrome版本，禁用自动更新，同时让
undetected-chromedriver使用指定的chromedriver路径。这样环境稳定，但牺牲了新功能。 - 每次部署时先读取Chrome版本，再安装对应版本的WebDriver，用脚本做版本校验。
如果你所在团队有专门的采集环境，我更推荐第一条：稳定压倒一切。毕竟这类任务的目标是长期稳定不触发风控，而不是一直追着最新版本跑。
4. 行为模拟：让鼠标和滚动别出卖你
4.1 固定sleep是最容易被看穿的行为特征
指纹层面处理完之后，还有一个比指纹更容易暴露机器人的层面：行为节奏。人访问网站时的动作不是匀速的，你打字有快慢，看页面有停顿，滚动有加速和减速。而脚本如果写成：
time.sleep(1) driver.find_element(...).click() time.sleep(1) driver.find_element(...).click()这种固定间隔在风控系统眼里就是教科书级的机器人：每隔1000毫秒触发一次操作，偏差不超过几毫秒，正常人做不到这种精度。
正确做法是引入随机延迟。但“随机”也有讲究，最好用指数分布的随机值，直觉上就是短停顿多、长停顿少，偶尔来一个比较久的思考时间。简单实现：
import time import random def human_delay(base_ms=900, random_range=600): # 大部分停顿落在base附近，偶尔会拉开 delay_ms = base_ms + random.uniform(0, random_range) # 还有约10%的几率触发一次额外长停顿，模拟“阅读”行为 if random.random() < 0.1: delay_ms += random.uniform(500, 1200) time.sleep(delay_ms / 1000)这种分布规律不是严格意义上的指数分布，但在工程里已经完全够用。要点是：没有固定节奏，偶尔一个反常停顿反而更像人。
4.2 鼠标轨迹和滚动节奏的模拟思路
比点击间隔更复杂的是鼠标轨迹。真人操作鼠标时，指针从A点到B点走的是一条平滑、带点弧度和抖动的曲线；而ActionChains的move_to_element有时候是瞬移，有时候是直线匀速移动，这对检测系统来说非常明显。
处理办法有两种。简单一点的是把一次移动拆成多段，每段之间sleep很小的时间：
from selenium.webdriver.common.action_chains import ActionChains import random import time element = driver.find_element(...) actions = ActionChains(driver) # 把移动拆成5步，每步之间加随机小间隔 for i in range(5): actions.move_by_offset(random.randint(-2, 2), random.randint(-2, 2)) actions.perform() time.sleep(random.uniform(0.02, 0.08))这种写法还不够真，但已经比一次瞬移好太多。更精细的做法是用CDP直接派发Input.dispatchMouseEvent，手动构造贝塞尔曲线路径，再按曲线上的坐标点逐个触发鼠标事件。这个工程量大，如果目标网站没有强到用鼠标轨迹识别，没必要上。
滚动节奏也一样。一次性scrollTo(0, document.body.scrollHeight)是典型的机器人行为，真人滚动是一段一段的，中间有停顿、往回滚一滚看看。所以建议把滚动写成带随机段的循环，每滚一段就停留一会儿：
import random import time for _ in range(random.randint(3, 6)): driver.execute_script("window.scrollBy(0, arguments[0]);", random.randint(300, 600)) time.sleep(random.uniform(0.3, 0.8))这个模式同样适用于“查看文章列表”“翻看评论区”的场景。记住，风控系统一定会在后台记录交互时序，把交互时序做到“像人”，比单纯改指纹更重要。
4.3 请求序列与资源加载节奏也要像真人
还有一个层面的检测藏在浏览器网络面板里：driver.get(url)打开页面时，请求并不是瞬间全部加载完的。真实用户的浏览器会在几百毫秒内发出所有页面资源请求，顺序大体是HTML、CSS、JS、图片、字体。如果脚本刚get完就立刻执行click，很多资源还没加载完，这个节奏本身就透露了自动化特征。
更稳妥的做法是给首屏加载留出时间：
# 等页面进入“基本加载完”的状态，再继续动作 time.sleep(random.uniform(1.5, 3.0))此外，访问站点的路径也要自然。一个真实用户很少会直接打开深层页面，通常是先访问首页，再点进列表页，再进详情页。脚本如果每次都是直接driver.get("https://site.com/detail/123456")，检测系统会看到所有流量都直取深层URL，没有自然导航路径，这种模式也很容易被聚类模型发现。解决办法是在会话开始时先访问一次首页，保留Cookie，再按导航路径进入目标页。
5. 一次“被拦截”的完整排查链路
5.1 从返回内容判断是哪一层被识破了
规避检测这件事没法指望一次配置就永久有效，重要的是出问题时你能快速定位是哪一层泄露了。我的排查习惯是先把“被拦截”的返回内容保存下来，分门别类地看：
- 返回一个正常HTTP 200，但页面里出现验证码组件，这通常是行为层或指纹层触发风控。
- 返回HTTP 403或者带着“访问异常”字样的纯文本页，一般是IP层被标记。
- 返回200但内容里的一些关键字段全被替换成假数据，比如页面里商品价格变成0或没意义字符，这多半是整机指纹被标记，服务器端做了反制。
- 返回一个空白页面或无限重定向，可能是CDP或浏览器特征被识别后直接拒了会话。
保存原始响应有一个简单方法：用driver.execute_script("return document.documentElement.outerHTML")把当前页面HTML落盘，再在本地搜关键字判断是验证码还是错误页。别只盯着控制台输出。
5.2 逐项核对指纹：用浏览器特征检测页验证
第二步，用独立的环境检测页面来验证当前浏览器实例暴露出的指纹。常见的浏览器指纹检测页面会列出：User-Agent、WebGL信息、Canvas指纹、navigator.webdriver、navigator.plugins、navigator.languages、window.chrome、音频上下文指纹等。这些页面本身不是反爬专用，但能很好地帮你验证自己的隐藏是否生效。
验证时建议这样做：
- 用Selenium打开检测页，看看页面显示的字段是否和一个普通Chrome一致。
- 特别注意那些你改过的字段：
navigator.webdriver是否确实为undefined，navigator.plugins长度是否正常。 - 对比两次打开的结果，看Canvas指纹是否稳定。如果每次重启浏览器指纹都变，说明环境伪装没有做到“稳定关联”，长期会话容易被跟踪。
这一步很重要，因为很多开发者改完代码后就急着跑业务，忽略了“伪装是否真的生效”这一验证环节。多花两分钟做核对，能省掉后面一晚上的排查时间。
5.3 代理IP和会话策略里容易疏忽的坑
如果指纹已经查过没大问题，拦截依然存在，问题很可能在会话和IP维度。这里有三个常见的坑：
- IP质量太差：很多便宜代理IP是数据中心网段，早就被风控标记了，你浏览器伪装得再像，出口IP一查一个准。这属于“换汤不换药”。
- IP跳动和浏览器指纹不匹配：一个稳定的浏览器指纹，却频繁切换不同城市甚至不同国家的出口IP，这种组合本身就是异常模式。真人不可能上一秒在A城下一秒在B城。
- Cookie冷启动：一个全新浏览器环境，没有历史Cookie，第一次请求就访问目标站深层页面，这种“冷启动”行为也很可疑。正常用户多少都会先访问一次主页。
处理建议：优先保证单会话内IP稳定，至少保持同一城市；代理切换频率不要远低于会话时长；每次开新浏览器实例时，可以先用一个“浏览首页并停留几十秒”的预热操作，把基础会话状态建立起来再干活。
5.4 为什么过了一晚又失效
很多人的方案白天调试都是好的，睡一觉起来再跑就被拦了。这种情况我遇到过太多次，根源无非几种：
- 目标站点的风控策略更新了，新增了一个你没覆盖的检测维度，比如开始检查某个新暴露的浏览器特性。
- 你的出口IP在昨晚被标记了。同一个IP高频次低IP池的数量，不管浏览器伪装多好，一旦IP进入黑名单，整条链路都会被卡住。
- 你的浏览器环境发生了变化，比如Chrome自动更新了版本，
undetected-chromedriver的patch失效，或者指纹属性被新版浏览器改了默认值。
排查“隔夜失效”问题，别一上来就重装驱动、换代码，先做两步：第一，用同一套代码，换一个干净IP和干净Profile，手工访问同一个页面，看是否被拦截；第二，把Chrome手动更新关掉，锁死版本。这两步通常能过滤掉八成的原因。
6. 把这些手段组合成一套能落地的配置骨架
6.1 推荐的基础配置代码骨架
总结一下，一套比较完整的Selenium反检测配置至少应该包含四块：启动参数、CDP注入、行为节奏、会话管理。下面给一个可以直接跑通的骨架，这里没有引入undetected-chromedriver，用官方Selenium也能跑：
import random import time from selenium import webdriver from selenium.webdriver.chrome.options import Options def build_driver(profile_dir): options = Options() options.add_argument("--disable-blink-features=AutomationControlled") options.add_experimental_option("excludeSwitches", ["enable-automation"]) options.add_experimental_option("useAutomationExtension", False) # 固定用户数据目录，保持会话一致 options.add_argument(f"--user-data-dir={profile_dir}") driver = webdriver.Chrome(options=options) # 在页面加载前注入改动 driver.execute_cdp_cmd("Page.addScriptToEvaluateOnNewDocument", { "source": """ Object.defineProperty(navigator, 'webdriver', { get: () => undefined }); Object.defineProperty(navigator, 'languages', { get: () => ['zh-CN', 'zh', 'en-US'] }); Object.defineProperty(navigator, 'plugins', { get: () => [1, 2, 3, 4, 5] }); window.chrome = window.chrome || { runtime: {} }; """ }) return driver def human_pause(): delay_ms = random.uniform(700, 1400) if random.random() < 0.1: delay_ms += random.uniform(600, 1500) time.sleep(delay_ms / 1000) driver = build_driver(profile_dir="/tmp/profile_auto") driver.get("https://target-site.com/") human_pause() # 这里再开始你的业务操作这个骨架把第2章的隐藏手段和第4章的行为节奏都带上了，算是一个及格线水平的配置。要在生产环境长期稳定跑，还得接上代理管理和任务调度。
6.2 实例隔离：多任务时的浏览器环境管理
多任务并行是最容易触发风控的场景之一。如果你用同一个浏览器Profile并发跑几十个线程，每个线程的Cookie、LocalStorage和指纹完全一样，这在风控眼里就是“一个用户不可能同时在五十个地方操作”。
正确的隔离思路是：每个会话单独一个--user-data-dir目录，目录里放一套独立的浏览器配置和Cookie。你可以预先准备几个Profile目录，任务启动时随机分配一个，跑完再挂起。这样每个任务看起来都像是一个独立用户在固定设备上操作。
指纹管理更谨慎的团队，会配合使用虚拟浏览器容器或指纹浏览器工具，把Canvas、WebGL、UA、字体等信息做成稳定的虚拟指纹。这类工具在市面上有不少成熟方案，我不是在这里给哪个产品打广告，只是说架构上要理解：稳定性优先于隐蔽性。一个固定不变的普通指纹，比一个每次重启都变化的“完美指纹”更安全。因为风控系统会做关联分析，变化的指纹意味着“你的设备在频繁更换硬件”，这本身就不像真人。
6.3 验证码这种兜底风控，别硬碰
最后说一个很多新人容易走偏的地方：验证码。当你把指纹、行为、IP都做得比较像真人之后，目标站点仍然可能在风险评分较高的情况下弹出验证码，这属于风控模型的兜底策略，不代表你的方案彻底失败了。
我的态度很明确：不要花大力气去做自动破解验证码这件事。一是技术上吃力不讨好，滑块缺口识别、点选语义分析都需要机器学习模型支撑，维护成本极高；二是合规风险陡增。验证码是网站明确设立的访问门槛，绕过去跟直接突破访问控制没什么区别。
更稳妥的方式是调整任务本身：降低采集频率、增加会话间歇、或者把任务排队到人少的时间段执行。有些验证码是“一批IP被标记后全体弹窗”，这时候等一两天再跑可能就好了，硬刚反而会把IP段越用越脏。
我在实际项目中见过太多这样的场景：开发者把80%的时间花在研究验证码破解上，最后发现换一批干净IP、把访问频率砍掉一半，问题自己就消失了。这也印证了整篇文章的核心——规避检测是个系统工程，木桶效应明显，短板决定你能跑多久。与其盯着某个单一魔法功能，不如老老实实把每一层都做得像一个普通用户，然后接受“没有一条流水线能永久有效”这个事实，保持排查和调整的节奏。
