Autenticación del proxy con usuario y contraseña: cómo conectarse y evitar errores

Con la autenticación mediante nombre de usuario y contraseña, la aplicación envía al proxy las credenciales emitidas por el proveedor. El proxy las comprueba y permite utilizar el servicio. Este método resulta útil al trabajar desde distintos dispositivos y redes: si el servicio no exige también autenticación por IP, trasladar un script a otro servidor no requiere cambiar una dirección IP permitida.

Para que una conexión funcione hace falta algo más que un nombre de usuario y una contraseña. También se necesitan la dirección, el puerto y el protocolo correctos del proxy. La aplicación debe admitir el método de autenticación requerido. Por tanto, un error de autenticación no significa necesariamente que la contraseña sea incorrecta.

Para comparar los métodos de acceso y elegir uno, consulta Autenticación del proxy. Este artículo explica cómo conectarse con usuario y contraseña, desde introducir la configuración hasta diagnosticar problemas en un script en ejecución.

Qué significa la autenticación con usuario y contraseña

El nombre de usuario identifica una cuenta o el acceso a un servicio concreto, mientras que la contraseña confirma el derecho a utilizarlo. Una vez superada la comprobación, el proxy gestiona la conexión dentro de los permisos concedidos: la lista de direcciones disponible, el cupo contratado y los límites aplicables.

Las credenciales del proxy no deben confundirse con la contraseña del panel de control. Los datos que utiliza una aplicación pueden ser distintos de los que permiten iniciar sesión en la web del proveedor. Una clave API sirve para realizar solicitudes a la API del servicio; la contraseña de un sitio de destino sirve para iniciar sesión en ese sitio. Utiliza cualquiera de ellas como contraseña del proxy solo si el proveedor especifica expresamente ese método de conexión.

Autenticarse correctamente en el proxy no inicia sesión en el sitio de destino. Si el sitio requiere su propia cuenta, cookies o un token, la aplicación debe proporcionarlos por separado.

Cuándo resulta útil este método

El acceso con usuario y contraseña permite utilizar aplicaciones desde varias ubicaciones, tanto fijas como cambiantes. Sin restricciones de IP, cada aplicación necesita las credenciales y los datos de conexión del proxy, sin una entrada independiente para su red en la lista de IP permitidas.

Por ejemplo, un equipo trabaja desde dos oficinas y una vivienda, cada una con una IP pública diferente. Las aplicaciones pueden utilizar las mismas credenciales del proxy si el servicio permite compartirlas sin vinculación a una IP. Cada aplicación conserva su propia configuración de conexión; el proxy comprueba las credenciales que envía cada una.

Este método también sirve para varios servidores permanentes. Sin embargo, la cantidad de dispositivos, las conexiones simultáneas y los recursos disponibles dependen del plan. Una sola contraseña no concede acceso ilimitado.

Cómo envía una aplicación las credenciales del proxy

La secuencia general es sencilla: la aplicación contacta con el proxy, supera la comprobación de acceso y lo utiliza para llegar al recurso solicitado. Los detalles dependen del protocolo.

Un proxy HTTP puede devolver primero 407 Proxy Authentication Required e indicar el método de autenticación que acepta. La aplicación envía la información de autenticación en la cabecera Proxy-Authorization. Algunos clientes la envían directamente, por lo que el desafío inicial puede no aparecer en el registro.

Al abrir un sitio HTTPS a través de un proxy HTTP convencional, la autenticación puede realizarse durante la solicitud CONNECT que establece el túnel. Después, la aplicación establece una conexión segura con el sitio. Las solicitudes posteriores al sitio a través de ese túnel no repiten el inicio de sesión en el proxy utilizado para abrirlo.

Con SOCKS5, el usuario y la contraseña se comprueban al principio de la conexión, antes de solicitar la conexión con el destino. Si la comprobación falla, la aplicación no obtiene la conexión solicitada a través del proxy. Un fallo de autenticación propio de SOCKS5 no es una respuesta HTTP 407.

Selecciona el protocolo y el método de autenticación que admita el servicio. SOCKS4 tiene un campo de ID de usuario, pero no define el intercambio de usuario y contraseña de SOCKS5. Rellenar ese campo no permite que un cliente SOCKS4 realice la autenticación con contraseña de SOCKS5.

Qué datos introducir en la aplicación

Empieza por los datos de conexión de tu servicio concreto. Si la aplicación ofrece campos separados, introduce cada valor en el campo correspondiente:

Algunas aplicaciones aceptan una sola cadena con el formato protocol://username:password@host:port. Por ejemplo, en http://client01:River%[email protected]:8080, el usuario es client01, la contraseña es River@2026, el host es proxy.example y el puerto es 8080. La @ de la contraseña se representa como %40 para no confundirla con el separador que precede al host.

