Proxy con contraseña sin autorización: puerta de enlace local

Has comprado un proxy, recibido una cadena del tipo login:password@host:port, y el programa solo pide "dirección y puerto". Una situación familiar: Chrome con la bandera --proxy-server, configuraciones del sistema en Windows y Android, un viejo parser, Selenium grid, una utilidad sin campo para la contraseña. La solución ha sido la misma durante muchos años: puerta de enlace local: un pequeño proxy en tu propia máquina que acepta conexiones sin contraseña y añade el login al conectarse al proxy real. Vamos a analizar cuatro herramientas comprobadas, los comandos para cada una y los errores en los que comúnmente se pierde tiempo y dinero.

Por qué los programas "no entienden" proxies con contraseña

Hay dos formas de autenticarse con el proveedor de proxy: por login y contraseña (Basic Auth) o mediante una lista blanca de IP. La segunda opción elimina el problema, pero solo funciona si tienes una IP externa fija — la mayoría de las conexiones de internet doméstico y móviles no la tienen, y en las funciones en la nube cambia con cada inicio. Hemos comparado ambos métodos en una guía de autenticación de proxy.

Con login y contraseña nos encontramos con las limitaciones de los propios programas:

Chrome y Chromium. La bandera --proxy-server según la documentación de Chromium acepta esquema, host y puerto (por ejemplo, --proxy-server="foopy:8080") — no hay campos para credenciales en esta sintaxis. En una ventana normal del navegador aparecerá un diálogo para la contraseña, pero en modo headless y en pruebas automáticas no hay nadie que lo complete.
Configuraciones del sistema. En la configuración manual de proxy de Windows y en la configuración de Wi-Fi en la mayoría de las versiones de Android solo hay host y puerto. La contraseña la pedirá una aplicación específica o no se puede introducir en ningún lugar.
Software antiguo y hecho a medida. Muchas utilidades y bibliotecas soportan proxies, pero sin autenticación, o fallan con caracteres especiales en la contraseña.
Programas sin soporte de proxy en absoluto. Utilidades de consola que no leen ni variables de entorno ni configuraciones.

La puerta de enlace local cubre los cuatro casos: el programa ve el proxy 127.0.0.1:8080 sin contraseña, y la puerta de enlace reenvía el tráfico al proveedor ya con el login.

Cómo funciona el esquema

En tu máquina (o VPS, donde funciona el parser) se inicia un servidor proxy ligero y escucha en un puerto local, por ejemplo 127.0.0.1:8080.
En la configuración de la puerta de enlace se especifica el proxy "padre" (upstream) — la dirección del proveedor, el login y la contraseña.
El programa se conecta al puerto local sin autenticación.
La puerta de enlace abre una conexión con el proveedor, pasa la autenticación y reenvía el tráfico. Para el sitio, apareces con la dirección IP del proveedor, no con la tuya.

HTTPS no se descifra: a través de un proxy HTTP, el navegador establece un túnel mediante el método CONNECT, y la puerta de enlace simplemente transmite los bytes cifrados.

Opción 1: gost — un comando, sin configuraciones

gost (GO Simple Tunnel) — un archivo ejecutable en Go para Windows, macOS y Linux. Es la forma más rápida de levantar una puerta de enlace. En gost, la bandera -L define el servicio local, -F — el nodo a través del cual se reenviará el tráfico. Las credenciales se especifican directamente en la dirección del nodo:

gost -L http://127.0.0.1:8080 -F socks5://LOGIN:PASSWORD@HOST:PORT

