Selenium与住宅代理反爬实战：从环境配置到生产部署

1. 从requests到Selenium的换血：一个采集项目的反爬对抗记录

先说项目背景。几个月前我接了一个电商价格采集的需求，需要在商品详情页上抓取SKU价格、库存状态和促销信息，每天两次，量级不算大，也就几千个页面。最初我按常规思路用requests + BeautifulSoup直接怼，配合随机User-Agent和代理IP池，理论上够用了。

结果呢？第一轮跑了不到两百个页面，对方的风控就以肉眼可见的速度收紧。先是返回403，接着是滑块验证，再往后甚至连首页都访问不了。这不是个别站点的问题，现在主流的电商、社交、内容类平台，都上了成套的反爬体系：请求频率统计、IP维度风险评估、浏览行为模型、JS环境检测。requests模拟出来的请求特征，本质上和真实浏览器差距太大，几乎一眼就能被识别。

就在那段时间，我认真比较了Playwright、Puppeteer和Selenium三套方案。Playwright在API设计和速度上确实更现代，Puppeteer的生态也不错，但Selenium有一个不可替代的优势：社区资料极其丰富，几乎你能踩到的每一个边界问题，都有人在Stack Overflow上给出了完整答案。加上它对Chrome、Firefox、Edge多浏览器驱动的成熟支持，团队的维护成本最低。再配合住宅代理，把出口IP从机房IP换成真实家庭宽带的IP段，整个请求的特征就无限接近一个普通用户了。

这套组合的逻辑其实很简单：Selenium负责把“行为”做得像真人，住宅代理负责把“身份”做得像真人。前者解决的是浏览器指纹和JavaScript渲染的问题，后者解决的是IP信誉度的问题。两个维度一起发力，才能穿过绝大多数风控系统的第一道和第二道防线。

当然，也不是说Selenium + 住宅代理就万能了，后文会详细展开我踩过的坑，包括WebDriver特征暴露、代理切换太频繁导致频繁验证、以及任务跑一半卡死等等。这中间任何一环掉链子，整个采集链路都会挂掉。

2. 环境准备里的三个坑：驱动版本、Docker化与代理参数

在写任何业务代码之前，先把环境搭明白。很多人一上来就pip install selenium，然后跑Demo，结果报错session not created，或者Chrome failed to start，九成都是环境问题而不是代码问题。

2.1 驱动版本对应关系，别在这上面浪费时间

Selenium本身只是一个协议层的封装，真正的“驾驶员”是浏览器驱动。Chrome对应chromedriver，Firefox对应geckodriver。版本对应是一个非常烦琐又必须要做的事：驱动主版本号和浏览器主版本号必须匹配。比如你的Chrome是120版本，驱动就最好是用120.x.x的chromedriver，否则会直接报版本不兼容。

我个人的建议是引入webdriver-manager这个库，它能自动检测浏览器版本并下载对应驱动，省去手工配版本号的麻烦。实测下来非常省心，尤其是团队里有多个开发机、浏览器版本不统一的情况下，一段代码解决驱动问题：

python复制from selenium import webdriver
from selenium.webdriver.chrome.service import Service
from webdriver_manager.chrome import ChromeDriverManager

service = Service(ChromeDriverManager().install())
options = webdriver.ChromeOptions()
driver = webdriver.Chrome(service=service, options=options)

这里有个容易被忽略的细节：如果你的运行环境是Linux服务器，且没有安装图形界面，光装Chrome还不够，还需要处理一堆系统依赖库（libxss1、libasound2等）。而且启动参数里必须加上--headless=new和--no-sandbox，否则普通用户权限下Chome根本起不来。

2.2 Docker化部署，避免环境漂移

项目跑了一段时间后，我把整个采集服务容器化了。原因很简单：本地跑得好好的，一上服务器就跑不起来，这类“环境漂移”问题我在项目里遇到过太多次。Dockerfile里把Chrome、驱动、Python依赖一次性装好，推送到镜像仓库，无论在哪个机器上拉下来跑，行为完全一致。

一个可用的Dockerfile片段是这样：

dockerfile复制FROM python:3.11-slim

RUN apt-get update && apt-get install -y wget gnupg unzip \
    && wget -q -O - https://dl.google.com/linux/linux_signing_key.pub | apt-key add - \
    && echo "deb http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google.list \
    && apt-get update && apt-get install -y google-chrome-stable

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .

CMD ["python", "main.py"]

