407 Proxy Authentication Required: Cada Causa y Cómo Solucionarlo
HTTP 407 tiene exactamente un significado: el proxy frente a ti rechazó tus credenciales. Ese único hecho elimina la mayoría de los errores — aquí está el resto del mapa.
HTTP 407 Proxy Authentication Required tiene exactamente un significado, y es más limitado de lo que la mayoría de la gente supone: un proxy entre tú y el internet rechazó la solicitud porque carece de credenciales válidas para el propio proxy. El sitio web objetivo nunca fue contactado. Nunca vio tu solicitud, nunca tomó una decisión, y no puede ser la causa. Por lo tanto, solucionar un 407 siempre significa corregir tu configuración de proxy — y la lista de cosas que pueden estar mal con ella es corta y completamente enumerable. Esta guía recorre toda la lista, con las soluciones específicas de herramientas que más confunden a las personas.
Lee primero el encabezado Proxy-Authenticate
Según la especificación HTTP (RFC 9110), un 407 debe ir acompañado de un encabezado Proxy-Authenticate que describa cómo autenticar — típicamente algo como Proxy-Authenticate: Basic realm="Access to internal site". Se espera que tu cliente repita la solicitud con un encabezado Proxy-Authorization. Esa combinación vale la pena memorizar, porque es lo que distingue al 407 de su vecino: un 401 proviene del servidor de origen y combina WWW-Authenticate con Authorization, mientras que el 407 proviene de un intermediario y usa las versiones con el prefijo Proxy-. Si estás mirando un encabezado WWW-Authenticate, estás depurando el salto equivocado.
# See exactly which hop is refusing you, and what scheme it wants
curl -v -x http://USER:PASS@gate.quantumproxies.io:8000 https://httpbin.org/ip
# Response you are looking for on failure:
# HTTP/1.1 407 Proxy Authentication Required
# Proxy-Authenticate: Basic realm="..."
#
# Response you want on success: your exit IP, not your own
# {"origin": "203.0.113.45"}
Si curl -x con credenciales devuelve tu IP de salida, el proxy y las credenciales están bien — y cualquier 407 que aún veas en una aplicación es la propia configuración de esa aplicación, no del proxy. Esa única prueba divide el problema a la mitad en unos diez segundos.
Causa 1: las credenciales están ausentes, son incorrectas o están en el lugar equivocado
La causa más común es también la más aburrida. Las credenciales pertenecen a la URL del proxy, antes del host, en forma user:pass@host:port — y la biblioteca del cliente construye el encabezado Proxy-Authorization a partir de ellas. Copiar un endpoint de un panel sin las credenciales, o pegar tu contraseña de cuenta en lugar de la contraseña del proxy (generalmente son diferentes), produce un 407 inmediato y permanente en cada solicitud.
import requests
proxy = "http://USER:PASS@gate.quantumproxies.io:8000"
proxies = {"http": proxy, "https": proxy}
r = requests.get("https://httpbin.org/ip", proxies=proxies, timeout=15)
print(r.status_code, r.json()) # 200 and the exit IP = auth is correct
Revisa también el puerto. Los proveedores exponen diferentes puertos para endpoints rotativos y fijos, y para HTTP versus SOCKS5; usar el incorrecto con credenciales válidas aún puede devolver un 407 porque ese oyente espera un formato de identidad diferente. Si no estás seguro de qué protocolo estás usando, nuestro explicador sobre SOCKS5 versus proxies HTTP detalla las diferencias.
Causa 2: caracteres especiales que nunca fueron codificados por porcentaje
Este problema le cuesta a la gente tardes enteras. Una URL de proxy es una URL, por lo que cualquier carácter reservado en tu nombre de usuario o contraseña debe ser codificado por porcentaje o el analizador dividirá la cadena en el lugar equivocado. Una contraseña que contenga @ termina la sección de información de usuario temprano y tu cliente intenta conectarse a un host que no existe; un : divide el nombre de usuario de la contraseña en el lugar equivocado.
@se convierte en%40— el infractor más común, porque los correos electrónicos se usan como nombres de usuario.:se convierte en%3A— de lo contrario, se lee como el separador de nombre de usuario/contraseña.#se convierte en%23— todo lo que sigue se trata como un fragmento y se descarta silenciosamente./se convierte en%2Fy?se convierte en%3F— ambos terminan la sección de autoridad.- Un espacio literal se convierte en
%20. Si tu contraseña tiene uno, cámbiala en su lugar.
from urllib.parse import quote
user = quote("team@example.com", safe="") # team%40example.com
pwd = quote("p@ss:w#rd", safe="") # p%40ss%3Aw%23rd
proxy = f"http://{user}:{pwd}@gate.quantumproxies.io:8000"