curl, por ejemplo, admite esta interpretación de una URL de proxy. Un campo de contraseña independiente suele esperar la contraseña en sí, sin codificación URL. No copies un valor codificado de una URL en un campo separado sin comprobar el formato: la aplicación puede interpretarlo como otra contraseña. En cadenas que contengan %, dos puntos u otros caracteres especiales, sigue los requisitos de formato del propio cliente.

Codifica una sola vez los caracteres necesarios dentro de las credenciales; codificar toda la cadena estropearía sus separadores. Poner un argumento de un comando entre comillas no sustituye a la codificación URL. El método de autenticación puede imponer sus propias restricciones: HTTP Basic, por ejemplo, permite dos puntos en la contraseña, pero no en el nombre de usuario.

Los formatos de importación también varían. host:port:username:password y username:password@host:port no son intercambiables. Unos valores correctos en un orden incorrecto no funcionarán si el importador espera otra disposición.

El prefijo http:// de una URL de proxy describe cómo se conecta el cliente al propio proxy. No impide acceder a sitios HTTPS: el cliente puede establecer un túnel para ellos. Cambiar simplemente el prefijo a https:// no añade al servidor la capacidad de aceptar conexiones seguras al proxy.

Algunos servicios incluyen en el nombre de usuario un país, un grupo de salida o un parámetro de sesión. Copia la cadena completa. Estos parámetros controlan el enrutamiento según las reglas del proveedor; no inventes su sintaxis ni tomes la de otro servicio.

Por qué conviene comprobar que la aplicación admite la autenticación

Admitir proxies y admitir su autenticación son capacidades distintas. La existencia de campos para el host y el puerto no significa necesariamente que el cliente pueda enviar un usuario y una contraseña.

Comprueba la combinación exacta de protocolo del proxy, método de autenticación y aplicación. Por ejemplo, la implementación SOCKS5 incorporada en Chrome no admite la autenticación de proxies SOCKS5. Unas credenciales correctas no resuelven esa limitación. Una extensión para seleccionar proxies tampoco añade necesariamente el método de autenticación que falta.

En los scripts, la compatibilidad puede depender de la biblioteca, sus componentes opcionales y la forma de proporcionar la configuración. Una aplicación no utiliza necesariamente la configuración de proxy del sistema ni la de un navegador en el que la conexión ya funciona.

Antes de iniciar una tarea grande, prueba una solicitud en la aplicación que vaya a ejecutarla. Confirma que utiliza el proxy especificado y que, tras un fallo, no continúa con una conexión directa. Que una página cargue correctamente no confirma por sí solo que la configuración sea correcta.

Qué ocurre cuando cambia tu IP

En una conexión ADSL con IP dinámica, el proveedor de Internet puede asignar otra dirección después de reiniciar el router o de volver a conectarse. Si el proxy solo comprueba un usuario y una contraseña, la aplicación se conecta con las mismas credenciales: no hay una nueva IP que añadir en el panel. Lo mismo ocurre al pasar de la oficina a una red doméstica.

Sin embargo, cambiar de red puede interrumpir las conexiones existentes. El cliente tendrá que volver a conectarse y quizá deba reintentar una solicitud sin terminar. Un error inmediatamente después de pasar de Wi-Fi a Internet móvil no debe interpretarse automáticamente como un problema de contraseña.

Algunos servicios comprueban tanto las credenciales como la dirección de origen. Una contraseña correcta no anula esa restricción de red: la nueva IP debe coincidir con una dirección o un rango permitidos. Antes de trasladar un script, averigua si el servicio acepta conexiones desde cualquier red o aplica una comprobación combinada.

¿Está protegida la contraseña durante la transmisión?

La autenticación determina quién puede acceder. El cifrado determina si alguien situado en el recorrido puede leer los datos transmitidos. Tener una contraseña no significa, por sí solo, que la conexión esté cifrada.

HTTP Basic codifica el usuario y la contraseña en Base64. Se trata de una representación reversible, no de cifrado. Sin protección en la conexión con el proxy, quien observe ese tramo de red puede obtener las credenciales. La autenticación estándar con usuario y contraseña de SOCKS5 tampoco cifra su transmisión.

El HTTPS del sitio de destino protege la conexión entre la aplicación y ese sitio. Con un proxy HTTP, la autenticación para establecer el túnel ocurre antes; el TLS del sitio no protege las credenciales del proxy que ya se han enviado. Del mismo modo, una solicitud HTTPS a través de SOCKS5 no cifra la comprobación previa de la contraseña del proxy.

Proteger ese tramo requiere protección entre la aplicación y el proxy, por ejemplo, un proxy HTTPS con TLS, cuando tanto el servicio como el cliente lo admitan. La aplicación debe validar el certificado del proxy. En algunas ofertas comerciales, «proxy HTTPS» solo significa que permite acceder a sitios HTTPS, por lo que conviene comprobar dónde se aplica realmente TLS.

