Proxies Autenticados en Navegadores Anti-Detect: Mapa de Soporte 2026
Chromium nunca ha aceptado credenciales en SOCKS5, y un lanzador que solo pasa --proxy-server no tiene a nadie que responda al aviso de autenticación. Aquí está qué marco toma user:pass, cuál necesita un ayudante y cuál es un callejón sin salida.
Un proxy autenticado en un navegador anti-detect falla de tres maneras, y los síntomas nunca cambian: un popup de credenciales de Chrome que nada puede cerrar, un 407 en cada solicitud, o una página que carga perfectamente desde tu propia IP. Rara vez es culpa del proxy. Chromium nunca ha aceptado un nombre de usuario y contraseña en SOCKS5, y un lanzador que solo reenvía --proxy-server al binario no tiene a nadie que responda al desafío de autenticación del navegador. Este es el mapa 2026: qué marcos toman user:pass de forma nativa, cuáles necesitan un ayudante y dónde termina el camino.
Una causa raíz, tres síntomas
La pila de proxy de Chromium tiene un espacio para una dirección de servidor SOCKS5 y ningún espacio para credenciales. La solicitud ha estado en el rastreador de Chromium como el problema 40323993 durante años, la extensión SwitchyOmega registró la confirmación del equipo de Chrome en su propio problema #1455, y los usuarios de ChromeDriver que buscan lo mismo son dirigidos al crbug 40829748. Firefox es la excepción: autentica SOCKS5 de forma nativa, por lo que Camoufox aterriza en una columna diferente a todo lo demás aquí. Si la división de protocolos es nueva para ti, comienza con SOCKS5 vs proxies HTTP.
Los proxies HTTP y HTTPS son una historia diferente: las credenciales funcionan, solo que nunca desde la línea de comandos. Chrome responde a un 407 levantando un desafío de autenticación, y algo tiene que responder, en un navegador normal, el popup que ves. En automatización debe ser una extensión cargada, un manejador CDP suscrito a Fetch.authRequired, o el propio marco. Cualquier cosa que solo pase un flag de lanzamiento deja el desafío sin respuesta, y esa es la página colgada que la gente sigue capturando en pantalla. La mitad del formato de credenciales se cubre en arreglando 407 proxy authentication required.
Soporte de proxy autenticado en navegadores anti-detect: el mapa 2026
Tres categorías: credenciales aceptadas por la API, credenciales aceptadas solo a través de un ayudante que construyes, y un límite del motor que ninguna configuración moverá.
Funciona de forma nativa con user:pass
- Playwright —
proxy={server, username, password}al inicio o por contexto, documentado solo para HTTP(S); la otra mitad está en autenticación de proxy socks5 playwright. - Patchright — reemplazo de Playwright, objeto de proxy idéntico, y mantiene deliberadamente las extensiones habilitadas al omitir
--disable-extensions. Ver configuración de proxy patchright. - browser-use —
ProxySettings(server=..., username=..., password=...), pero fija la versión: el problema #2445 muestra una configuración que funcionó en 0.1.45 y se detuvo silenciosamente en 0.5.4. Ver configuración de proxy browser-use. - Camoufox — motor Firefox, diccionario de proxy Playwright, y el único que también deriva zona horaria, localización, coordenadas y la dirección WebRTC falsificada desde la IP de salida a través de
geoip=True. Ver proxy Camoufox y GeoIP. - Puppeteer — lanza
--proxy-serversin credenciales, luego llama apage.authenticate({username, password})antes de navegar.
Necesita una extensión, un relé o un manejador CDP
- nodriver — la discusión #1798 ha sido el resultado principal desde marzo de 2024: Chrome no toma credenciales a través de argumentos del navegador, y la respuesta aceptada conecta un manejador CDP
Fetch. Guía en autenticación de proxy nodriver. - zendriver — el fork hereda la brecha; el problema #208 pide proxies autenticados y el problema #10 tiene un usuario cambiando a una extensión de proxy en su lugar. Ver zendriver proxy con autenticación.
- SeleniumBase UC Mode —
--proxy=USER:PASS@host:portfunciona en Chromium, pero solo porque genera una extensión de Chrome para ti; los cambios de extensión de Chrome 137 rompieron exactamente eso, y los problemas #3046 y #3918 rastrean proxies de autenticación luchando contra el bypass. Lista de verificación en SeleniumBase UC Mode proxy no funciona. - Selenium simple con Chrome — sin mecanismo nativo en absoluto; la respuesta del ecosistema es la misma extensión generada, que es todo lo que hacen los paquetes de ayuda en PyPI.
Nunca funciona: SOCKS5 con credenciales
- Cada marco de Chromium arriba — nodriver, zendriver, Patchright, SeleniumBase, Puppeteer y el Chromium de Playwright heredan el límite del motor; al menos Playwright lanza
Browser does not support socks5 proxy authentication. - Problema de Playwright #10567 — abierto desde noviembre de 2021 y aún etiquetado como recopilando comentarios. No planees en torno a que se resuelva.
- Camoufox — la autenticación HTTP funciona en su motor Firefox, pero los usuarios informan que las credenciales SOCKS5 solo funcionan al poner un proxy local al frente, así que trata ese camino como incierto en lugar de soportado.
- La solución honesta — usa el endpoint HTTP, o lista blanca tu IP y elimina las credenciales por completo.