注意一点：容器里跑Chrome时，--headless=new模式下仍然需要一些共享内存资源，默认的/dev/shm只有64MB，稍微大一点的页面就会崩。务必在启动时加上--shm-size=2g，或者给Chrome传--disable-dev-shm-usage参数。这个坑我印象深刻，曾经一个任务稳定跑五分钟后崩溃，排查半天，最后发现就是共享内存不够。

2.3 Linux环境下的代理参数陷阱

住宅代理的接入，通常需要你在启动浏览器时把代理配置传入。Selenium里最直接的用法是给Chrome加--proxy-server参数：

python复制options.add_argument(f'--proxy-server=http://{proxy_host}:{proxy_port}')

这个用法在Windows/Mac下没问题，但Linux下有一个陷阱：很多住宅代理是带用户名密码认证的，--proxy-server参数本身不支持直接带上认证信息。你需要通过Chrome的--proxy-bypass-list配合扩展插件来做认证，或者更简单的方式是用selenium-wire这个库拦截请求加上Proxy-Authorization头。

我后续实测下来，selenium-wire的集成成本最低，而且还能顺带查看网络请求细节，非常实用：

python复制from seleniumwire import webdriver

options = {
    'proxy': {
        'http': f'http://{username}:{password}@{proxy_host}:{proxy_port}',
        'https': f'https://{username}:{password}@{proxy_host}:{proxy_port}',
        'no_proxy': 'localhost,127.0.0.1'
    }
}
driver = webdriver.Chrome(options=options)

这里注意一点，selenium-wire和webdriver-manager配合使用时，Service的写法稍有不同，建议直接用seleniumwire.webdriver.Chrome的默认方式，不要手动指定Service，否则偶尔会冲突。

3. 住宅代理的实际接入：从API提取到浏览器会话保持

住宅代理（Residential Proxy）跟机房代理最本质的区别在于IP来源。机房代理的IP全部来自云服务商的IP段，风控系统有成熟的IP段库，识别率极高；住宅代理的IP则是运营商分配给真实家庭宽带的地址，遍布在各个城市、各个运营商，看起来就是一个个真实用户。

但“看起来像真实用户”不等于直接能用好。具体到Selenium采集场景，住宅代理的接入有几个关键细节决定成败。

3.1 从代理服务商的API提取IP

市面上主流的住宅代理服务商都有API提取接口。一般流程是：请求一个API链接，返回可用代理列表，然后你把它解析出来用。API通常支持参数定制，比如国家、城市、会话时长、IP轮换模式。

我在项目里写的提取函数大概是这样的：

python复制import requests

def fetch_proxies(api_url):
    resp = requests.get(api_url, timeout=10)
    proxy_list = []
    if resp.status_code == 200:
        lines = resp.text.strip().split('\n')
        for line in lines[:10]:
            parts = line.strip().split(':')
            if len(parts) == 2:
                proxy_list.append({
                    'host': parts[0],
                    'port': int(parts[1])
                })
    return proxy_list

关键的一个参数是会话时长（session duration），也叫粘性会话（sticky session）。住宅代理的API可以指定一个IP保持多长时间不变，从1分钟到30分钟都有。采集时建议设置成10分钟以上的粘性会话，因为Selenium打开的浏览器如果频繁切换IP，触发风控的概率反而更高。一个浏览器会话用一个稳定的IP，行为和真实用户更一致。

3.2 接入代理后的一分钟验证

拿到代理列表之后，别急着塞进Selenium里跑业务代码。先做一个快速连通性和匿名性检验。我一般是这样：

python复制def validate_proxy(proxy_url):
    test_url = 'https://httpbin.org/ip'
    try:
        resp = requests.get(test_url, proxies={'https': proxy_url}, timeout=15)
        if resp.status_code == 200:
            return resp.json().get('origin', '')
    except Exception:
        pass
    return None

这里有一个很容易踩的坑：很多住宅代理服务商为了提高响应速度，会内置缓存或者对httpbin.org这类检测站点返回固定的、不真实的IP，导致你以为代理不可用，或者反过来——你以为代理可用，但实际上所有请求都在走同一个出口。所以更稳妥的办法是拿目标站点的API接口做验证，比如请求一个返回当前IP信息的业务接口，确认IP是否在目标区域、是否是住宅IP段。

3.3 浏览器会话的代理保持策略

