Solución de problemas4 min de lectura

Corrige el error de proxy 407 sin adivinar

Diagnostica Proxy Authentication Required en un orden repetible: gateway, método de autenticación, codificación de credenciales, alcance de cuenta y ajustes del cliente.

En esta página

El punto de partida

Un 407 apunta a la capa de autenticación del proxy. Empieza por ahí antes de cambiar la petición al destino o añadir reintentos.

Identifica quién pide las credenciales

HTTP 407 significa que el proxy requiere autenticación. La respuesta incluye un desafío Proxy-Authenticate. El cliente proporciona las credenciales del proxy mediante Proxy-Authorization. La autenticación del destino es independiente: poner la contraseña del proxy en la cabecera Authorization del destino es la solución equivocada.

Para un destino HTTPS, el rechazo puede producirse durante CONNECT, antes de que tu aplicación reciba una respuesta del destino. Algunos clientes informan de una excepción de proxy o de túnel en lugar de exponer una Response normal con estado 407.

Comprueba una variable cada vez

Sigue este orden para obtener una reproducción útil en lugar de una secuencia de cambios inconexos.

  • Gateway: copia el esquema, el nombre de host y el puerto exactos de las instrucciones de configuración actuales de la cuenta.
  • Método: confirma si este endpoint espera usuario/contraseña, una IP de origen autorizada u otro mecanismo de autenticación documentado.
  • Alcance de las credenciales: confirma que el nombre de usuario pertenece a este producto o subusuario, y no solo al inicio de sesión del panel.
  • Codificación: codifica las credenciales con percent-encoding cuando las incrustes en una URL; usa campos de credenciales separados cuando el cliente lo permita.
  • Cliente: revisa la configuración de proxy heredada y verifica que el gateway previsto es realmente el seleccionado.

Compara curl con la aplicación que falla

Ejecuta la receta acotada de curl de la guía relacionada con el mismo gateway, destino y credenciales. Si funciona, concéntrate en cómo la aplicación traslada esa configuración. En Playwright, por ejemplo, las credenciales del proxy van en proxy.username y proxy.password, no en httpCredentials.

Si ambos clientes fallan, elimina los modificadores opcionales de país o sesión específicos del proveedor y prueba el formato de credenciales documentado más simple. Confirma con el proveedor el acceso a la cuenta y las instrucciones de autenticación del endpoint. No asumas que todos los proveedores usan 407 para la misma condición de facturación o de acceso al producto.

Envía un informe reproducible y sin datos sensibles

Conserva la versión del cliente, la marca de tiempo en UTC, el host y el puerto del gateway, el nombre de host del destino, el método de autenticación y el estado o la clase de excepción. Indica si la reproducción mínima con curl también falla. Esos detalles permiten al soporte localizar el intento sin recibir tu contraseña.

Elimina de los registros los tokens, las URL con credenciales, las cookies y las cabeceras de autorización. Detén los reintentos automáticos mientras diagnosticas un 407 persistente. Una vez corregido, vuelve a ejecutar una petición y después el escenario de aplicación más pequeño antes de restaurar la concurrencia normal.

Antes de publicar

  • Identifica la autenticación del proxy por separado de la autenticación del sitio web.
  • Reproduce con la misma configuración en un segundo cliente.
  • Comparte diagnósticos sin datos sensibles en lugar de credenciales o trazas en bruto.

Fuentes y lecturas adicionales

Referencias técnicas usadas para esta guía. Consulta la documentación de tu versión instalada y la configuración compatible de tu proveedor.