Autenticación de proxy: usuario y contraseña o whitelist de IP

Un proxy tiene dos formas de saber que una conexión es tuya. O el cliente lo demuestra en cada conexión con usuario y contraseña, o el proxy mantiene una lista de direcciones que pueden entrar sin demostrar nada. Ambas son sencillas, ambas se usan muchísimo y cada una tiene sus propios errores.

En esta guía verás qué envía realmente cada método por la red (medido en un proxy de prueba, no descrito de memoria), qué herramientas solo admiten uno de los dos y el fallo de contraseña que explica buena parte de los «el proxy no funciona» del primer día.

Qué envían realmente el usuario y la contraseña

Con un proxy HTTP, las credenciales viajan en una cabecera Proxy-Authorization en cada petición o túnel. Lanzamos curl contra un proxy de prueba que registra todo lo que recibe:

curl -x http://user:p%40ss%23word@127.0.0.1:18407 http://example.com/

El proxy recibió:

Proxy-Authorization: Basic dXNlcjpwQHNzI3dvcmQ=

Esa cadena no es un hash. dXNlcjpwQHNzI3dvcmQ= es el base64 de user:p@ss#word, y cualquiera que pueda leer la conexión lo decodifica en una línea. La autenticación Basic codifica la contraseña, no la cifra. Entre tu máquina y un proxy HTTP, el login cruza la red de forma legible para cualquiera que esté en el camino, salvo que la conexión con el proxy vaya por TLS, algo que en la mayoría de los servicios de proxy no ocurre. Por eso las credenciales del proxy deben tratarse como un secreto de la misma categoría que una API key, y por eso no deben aparecer en el historial de la shell, en los logs de CI ni en capturas de pantalla.

Con SOCKS5 las credenciales no van en una cabecera: son un paso del handshake del protocolo (el método usuario/contraseña de RFC 1929), y por eso los clientes SOCKS las piden en campos separados en lugar de dentro de la URL. También se envían en texto plano.

Dos códigos de respuesta te dicen dónde está el fallo:

• 407 Proxy Authentication Required lo devuelve el proxy. El login faltaba o era incorrecto. Nuestro proxy de prueba respondió 407 tanto a una petición sin credenciales como a una con la contraseña equivocada.
• 401 Unauthorized lo devuelve el sitio de destino. El proxy te dejó pasar; es el sitio el que pide su propio login.

La mayor parte del tiempo perdido con la «autenticación» se va en depurar el código equivocado de los dos. La lista completa de comprobaciones para el primero está en 407 Proxy Authentication Required.

El fallo de contraseña que rompe la mayoría de las primeras configuraciones

Las credenciales dentro de una URL tienen esta forma: http://user:password@host:port. La sintaxis de URL usa @ para separar las credenciales del host y # para iniciar un fragmento. Una contraseña que contenga cualquiera de los dos rompe el análisis, y las librerías no te avisan: hacen algo incorrecto con total seguridad.

Le pasamos a Python requests la contraseña p@ss#word tal cual:

proxies = {"http": "http://user:p@ss#word@127.0.0.1:18407"}

No falló con un «contraseña incorrecta». Intentó conectarse a un proxy llamado ss en el puerto 80:

ProxyError: HTTPConnectionPool(host='ss', port=80): Max retries exceeded

La misma petición con la contraseña codificada en porcentaje, p%40ss%23word, devolvió 200, igual que httpx con la forma codificada.

La regla: dentro de una URL, codifica la contraseña en porcentaje: @ como %40, # como %23, : como %3A, / como %2F. O evita la URL por completo y pasa las credenciales en campos separados cuando la herramienta lo permita: username y password en Playwright, page.authenticate en Puppeteer, los campos de login de cualquier perfil de navegador antidetect. Con campos separados no hay problema de codificación.

Qué es una whitelist de IP y qué no es

Una whitelist es una lista de direcciones de origen que el proxy acepta sin credenciales. Añades la dirección pública de la máquina que se va a conectar y, a partir de ahí, esa máquina no envía ningún login.

Existe por un motivo real: algunas herramientas no pueden enviar credenciales de proxy. Selenium es el caso típico. Ni Chrome ni Firefox aceptan un login de proxy mediante la capability estándar de WebDriver, así que las opciones son un complemento como selenium-wire, una extensión generada o añadir la máquina a la whitelist. Para un scraper en un servidor fijo, la whitelist es sencillamente menos configuración.

No es una mejora de seguridad. Falla de tres maneras, y las tres en silencio:

• La dirección cambia. Una conexión doméstica, un hotspot móvil, un portátil que pasa de una red a otra. La entrada de la whitelist queda obsoleta y el proxy empieza a responder 407 a una máquina en la que «no se ha tocado nada». Añade servidores a la whitelist, no portátiles.
• La dirección es compartida. En un host en la nube, una conexión de oficina compartida o un operador detrás de NAT, la dirección pública no es solo tuya. Cualquiera que pueda enviar tráfico desde ella hereda tu acceso y tu factura de tráfico.
• La dirección no es la que crees. Los contenedores, las VPN y la salida corporativa cambian la dirección que ve el proxy. Compruébala con una petición simple a un servicio que muestre tu IP desde la propia máquina, no desde tu navegador.