Selenium的浏览器会话一旦建立，代理配置就不好在运行中动态修改。这就意味着，必须在浏览器启动之前决定用哪个代理IP，并且在整个浏览器生命周期内尽量保持这个IP不变。单个页面采集完成后，如果是新的浏览器上下文（context），可以重新创建浏览器或使用selenium-wire动态切换。但如果只是重新加载页面、继续滚动，就保持现有代理即可，切换过于频繁反而容易被风控盯上。

一种我实际在用的策略是：把采集任务按“会话”粒度切分。每个会话对应一个代理IP、一个浏览器实例，跑固定数量的页面（比如30~50页），然后主动关闭这个浏览器，换下一个IP。这样既避免了同一IP请求量过大，又不会因为频繁切换IP导致浏览器行为异常。在Selenium中，对应的是：

python复制session_proxy = get_next_proxy()
driver = create_driver_with_proxy(session_proxy)
try:
    for url in current_batch:
        crawl_page(driver, url)
finally:
    driver.quit()

3.4 代理失效后的自动切换与重试

住宅代理的稳定性再怎么高，也会有失效的时候。常见表现有：连接超时、目标站返回502/503、页面加载不完整。处理方式很简单——重试。但重试必须考虑幂等性，尤其是采集任务里如果涉及表单提交、购物车操作，重试可能会导致重复下单或者重复写入。

我自己的经验是：在采集层的重试逻辑里，只对“读取类”操作做无脑重试，对于提交类操作，先把当前页面状态打日志，再人工介入确认。代理切换后的重试还会带来一个副作用：浏览器上下文变了，可能之前已登录的账号状态丢失，需要重新登录。所以，如果目标站点需要登录态，尽量把登录态做持久化（比如复用Chrome的user-data-dir），否则每次换IP都要重新处理登录，效率会非常低。

4. 自动化采集的节奏控制：等待策略与限速机制

Selenium采集跟requests最大的一个不同点，是页面加载是异步、动态的。driver.get()返回之后，页面上的数据未必已经渲染完成。如果你的代码立刻去定位元素，大概率会报NoSuchElementException。这其实就是“隐式等待”和“显式等待”两种策略各自解决的问题。

4.1 显式等待，比隐式等待更可靠

隐式等待（implicitly_wait）的机制是：在指定的超时时间内，轮询查找元素，直到找到或超时。它使用起来简单，但它有一个全局性，所有find_element调用都会生效，在某些情况下会导致奇奇怪怪的等待叠加问题。我后来逐渐弃用了隐式等待，全面转向显式等待。

显式等待的写法是这样的：

python复制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)
price_element = wait.until(
    EC.presence_of_element_located((By.CSS_SELECTOR, 'span.price'))
)

这里有个更进阶的点：页面刚加载完，元素存在，但数据可能是初始占位符，比如"￥0.00"或者"--"。这时候用presence_of_element_located还不够，需要加上内容条件判断。我有一次采集就栽在这个上面：所有元素都能定位到，但拿到的价格全是0，因为页面是先渲染模板、再异步填充数据。后来改成用自定义的等待条件，轮询判断元素文本是否包含有效价格格式：

python复制def price_loaded(driver):
    el = driver.find_element(By.CSS_SELECTOR, 'span.price')
    return el.text not in ('', '--', '￥0.00')

wait.until(price_loaded)

4.2 元素定位的优先级顺序

Selenium里定位元素的方式很多，项目里常见的优先级建议是这样：id优先，其次CSS_SELECTOR，最后XPath。id是最高效的，但很多现代框架（比如React/Vue）的动态渲染页面里，id可能不稳定或者跟数据绑定相关。这个时候CSS选择器往往是更好的选择，它比XPath更简洁、性能也更好。

XPath虽然灵活，但有两个明显问题：一是表达式写复杂了可读性非常差，二是在某些JS频繁重绘的场景下，text()内容匹配会不稳定。我通常只在不得不依赖文本内容定位的情况下才用XPath，比如定位一个“去结算”按钮而它没有id、name、class等特征时。

这里顺便提一下页面里iframe的情况。如果你定位不到元素，先别急着怀疑选择器写错了，先检查目标元素是不是在iframe里。Selenium默认只能访问顶层文档，跨到iframe需要先切换上下文：

python复制driver.switch_to.frame('iframe_name_or_id')
# 操作完再切回顶层
driver.switch_to.default_content()

4.3 限速与随机延时，做一个“有耐心”的程序

