Playwright/Selenium 浏览器自动化怎么挂代理？AI 操作网页防封完整指南

AI Agent 要从”回答问题”走向”替人办事”，第一步往往就是操作网页：填表单、点按钮、翻列表、把页面里的数据提取成结构化结果。Playwright 和 Selenium 是目前应用最广的两套浏览器自动化框架，配合 AI 模型的任务编排，已经能完成相当复杂的真实网页操作。

但自动化脚本有一个绕不开的问题：访问特征和真人差异明显。同一个出口 IP 在短时间内发起成百上千次请求，风控系统很容易把它识别为机器行为——验证码弹窗、访问被限流、出口地址直接被封禁。解决思路很直接：给浏览器自动化接上代理，让请求从合适的出口 IP 发出，让”机器操作”拥有”真人访问”的网络身份。

本文讲透三件事：Selenium 和 Playwright 分别怎么配代理（附可直接运行的代码）、自动化场景该选哪种代理、以及为什么只挂 IP 还不够。

浏览器自动化为什么需要代理？先看风控怎么看”机器”

要理解代理在自动化里的作用，先看平台如何判断一次访问”像不像真人”。核心看三个维度：

• 出口 IP 的信任度：IP 归属是住宅网络、移动网络还是机房段？有没有滥用历史？是否被多人共用？
• 访问频率与节奏：真人访问有思考时间、有操作间隔；脚本可以做到每秒几十次请求，频率特征一眼可辨。
• 浏览器环境的一致性：UA、时区、语言、设备指纹是否与 IP 归属地匹配。

自动化脚本与真人差异最大的，是第一点和第二点。而代理解决的就是第一点：它让脚本的请求从你指定的出口 IP 发出，目标网站看到的是代理地址，而不是你的真实地址；配合合理限速与随机延迟，第二点的差异也能被大幅抹平。

还需要提前说清一个边界：代理解决的是网络入口问题，它不是万能的。时区不匹配、指纹不一致、操作频率像机器，即使挂了代理也会被判定异常。这一点第三节专门展开。

Selenium 怎么挂代理？直接可跑的代码

Selenium 通过浏览器启动参数注入代理。以 Chrome 为例，核心是 add_argument 传入 --proxy-server：

from selenium import webdriver

options = webdriver.ChromeOptions()
# 无认证代理：直接指定地址与端口
options.add_argument("--proxy-server=http://IP:端口")
driver = webdriver.Chrome(options=options)
driver.get("https://example.com")
print(driver.current_url)
driver.quit()

如果代理需要用户名密码认证，--proxy-server 无法直接携带凭据，需要借助代理扩展（extension）加载认证信息。做法是生成一个 Chrome 扩展：把认证逻辑写进 manifest.json 与 background.js，再通过 add_extension 加载。

manifest.json：

{
  "version": "1.0.0",
  "manifest_version": 2,
  "name": "proxy-auth",
  "permissions": ["proxy", "tabs", "unlimitedStorage", "storage", "<all_urls>"],
  "background": {"scripts": ["background.js"]}
}

background.js（将 IP、端口、用户名、密码替换为真实代理信息）：

var config = {
  mode: "fixed_servers",
  rules: {
    singleProxy: {scheme: "http", host: "IP", port: 端口}
  }
};
chrome.proxy.settings.set({value: config, scope: "regular"}, function() {});
function callbackFn(details) {
  return {authCredentials: {username: "用户名", password: "密码"}};
}
chrome.webRequest.onAuthRequired.addListener(
  callbackFn,
  {urls: ["<all_urls>"]},
  ["blocking"]
);

扩展生成后加载：

options.add_extension("path/to/proxy_auth_extension")
driver = webdriver.Chrome(options=options)

注意：Selenium 4 的 webdriver.ChromeOptions() 写法兼容旧版本；Chrome 对 --proxy-server 参数的解析保持稳定，直接可用。

Playwright 怎么挂代理？一个参数搞定

相比 Selenium，Playwright 对代理的支持更直接：launch 时传入 proxy 参数即可，且原生支持认证凭据：

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch(
        proxy={
            "server": "http://IP:端口",        # 或 socks5://IP:端口
            "username": "用户名",
            "password": "密码",
        }
    )
    page = browser.new_page()
    page.goto("https://example.com")
    print(page.title())
    browser.close()

需要更精细控制时，也可以把代理挂在浏览器上下文（context）级别，让不同上下文使用不同出口：

context = browser.new_context(
    proxy={"server": "http://IP:端口", "username": "用户名", "password": "密码"},
    user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) ...",
)
page = context.new_page()

Playwright 的 server 字段支持 http、https、socks5 三种协议，覆盖绝大多数代理类型；认证凭据是官方原生字段，不需要额外扩展，比 Selenium 少一步。

自动化场景怎么选代理？住宅还是数据中心

挂代理之前先选对类型。自动化业务大致分两类，选型逻辑完全不同：

第一类：低风险、可批量的数据采集。 例如抓取公开商品价格、行业资讯、公开目录。这类任务频率可控、不涉及登录态，对长期稳定性要求不高，静态数据中心代理是性价比之选——量大、速度快、成本低，做好限速与轮换即可完成多数采集任务。

第二类：需要登录、长期使用同一环境、涉及账号身份的自动化。 例如跨境电商店铺操作、社交媒体账号运营、需要维持登录态的 AI Agent 任务。这类业务要的是”稳定可信的出口身份”，住宅代理（尤其是静态住宅 / ISP 代理）更合适：出口来自真实住宅网络，平台信任度高；独享端口保证只有你使用，不会因他人违规被连带封禁。

