反检测浏览器中的认证代理：2026支持地图

Chromium从未接受过SOCKS5的凭证，而仅传递--proxy-server的启动器无人响应身份验证提示。以下是哪些框架接受user:pass，哪些需要辅助工具，哪些是死胡同。

反检测浏览器中的认证代理以三种方式之一失败，症状从未改变：Chrome凭证弹出窗口无法关闭，每个请求的407，或从您自己的IP完美加载的页面。代理很少是问题所在。Chromium从未接受过SOCKS5的用户名和密码，而仅将--proxy-server转发给二进制文件的启动器无人响应浏览器的身份验证挑战。这是2026年的地图：哪些框架原生接受user:pass，哪些需要辅助工具，哪些是死胡同。

一个根本原因，三个症状

Chromium的代理堆栈有一个SOCKS5服务器地址的插槽，但没有凭证的插槽。请求多年来一直在Chromium跟踪器上作为问题40323993，SwitchyOmega扩展在其自己的问题#1455中记录了Chrome团队的确认，而追求同一问题的ChromeDriver用户被指向crbug 40829748。Firefox是个例外——它原生认证SOCKS5——这就是为什么Camoufox在这里与其他所有东西分列。如果协议分裂对您来说是新的，请从SOCKS5与HTTP代理开始。

HTTP和HTTPS代理是另一回事：凭证有效，只是从未在命令行中。Chrome通过提出身份验证挑战来响应407，必须有人响应——在正常浏览器中，您看到的弹出窗口。在自动化中，它必须是加载的扩展、订阅Fetch.authRequired的CDP处理程序或框架本身。任何仅传递启动标志的东西都留下了未回答的挑战，这就是人们不断截屏的挂起页面。凭证格式的另一半在修复407代理认证要求中涵盖。

反检测浏览器中的认证代理支持：2026地图

三个类别：API接受的凭证，仅通过您构建的辅助工具接受的凭证，以及引擎的限制，任何配置都无法移动。

原生支持user:pass

Playwright — 在启动或每个上下文中使用proxy={server, username, password}，仅记录HTTP(S)；另一半在Playwright SOCKS5代理认证中。
Patchright — 即插即用的Playwright替代品，相同的代理对象，并通过删除--disable-extensions故意保持扩展启用。参见Patchright代理设置。
browser-use — ProxySettings(server=..., username=..., password=...)，但要固定版本：问题#2445显示了一个在0.1.45上路由并在0.5.4上静默停止的配置。参见browser-use代理配置。
Camoufox — Firefox引擎，Playwright代理字典，也是唯一一个通过geoip=True从出口IP派生时区、区域设置、坐标和伪造的WebRTC地址的。参见Camoufox代理和GeoIP。
Puppeteer — 启动--proxy-server不带凭证，然后在导航前调用page.authenticate({username, password})。

需要扩展、转发或CDP处理程序

nodriver — 讨论#1798自2024年3月以来一直是热门结果：Chrome不接受浏览器参数中的凭证，接受的答案连接了一个CDP Fetch处理程序。nodriver代理认证中的演练。
zendriver — 分叉继承了这个缺口；问题#208要求认证代理，问题#10有用户改用代理扩展。参见zendriver代理认证。
SeleniumBase UC模式 — --proxy=USER:PASS@host:port在Chromium上有效，但仅因为它为您生成了一个Chrome扩展；Chrome 137的扩展更改正好破坏了这一点，问题#3046和#3918跟踪认证代理绕过的斗争。SeleniumBase UC模式代理不工作中的检查清单。
普通Selenium与Chrome — 根本没有原生机制；生态系统的答案是相同的生成扩展，这就是PyPI上的所有辅助包所做的。

从不工作：带凭证的SOCKS5

上面每个Chromium框架 — nodriver、zendriver、Patchright、SeleniumBase、Puppeteer和Playwright的Chromium都继承了引擎限制；至少Playwright抛出Browser does not support socks5 proxy authentication。
Playwright问题#10567 — 自2021年11月以来一直开放，仍标记为收集反馈。不要计划它的实现。
Camoufox — HTTP认证在其Firefox引擎上有效，但用户报告仅通过在前面放置本地代理使SOCKS5凭证工作，因此将该路径视为不明确而不是支持。
诚实的修复 — 使用HTTP端点，或将您的IP列入白名单并完全删除凭证。

认证代理支持的三列比较：具有原生用户和密码支持的框架，需要扩展或CDP处理程序的框架，以及在Chromium中从不工作的带凭证的SOCKS5 — 相同的Chromium核心，三种结果。第一列是配置更改，第二列是构建步骤，第三列是您需要绕过的引擎限制。