Si se expone una cadena de conexión completa con una contraseña válida, otra persona podría utilizar el servicio dentro de sus reglas, consumir el cupo u ocupar conexiones. Esto no equivale a obtener la contraseña del panel cuando las credenciales son distintas. El método de autenticación tampoco garantiza que una dirección no pueda identificarse como proxy: un desafío de autenticación accesible desde el exterior puede revelar el servicio.

¿Pueden varias aplicaciones utilizar las mismas credenciales?

Técnicamente, varios clientes pueden enviar el mismo usuario y la misma contraseña. El proveedor determina si está permitido y establece las condiciones: reglas de uso compartido, límites de conexiones activas, cupo contratado y otras restricciones.

Por ejemplo, dos scripts pueden utilizar una cuenta mientras abren distintas cantidades de conexiones. Una contraseña no significa una conexión. Del mismo modo, iniciar diez procesos no multiplica por diez el cupo total de conexiones del servicio.

La cantidad de pares de credenciales también es distinta de la cantidad de IP de salida. Un usuario y una contraseña pueden dar acceso a una lista de proxies estáticos o a una puerta de enlace respaldada por un grupo de direcciones. La IP que ve el sitio depende del proxy seleccionado y de las reglas de enrutamiento del servicio.

Si el servicio ofrece credenciales distintas para aplicaciones o miembros del equipo, se puede desactivar un conjunto sin cambiar los demás. Con una contraseña compartida, cambiarla obliga a actualizar todas las aplicaciones que la utilizan. Unas credenciales separadas tampoco implican cupos independientes de conexiones o tráfico: comprueba qué límites comparten.

Por qué un proxy rechaza el usuario y la contraseña

Identifica primero quién ha devuelto el error. El código HTTP 407 corresponde a la autenticación en el proxy; un 401 del sitio de destino corresponde al acceso a ese sitio. Un mensaje 403 o un tiempo de espera agotado no permiten determinar, sin más pruebas, si la contraseña del proxy es correcta.

Comprueba el estado del servicio y el cupo restante; después, prueba una solicitud con la configuración proporcionada en la aplicación real. Si falla, utiliza la tabla para revisar la compatibilidad del cliente, el formato de las credenciales y las restricciones de IP de origen, cambiando un ajuste cada vez. Cuando la solicitud funcione de forma constante, aumenta la carga y observa los límites que solo aparecen con ella.

Cómo guardar y cambiar las credenciales en scripts en uso

Guarda las credenciales separadas del código, en una configuración con acceso controlado o en el almacén de secretos de tu entorno. Una aplicación puede recibirlas mediante variables de entorno, pero estas no son una forma de cifrado por sí mismas. No incluyas contraseñas activas en repositorios ni en plantillas que compartas con otras personas.

Normalmente, un registro necesita el host y el puerto del proxy, el resultado de la conexión y el código de error. Una cadena de conexión completa contiene la contraseña; ocúltala antes de escribir el registro. Con herramientas de línea de comandos, ten en cuenta que un secreto puede permanecer en el historial o ser visible en los argumentos del proceso, según la aplicación y el sistema.

Antes de cambiar una contraseña, localiza todos sus consumidores: aplicaciones locales, procesos de servidor, tareas programadas y sistemas de compilación. Después del cambio, actualiza su configuración y establece una conexión nueva para probarlos. Confirma que los procesos de larga duración también han recibido el nuevo valor; algunos necesitan reiniciarse.

Si la contraseña anterior debe dejar de funcionar, comprueba que se rechaza una conexión nueva que la utilice. Las conexiones existentes siguen las reglas del propio servicio: cambiar una contraseña no siempre las cierra inmediatamente. Para revocar el acceso de forma urgente, utiliza el método de desactivación que admita el proveedor.

Autenticación combinada: IP y contraseña

Con la autenticación combinada, el proxy comprueba dos condiciones: las credenciales y la dirección desde la que se conecta la aplicación. Ambas deben cumplirse. Una contraseña correcta por sí sola no anula la restricción de IP.

En los paquetes estáticos de ProxyCompass, el modo combinado utiliza una subred /24. Si tienes varias direcciones IPv4 públicas en la misma subred, basta con añadir una a la lista de IP permitidas. Las demás direcciones de esa subred pueden conectarse con el usuario y la contraseña correctos, sin una entrada independiente para cada dirección.

En la ilustración, la IP pública de la aplicación comparte los tres primeros números con la dirección permitida. Puede conectarse con credenciales válidas; una dirección de otra subred no supera la comprobación de red, y una contraseña incorrecta falla incluso dentro de ella. Otras IP de clientes en la misma subred también pueden utilizar esta entrada. Resulta útil para aplicaciones que requieren campos de usuario y contraseña. La regla se refiere a las IP públicas de tus aplicaciones, no a las IP de salida de los proxies contratados.