Causa 3: autenticación de lista blanca y una IP que se movió
La mayoría de los proveedores admiten dos modos de autenticación: credenciales en la URL o lista blanca de IP, donde autorizas la dirección pública de tu servidor en el panel y no envías credenciales en absoluto. QuantumProxies admite ambos. El modo de fallo es específico y muy reconocible: todo funcionó durante semanas, luego cada solicitud comenzó a devolver 407 sin un cambio de código. Eso es tu IP pública cambiando — una renovación de arrendamiento DHCP en la oficina, una nueva puerta de enlace NAT después de una reimplementación en la nube, un anclaje móvil o un corredor de CI que obtiene una dirección nueva en cada trabajo.
Confirma eso antes de depurar cualquier otra cosa: obtén tu dirección pública actual con curl -sS https://api.ipify.org, compárala con la lista blanca y vuelve a agregarla si es diferente. Si tu IP de salida no es estable — los corredores de CI y los grupos de escalado automático rara vez lo son — cambia ese entorno a autenticación user:pass, que viaja con la configuración en lugar de la red. La otra mitad de esta trampa es mezclar modos: algunas puertas de enlace rechazan credenciales en un endpoint solo de lista blanca, por lo que enviar ambas puede fallar donde enviar ninguna tiene éxito.
Causa 4: HTTPS pasa por un túnel CONNECT
Un 407 que aparece solo en URLs https://, a menudo como el error de Python OSError: Tunnel connection failed: 407 Proxy Authentication Required, tiene una causa estructural. Las solicitudes HTTP simples son reenviadas por el proxy, pero las solicitudes HTTPS abren primero un túnel con una solicitud CONNECT — y ese CONNECT lleva su propio encabezado Proxy-Authorization. Si tu configuración solo estableció un proxy HTTP, o estableció credenciales en un esquema y no en el otro, el túnel se intenta de forma anónima y se rechaza antes de que TLS siquiera comience.
La regla es simple: siempre configura ambos esquemas con las mismas credenciales. En Python eso significa ambas claves en el diccionario proxies; en la terminal significa HTTP_PROXY y HTTPS_PROXY; en npm significa proxy y https-proxy. Nota que HTTPS_PROXY casi siempre toma un esquema http:// — el esquema describe cómo hablas con el proxy, no lo que estás obteniendo a través de él.
// Node 18+ with undici: one dispatcher covers http and https targets
import { ProxyAgent, fetch } from "undici";
const dispatcher = new ProxyAgent(
"http://USER:PASS@gate.quantumproxies.io:8000"
);
const res = await fetch("https://httpbin.org/ip", { dispatcher });
console.log(res.status, await res.json());
Causa 5: la herramienta tiene su propia configuración de proxy
Las variables de entorno no son universales. Muchas herramientas leen su propio archivo de configuración e ignoran completamente la terminal, lo que produce el estado frustrante donde curl funciona y tu compilación no. Un problema de larga duración en GitHub Desktop es la ilustración de libro de texto: un desarrollador detrás de un proxy corporativo había configurado el proxy en .gitconfig y en el entorno, sin embargo, el inicio de sesión seguía fallando con un 407 y net::ERR_TUNNEL_CONNECTION_FAILED — porque la configuración de git solo autenticaba git, mientras que el navegador incrustado que realizaba el flujo OAuth no tenía credenciales de proxy propias. Cada subsistema necesita ser informado por separado.
# shell-wide (respected by curl, wget, pip, most SDKs)
export HTTP_PROXY="http://USER:PASS@gate.quantumproxies.io:8000"
export HTTPS_PROXY="$HTTP_PROXY"
export NO_PROXY="localhost,127.0.0.1,.internal"
# npm - both keys, or https installs will 407
npm config set proxy "$HTTP_PROXY"
npm config set https-proxy "$HTTPS_PROXY"
# git
git config --global http.proxy "$HTTP_PROXY"
git config --global https.proxy "$HTTPS_PROXY"
# apt - /etc/apt/apt.conf.d/95proxies
# Acquire::http::Proxy "http://USER:PASS@gate.quantumproxies.io:8000";
# Acquire::https::Proxy "http://USER:PASS@gate.quantumproxies.io:8000";
- Postman — Configuración, Proxy, configuración de proxy personalizada, luego marca la autenticación de proxy y completa el nombre de usuario y la contraseña. El interruptor de proxy del sistema no lleva credenciales.
- .NET / C# — una
WebExceptionque lee "El servidor remoto devolvió un error: (407)" significa que elWebProxyno tieneCredentials; establécelas explícitamente o usa las credenciales de red predeterminadas. - Java — propiedades del sistema
http.proxyUseryhttp.proxyPassword, además de unAuthenticator, ya que la JVM no lee las variables de entorno. - Navegadores — un 407 en caché puede persistir después de que corrijas las credenciales; recarga dura o limpia la caché antes de asumir que la corrección falló.
- Docker — el demonio y la compilación necesitan configuraciones de proxy, y se configuran en diferentes lugares.
Una nota de seguridad mientras editas todos estos archivos: las credenciales en una configuración global de git o npm terminan en texto plano, y las URLs de proxy con contraseñas incrustadas se filtran en el historial de la terminal, registros de CI y trazas de errores. En máquinas con una dirección estable, la lista blanca de IP evita el secreto por completo.

