Proxies Autenticados em Navegadores Anti-Detect: Mapa de Suporte 2026
O Chromium nunca aceitou credenciais no SOCKS5, e um launcher que apenas passa --proxy-server não tem ninguém para responder ao prompt de autenticação. Aqui está qual framework aceita user:pass, qual precisa de um auxiliar e qual é um beco sem saída.
Um proxy autenticado em um navegador anti-detect falha de três maneiras, e os sintomas nunca mudam: um popup de credenciais do Chrome que nada pode dispensar, um 407 em cada solicitação ou uma página que carrega perfeitamente do seu próprio IP. O proxy raramente é o culpado. O Chromium nunca aceitou um nome de usuário e senha no SOCKS5, e um launcher que apenas encaminha --proxy-server para o binário não tem ninguém para responder ao desafio de autenticação do navegador. Este é o mapa de 2026: quais frameworks aceitam user:pass nativamente, quais precisam de um auxiliar e onde o caminho termina.
Uma causa raiz, três sintomas
A pilha de proxy do Chromium tem um slot para um endereço de servidor SOCKS5 e nenhum slot para credenciais. A solicitação está no rastreador do Chromium como problema 40323993 há anos, a extensão SwitchyOmega registrou a confirmação da equipe do Chrome em seu próprio problema #1455, e os usuários do ChromeDriver perseguindo a mesma coisa são direcionados para o crbug 40829748. O Firefox é a exceção — ele autentica SOCKS5 nativamente — e é por isso que o Camoufox está em uma coluna diferente de tudo o mais aqui. Se a divisão de protocolo é nova para você, comece com SOCKS5 vs proxies HTTP.
Proxies HTTP e HTTPS são uma história diferente: as credenciais funcionam, apenas nunca a partir da linha de comando. O Chrome responde a um 407 levantando um desafio de autenticação, e algo tem que responder — em um navegador normal, o popup que você vê. Na automação, deve ser uma extensão carregada, um manipulador CDP inscrito em Fetch.authRequired ou o próprio framework. Qualquer coisa que apenas passa um sinalizador de lançamento deixa o desafio sem resposta, e essa é a página travada que as pessoas continuam capturando. A metade do formato de credenciais é coberta em corrigindo 407 proxy authentication required.
Suporte a proxy autenticado em navegadores anti-detect: o mapa de 2026
Três baldes: credenciais aceitas pela API, credenciais aceitas apenas via um auxiliar que você constrói e um limite do motor que nenhuma configuração moverá.
Funciona nativamente com user:pass
- Playwright —
proxy={server, username, password}no lançamento ou por contexto, documentado apenas para HTTP(S); a outra metade está em autenticação proxy SOCKS5 Playwright. - Patchright — substituto direto do Playwright, objeto de proxy idêntico, e mantém deliberadamente as extensões ativadas ao descartar
--disable-extensions. Veja configuração de proxy Patchright. - browser-use —
ProxySettings(server=..., username=..., password=...), mas fixe a versão: o problema #2445 mostra uma configuração que roteou na 0.1.45 e parou silenciosamente na 0.5.4. Veja configuração de proxy browser-use. - Camoufox — motor Firefox, dicionário de proxy Playwright, e o único que também deriva fuso horário, localidade, coordenadas e o endereço WebRTC falsificado do IP de saída via
geoip=True. Veja proxy Camoufox e GeoIP. - Puppeteer — lança
--proxy-serversem credenciais, depois chamapage.authenticate({username, password})antes de navegar.
Precisa de uma extensão, um relay ou um manipulador CDP
- nodriver — a discussão #1798 tem sido o resultado principal desde março de 2024: o Chrome não aceita credenciais via argumentos do navegador, e a resposta aceita conecta um manipulador CDP
Fetch. Tutorial em autenticação proxy nodriver. - zendriver — o fork herda a lacuna; o problema #208 pede proxies autenticados e o problema #10 tem um usuário trocando para uma extensão de proxy em vez disso. Veja zendriver proxy com autenticação.
- SeleniumBase UC Mode —
--proxy=USER:PASS@host:portfunciona no Chromium, mas apenas porque gera uma extensão Chrome para você; as mudanças de extensão do Chrome 137 quebraram exatamente isso, e os problemas #3046 e #3918 rastreiam proxies de autenticação lutando contra o bypass. Lista de verificação em SeleniumBase UC Mode proxy não funcionando. - Selenium simples com Chrome — nenhum mecanismo nativo; a resposta do ecossistema é a mesma extensão gerada, que é tudo o que os pacotes auxiliares no PyPI fazem.
Nunca funciona: SOCKS5 com credenciais
- Todo framework Chromium acima — nodriver, zendriver, Patchright, SeleniumBase, Puppeteer e o Chromium do Playwright herdam o limite do motor; o Playwright pelo menos lança
Browser does not support socks5 proxy authentication. - Problema #10567 do Playwright — aberto desde novembro de 2021 e ainda rotulado como coletando feedback. Não planeje em torno de seu lançamento.
- Camoufox — a autenticação HTTP funciona em seu motor Firefox, mas os usuários relatam conseguir que as credenciais SOCKS5 funcionem apenas colocando um proxy local na frente, então trate esse caminho como incerto em vez de suportado.
- A correção honesta — use o endpoint HTTP, ou coloque seu IP na lista de permissões e elimine completamente as credenciais.

