# 反检测浏览器中的认证代理：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代理](https://quantumproxies.io/blog/socks5-vs-http-proxy-difference)开始。

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

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

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

**原生支持user:pass**

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

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

- **nodriver** — 讨论#1798自2024年3月以来一直是热门结果：Chrome不接受浏览器参数中的凭证，接受的答案连接了一个CDP `Fetch`处理程序。[nodriver代理认证](https://quantumproxies.io/blog/nodriver-proxy-authentication)中的演练。
- **zendriver** — 分叉继承了这个缺口；问题#208要求认证代理，问题#10有用户改用代理扩展。参见[zendriver代理认证](https://quantumproxies.io/blog/zendriver-proxy-with-authentication)。
- **SeleniumBase UC模式** — `--proxy=USER:PASS@host:port`在Chromium上有效，但仅因为它为您生成了一个Chrome扩展；Chrome 137的扩展更改正好破坏了这一点，问题#3046和#3918跟踪认证代理绕过的斗争。[SeleniumBase UC模式代理不工作](https://quantumproxies.io/blog/seleniumbase-uc-mode-proxy-not-working)中的检查清单。
- **普通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列入白名单并完全删除凭证。

![同一 Chromium 内核上认证代理支持情况的三列图：原生接受用户名和密码的框架，需要扩展或 CDP 处理程序的框架，以及在 Chromium 中始终无法使用的带凭据 SOCKS5。卡片说明了每一列的代价。](https://res.cloudinary.com/dmqliab0t/image/upload/f_auto,q_auto,w_1200/v1785776556/blog/generated/qp-b10-010-diag1.png)
*相同的Chromium核心，三种结果。第一列是配置更改，第二列是构建步骤，第三列是您需要绕过的引擎限制。*

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

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

```python
# 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://residentialpremium.quantumproxies.io:8080",  # 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列入白名单](https://quantumproxies.io/residential-proxies)

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

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

```js
// 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 = "residentialpremium.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域之前注册处理程序，并且永远不要在处理程序内部等待，否则会死锁事件循环。

```python
import asyncio, nodriver as uc

PROXY = "http://residentialpremium.quantumproxies.io:8080"   # 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("data:,")

    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 加入白名单，最后才考虑构建 Chrome 认证扩展、CDP 处理程序或本地中继。卡片对比了无需额外代码的简单修复，和需要有头模式运行、锁定版本的较难修复。](https://res.cloudinary.com/dmqliab0t/image/upload/f_auto,q_auto,w_1200/v1785776556/blog/generated/qp-b10-010-diag2.png)
*操作顺序：更改端点，然后将IP列入白名单。只有在两者都不可能时才构建扩展、转发或CDP挂钩。*

## 解决方法4：本地转发

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

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

# Relay route: credentials upstream, no auth on the local listener
SOCKS5_SERVER=residentialpremium.quantumproxies.io:1080 \
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质量检查器](https://quantumproxies.io/ip-checker)检查它。

## 常见问题

### 为什么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白名单](https://quantumproxies.io/residential-proxies)