Autenticación de proxy: user:pass o lista blanca de IP

Cuando compras un proxy, recibes una dirección y un puerto. Si el proxy reenviara el tráfico de cualquiera que se conectara a esa dirección, otras personas lo estarían usando. Por eso todo proxy de pago comprueba quién se conecta antes de aceptar la conexión. Hay dos formas habituales de hacerlo: un usuario y contraseña (user:pass) o una lista de direcciones IP permitidas (lista blanca de IP).

En este artículo explicamos cómo funcionan ambos métodos por dentro, cuál es más seguro y práctico en cada situación y cómo conectarse con cada uno en cURL, Python y el navegador. También vemos las causas del error 407 Proxy Authentication Required, que acapara buena parte de las consultas al soporte, y el problema que plantea una IP dinámica para la lista blanca.

¿Qué es la autenticación de proxy?#

La autenticación de proxy es la comprobación que hace el servidor proxy de que una conexión pertenece a un usuario autorizado antes de reenviarla. Si la autenticación falla, el proxy no reenvía la petición al destino.

Los dos métodos responden a preguntas distintas:

• Usuario y contraseña: «¿Quien envía esta petición conoce las credenciales correctas?»
• Lista blanca de IP: «¿Esta conexión viene de una dirección IP permitida?»

En el primer método la credencial va dentro de la petición; en el segundo, el origen de la conexión hace de identidad. Esa diferencia determina la portabilidad, la seguridad y los fallos típicos de cada método. Explicamos cómo funciona un proxy en general en Qué es un servidor proxy y cómo funciona.

¿Cómo funciona la conexión con usuario y contraseña?#

En los proxies HTTP, la autenticación con usuario y contraseña forma parte del estándar HTTP. RFC 9110 define la cabecera Proxy-Authenticate, con la que el proxy pide credenciales, y la cabecera Proxy-Authorization, con la que el cliente las envía. El esquema más común es Basic, definido en RFC 7617.

Para una petición HTTPS, el proceso es este:

1. El cliente se conecta al proxy y envía una petición CONNECT target.com:443.
2. Si la petición no lleva credenciales, el proxy responde con 407 Proxy Authentication Required y una cabecera Proxy-Authenticate: Basic realm="proxy".
3. El cliente une usuario y contraseña como user:pass, los codifica en Base64 y vuelve a enviar la petición con la cabecera Proxy-Authorization: Basic dXNlcjpwYXNz.
4. El proxy comprueba las credenciales. Si son correctas, se conecta al destino y devuelve 200 Connection Established; si no, vuelve a devolver 407.

La mayoría de los clientes añaden la cabecera en el primer intento, así que en la práctica el paso 2 se omite. Los navegadores prueban primero sin cabecera y muestran un cuadro de inicio de sesión al recibir un 407.

Hay un detalle importante: Base64 es codificación, no cifrado. Cualquiera que vea la cabecera puede decodificarla en segundos y leer el usuario y la contraseña. En la mayoría de los esquemas, la conexión entre el cliente y el proxy es HTTP sin cifrar, lo que significa que las credenciales viajan prácticamente en texto plano en ese tramo corto. El túnel HTTPS establecido con el sitio de destino no protege esta cabecera, porque se envía antes de que exista el túnel.

Los proxies SOCKS5 tienen una subnegociación similar de usuario y contraseña definida en RFC 1929; también ahí las credenciales se envían sin cifrar.

¿Cómo funciona una lista blanca de IP?#

Con una lista blanca de IP, la petición no contiene ninguna credencial. Registras una o varias direcciones IP como autorizadas en el panel de cliente, y el servidor proxy compara la IP de origen de cada conexión entrante con esa lista.

1. En el panel, añades la dirección IP pública del equipo que usará el proxy.
2. El cliente se conecta al proxy sin usuario ni contraseña.
3. El proxy mira la dirección de origen de la conexión. Si está en la lista, reenvía la petición.
4. Si la dirección no está en la lista, la conexión se rechaza o recibe un 407.

La «dirección IP pública» no es la dirección local del tipo 192.168.x.x que ves en la configuración de red de tu equipo. La dirección que ve el proxy es la que usa tu módem o servidor en internet. Para averiguarla, ejecuta este comando con el proxy desactivado:

curl https://api.ipify.org

La mayor ventaja de una lista blanca es que funciona con software que no admite credenciales. Algunas aplicaciones de escritorio antiguas, clientes de juegos y herramientas de automatización solo ofrecen campos de dirección y puerto en su configuración de proxy; en ese caso, la lista blanca es la única opción.

Comparación de los dos métodos#

¿Cuál es más seguro?#

No hay una única respuesta; los dos métodos están expuestos a riesgos distintos.

