做爬虫的朋友应该都有同感代码逻辑写得再顺一放到线上就容易碰壁要么返回403要么验证码挡住要么请求频率一高直接被封IP。这些问题的根源很多时候不是代码写错而是你没把“浏览器”和“网络身份”这两件事处理好。Selenium负责让脚本像真人一样操作浏览器住宅代理负责让流量看起来来自真实的家庭宽带用户两者配合才能支撑起稳定的数据采集任务。这篇文章我会从方案选型、环境搭建、代码实现到高频坑点把这套组合的完整玩法讲清楚。适合已经写过一些requests脚本、被反爬机制折磨过、准备做更复杂页面采集的Python开发者参考。1. 为什么偏偏是Selenium加住宅代理1.1 单用Selenium的瓶颈在哪里Selenium的核心能力是模拟用户在浏览器里的完整操作流程它能执行JavaScript、能点击、能填写表单、能处理异步加载的内容这些是单纯用requests加cookie模拟很难做到的。但Selenium也有明显的短板。它启动的浏览器实例带着可被识别的自动化特征比如navigator.webdriver属性默认为true这是网站判断脚本与真人最直接的途径。再者普通数据中心IP的请求特征非常集中同一IP在短时间内高密度访问很容易触发服务端的频率控制策略。就算你代码写得再隐蔽只要请求频率和来源IP异常照样会被拉黑。Selenium解决的是“怎么操作页面”的问题但它解决不了“你是谁、从哪来”的问题。要补上后面这块就必须在网络出口层面做文章。1.2 住宅代理与数据中心代理的本质差异住宅代理的IP段来自电信、联通、移动等运营商分配给家庭宽带的真实地址而数据中心代理来自云服务商机房的IP段。网站从访问日志上看住宅IP的归属地、网络类型、历史行为都和普通用户一致因此检测系统很难通过IP维度把它识别为异常流量。数据中心代理便宜、速度快但IP段会被网站标记为“机房流量”很多平台对这类IP的请求策略是一刀切拒绝。住宅代理虽然单价比数据中心代理高但胜在“身份干净”配合Selenium的低频操作能够把被拦截的概率压到很低。这里要说明一点住宅代理并不等于可以直接绕过所有反爬机制它只是解决了IP信誉问题。验证码、行为分析、设备指纹这些依然存在所以Selenium本身的反检测设置也很重要。1.3 这个组合适合什么场景这套方案最适合那些依赖动态渲染、数据通过JavaScript异步加载、且对来源IP有严格风控的网站。比如电商平台的商品价格与库存监控、社交平台的热门内容统计、招聘网站岗位信息聚合、地图服务商的POI数据整理等。如果你的目标页面是纯静态页面还是建议优先用requests方案效率高且资源占用低。Selenium加住宅代理的开销比较大一个浏览器实例起步就要几百兆内存适合解决“别的方案搞不定”的任务而不是所有任务的首选。2. 环境准备与关键选型2.1 Selenium版本和浏览器驱动怎么搭配这个是我答疑时遇到最多的问题装了Selenium之后一运行就报SessionNotCreatedException八成是驱动和浏览器版本对不上。Selenium本身只是一个自动化协议库它需要调用浏览器驱动来控制浏览器进程。Chrome对应ChromeDriverEdge对应EdgeDriverFirefox对应GeckoDriver。驱动版本必须与浏览器主版本一致比如你用的是Chrome 120那驱动也应该选120.x.x.x系列。我建议用pip install selenium -U装最新版然后用浏览器自带的管理器自动下载驱动。Selenium 4.6以上内置了Selenium Manager默认会自动检测浏览器版本并下载对应驱动省去手动匹配的工作。但如果你在公司网络环境或者使用定制版浏览器自动下载可能失败这时就去ChromeDriver官网下对应版本把可执行文件放到PATH里或者直接用Service指定路径。判断驱动是否匹配最简单的方法是在浏览器地址栏输入chrome://version查看版本号再去驱动仓库找到对应目录。下载时注意选win32、mac-arm64还是linux64别选错平台。2.2 住宅代理的选择标准住宅代理服务商有很多参数上重点看这么几个IP池规模、会话控制方式、协议支持、认证方式。IP池规模决定了可用IP的数量。如果你只是跑个几百页的小项目几千个IP的池子就够用了。如果你要大量并发采集那建议选几十万级以上的大池否则容易拿到重复IP或脏IP。会话控制是我重点关注的功能。所谓“Session”是指同一IP持续生效的时间长度比如sticky session可以设置1分钟到30分钟。对于需要登录状态的场景你登录时用的IP和后续采集的IP必须一致否则网站会认为账号异常直接把会话踢下线。这种情况下设置5到10分钟的sticky session是很必要的。纯透明的轮换IP适合匿名访问的场景但遇到需要保持状态的流程就不好用。协议方面大部分住宅代理同时支持HTTP和HTTPS认证方式基本是用户名密码用http://user:passhost:port这种格式嵌入请求。个别服务商支持API白名单认证但配置稍复杂新手不建议折腾。2.3 辅助库低调模拟的关键除了selenium建议把undetected-chromedriver也装上。这个库是对ChromeDriver的补丁版本主要作用是隐藏自动化特征让网站在执行JS检测时更难发现脚本痕迹。实测下来在大多数压力不大的站点上成功率高很多。还有一个常用的方案是引入stealth.min.js脚本在页面加载前注入覆盖掉navigator.webdriver等关键属性。这个方案更轻量不需要换驱动但维护成本稍高。再配合requests做代理连通性测试、fake-useragent生成随机UA、retry库处理重试逻辑基本上就是一个完整的工程组合了。3. 核心代码实现从零搭一个稳定的采集脚本3.1 代理配置的两种姿势先讲最简单的做法通过ChromeOptions直接设置代理参数。from selenium import webdriver from selenium.webdriver.chrome.options import Options proxy_host geo.iproyal.com proxy_port 12321 proxy_user your_username proxy_pass your_password proxy_url fhttp://{proxy_user}:{proxy_pass}{proxy_host}:{proxy_port} options Options() options.add_argument(f--proxy-server{proxy_url}) driver webdriver.Chrome(optionsoptions) driver.get(https://httpbin.org/ip) print(driver.page_source) driver.quit()这个方法最直观一条参数就把HTTP和HTTPS流量都代理了。需要注意的是代理URL里有密码启动的时候不要太张扬地在命令行打印。第二种方式是通过DesiredCapabilities配置这在Selenium 3时代比较常见Selenium 4里依然兼容。这种方式的好处是可以通过seleniumwire等库抓取请求和响应详情方便调试。from seleniumwire import webdriver options { proxy: { http: fhttp://{proxy_user}:{proxy_pass}{proxy_host}:{proxy_port}, https: fhttps://{proxy_user}:{proxy_pass}{proxy_host}:{proxy_port}, no_proxy: localhost,127.0.0.1 } } driver webdriver.Chrome(seleniumwire_optionsoptions)seleniumwire还自带请求拦截和响应修改功能适合需要调试请求头的场景。但它会拖慢程序运行速度生产环境建议关掉请求记录功能或者只在调试阶段用。3.2 隐藏自动化特征的核心手段给浏览器挂上代理只是解决了出口IP的问题。如果网站通过JS检测浏览器指纹脚本照样会暴露。所以在启动参数里还要加一些“反检测”设置。options.add_argument(--disable-blink-featuresAutomationControlled) options.add_experimental_option(excludeSwitches, [enable-automation]) options.add_experimental_option(useAutomationExtension, False) driver webdriver.Chrome(optionsoptions) # 覆盖 webdriver 属性 script Object.defineProperty(navigator, webdriver, { get: () undefined }); driver.execute_cdp_cmd(Page.addScriptToEvaluateOnNewDocument, {source: script})disable-blink-featuresAutomationControlled的作用是关闭Chromium对自动化控制的提示特性excludeSwitches去掉自动化扩展最后的CDP命令在页面文档创建之前注入脚本把navigator.webdriver改为undefined。这三层加起来大多数基础检测就能过掉。更深层的检测点包括navigator.languages、navigator.plugins、window.chrome等。有些反爬体系会校验这些指纹是否符合真实浏览器如果你发现加了上面的代码还是被识别可以考虑用undetected-chromedriver代替标准Selenium它会自动处理这类指纹伪装。3.3 稳定的页面等待策略用Selenium采集最怕的是页面还没渲染完就去抓数据。time.sleep(5)这种固定等待不推荐一是太慢二是网络波动时依然不稳定。推荐用WebDriverWait配合expected_conditions按条件等待目标元素出现。from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC from selenium.webdriver.common.by import By wait WebDriverWait(driver, 15) element wait.until( EC.presence_of_element_located((By.XPATH, //div[classprice])) )这种等待方式比sleep稳定得多页面元素没出现就继续等超时则抛出异常。唯一的细节是presence_of_element_located只检查元素存在不一定可点击。如果要点击按钮建议用element_to_be_clickable避免元素被遮挡或不可交互导致的报错。对于动态加载无限滚动的页面可以写一个循环下拉到底直到页面高度不再变化为止。这个逻辑在Selenium里也很常见核心是不断执行window.scrollTo并记录上一次的高度做对比。3.4 完整样例带代理抓取动态页面这里给出一个可以直接参考的完整脚本模板假设目标是抓取某个商品列表页的数据。import json import time import random import pickle from selenium import webdriver from selenium.webdriver.chrome.options import Options from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC def build_driver(proxy_url): options Options() options.add_argument(--start-maximized) options.add_argument(--disable-blink-featuresAutomationControlled) options.add_argument(f--proxy-server{proxy_url}) options.add_experimental_option(excludeSwitches, [enable-automation]) options.add_experimental_option(useAutomationExtension, False) driver webdriver.Chrome(optionsoptions) driver.execute_cdp_cmd(Page.addScriptToEvaluateOnNewDocument, {source: Object.defineProperty(navigator, webdriver, { get: () undefined }); window.chrome { runtime: {} }; }) return driver def main(): proxy_host geo.iproyal.com proxy_port 12321 proxy_user your_username proxy_pass your_password proxy_url fhttp://{proxy_user}:{proxy_pass}{proxy_host}:{proxy_port} driver build_driver(proxy_url) wait WebDriverWait(driver, 15) try: driver.get(https://example.com/list) # 等待列表加载 wait.until(EC.presence_of_element_located((By.CSS_SELECTOR, .product-item))) items driver.find_elements(By.CSS_SELECTOR, .product-item) results [] for item in items: name item.find_element(By.CSS_SELECTOR, .product-name).text price item.find_element(By.CSS_SELECTOR, .product-price).text results.append({name: name, price: price}) print(json.dumps(results, ensure_asciiFalse, indent2)) finally: driver.quit() if __name__ __main__: main()代码里的要点构建浏览器参数时把代理和反检测配置合并成一个函数方便复用进入页面后用显式等待保证数据加载完成抓完数据必须在finally里quit()否则浏览器进程会残留时间长了内存被吃光。如果网站有登录要求可以在登录成功后执行pickle.dump(driver.get_cookies(), open(cookies.pkl, wb))保存Cookie下次启动直接add_cookie恢复会话。这样一来配合sticky session的住宅代理登录态就不会频繁失效。4. 运行中的高频问题与排查技巧4.1 代理配了但流量没走代理有朋友遇到过这个问题代码里设置了--proxy-server但是访问httpbin.org/ip时显示的IP还是本机地址。常见原因是浏览器在启动时继承了系统代理设置而命令行参数被覆盖了。解决方案是在Options里同时设置--proxy-bypass-list-loopback把本地回环地址排除在外。还有一个容易被忽略的点如果配置里用的是http://user:passhost:port格式且密码里有或#等特殊字符解析会出错导致代理参数无效。建议用urllib.parse.quote对密码做URL编码。4.2 脚本运行结束只打印“Process finished with exit code 0”这个在IDE里很常见程序退出码是0说明没有异常但也没有任何输出。问题大概率出在页面元素定位上等待条件超时了或者找元素的表达式写错了但异常被吞了。排查思路很简单把常见的NoSuchElementException、TimeoutException先打出来不要用try...except: pass绕过。另外在开发阶段可以加一行driver.save_screenshot(debug.png)把报错时的页面截图保存下来一眼就能看出页面是白屏、弹了验证码还是布局变了。4.3 验证码与滑块频繁出现这个问题的原因排除代理IP质量问题外最可能是行为特征暴露了。真人操作鼠标移动轨迹是带加速度的曲线而自动化脚本通常是瞬移直接点击验证码系统能识别这种差异。应对思路有三层第一是降低操作频率在两次操作之间加2到5秒随机等待不要固定间隔第二是随机化鼠标轨迹移动鼠标时先移动到元素附近再做小幅偏移再点击第三是如果验证码过于复杂优先考虑人工打码平台而不是硬写自动化识别维护成本太高。4.4 代理连接超时与重试机制住宅代理的网络链路更长延迟比数据中心代理高不少超时是正常现象。关键是脚本要能优雅处理超时捕获TimeoutException后更换代理IP重试而不是直接崩溃。我一般会写一个retry装饰器重试次数设为3到5次每次重试前从代理池里刷新一个新的IP。等重试次数用尽仍然失败把当前URL和错误信息写入日志文件等下一轮调度时再处理。这种设计能保证任务不会因为个别坏IP整体挂掉。4.5 高并发下的内存问题如果需要用ThreadPoolExecutor或multiprocessing同时跑多个浏览器实例要提前估算内存占用。一个Headless Chrome在加载几个页面之后轻轻松松占用300到500MB内存。如果你在8GB的机器上同时开10个线程跑Chrome大概率会OOM。建议优先用无头模式--headlessnew不要加载图片--blink-settingsimagesEnabledfalse关闭GPU加速--disable-gpu这样内存能压到150MB左右。调度层面用队列控制并发数不要让线程无脑创建。5. IP池与会话管理的进阶心得5.1 为什么保持会话IP一致性很重要如果你需要登录目标网站登录时使用的IP和后续操作的IP换了网站会判断这是一个可疑行为很可能强制下线账号或者触发二次验证。真实项目的经验是在登录前先请求一次代理确认IP可用登录后的整个会话周期绑死同一个IP。住宅代理服务商一般会提供“会话控制”参数比如把session周期设置为5分钟代表在这5分钟内的所有请求都通过同一个出口IP当周期结束后才切换到下一个IP。对于采集任务来说一个任务周期的时长应该和session周期做匹配避免中途换IP带来登录态丢失。5.2 代理IP不可用时的自动剔除代理池里的IP即使是付费的也会有小概率出现连接超时、响应慢、被目标网站封禁的情况。这时候如果不去管它脚本会卡在超时上浪费大量时间。工程化一点的做法是维护一个“代理健康表”每次请求结束后记录响应时间和状态码如果某个IP连续报错超过阈值把它加入黑名单短期内不再使用。每次调度时从健康表里随机选一个IP而不是每次都从服务商API拿一个新的能显著提高成功率。5.3 采集任务多久能跑一次才算安全所谓“安全”其实就是尽量别给目标服务器制造压力。适合Selenium加住宅代理的任务理想频率是每分钟不超过5到10次页面访问。如果单次采集量很大可以延长总时长配合随机延时来模拟不同用户的访问节奏。有朋友问过用了住宅代理是不是就能高频率采集了。答案是否定的。住宅代理解决的是“身份真实”问题但一段住宅IP上每秒几十个请求网站的实时风控照样能判异常。频率控制还是要做把随机延时、限速、错峰访问都加上才能长期稳定地跑。5.4 用日志体系沉淀采集经验采集任务跑久了最终沉淀下来的不是代码而是日志。我会在脚本里记录每个阶段的耗时、代理IP、响应状态码、抓取条数、异常堆栈。不要小看这些数据当你想优化采集效率或者排查某个IP被封的问题时日志能告诉你一切。推荐用loguru库配置起来非常简单支持按天轮转甚至可以推送到钉钉或企业微信机器人实现异常告警。脚本异常时自动发个通知不用盯着控制台也能及时发现问题。6. 一套经过验证的实战流程总结最后分享一个我自己常用的流程模板。接到一个动态页面的采集需求从零到稳定运行大概分成这几步第一是页面分析。手动打开目标页用开发者工具确认数据是通过接口返回还是直接在HTML里。如果用requests能直接拿到接口JSON就没必要上Selenium了成本差好几倍。第二是环境验证。先不急着写完整代码用最小脚本启动一个带代理的浏览器实例手动访问目标站检查是否能正常加载、有没有验证码、页面元素能否定位到。这一步通过再往下推进。第三是编写核心逻辑。从首页到详情页或者从列表翻页按模块拆开写。每一步用显式等待代替固定延时抓取数据统一走数据模型类方便后续落库。第四是异常处理与告警。把超时、验证码、IP被封几种异常单独定义异常类分别处理。补上重试机制和日志输出告警通道提前配置好。第五是小规模试运行。用1个浏览器实例、低并发跑半小时观察成功率、响应速度和内存占用。确认稳定后再逐步放大并发。第六是上线与定期检查。任务跑起来之后隔几天检查一次日志看看成功率是否下降、目标网站是否有改版及时调整选择器和风控策略。我在实际项目中的体会是Selenium加大规模代理池这套玩法70%的功夫都花在了“稳定”上。爬虫写出来只是开始让它在长达数周甚至数月的周期里稳定产出数据才是真正考验工程能力的地方。每次调整完代理策略或反检测设置都要在现场多跑几轮验证确认没有回归问题再推上线。
Selenium+住宅代理：破解动态页面反爬的实战指南
做爬虫的朋友应该都有同感代码逻辑写得再顺一放到线上就容易碰壁要么返回403要么验证码挡住要么请求频率一高直接被封IP。这些问题的根源很多时候不是代码写错而是你没把“浏览器”和“网络身份”这两件事处理好。Selenium负责让脚本像真人一样操作浏览器住宅代理负责让流量看起来来自真实的家庭宽带用户两者配合才能支撑起稳定的数据采集任务。这篇文章我会从方案选型、环境搭建、代码实现到高频坑点把这套组合的完整玩法讲清楚。适合已经写过一些requests脚本、被反爬机制折磨过、准备做更复杂页面采集的Python开发者参考。1. 为什么偏偏是Selenium加住宅代理1.1 单用Selenium的瓶颈在哪里Selenium的核心能力是模拟用户在浏览器里的完整操作流程它能执行JavaScript、能点击、能填写表单、能处理异步加载的内容这些是单纯用requests加cookie模拟很难做到的。但Selenium也有明显的短板。它启动的浏览器实例带着可被识别的自动化特征比如navigator.webdriver属性默认为true这是网站判断脚本与真人最直接的途径。再者普通数据中心IP的请求特征非常集中同一IP在短时间内高密度访问很容易触发服务端的频率控制策略。就算你代码写得再隐蔽只要请求频率和来源IP异常照样会被拉黑。Selenium解决的是“怎么操作页面”的问题但它解决不了“你是谁、从哪来”的问题。要补上后面这块就必须在网络出口层面做文章。1.2 住宅代理与数据中心代理的本质差异住宅代理的IP段来自电信、联通、移动等运营商分配给家庭宽带的真实地址而数据中心代理来自云服务商机房的IP段。网站从访问日志上看住宅IP的归属地、网络类型、历史行为都和普通用户一致因此检测系统很难通过IP维度把它识别为异常流量。数据中心代理便宜、速度快但IP段会被网站标记为“机房流量”很多平台对这类IP的请求策略是一刀切拒绝。住宅代理虽然单价比数据中心代理高但胜在“身份干净”配合Selenium的低频操作能够把被拦截的概率压到很低。这里要说明一点住宅代理并不等于可以直接绕过所有反爬机制它只是解决了IP信誉问题。验证码、行为分析、设备指纹这些依然存在所以Selenium本身的反检测设置也很重要。1.3 这个组合适合什么场景这套方案最适合那些依赖动态渲染、数据通过JavaScript异步加载、且对来源IP有严格风控的网站。比如电商平台的商品价格与库存监控、社交平台的热门内容统计、招聘网站岗位信息聚合、地图服务商的POI数据整理等。如果你的目标页面是纯静态页面还是建议优先用requests方案效率高且资源占用低。Selenium加住宅代理的开销比较大一个浏览器实例起步就要几百兆内存适合解决“别的方案搞不定”的任务而不是所有任务的首选。2. 环境准备与关键选型2.1 Selenium版本和浏览器驱动怎么搭配这个是我答疑时遇到最多的问题装了Selenium之后一运行就报SessionNotCreatedException八成是驱动和浏览器版本对不上。Selenium本身只是一个自动化协议库它需要调用浏览器驱动来控制浏览器进程。Chrome对应ChromeDriverEdge对应EdgeDriverFirefox对应GeckoDriver。驱动版本必须与浏览器主版本一致比如你用的是Chrome 120那驱动也应该选120.x.x.x系列。我建议用pip install selenium -U装最新版然后用浏览器自带的管理器自动下载驱动。Selenium 4.6以上内置了Selenium Manager默认会自动检测浏览器版本并下载对应驱动省去手动匹配的工作。但如果你在公司网络环境或者使用定制版浏览器自动下载可能失败这时就去ChromeDriver官网下对应版本把可执行文件放到PATH里或者直接用Service指定路径。判断驱动是否匹配最简单的方法是在浏览器地址栏输入chrome://version查看版本号再去驱动仓库找到对应目录。下载时注意选win32、mac-arm64还是linux64别选错平台。2.2 住宅代理的选择标准住宅代理服务商有很多参数上重点看这么几个IP池规模、会话控制方式、协议支持、认证方式。IP池规模决定了可用IP的数量。如果你只是跑个几百页的小项目几千个IP的池子就够用了。如果你要大量并发采集那建议选几十万级以上的大池否则容易拿到重复IP或脏IP。会话控制是我重点关注的功能。所谓“Session”是指同一IP持续生效的时间长度比如sticky session可以设置1分钟到30分钟。对于需要登录状态的场景你登录时用的IP和后续采集的IP必须一致否则网站会认为账号异常直接把会话踢下线。这种情况下设置5到10分钟的sticky session是很必要的。纯透明的轮换IP适合匿名访问的场景但遇到需要保持状态的流程就不好用。协议方面大部分住宅代理同时支持HTTP和HTTPS认证方式基本是用户名密码用http://user:passhost:port这种格式嵌入请求。个别服务商支持API白名单认证但配置稍复杂新手不建议折腾。2.3 辅助库低调模拟的关键除了selenium建议把undetected-chromedriver也装上。这个库是对ChromeDriver的补丁版本主要作用是隐藏自动化特征让网站在执行JS检测时更难发现脚本痕迹。实测下来在大多数压力不大的站点上成功率高很多。还有一个常用的方案是引入stealth.min.js脚本在页面加载前注入覆盖掉navigator.webdriver等关键属性。这个方案更轻量不需要换驱动但维护成本稍高。再配合requests做代理连通性测试、fake-useragent生成随机UA、retry库处理重试逻辑基本上就是一个完整的工程组合了。3. 核心代码实现从零搭一个稳定的采集脚本3.1 代理配置的两种姿势先讲最简单的做法通过ChromeOptions直接设置代理参数。from selenium import webdriver from selenium.webdriver.chrome.options import Options proxy_host geo.iproyal.com proxy_port 12321 proxy_user your_username proxy_pass your_password proxy_url fhttp://{proxy_user}:{proxy_pass}{proxy_host}:{proxy_port} options Options() options.add_argument(f--proxy-server{proxy_url}) driver webdriver.Chrome(optionsoptions) driver.get(https://httpbin.org/ip) print(driver.page_source) driver.quit()这个方法最直观一条参数就把HTTP和HTTPS流量都代理了。需要注意的是代理URL里有密码启动的时候不要太张扬地在命令行打印。第二种方式是通过DesiredCapabilities配置这在Selenium 3时代比较常见Selenium 4里依然兼容。这种方式的好处是可以通过seleniumwire等库抓取请求和响应详情方便调试。from seleniumwire import webdriver options { proxy: { http: fhttp://{proxy_user}:{proxy_pass}{proxy_host}:{proxy_port}, https: fhttps://{proxy_user}:{proxy_pass}{proxy_host}:{proxy_port}, no_proxy: localhost,127.0.0.1 } } driver webdriver.Chrome(seleniumwire_optionsoptions)seleniumwire还自带请求拦截和响应修改功能适合需要调试请求头的场景。但它会拖慢程序运行速度生产环境建议关掉请求记录功能或者只在调试阶段用。3.2 隐藏自动化特征的核心手段给浏览器挂上代理只是解决了出口IP的问题。如果网站通过JS检测浏览器指纹脚本照样会暴露。所以在启动参数里还要加一些“反检测”设置。options.add_argument(--disable-blink-featuresAutomationControlled) options.add_experimental_option(excludeSwitches, [enable-automation]) options.add_experimental_option(useAutomationExtension, False) driver webdriver.Chrome(optionsoptions) # 覆盖 webdriver 属性 script Object.defineProperty(navigator, webdriver, { get: () undefined }); driver.execute_cdp_cmd(Page.addScriptToEvaluateOnNewDocument, {source: script})disable-blink-featuresAutomationControlled的作用是关闭Chromium对自动化控制的提示特性excludeSwitches去掉自动化扩展最后的CDP命令在页面文档创建之前注入脚本把navigator.webdriver改为undefined。这三层加起来大多数基础检测就能过掉。更深层的检测点包括navigator.languages、navigator.plugins、window.chrome等。有些反爬体系会校验这些指纹是否符合真实浏览器如果你发现加了上面的代码还是被识别可以考虑用undetected-chromedriver代替标准Selenium它会自动处理这类指纹伪装。3.3 稳定的页面等待策略用Selenium采集最怕的是页面还没渲染完就去抓数据。time.sleep(5)这种固定等待不推荐一是太慢二是网络波动时依然不稳定。推荐用WebDriverWait配合expected_conditions按条件等待目标元素出现。from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC from selenium.webdriver.common.by import By wait WebDriverWait(driver, 15) element wait.until( EC.presence_of_element_located((By.XPATH, //div[classprice])) )这种等待方式比sleep稳定得多页面元素没出现就继续等超时则抛出异常。唯一的细节是presence_of_element_located只检查元素存在不一定可点击。如果要点击按钮建议用element_to_be_clickable避免元素被遮挡或不可交互导致的报错。对于动态加载无限滚动的页面可以写一个循环下拉到底直到页面高度不再变化为止。这个逻辑在Selenium里也很常见核心是不断执行window.scrollTo并记录上一次的高度做对比。3.4 完整样例带代理抓取动态页面这里给出一个可以直接参考的完整脚本模板假设目标是抓取某个商品列表页的数据。import json import time import random import pickle from selenium import webdriver from selenium.webdriver.chrome.options import Options from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC def build_driver(proxy_url): options Options() options.add_argument(--start-maximized) options.add_argument(--disable-blink-featuresAutomationControlled) options.add_argument(f--proxy-server{proxy_url}) options.add_experimental_option(excludeSwitches, [enable-automation]) options.add_experimental_option(useAutomationExtension, False) driver webdriver.Chrome(optionsoptions) driver.execute_cdp_cmd(Page.addScriptToEvaluateOnNewDocument, {source: Object.defineProperty(navigator, webdriver, { get: () undefined }); window.chrome { runtime: {} }; }) return driver def main(): proxy_host geo.iproyal.com proxy_port 12321 proxy_user your_username proxy_pass your_password proxy_url fhttp://{proxy_user}:{proxy_pass}{proxy_host}:{proxy_port} driver build_driver(proxy_url) wait WebDriverWait(driver, 15) try: driver.get(https://example.com/list) # 等待列表加载 wait.until(EC.presence_of_element_located((By.CSS_SELECTOR, .product-item))) items driver.find_elements(By.CSS_SELECTOR, .product-item) results [] for item in items: name item.find_element(By.CSS_SELECTOR, .product-name).text price item.find_element(By.CSS_SELECTOR, .product-price).text results.append({name: name, price: price}) print(json.dumps(results, ensure_asciiFalse, indent2)) finally: driver.quit() if __name__ __main__: main()代码里的要点构建浏览器参数时把代理和反检测配置合并成一个函数方便复用进入页面后用显式等待保证数据加载完成抓完数据必须在finally里quit()否则浏览器进程会残留时间长了内存被吃光。如果网站有登录要求可以在登录成功后执行pickle.dump(driver.get_cookies(), open(cookies.pkl, wb))保存Cookie下次启动直接add_cookie恢复会话。这样一来配合sticky session的住宅代理登录态就不会频繁失效。4. 运行中的高频问题与排查技巧4.1 代理配了但流量没走代理有朋友遇到过这个问题代码里设置了--proxy-server但是访问httpbin.org/ip时显示的IP还是本机地址。常见原因是浏览器在启动时继承了系统代理设置而命令行参数被覆盖了。解决方案是在Options里同时设置--proxy-bypass-list-loopback把本地回环地址排除在外。还有一个容易被忽略的点如果配置里用的是http://user:passhost:port格式且密码里有或#等特殊字符解析会出错导致代理参数无效。建议用urllib.parse.quote对密码做URL编码。4.2 脚本运行结束只打印“Process finished with exit code 0”这个在IDE里很常见程序退出码是0说明没有异常但也没有任何输出。问题大概率出在页面元素定位上等待条件超时了或者找元素的表达式写错了但异常被吞了。排查思路很简单把常见的NoSuchElementException、TimeoutException先打出来不要用try...except: pass绕过。另外在开发阶段可以加一行driver.save_screenshot(debug.png)把报错时的页面截图保存下来一眼就能看出页面是白屏、弹了验证码还是布局变了。4.3 验证码与滑块频繁出现这个问题的原因排除代理IP质量问题外最可能是行为特征暴露了。真人操作鼠标移动轨迹是带加速度的曲线而自动化脚本通常是瞬移直接点击验证码系统能识别这种差异。应对思路有三层第一是降低操作频率在两次操作之间加2到5秒随机等待不要固定间隔第二是随机化鼠标轨迹移动鼠标时先移动到元素附近再做小幅偏移再点击第三是如果验证码过于复杂优先考虑人工打码平台而不是硬写自动化识别维护成本太高。4.4 代理连接超时与重试机制住宅代理的网络链路更长延迟比数据中心代理高不少超时是正常现象。关键是脚本要能优雅处理超时捕获TimeoutException后更换代理IP重试而不是直接崩溃。我一般会写一个retry装饰器重试次数设为3到5次每次重试前从代理池里刷新一个新的IP。等重试次数用尽仍然失败把当前URL和错误信息写入日志文件等下一轮调度时再处理。这种设计能保证任务不会因为个别坏IP整体挂掉。4.5 高并发下的内存问题如果需要用ThreadPoolExecutor或multiprocessing同时跑多个浏览器实例要提前估算内存占用。一个Headless Chrome在加载几个页面之后轻轻松松占用300到500MB内存。如果你在8GB的机器上同时开10个线程跑Chrome大概率会OOM。建议优先用无头模式--headlessnew不要加载图片--blink-settingsimagesEnabledfalse关闭GPU加速--disable-gpu这样内存能压到150MB左右。调度层面用队列控制并发数不要让线程无脑创建。5. IP池与会话管理的进阶心得5.1 为什么保持会话IP一致性很重要如果你需要登录目标网站登录时使用的IP和后续操作的IP换了网站会判断这是一个可疑行为很可能强制下线账号或者触发二次验证。真实项目的经验是在登录前先请求一次代理确认IP可用登录后的整个会话周期绑死同一个IP。住宅代理服务商一般会提供“会话控制”参数比如把session周期设置为5分钟代表在这5分钟内的所有请求都通过同一个出口IP当周期结束后才切换到下一个IP。对于采集任务来说一个任务周期的时长应该和session周期做匹配避免中途换IP带来登录态丢失。5.2 代理IP不可用时的自动剔除代理池里的IP即使是付费的也会有小概率出现连接超时、响应慢、被目标网站封禁的情况。这时候如果不去管它脚本会卡在超时上浪费大量时间。工程化一点的做法是维护一个“代理健康表”每次请求结束后记录响应时间和状态码如果某个IP连续报错超过阈值把它加入黑名单短期内不再使用。每次调度时从健康表里随机选一个IP而不是每次都从服务商API拿一个新的能显著提高成功率。5.3 采集任务多久能跑一次才算安全所谓“安全”其实就是尽量别给目标服务器制造压力。适合Selenium加住宅代理的任务理想频率是每分钟不超过5到10次页面访问。如果单次采集量很大可以延长总时长配合随机延时来模拟不同用户的访问节奏。有朋友问过用了住宅代理是不是就能高频率采集了。答案是否定的。住宅代理解决的是“身份真实”问题但一段住宅IP上每秒几十个请求网站的实时风控照样能判异常。频率控制还是要做把随机延时、限速、错峰访问都加上才能长期稳定地跑。5.4 用日志体系沉淀采集经验采集任务跑久了最终沉淀下来的不是代码而是日志。我会在脚本里记录每个阶段的耗时、代理IP、响应状态码、抓取条数、异常堆栈。不要小看这些数据当你想优化采集效率或者排查某个IP被封的问题时日志能告诉你一切。推荐用loguru库配置起来非常简单支持按天轮转甚至可以推送到钉钉或企业微信机器人实现异常告警。脚本异常时自动发个通知不用盯着控制台也能及时发现问题。6. 一套经过验证的实战流程总结最后分享一个我自己常用的流程模板。接到一个动态页面的采集需求从零到稳定运行大概分成这几步第一是页面分析。手动打开目标页用开发者工具确认数据是通过接口返回还是直接在HTML里。如果用requests能直接拿到接口JSON就没必要上Selenium了成本差好几倍。第二是环境验证。先不急着写完整代码用最小脚本启动一个带代理的浏览器实例手动访问目标站检查是否能正常加载、有没有验证码、页面元素能否定位到。这一步通过再往下推进。第三是编写核心逻辑。从首页到详情页或者从列表翻页按模块拆开写。每一步用显式等待代替固定延时抓取数据统一走数据模型类方便后续落库。第四是异常处理与告警。把超时、验证码、IP被封几种异常单独定义异常类分别处理。补上重试机制和日志输出告警通道提前配置好。第五是小规模试运行。用1个浏览器实例、低并发跑半小时观察成功率、响应速度和内存占用。确认稳定后再逐步放大并发。第六是上线与定期检查。任务跑起来之后隔几天检查一次日志看看成功率是否下降、目标网站是否有改版及时调整选择器和风控策略。我在实际项目中的体会是Selenium加大规模代理池这套玩法70%的功夫都花在了“稳定”上。爬虫写出来只是开始让它在长达数周甚至数月的周期里稳定产出数据才是真正考验工程能力的地方。每次调整完代理策略或反检测设置都要在现场多跑几轮验证确认没有回归问题再推上线。