Ahora cualquier programa puede usar el proxy HTTP 127.0.0.1:8080 sin contraseña. Si la contraseña contiene caracteres especiales (@, :, #), la documentación de gost sugiere pasarlos a través del parámetro auth en base64:

echo -n LOGIN:PASSWORD | base64
gost -L http://127.0.0.1:8080 -F socks5://HOST:PORT?auth=<resultado_base64>

Ten en cuenta: si se especifica auth, el login y la contraseña escritos directamente en la dirección son ignorados por gost. Varias banderas -F en secuencia forman una cadena de varios proxies.

Cuándo usar: necesitas "conectar" rápidamente un navegador o script con un proxy, sin instalar paquetes y sin editar configuraciones.

Opción 2: 3proxy — muchos puertos en una sola máquina

3proxy — un servidor proxy compacto con configuración en un solo archivo. La directiva clave es parent; según la documentación, su sintaxis es: parent <weight> <type> <ip> <port> <username> <password>, y debe ir después de la regla allow. La configuración mínima de la puerta de enlace:

auth iponly
allow * 127.0.0.1
parent 1000 http HOST PORT LOGIN PASSWORD
proxy -p8080 -i127.0.0.1

Lo importante aquí:

auth iponly — sin contraseña, pero con verificación por ACL; la regla allow * 127.0.0.1 solo permite conexiones locales.
El peso 1000 significa "siempre a través de este padre". Pesos menores de 1000 son utilizados por 3proxy para formar cadenas aleatorias.
Tipo de padre: http, connect, socks4, socks5 y otros — elige el protocolo que te proporcionó el proveedor.
-i127.0.0.1 vincula el servicio a la interfaz local. Por defecto, 3proxy acepta conexiones en todas las interfaces.

Un truco útil: repetir el bloque allow / parent / proxy varias veces con diferentes puertos y diferentes credenciales del proveedor. Así se obtiene "puerto = proxy separado": 127.0.0.1:8081 — EE. UU., :8082 — Alemania, y así sucesivamente. Este formato es entendido por casi cualquier software, incluyendo aquel donde los proxies se introducen en una lista "host:puerto".

Cuándo usar: decenas de perfiles o flujos, cada uno necesita su propia salida.

Opción 3: Squid — si necesitas caché y registro

Squid es más pesado, pero ofrece almacenamiento en caché, registros detallados y ACL flexibles. El proveedor se especifica como nodo padre a través de cache_peer, y la directiva never_direct allow all prohíbe a Squid acceder a internet directamente eludiendo al padre:

http_port 127.0.0.1:3128
cache_peer HOST parent PORT 0 no-query default login=LOGIN:PASSWORD
never_direct allow all

Detalles de la documentación de Squid:

El puerto ICP se establece en 0 si el padre no lo soporta — los proxies comerciales no lo tienen.
En login= se permiten secuencias de escape de URL (por ejemplo, %20 para un espacio), por lo que el símbolo % en la contraseña debe escribirse como %%.
Sin never_direct, Squid puede decidir que es más rentable ir directamente al sitio — y la solicitud se enviará con tu IP real. Para el scraping y el multi-cuentas, este es el peor escenario.

Cuándo usar: oficina o equipo donde se necesita un registro de a dónde va cada uno, o solicitudes repetidas a los mismos recursos.

Opción 4: proxychains-ng — para programas sin soporte de proxy

Si un programa no sabe nada de proxies, proxychains-ng (Linux y macOS) puede ayudar. Intercepta las llamadas de red del programa y envuelve sus conexiones TCP en un proxy. Soporta SOCKS4a, SOCKS5 y HTTP, la autenticación — login y contraseña para SOCKS y Basic para HTTP. La línea en la sección [ProxyList] tiene el formato tipo ip puerto [login contraseña]:

strict_chain
proxy_dns
tcp_read_time_out 15000
tcp_connect_time_out 8000

[ProxyList]
http HOST PORT LOGIN PASSWORD

Ejemplo de ejecución: proxychains4 curl https://api.ipify.org — en la respuesta aparecerá la IP del proveedor, no la tuya.

strict_chain — todos los proxies de la lista se utilizan en orden, y si uno no está disponible, no habrá conexión. Más seguro que dynamic_chain, que omite nodos muertos.
proxy_dns — las solicitudes DNS también pasan a través del proxy. Sin esto, el proveedor de tu internet puede ver qué dominios estás solicitando, y el sitio puede notar la discrepancia entre la geolocalización de DNS y la IP.
La configuración se busca en orden: archivo de -f o variable PROXYCHAINS_CONF_FILE, luego ./proxychains.conf, ~/.proxychains/proxychains.conf y /etc/proxychains.conf.

Limitaciones que mencionan los propios autores: solo TCP (UDP e ICMP no se proxyan), pueden ocurrir fallos en programas que generan muchos procesos, y en macOS la protección SIP no permite interceptar programas del sistema.

Qué herramienta elegir: guía rápida

Un navegador o script, necesita "ahora mismo" — gost.
Muchos perfiles, cada uno con su IP o país — 3proxy con un puerto separado por cuenta.
Equipo, registro de solicitudes, caché — Squid.
Programa sin configuraciones de proxy en absoluto — proxychains-ng.

Cinco errores que son los más costosos

La puerta de enlace escucha en todas las interfaces. Iniciaste gost con -L http://:8080 en VPS — y obtuviste un proxy abierto para todo internet en tus gigabytes. Los escáneres encuentran proxies abiertos rápidamente. Siempre especifica 127.0.0.1, y si otras máquinas utilizan la puerta de enlace — cierra el puerto con un firewall. Sobre cómo los botnets encuentran rápidamente puertos abiertos en servidores con parsers, hemos escrito en el análisis del gusano CARBONATO.
Fuga de datos a través de la puerta de enlace. Squid sin never_direct, proxychains sin proxy_dns, un navegador que accede a través de WebRTC/UDP directamente, — todo esto revela la IP real. Verifica el resultado en un servicio de determinación de IP y en una prueba de fugas DNS.
Una puerta de enlace para todas las cuentas. Si 30 perfiles de anti-detección miran a un solo puerto con una sesión sticky, todos tendrán la misma IP — este es un camino directo hacia la vinculación de cuentas. Distribuye los perfiles por puertos o utiliza parámetros de sesión del proveedor.
Caracteres especiales en la contraseña. @ y : rompen el análisis de direcciones del tipo login:pass@host. Utiliza el parámetro base64 en gost, el escape en Squid o genera una contraseña sin caracteres especiales.
La puerta de enlace es un salto adicional y un punto de fallo. En la máquina local, la latencia es casi cero, pero si la puerta de enlace está en otro centro de datos, cada solicitud añade latencia de red. Mantén la puerta de enlace cerca del programa y configura el inicio automático (systemd, servicio de Windows), de lo contrario, después de reiniciar el servidor, el parser se irá silenciosamente a ninguna parte.

Qué proxies usar detrás de la puerta de enlace

A la puerta de enlace no le importa qué tipo de proxy está detrás de ella, — la elección depende de la tarea:

Proxies residenciales — para scraping de sitios protegidos, marketplaces y perfiles anti-detección: las IP de usuarios domésticos generan menos sospechas para los anti-bots.
Proxies móviles — para redes sociales y aplicaciones donde la verificación es más estricta: detrás de una sola IP de un operador móvil (a través de CGNAT) suelen salir a la red muchos abonados reales, y bloquearla es arriesgado para la propia plataforma.
Proxies de centros de datos — para tareas voluminosas sin protección estricta: verificaciones de disponibilidad, API, pruebas. Más baratos por gigabyte.

Si el proxy tiene rotación, la lógica de cambio de IP generalmente la establece el proveedor — a través de parámetros en el login o configuraciones en el panel. La puerta de enlace no la rompe: transmite el login tal cual. Por lo tanto, es conveniente levantar varios puertos con diferentes parámetros de sesión — uno con una nueva IP para cada solicitud, otro con una IP fija durante 30 minutos.

Conclusión

Un proxy con login y contraseña es adecuado para cualquier programa, si se coloca una puerta de enlace local entre ellos. Gost resuelve la tarea con un solo comando, 3proxy es conveniente para "puerto = perfil", Squid — para equipos con registro, y proxychains-ng conecta a proxies incluso software que no sabe nada de proxies. Las reglas principales: escuchar solo en 127.0.0.1, prohibir conexiones directas eludiendo al padre y verificar que el sitio vea la IP del proveedor, no la tuya.