Y mantén las credenciales operativas en paralelo. Si la whitelist es tu única vía de entrada y la dirección del servidor cambia, te has dejado fuera tú mismo.

Cuál usar según la situación

Un detalle propio de cómo algunos proveedores, nosotros incluidos, estructuran el login: el nombre de usuario no es solo una identidad, también lleva la segmentación. Nuestro login residencial admite sufijos de país, ciudad y sesión sticky, como login_c_US_s_7_ttl_1h. Con una whitelist no hay login, así que no hay dónde ponerlos y se aplican los valores por defecto. Si necesitas geolocalización o sesiones por petición, eso por sí solo inclina la balanza hacia las credenciales. La sintaxis de los sufijos está en la referencia de la cadena de conexión.

Qué productos admiten cada método

Esto varía según el proveedor, y conviene comprobarlo antes de comprar, no después. Con nosotros, los proxies residenciales admiten tanto credenciales como whitelist; las direcciones ISP, de datacenter, IPv6 y móviles se autentican solo con credenciales. La whitelist se gestiona desde el panel o a través de la API, y la referencia de autenticación y whitelist de IP tiene los endpoints.

Cómo evitar que las credenciales acaben donde no deben

Como un login de proxy se puede leer en la red y lo puede reutilizar cualquiera que lo tenga, las reglas de manejo son las de cualquier secreto:

• Fuera de la línea de comandos siempre que puedas. curl -x http://user:pass@... acaba en el historial de la shell. Usa --proxy-user con solicitud de contraseña, una variable de entorno o un archivo de configuración con permisos restringidos.
• Fuera de repositorios y logs de CI. Las librerías imprimen la URL del proxy en los mensajes de error, credenciales incluidas, como muestra el error de requests de arriba. Censúralas antes de pegar un traceback en cualquier sitio.
• Logins separados por proyecto cuando el proveedor lo permita, para que una filtración en un sitio no te cueste la cuenta entera.
• Rota las credenciales cuando se vaya cualquiera que tuviera el login. Una entrada en la whitelist para el servidor de un contratista que ya no está es el mismo problema en otra forma.

Cómo comprobar qué método está en juego

Tres pruebas rápidas, desde la máquina que realmente va a usar el proxy:

1. Petición con credenciales. Un 200 significa que las credenciales funcionan. Un 407 significa que el login es incorrecto o está mal formado; revisa primero la codificación.
2. Petición sin credenciales. Un 200 significa que tu dirección está en la whitelist (o que el proxy está abierto, que es otro problema). Un 407 significa que no lo está.
3. Petición con credenciales desde otra red. Un 200 confirma que lo que funciona son las credenciales, no la dirección.

Cada prueba es un solo comando curl, y las tres juntas llevan un minuto. El conjunto completo de comprobaciones antes de pagar por volumen está en cómo probar un proxy antes de comprarlo.

Preguntas frecuentes

¿Qué es la autenticación de proxy?

La forma en que un proxy decide si atiende una conexión: o el cliente envía usuario y contraseña en cada conexión, o el proxy acepta conexiones de una lista de direcciones de origen aprobadas de antemano sin credenciales. Un intento rechazado devuelve 407 desde el proxy; el 401 viene del sitio web, no del proxy.

¿Es segura la autenticación de proxy con usuario y contraseña?

Las credenciales van codificadas en base64, no cifradas, así que cualquiera en el camino de red entre tú y un proxy HTTP puede leerlas salvo que esa conexión vaya por TLS. En la práctica, trata el login como un secreto: mantenlo fuera de las URL en el historial de la shell, los logs y los repositorios, y cámbialo si ha podido filtrarse.

¿Por qué no funciona la contraseña de mi proxy?

Lo más habitual es que contenga @, #, : o / y se haya puesto en una URL sin codificar. Python requests, con p@ss#word en la URL del proxy, intentó conectarse a un host llamado ss. Codifica la contraseña en porcentaje (%40, %23, %3A, %2F) o pásala en campos separados de usuario y contraseña.

¿Es mejor la whitelist de IP que una contraseña?

Es más cómoda para un servidor fijo y necesaria para herramientas que no pueden enviar un login, como Selenium. Es peor para cualquier cosa cuya dirección cambie o sea compartida, y no puede llevar la segmentación por petición que va en el login. Mantén las credenciales operativas aunque uses whitelist.

¿Puedo usar credenciales y whitelist a la vez?

Normalmente sí, y deberías: añade a la whitelist los servidores fijos por comodidad y conserva las credenciales como la vía que sobrevive a un cambio de dirección. Con nosotros, los residenciales admiten ambos métodos; los productos estáticos, solo credenciales.