Solución 1: usa el endpoint HTTP del proveedor
Esto soluciona la mayoría de los hilos enlazados arriba, y no cuesta nada. Si tu proveedor expone el mismo pool sobre HTTP y SOCKS5, apunta el navegador al gateway HTTP y las credenciales se convierten en un parámetro soportado en lugar de uno no soportado. El DNS del lado del proxy viene gratis: Chromium siempre delega la resolución de nombres a un proxy HTTP. Cada plan de QuantumProxies sirve HTTP y SOCKS5 desde el mismo gateway con las mismas credenciales, por lo que cambiar es un cambio de esquema, no un nuevo 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: ...
Solución 2: lista blanca de IP
La respuesta más limpia es eliminar el paso de autenticación. Con la lista blanca de IP registras la IP pública de la máquina que ejecuta el navegador y el gateway la autoriza por dirección de origen — sin nombre de usuario, sin contraseña, sin popup, nada para que el marco responda. Cada problema en esta página desaparece de una vez, SOCKS5 incluido, porque no queda credencial para pasar. Es adecuado para un servidor de scraping fijo o un contenedor detrás de una IP de salida estática, y no adecuado para laptops en redes cambiantes. La lista blanca se encuentra junto a user:pass en cada plan de QuantumProxies, por lo que producción puede estar en lista blanca mientras desarrollo mantiene las credenciales.
Lista blanca de tu IP en un pool residencial de más de 90M
Solución 3: una extensión de autenticación de Chrome generada, o un manejador CDP
Si debes mantener credenciales en un marco de Chromium que no las acepta, algo dentro del navegador debe responder al desafío. La opción uno es una extensión que establece el proxy y responde a onAuthRequired — exactamente lo que SeleniumBase construye detrás de su flag --proxy. Bajo Manifest V3 los dos permisos que lo hacen funcionar son webRequest y webRequestAuthProvider; si falta el segundo, el listener nunca se activa.
// 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"],
);
Dos advertencias. Las extensiones no se cargan en cada configuración sin cabeza, por lo que esto a menudo obliga a usar una configuración con cabeza más una pantalla virtual en servidores. Y la superficie de la extensión se mueve: los usuarios de SeleniumBase perdieron la autenticación de proxy por un cambio de extensión en Chrome 137, así que fija tus versiones de navegador y marco.
La opción dos omite la extensión y responde al desafío sobre CDP. Esta es la solución aceptada en la discusión de nodriver, y el orden confunde a todos: registra los manejadores antes de habilitar el dominio Fetch, y nunca esperes dentro de un manejador o bloquearás el bucle 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())