Un 407 nunca es culpa del sitio objetivo
Vale la pena repetirlo, porque te salva de perseguir fantasmas. Si estás recibiendo 407s, ninguna cantidad de rotación de agentes de usuario, agregar encabezados o cambiar países de salida ayudará — la solicitud aún no ha salido de tu proxy. Los bloqueos que provienen del objetivo se ven diferentes: un 403 Forbidden significa que el sitio te rechazó, y un 429 Too Many Requests significa que fuiste demasiado rápido. Diagnostica cuál de los tres realmente tienes antes de escribir cualquier código. Y si Python está lanzando ProxyError o SSLError en lugar de un 407 limpio, nuestra guía para depurar ProxyError en Requests cubre los fallos a nivel de transporte.
Preguntas frecuentes
¿Cómo resuelvo 407 Proxy Authentication Required?
Coloca credenciales válidas en la URL del proxy como http://user:pass@host:port, codificando por porcentaje cualquier carácter reservado, y configura tanto la configuración de proxy HTTP como HTTPS. Si tu proveedor usa lista blanca de IP en su lugar, autoriza tu IP pública actual y no envíes credenciales. Verifica con curl -x contra un servicio de eco de IP antes de tocar el código de tu aplicación.
¿Qué significa 407 Proxy Authentication Required?
Significa que un proxy intermediario rechazó la solicitud por falta de credenciales de proxy válidas. La respuesta incluye un encabezado Proxy-Authenticate que nombra el esquema, y se espera que el cliente reintente con Proxy-Authorization. Es distinto de 401, que proviene del servidor de destino en lugar del proxy intermedio.
¿Cómo soluciono el error npm 407?
Configura ambas claves: npm config set proxy y npm config set https-proxy, cada una con la URL completa http://user:pass@host:port. El tráfico del registro es HTTPS, por lo que una configuración solo HTTP falla en el túnel CONNECT. Codifica por porcentaje los caracteres especiales en la contraseña y verifica si un .npmrc a nivel de proyecto está sobrescribiendo tu configuración global.
¿Por qué Python genera Tunnel connection failed: 407?
Porque la solicitud HTTPS abrió un túnel CONNECT que no llevaba credenciales de proxy. Establece ambas claves http y https del diccionario proxies a la misma URL autenticada. También verifica si HTTP_PROXY o HTTPS_PROXY en el entorno está sobrescribiendo tu diccionario — establece session.trust_env = False para descartar eso.
¿Cómo configuro la autenticación de proxy en Postman?
Abre Configuración, ve a la pestaña Proxy, habilita la configuración de proxy personalizada, ingresa host y puerto, luego marca la casilla de autenticación de proxy y agrega el nombre de usuario y la contraseña. Confiar en el interruptor de proxy del sistema es el error habitual — enruta el tráfico a través del proxy pero nunca proporciona credenciales, por lo que cada solicitud devuelve 407.
Cinco causas cubren esencialmente cada 407 en la naturaleza: credenciales faltantes, caracteres especiales no codificados, una IP en lista blanca que cambió, un túnel CONNECT no autenticado y una herramienta con su propia configuración. Trabájalas en ese orden y el código de estado desaparece — luego puedes empezar a preocuparte por lo que el sitio objetivo piensa de ti.
Obtén proxies residenciales con autenticación user:pass o lista blanca de IP