El riesgo del usuario y contraseña es la filtración. Basta con un archivo de configuración subido por error a un repositorio de código, un comando visible al compartir pantalla o un inicio de sesión guardado en el navegador de un equipo compartido. Las credenciales filtradas se pueden usar desde cualquier parte del mundo, y ese uso se factura a tu cuenta.

El riesgo de la lista blanca de IP es una dirección IP compartida. Los operadores móviles y algunos proveedores de internet doméstico ponen a muchos abonados detrás de la misma IP pública con una técnica llamada CGNAT. Si añades una dirección así a la lista, usuarios desconocidos que comparten esa dirección también pueden conectarse a tu proxy. Lo mismo ocurre en redes de cafeterías, hoteles y espacios de coworking.

Reglas prácticas:

• Si trabajas desde un servidor con IP fija, la lista blanca es más segura; no llevas secretos en el código.
• No uses lista blanca desde una línea móvil ni desde una conexión doméstica detrás de CGNAT.
• Si usas usuario y contraseña, no los escribas en el código; guárdalos en una variable de entorno o en un gestor de secretos.
• Si tu panel permite crear subusuarios separados para distintos trabajos, aprovéchalo; una credencial filtrada solo afectará a un trabajo.

Ambos métodos con ejemplos#

Las direcciones y puertos de los ejemplos son marcadores de posición; toma tus propios valores del panel de cliente.

cURL#

# Usuario y contraseña dentro de la dirección
curl -x "http://user:pass@pr.proxynet.io:8000" https://httpbin.org/ip

# Usuario y contraseña como opción aparte
curl -x "http://pr.proxynet.io:8000" -U "user:pass" https://httpbin.org/ip

# Lista blanca de IP: sin credenciales
curl -x "http://pr.proxynet.io:8000" https://httpbin.org/ip

La opción -U (forma larga --proxy-user) también reduce los problemas con caracteres especiales, porque la contraseña no se escribe dentro de la dirección. Para otras opciones de cURL, consulta Cómo usar un proxy con cURL.

Python Requests#

import os
from urllib.parse import quote

import requests

user = os.environ["PROXY_USER"]
password = quote(os.environ["PROXY_PASS"], safe="")  # codifica caracteres como @, : y /

# Usuario y contraseña
proxy = f"http://{user}:{password}@pr.proxynet.io:8000"
r = requests.get("https://httpbin.org/ip", proxies={"http": proxy, "https": proxy}, timeout=20)
print(r.json())

# Lista blanca de IP
proxy = "http://pr.proxynet.io:8000"
r = requests.get("https://httpbin.org/ip", proxies={"http": proxy, "https": proxy}, timeout=20)
print(r.json())

Como las credenciales se leen de variables de entorno, la contraseña no queda visible aunque se comparta el archivo de código. Mostramos un esquema rotativo en Python en Cómo rotar proxies en Python. Para el equivalente en Node.js, consulta Cómo usar un proxy en Node.js.

Navegador#

Los navegadores toman la dirección del proxy de su configuración o del sistema operativo, pero no piden usuario y contraseña en la pantalla de ajustes. Cuando el proxy devuelve un 407 en la primera petición, se abre un cuadro de inicio de sesión y ahí introduces las credenciales. Chrome no admite autenticación con usuario y contraseña para proxies SOCKS5; si quieres usar SOCKS5 con Chrome, necesitas una lista blanca de IP.

Los pasos para Windows y Chrome están en Configuración de proxy en Windows y Chrome, y para Firefox en Configuración de proxy en Firefox. Para la configuración en la herramienta de pruebas de API, consulta Configuración de proxy en Postman. La opción de enrutar aplicaciones de escritorio que no tienen ajustes de proxy se trata en Proxifier.

¿Por qué aparece el error 407 Proxy Authentication Required?#

La sección 15.5.8 de RFC 9110 define el 407 como «el cliente necesita autenticarse para usar el proxy». Es decir, el problema está entre tú y el proxy, no en el sitio de destino. Las causas más comunes son:

1. El usuario o la contraseña son incorrectos. Basta con un espacio al final o una diferencia de mayúsculas al copiar.
2. La contraseña contiene un carácter especial sin codificar. En http://user:p@ss@pr.proxynet.io:8000, el cliente trata todo lo que va después del primer @ como nombre del servidor. @ debe escribirse como %40, : como %3A y / como %2F.
3. La IP de la lista blanca no coincide con la IP de origen de la conexión. El módem se reinició, sigue activa una VPN o te conectas desde otra red en el trabajo.
4. El software no envía las credenciales. Algunas herramientas ignoran la parte user:pass@ de la dirección del proxy y necesitan un campo u opción de credenciales aparte.
5. Protocolo o puerto equivocado. Incluso con credenciales correctas, conectarse al puerto HTTP con SOCKS5, o al revés, produce un error confuso.
6. La cuenta o el subusuario están suspendidos. Puede que se haya agotado el saldo, se haya eliminado el subusuario o se haya consumido la cuota de tráfico.