一句话归纳：做量、做速度，选数据中心；做身份、做稳定，选住宅。

如果任务需要频繁更换访问来源（如批量市场调研、区域数据对比），还可以考虑动态住宅代理：每次请求轮换不同出口 IP，模拟多个真实用户访问。但要注意轮换节奏——每请求都换反而像爬虫特征，低频轮换（按分钟或按任务切换）更贴近真人。

为什么只挂 IP 还不够？环境一致性三层配置

这是自动化最容易踩的坑：以为挂了代理就”隐身”了，结果还是触发风控。原因在于，现代风控看的是组合特征，网络层只是其中一环：

• IP 归属：国家/地区、运营商、ASN 是否与业务场景一致；
• 设备指纹：浏览器 UA、Canvas、WebGL、字体、时区、语言等特征的组合；
• 行为频率：请求间隔、操作节奏、单次会话停留时长。

如果挂了代理但时区还是本地、语言还是默认、操作频率像机器，依然会被判定异常。一份完整的浏览器自动化防封配置，至少要覆盖三层：

1. 网络层：住宅代理或合适的出口 IP，归属地与业务保持一致；
2. 指纹层：固定浏览器指纹、合适的 UA、关闭 WebRTC 泄露（避免真实 IP 泄漏）；
3. 行为层：请求之间加随机延迟（如 2-6 秒抖动）、控制并发、必要时定时轮换 IP。

举一个典型的反例：出口 IP 在美国西海岸，账号时区却设置成东八区，登录后平台立刻能发现语言、时区与网络归属不一致，异常信号随之产生。反过来，把归属地、时区、语言、操作时段全部对齐到同一地区，访问记录才经得起风控的交叉核对。

把这三层对齐，自动化脚本的”人味”才会出来。这也是账号运营、养号类业务反复强调”一账号一 IP 一指纹”的原因——环境整体一致，才像真实用户。

批量任务怎么换 IP？动态住宅 + 轮换节奏

采集或调研类任务常常需要成百上千次请求。如果全部走同一个出口 IP，再干净的地址也会因为频率触发风控；合理做法是给任务配一个 IP 池，低频、稳定地轮换。

Playwright 中为每个上下文挂不同代理，即可实现”一任务一出口”：

以 kookeey 动态住宅代理为例：在管理后台「生成动态独享端口」后，
会拿到一组出口地址（服务器地址:端口 + 账号 + 密码），按任务填入列表即可

proxy_list = [
    "http://kookeey账号:kookeey密码@服务器地址:端口",   # 出口 1
    "http://kookeey账号:kookeey密码@服务器地址:端口",   # 出口 2
]
for i, url in enumerate(urls):
    ctx = browser.new_context(
        proxy={"server": proxy_list[i % len(proxy_list)]}
    )
    ...

requests 层面思路一致：用 Session 每次绑定一个出口，或维护一个代理池循环取用。关键在轮换节奏——按任务或按分钟切换，而不是每次请求都换；每请求都换本身就是明显的爬虫特征。

👉点击领取kookeey全球代理IP：领取288元优惠券+200Mb动态流量+100MB移动代理

kookeey 动态住宅代理支持自定义轮换时间，并提供完整流量管理面板，可实时查看线路流量、生成动态独享端口，适合”不同任务不同出口”的规模化场景。

常见报错：403 / 429 怎么排查

接好代理后，脚本仍可能报错，最常见的是两种：

• 403 Forbidden：访问被拒绝。通常是 UA 被识别为脚本，或出口 IP 被目标站点列入观察名单。先更换 UA，再检查 IP 纯净度（是否机房段、是否在黑名单），必要时更换线路。
• 429 Too Many Requests：请求频率超限。降低并发、加大请求间隔、做指数退避重试，比换 IP 更有效——换 IP 只是绕开当前限流，不调整频率还会继续触发。

排查顺序建议：先用 curl 验证代理连通性并确认出口 IP 是否正确，再看报错类型，最后分别调整 UA、频率、出口 IP。绝大多数自动化报错，走完这三步都能定位。

写在最后

把”AI 操作网页”和”代理”放在一起看，本质是同一个问题：自动化要做真人的事，就得有真人的网络身份。Playwright 一行 proxy 参数、Selenium 一个启动参数，接上适配的出口 IP，再配齐指纹与行为节奏，脚本的稳定性会有明显提升。

选代理时记住两个方向：做量选数据中心、做身份选住宅；选服务商时优先看 IP 纯净度控制——是否一 IP 一用、是否有冷静期沉淀、是否支持独享端口与 API 调用，这些直接决定自动化能不能长期稳定跑。

如果你的自动化已经跑在 Python 脚本里，kookeey 还支持通过 API 获取动态 IP：程序按需拉取出口、用完即释放，规模化采集时可以由代码调度整个代理池，无需手工维护地址列表。业务级 IP 池配合 6 个月冷静期，意味着每个 IP 在出售前完成沉淀与清洗；再结合独享端口使用，可以显著降低因出口共享导致的连带封禁风险。

kookeey 提供静态住宅（ISP）、静态数据中心、动态住宅、移动代理四类产品，统一支持 HTTP(S) 与 SOCKS5，配套可视化管理后台与 API，可按自动化业务的规模弹性配置并发，满足从单机脚本到大规模采集集群的不同需求。