关于限速，很多初学者有一种误区，觉得延时越短、并发越高就越“高效”。但在Selenium + 住宅代理的场景里，这个想法是反的。**Selenium本身就是一个“模拟真人”的工具，真人的访问节奏不可能像一个无情的请求机器。**所以，控制节奏比提高速度更重要。

我的默认节奏是：

• 每次driver.get()之后，至少等待2~4秒才开始操作元素；
• 每次滚动页面之后，随机等待1~3秒，模拟阅读；
• 每采集完一个页面，随机等待3~6秒再进入下一个；
• 每用完一个住宅代理IP，固定休息30~60秒再切下一个。

听起来很慢？确实慢，但稳定。采集追求的不是峰值速度，而是持续跑几个小时、几天不挂的能力。住宅代理是按流量计费的，你要是被风控封了IP，流量就白烧了，重试的成本远超慢慢跑省下的时间。

延时这里我会加一点随机性，而不是固定值。因为固定值本身也有特征：

python复制import time
import random

def human_delay(min_sec=2, max_sec=4):
    time.sleep(random.uniform(min_sec, max_sec))

5. 踩坑实录：WebDriver特征暴露与代理失效的完整排查链路

再好的方案，跑上线之后一定会出问题。这一章节我记录几个真实遇到过的问题，以及完整的排查过程，希望对你有参考价值。

5.1 问题一：浏览器能正常打开，但页面一直显示“访问异常”

某次采集一个电商平台的搜索结果页时，浏览器能正常加载首页，但一进搜索页就弹出滑块验证，而且无论怎么操作都过不去。第一反应是代理IP的维度不够干净，但换了几个不同城市、不同运营商的IP都一样，那就说明问题出在浏览器本身。

排查过程是这样的：我首先用无头模式跑了一个最简单的页面，在页面里执行navigator.webdriver这个JS属性。正常的浏览器返回undefined，而Selenium控制的浏览器返回true。这就是标准的WebDriver特征暴露。

进一步仔细核对下来，风控系统可以从这几个维度判断一个浏览器是否被自动化工具控制：

这里我不建议也不展开讲解“如何隐藏WebDriver特征”的具体代码，因为从长期来看，这是一场无止境的军备竞赛，而且很多规避手段存在法律和合规风险。更稳妥的做法，是把采集目标限定在合法授权、公开数据的范围内，并严格遵守目标网站的robots.txt和服务条款；如果是自己拥有或获得授权的站点，那就完全不存在这个问题。

我在实际项目中遇到需要处理该问题的时候，最有效的解法其实是“降频 + 换路径”。也就是把请求频率降下来，目标页面换成移动端或API接口（如果目标业务允许），再配合住宅代理的IP多样性，从源头减少被判定为异常流量的概率。风控系统判定一个会话异常，不只看单一特征，更看“组合信号”。如果行为节奏正常、IP质量高、操作路径合理，单一特征异常的触发权重会低很多。

5.2 问题二：代理IP明明有效，请求却总是超时

另外一次，代理IP从API拉下来后，单独用requests测试能通，但放进Selenium里就超时。排查了半天，发现是DNS解析的问题。Chrome默认会用自己的DNS解析逻辑，而在某些网络环境下，通过代理访问时，Chrome的DNS解析可能走了本地DNS，导致解析失败。

解决办法是在Chrome的启动参数里加上--proxy-server的同时，也加上--host-resolver-rules=MAP * ~NOTFOUND , EXCLUDE localhost，强制所有解析走代理。这个参数在不同系统下的兼容性略有不同，但在Linux服务器上实测是有效的。很多代理服务商的技术文档里也会提到这个参数，值得留意。

5.3 问题三：采集任务跑到几十页后突然卡死

Selenium任务卡死最常见的原因有两个：一是某个页面上的JavaScript无限循环或弹窗阻塞，导致driver.get()一直不返回；二是Chrome进程内存泄漏，长时间运行后响应变慢。

排查卡死问题，我一般分三步走：

1. 给driver.get()调用设置超时。Selenium本身没有直接的超时参数，但要通过driver.set_page_load_timeout(30)来兜底，30秒内页面没加载完就抛异常，由外层逻辑处理重试。
2. 定时监控任务心跳。我在公司内部实现里加了一个心跳线程，每30秒输出一次当前正在访问的URL和浏览器运行状态，一旦超过5分钟没有心跳，就触发超时重启。
3. 给Chrome设置page_load_strategy为eager。这个策略下，driver.get()在DOM准备完成后就会返回，不必等所有图片和子资源加载完。对于采集场景，eager能显著降低卡死概率，而且几乎不影响采集数据的完整性。