La salida detallada de cURL ayuda a diagnosticar el error:

curl -v -x "http://user:pass@pr.proxynet.io:8000" https://httpbin.org/ip 2>&1 | grep -iE "proxy-authorization|< HTTP"

Si en la salida no aparece ninguna línea Proxy-Authorization, el cliente no envía las credenciales. Si la línea aparece pero la respuesta es 407, las credenciales son incorrectas o hay un problema con la cuenta. Reunimos el significado de los códigos de error HTTP en el scraping en Códigos de estado HTTP en web scraping.

¿Qué pasa con la lista blanca si la IP es dinámica?#

En la mayoría de las conexiones domésticas la IP pública no es fija. Cuando el módem se reinicia, la línea se cae o el proveedor cambia las direcciones cada cierto tiempo, recibes una IP nueva. La dirección antigua de la lista blanca deja de ser válida y el proxy rechaza la conexión.

Tus opciones son:

• Pasar a usuario y contraseña. Es lo que menos esfuerzo requiere con IP dinámica.
• Pedir una IP fija a tu proveedor. Solución permanente si tu trabajo siempre se hace desde la misma red.
• Llevar el trabajo a un servidor con IP fija. Los servidores en la nube suelen tener una dirección de salida fija, lo que encaja con scripts de scraping y tareas programadas.
• Actualizar la lista automáticamente si el panel tiene API. Depende de que el proveedor ofrezca esa API.

Las funciones en la nube y los contenedores con escalado automático pueden recibir una dirección de salida distinta en cada ejecución; en estos entornos normalmente no se puede usar una lista blanca.

Casos de uso#

• Script de scraping en un servidor con IP fija: lista blanca, para no tener contraseña en el código. Para distintas IP de salida a través de una sola dirección se usa un Proxies rotativos.
• Un equipo que trabaja desde distintas redes: usuario y contraseña; mejor aún si cada miembro puede tener su propio subusuario.
• Trabajo con cuentas que necesita sesión: normalmente usuario y contraseña; un Proxies de sesión fija para mantener la misma IP durante la sesión y un Proxies ISP para una dirección fija de larga duración.
• Software de escritorio antiguo sin campo de credenciales: la lista blanca es la única opción.
• Chrome con SOCKS5: lista blanca, porque Chrome no admite autenticación con contraseña para SOCKS5.

Guía de decisión#

Preguntas frecuentes#

¿Puedo usar los dos métodos a la vez?#

Depende del proveedor. Muchos proveedores aceptan en la misma cuenta conexiones sin contraseña desde IP de la lista blanca y conexiones con usuario y contraseña desde otros lugares. Este comportamiento lo deciden los ajustes del panel.

¿Mi usuario y contraseña se envían al sitio de destino junto con mi tráfico?#

No. La cabecera Proxy-Authorization está destinada solo al proxy; el proxy no la pasa al destino. El sitio de destino no ve tus credenciales.

¿Cómo guardo la contraseña del proxy de forma más segura?#

No escribas la contraseña en el código fuente. Usa una variable de entorno, un archivo .env excluido del control de versiones o el gestor de secretos de tu plataforma. Si sospechas que la contraseña se ha filtrado, cámbiala en el panel de inmediato.

¿Cuántas IP puedo añadir a la lista blanca?#

El límite varía según el proveedor y el plan. Encontrarás el límite vigente en tu panel de cliente o a través del equipo de soporte.

¿Por qué recibo un 407 si mi contraseña es correcta?#

La razón más común son caracteres especiales sin codificar en la contraseña. La segunda es que tu software no envía las credenciales incluidas en la dirección. Usa el comando curl -v de arriba para comprobar si se envía la cabecera.

¿Funciona la lista blanca con una VPN activa?#

Con una VPN activa, sales a internet con la dirección IP del servidor VPN. Si la IP de tu casa u oficina está en la lista blanca, el proxy rechaza la conexión. Desactiva la VPN o añade la dirección de salida de la VPN a la lista; esto último no se recomienda, porque otros usuarios pueden compartir esa dirección VPN.

En resumen#

Hay dos formas de autenticarse ante un proxy: un usuario y contraseña enviados con cada petición en la cabecera Proxy-Authorization, o una lista blanca de IP que mira la dirección de origen de la conexión. El usuario y contraseña funciona en cualquier red, pero las credenciales deben guardarse con cuidado; la lista blanca no deja secretos en el código, pero necesita una IP fija y no compartida. Un error 407 casi siempre se debe a credenciales incorrectas, un carácter especial sin codificar o una IP antigua en la lista blanca. Para planes que admiten ambos métodos, echa un vistazo a nuestros servicios de proxy.