解决方法1：使用提供商的HTTP端点

这修复了上面链接的大多数线程，而且不花一分钱。如果您的提供商通过HTTP和SOCKS5公开相同的池，请将浏览器指向HTTP网关，凭证成为支持的参数而不是不支持的参数。代理端DNS免费：Chromium总是将名称解析推迟给HTTP代理。每个QuantumProxies计划都从相同的网关上提供HTTP和SOCKS5，因此切换是方案更改，而不是新订单。

# Playwright, Patchright and Camoufox all take the same proxy object.
# Swap the import line; the proxy config does not change.
from playwright.sync_api import sync_playwright   # or: from patchright.sync_api import ...

PROXY = {
    "server": "http://gate.quantumproxies.io:PORT",  # HTTP endpoint, not socks5://
    "username": "USER",
    "password": "PASS",
}

with sync_playwright() as p:
    browser = p.chromium.launch(proxy=PROXY, headless=False)
    page = browser.new_page()
    page.goto("https://httpbin.org/ip")
    print(page.inner_text("pre"))
    browser.close()

# Camoufox: same dict, plus geoip so timezone/locale/WebRTC follow the exit IP.
# pip install -U "camoufox[geoip]"
# with Camoufox(geoip=True, proxy=PROXY) as browser: ...

解决方法2：IP白名单

最干净的答案是删除身份验证步骤。通过IP白名单，您注册运行浏览器的机器的公共IP，网关通过源地址授权它——没有用户名，没有密码，没有弹出窗口，框架无需回答任何问题。此页面上的每个问题都立即消失，包括SOCKS5，因为没有凭证需要传递。它适用于固定的抓取服务器或在静态出口IP后面的容器，不适用于网络变化的笔记本电脑。白名单与每个QuantumProxies计划上的user:pass并行，因此生产可以列入白名单，而开发保留凭证。

在90M+住宅池中将您的IP列入白名单

解决方法3：生成的Chrome认证扩展或CDP处理程序

如果您必须在不接受凭证的Chromium框架上保留凭证，浏览器内部的某些东西必须回答挑战。选项一是一个设置代理并回复onAuthRequired的扩展——正是SeleniumBase在其--proxy标志后面构建的。在Manifest V3下，使其工作的两个权限是webRequest和webRequestAuthProvider；如果缺少第二个，监听器永远不会触发。

// manifest.json (MV3) — webRequestAuthProvider is the one people forget
{
  "name": "proxy-auth",
  "version": "1.0",
  "manifest_version": 3,
  "permissions": ["proxy", "webRequest", "webRequestAuthProvider"],
  "host_permissions": ["<all_urls>"],
  "background": { "service_worker": "background.js" }
}

// background.js
const HOST = "gate.quantumproxies.io";
const PORT = 8080;              // your gateway port
const USER = "USER", PASS = "PASS";

chrome.proxy.settings.set({
  value: {
    mode: "fixed_servers",
    rules: { singleProxy: { scheme: "http", host: HOST, port: PORT } },
  },
  scope: "regular",
});

chrome.webRequest.onAuthRequired.addListener(
  () => ({ authCredentials: { username: USER, password: PASS } }),
  { urls: ["<all_urls>"] },
  ["blocking"],
);

两个警告。扩展并不在每个无头配置中加载，因此这通常会在服务器上强制使用有头加虚拟显示。而且扩展表面会移动：SeleniumBase用户因Chrome 137扩展更改而失去代理认证，因此请固定您的浏览器和框架版本。

选项二跳过扩展并通过CDP回答挑战。这是nodriver讨论中的公认解决方案，顺序让每个人都感到困惑：在启用Fetch域之前注册处理程序，并且永远不要在处理程序内部等待，否则会死锁事件循环。

import asyncio, nodriver as uc

PROXY = "http://gate.quantumproxies.io:PORT"   # no credentials in the flag
USER, PASS = "USER", "PASS"

async def main():
    browser = await uc.start(browser_args=[f"--proxy-server={PROXY}"])
    tab = await browser.get("draft:,")

    async def on_auth(event: uc.cdp.fetch.AuthRequired):
        # fire-and-forget: awaiting here blocks every other request
        asyncio.create_task(tab.send(uc.cdp.fetch.continue_with_auth(
            request_id=event.request_id,
            auth_challenge_response=uc.cdp.fetch.AuthChallengeResponse(
                response="ProvideCredentials", username=USER, password=PASS),
        )))

    async def on_paused(event: uc.cdp.fetch.RequestPaused):
        asyncio.create_task(tab.send(uc.cdp.fetch.continue_request(request_id=event.request_id)))

    tab.add_handler(uc.cdp.fetch.RequestPaused, on_paused)
    tab.add_handler(uc.cdp.fetch.AuthRequired, on_auth)
    # enable AFTER the handlers are registered, or no event ever arrives
    await tab.send(uc.cdp.fetch.enable(handle_auth_requests=True))

    page = await browser.get("https://httpbin.org/ip")
    print(await page.get_content())