Solución 4: un relé local
Un relé es un pequeño proxy que ejecutas en localhost que habla con el gateway ascendente con credenciales y ofrece a tu marco un listener no autenticado. El navegador se conecta a 127.0.0.1, no ve desafío de autenticación, y el problema de credenciales se traslada a un proceso que no tiene problemas con él. Esta es la única forma de usar SOCKS5 con credenciales desde Chromium en absoluto, y lo que los usuarios de Camoufox informan hacer. Los relés de código abierto en GitHub toman las credenciales ascendentes como variables de entorno. Mantén el listener vinculado al loopback — un proxy sin autenticación abierto en una interfaz pública es el ancho de banda gratuito de otra persona. Construir versus instalar se cubre en herramientas de relé de proxy para autenticación 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"]
Qué ruta elegir
- Servidor fijo o IP de salida estática: lista blanca y deja de leer.
- Máquinas dinámicas, objetivos HTTP: el endpoint HTTP con
user:pass. - API sin autenticación (nodriver, zendriver, Selenium simple): manejador CDP si posees el código, extensión si no lo haces.
- SOCKS5 obligatorio, o una herramienta que no habla nada más: relé local.
- El bypass retrocedió en el momento en que agregaste el proxy: sospecha de la reputación de la IP de salida, no del marco — verifícalo primero con el verificador de calidad de IP gratuito.
Preguntas frecuentes
¿Por qué Chrome no soporta SOCKS5 con nombre de usuario y contraseña?
Porque la pila de red de Chromium nunca implementó el método de autenticación de nombre de usuario y contraseña de SOCKS5. La solicitud ha estado en el rastreador de Chromium durante años como el problema 40323993, y el equipo de Chrome ha confirmado que no está soportado en hilos de extensión relacionados. No es un flag que te falte: ninguna combinación de argumentos de línea de comandos pasa credenciales SOCKS5 a Chromium, y cada marco basado en Chromium hereda eso.
¿Qué marco anti-detect tiene el mejor soporte de proxy?
Para proxies HTTP autenticados, la familia Playwright — Playwright, Patchright, browser-use y Camoufox — es la menos dolorosa, porque las credenciales son un parámetro de primera clase. Camoufox va más allá al alinear la zona horaria, localización y WebRTC con la IP de salida a través de su opción GeoIP. Las herramientas centradas en CDP, nodriver y zendriver, son fuertes en sigilo pero esperan que resuelvas la autenticación tú mismo.
¿Un proxy de autenticación rompe el bypass de Cloudflare en el Modo UC?
Puede, y los informes generalmente culpan a dos cosas separadas como una. La extensión de autenticación generada cambia la superficie del navegador, y el proxy cambia la IP de salida — y una IP con mala reputación desencadena desafíos difíciles que ningún marco puede superar. Prueba el mismo objetivo dos veces, una vez con el proxy y otra con una IP en lista blanca, antes de culpar al marco.
¿Es más seguro la lista blanca de IP que user:pass?
Operativamente es más simple y elimina toda una clase de fallos, ya que nada tiene que responder a un desafío y las credenciales nunca se sientan en un flag de lanzamiento o lista de procesos. La compensación es la flexibilidad: vincula el pool a una dirección de origen fija, por lo que las laptops en redes cambiantes y los trabajadores de escalado automático aún necesitan credenciales. La mayoría de los equipos ponen en lista blanca la producción y mantienen user:pass para el desarrollo.
El mapa es lo suficientemente corto como para memorizarlo. Playwright y sus forks toman credenciales; nodriver y zendriver te hacen construir la respuesta; SeleniumBase la construye para ti y ocasionalmente falla; SOCKS5 con credenciales es un callejón sin salida en Chromium. El resto es elegir entre endpoint HTTP, IP en lista blanca, extensión y relé — en ese orden, porque también es de menor a mayor mantenimiento.