Solução alternativa 1: use o endpoint HTTP do provedor
Isso resolve a maioria dos tópicos vinculados acima, e não custa nada. Se o seu provedor expõe o mesmo pool sobre HTTP e SOCKS5, aponte o navegador para o gateway HTTP e as credenciais se tornam um parâmetro suportado em vez de um não suportado. O DNS do lado do proxy vem de graça: o Chromium sempre delega a resolução de nomes a um proxy HTTP. Todo plano QuantumProxies serve HTTP e SOCKS5 do mesmo gateway com as mesmas credenciais, então a troca é uma mudança de esquema, não um novo pedido.
# 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: ...
Solução alternativa 2: lista de permissões de IP
A resposta mais limpa é eliminar a etapa de autenticação. Com a lista de permissões de IP, você registra o IP público da máquina que executa o navegador e o gateway o autoriza pelo endereço de origem — sem nome de usuário, sem senha, sem popup, nada para o framework responder. Todo problema nesta página desaparece de uma vez, SOCKS5 incluído, porque não há credencial a ser passada. É ideal para um servidor de scraping fixo ou um contêiner atrás de um IP de saída estático, e inadequado para laptops em redes que mudam. A lista de permissões está ao lado de user:pass em todo plano QuantumProxies, então a produção pode ser colocada na lista de permissões enquanto o desenvolvimento mantém as credenciais.
Coloque seu IP na lista de permissões em um pool residencial de 90M+
Solução alternativa 3: uma extensão de autenticação Chrome gerada ou um manipulador CDP
Se você deve manter credenciais em um framework Chromium que não as aceita, algo dentro do navegador precisa responder ao desafio. A primeira opção é uma extensão que define o proxy e responde a onAuthRequired — exatamente o que o SeleniumBase constrói por trás de seu sinalizador --proxy. Sob o Manifest V3, as duas permissões que o fazem funcionar são webRequest e webRequestAuthProvider; perca a segunda e o ouvinte nunca dispara.
// 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"],
);
Duas advertências. As extensões não carregam em todas as configurações sem cabeça, então isso geralmente força o modo com cabeça mais uma exibição virtual em servidores. E a superfície da extensão se move: os usuários do SeleniumBase perderam a autenticação de proxy para uma mudança de extensão do Chrome 137, então fixe suas versões do navegador e do framework.
A segunda opção pula a extensão e responde ao desafio via CDP. Esta é a solução aceita na discussão do nodriver, e a ordem confunde a todos: registre os manipuladores antes de habilitar o domínio Fetch, e nunca aguarde dentro de um manipulador ou você bloqueia o loop de eventos.
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())