uc.loop().run_until_complete(main())

对比代理认证简单修复的清单，例如使用HTTP端点和IP白名单，与生成认证扩展或编写CDP处理程序等更难的修复 — 操作顺序：更改端点，然后将IP列入白名单。只有在两者都不可能时才构建扩展、转发或CDP挂钩。

解决方法4：本地转发

转发是您在localhost上运行的小代理，它使用凭证与上游网关通信，并为您的框架提供一个未经认证的监听器。浏览器连接到127.0.0.1，看不到身份验证挑战，凭证问题转移到一个没有问题的进程。这是从Chromium中使用带凭证的SOCKS5的唯一方法，也是Camoufox用户报告的做法。GitHub上的开源转发将上游凭证作为环境变量。保持监听器绑定到环回——在公共接口上的开放无认证代理是别人的免费带宽。构建与安装在SOCKS5认证的代理转发工具中涵盖。

# SeleniumBase UC Mode: one flag, extension generated for you
pytest test_proxy.py --uc --proxy=USER:PASS@gate.quantumproxies.io:PORT

# Relay route: credentials upstream, no auth on the local listener
SOCKS5_SERVER=gate.quantumproxies.io:PORT \
SOCKS5_USER=USER SOCKS5_PASSWORD=PASS \
  ./socks-relay.py 127.0.0.1:1080

# now every framework can use it, credentials and limitations gone
# playwright: proxy={"server": "socks5://127.0.0.1:1080"}
# nodriver:   browser_args=["--proxy-server=socks5://127.0.0.1:1080"]

选择哪条路线

固定服务器或静态出口IP：将其列入白名单并停止阅读。
动态机器，HTTP目标：HTTP端点与user:pass。
无认证API（nodriver、zendriver、普通Selenium）：CDP处理程序如果您拥有代码，扩展如果您没有。
SOCKS5强制，或仅支持此协议的工具：本地转发。
添加代理后立即绕过：怀疑出口IP的声誉，而不是框架——首先使用免费的IP质量检查器检查它。

常见问题

为什么Chrome不支持带用户名和密码的SOCKS5？

因为Chromium的网络堆栈从未实现SOCKS5用户名和密码认证方法。请求多年来一直在Chromium跟踪器上作为问题40323993，Chrome团队在相关扩展线程中确认不支持。这不是您遗漏的标志：没有命令行参数组合将SOCKS5凭证传递给Chromium，并且每个基于Chromium的框架都继承了这一点。

哪个反检测框架具有最佳代理支持？

对于认证HTTP代理，Playwright家族——Playwright、Patchright、browser-use和Camoufox——是最不痛苦的，因为凭证是一级参数。Camoufox通过其GeoIP选项将时区、区域设置和WebRTC与出口IP对齐，走得最远。以CDP为主的工具，nodriver和zendriver，在隐身方面很强，但期望您自己解决认证问题。

认证代理是否会在UC模式下破坏Cloudflare绕过？

它可能会，报告通常将两个单独的事情归咎于一个。生成的认证扩展更改了浏览器的表面，而代理更改了出口IP——声誉不佳的IP会触发任何框架都无法通过的困难挑战。在责怪框架之前，先用代理和白名单IP对同一目标进行两次测试。

IP白名单比user:pass更安全吗？

从操作上讲，它更简单并消除了整个失败类别，因为没有任何东西需要回答挑战，凭证也不会出现在启动标志或进程列表中。权衡是灵活性：它将池绑定到固定的源地址，因此在变化网络上的笔记本电脑和自动扩展的工作者仍然需要凭证。大多数团队将生产列入白名单，并为开发保留user:pass。

地图足够短，可以记住。Playwright及其分叉接受凭证；nodriver和zendriver让您自己构建答案；SeleniumBase为您构建并偶尔中断；带凭证的SOCKS5在Chromium中是死胡同。其余的是在HTTP端点、白名单IP、扩展和转发之间选择——按此顺序，因为这也是从最少到最多的维护。

在一个计划中获取HTTP、SOCKS5和IP白名单