IP y puerto del proxy: ¿qué formato necesita tu aplicación?

Algunas aplicaciones piden IP:port. Otras necesitan una URL que empiece por http:// o socks5://. Los ajustes del navegador suelen separar la dirección y el puerto en distintos campos. Por tanto, el mismo endpoint puede aparecer en varios formatos sin cambiar de dirección.

Una entrada IPv4

Supongamos que una lista de proxies HTTP ofrece el proxy HTTP de ejemplo 203.0.113.10:8080.

No incluyas el puerto dos veces. Si la aplicación ya tiene un campo para el puerto, poner 203.0.113.10:8080 en el campo del host puede hacer que intente resolver toda la cadena como un nombre de host. Tampoco añadas un esquema a un campo que espere expresamente solo una dirección IP.

El esquema debe coincidir con el servicio. Elige HTTP o SOCKS5 según la compatibilidad del cliente antes de convertir la dirección. Escribir socks5:// delante de un endpoint HTTP cambia lo que envía el cliente; no habilita SOCKS5 en ese servidor.

IPv6 necesita corchetes en una URL

Una dirección IPv6 ya contiene dos puntos, por lo que la URL encierra la dirección entre corchetes antes de añadir el puerto:

http://[2001:db8::10]:8080
socks5://[2001:db8::10]:1080

Sin corchetes, el límite entre dirección y puerto es ambiguo. Una aplicación con campos separados suele esperar 2001:db8::10 como host y 8080 como puerto; sigue su formato de entrada. Ambas direcciones utilizadas aquí son ejemplos de documentación, no proxies activos.

Analiza las URL en lugar de dividir por cada signo de dos puntos

Un pequeño script de Python puede procesar URL IPv4 e IPv6 con corchetes mediante el analizador de URL estándar:

from urllib.parse import urlsplit

proxy = urlsplit("http://[2001:db8::10]:8080")
print(proxy.scheme)
print(proxy.hostname)
print(proxy.port)

La propiedad hostname devuelve la dirección sin los corchetes. Dividir la cadena original por cada signo de dos puntos rompería este ejemplo. En un importador real, rechaza también hosts ausentes, esquemas no compatibles y puertos fuera de 1–65535. Analizar una URL proporciona sus componentes; no demuestra que el servicio exista.

Cuando la lista incluye usuario y contraseña

Una estructura habitual de URL es http://username:password@host:port. Los caracteres como @, # y / dentro de las credenciales necesitan una codificación URL adecuada. Si el cliente ofrece campos separados para las credenciales, usarlos suele ser más sencillo que construir una URL a mano.

Comprueba el formato original del proveedor antes de convertir una cadena de credenciales separadas por dos puntos. Cuatro campos separados así no tienen un significado universal, y la propia contraseña puede contener dos puntos. Un analizador diseñado para líneas IP:port sencillas no debe adivinar silenciosamente otro formato.