Solução alternativa 4: um relay local
Um relay é um pequeno proxy que você executa no localhost que fala com o gateway upstream com credenciais e oferece ao seu framework um ouvinte não autenticado. O navegador se conecta a 127.0.0.1, não vê desafio de autenticação, e o problema de credencial se move para um processo que não tem problema com isso. Esta é a única maneira de usar SOCKS5 com credenciais do Chromium, e o que os usuários do Camoufox relatam fazer. Relays de código aberto no GitHub aceitam as credenciais upstream como variáveis de ambiente. Mantenha o ouvinte vinculado ao loopback — um proxy aberto sem autenticação em uma interface pública é a largura de banda gratuita de outra pessoa. Construir versus instalar é coberto em ferramentas de relay de proxy para autenticação 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"]
Qual rota escolher
- Servidor fixo ou IP de saída estático: coloque na lista de permissões e pare de ler.
- Máquinas dinâmicas, alvos HTTP: o endpoint HTTP com
user:pass. - API sem autenticação (nodriver, zendriver, Selenium simples): manipulador CDP se você possui o código, extensão se não possui.
- SOCKS5 obrigatório ou uma ferramenta que não fala outra coisa: relay local.
- O bypass regrediu no momento em que você adicionou o proxy: suspeite da reputação do IP de saída, não do framework — verifique primeiro com o verificador de qualidade de IP gratuito.
Perguntas frequentes
Por que o Chrome não suporta SOCKS5 com nome de usuário e senha?
Porque a pilha de rede do Chromium nunca implementou o método de autenticação de nome de usuário e senha do SOCKS5. A solicitação está no rastreador do Chromium há anos como problema 40323993, e a equipe do Chrome confirmou que não é suportado em threads de extensão relacionados. Não é um sinalizador que você está perdendo: nenhuma combinação de argumentos de linha de comando passa credenciais SOCKS5 para o Chromium, e todo framework baseado em Chromium herda isso.
Qual framework anti-detect tem o melhor suporte a proxy?
Para proxies HTTP autenticados, a família Playwright — Playwright, Patchright, browser-use e Camoufox — é a menos dolorosa, porque as credenciais são um parâmetro de primeira classe. O Camoufox vai mais longe ao alinhar fuso horário, localidade e WebRTC com o IP de saída através de sua opção GeoIP. As ferramentas CDP-first, nodriver e zendriver, são fortes em stealth, mas esperam que você resolva a autenticação por conta própria.
Um proxy de autenticação quebra o bypass do Cloudflare no Modo UC?
Pode, e os relatos geralmente culpam duas coisas separadas como uma só. A extensão de autenticação gerada muda a superfície do navegador, e o proxy muda o IP de saída — e um IP com má reputação aciona desafios difíceis que nenhum framework pode passar. Teste o mesmo alvo duas vezes, uma vez com o proxy e outra com um IP na lista de permissões, antes de culpar o framework.
A lista de permissões de IP é mais segura que user:pass?
Operacionalmente é mais simples e remove toda uma classe de falhas, já que nada precisa responder a um desafio e as credenciais nunca ficam em um sinalizador de lançamento ou lista de processos. A troca é a flexibilidade: ela vincula o pool a um endereço de origem fixo, então laptops em redes que mudam e trabalhadores de escalonamento automático ainda precisam de credenciais. A maioria das equipes coloca a produção na lista de permissões e mantém user:pass para desenvolvimento.
O mapa é curto o suficiente para memorizar. Playwright e seus forks aceitam credenciais; nodriver e zendriver fazem você construir a resposta; SeleniumBase constrói para você e ocasionalmente quebra; SOCKS5 com credenciais é um beco sem saída no Chromium. O resto é escolher entre endpoint HTTP, IP na lista de permissões, extensão e relay — nessa ordem, porque também é de menos para mais manutenção.
Obtenha HTTP, SOCKS5 e lista de permissões de IP em um único plano