5.4 问题四：代理切得太快，目标站直接冻结了整个IP段

这是我最惨痛的一次教训。某次为了赶数据进度，我把代理轮换频率调得很高，每个IP只跑两三个请求就切换。结果跑了不到十分钟，目标站对我们所在的整个住宅代理IP段做了风控封禁，导致代理服务商那一批IP几乎全部失效。

后来我复盘，问题的本质是我混淆了“代理轮换”和“真人行为”之间的关系。真人不会每隔几十秒就换一个IP，一个IP的活跃周期通常比较长，比如几分钟到十几分钟。所以，代理轮换的粒度不应该按“请求数”，而应该按“会话时长”。从那之后，我把策略改成粘性会话，一个代理IP至少使用10分钟以上，优先保证行为的一致性，IP池的消耗速度反而下降了，整体成功率也上升了。

6. 采集上线的生产环境：任务编排与数据校验

很多人的Selenium爬虫能跑通Demo，但一到生产环境就各种翻车。毕竟Demo只跑几十分钟，而生产环境要跑几天、几周，中间会出现各种意料之外的情况：网络抖动、目标站改版、代码异常、进程被kill。这一章聊聊我在生产化过程中的几个实践经验。

6.1 任务编排用队列，别用循环

最简单的爬虫是for url in url_list循环采集，但这在生产环境里非常脆弱。某个URL异常就会拖垮整个任务，而且断点续跑非常困难。更合理的做法是引入队列，比如Redis队列或者简单地用数据库表模拟任务队列。

我用的方案比较轻量：把待采集URL写入数据库表，每个任务有pending / processing / done / failed四种状态。采集进程每次从数据库取一批pending的任务，处理完后更新状态。这样即使进程崩溃，重启后也能从上次的进度继续跑，不会重复采集已完成的数据。如果临时需要加采集量，多开几个worker实例就能水平扩展。

6.2 数据校验，必须在采集层做

从Selenium拿到的数据，在上报或入库之前必须做一轮校验。我遇到过的典型案例是：价格数据里混入了促销活动的时间戳格式，或者某些SKU的库存状态字段被渲染成了null。

校验逻辑大致是这样：

• 必填字段是否存在、非空；
• 价格字段是否是数值或匹配货币格式；
• 时间字段是否在合理范围内；
• 重试几次后取回的数据是否一致。

对于价格这类关键数据，我会做跨页面的一致性校验：比如详情页价格和列表页价格不应该差距过大，如果差一个数量级以上，大概率采集解析出了问题，而不是真实的促销差异。

6.3 日志告诉你出了什么问题

生产环境跑采集，最忌讳的是没有日志。出了问题连现场都看不到，排查成本极高。我一般会在每个爬虫任务里加三个层级的日志：

• INFO：记录每个页面的URL、耗时、状态码、当前代理IP；
• WARN：记录超时重试、元素定位失败、数据为空等异常；
• ERROR：记录导致任务无法继续的致命错误，并输出完整堆栈。

日志格式里一定带上代理IP和任务ID，这样出问题时能快速定位到“哪条任务、哪个IP、什么时间点”出了问题。

6.4 优雅停机与资源释放

最后提一个容易被忽视的问题：进程被kill时，Selenium的Chrome进程可能还在后台运行。如果你的任务管理器发现主机上有一堆僵尸Chrome进程，那大概率是上次任务没有正常退出。建议在代码里加上atexit或signal处理，确保进程被终止时能执行driver.quit()：

python复制import atexit

atexit.register(lambda: driver.quit() if 'driver' in locals() else None)

Linux环境下，如果Chrome进程已经积累了一堆，可以定期用pkill chrome兜底清理，但更规范的做法还是从代码层面释放资源。

在我实际用的这套架构里，整个采集服务的核心跑得相当稳定，连续运行几十个小时也不需要人工介入。当然，Selenium + 住宅代理不是银弹，遇到JS逆向、签名参数之类的硬核风控，该上的还要上，但作为绝大多数业务型采集需求的首选方案，从投入产出比来看确实是最划算的。最后提醒一句：采集前务必确认数据来源的合法性和目标站的条款边界，技术方案再成熟，数据合规这个底线不能碰。