Conversor de formato de proxy: cualquier lista, al formato que espera tu herramienta

Por qué una lista de proxies nunca encaja con la herramienta que usas

No hay un estándar para escribir un proxy. Cuatro valores tienen que ir juntos —host, puerto, usuario y contraseña— y los proveedores han adoptado al menos seis formas de ordenarlos, sin acuerdo sobre el separador. Un panel te da 198.51.100.10:8080:alice:s3cret. Otro te da alice:s3cret@198.51.100.10:8080. Un tercero usa puntos y coma. Un cuarto imprime primero las credenciales y deja el endpoint al final. Algunos incluyen un prefijo socks5:// y otros esperan que lo sepas.

Mientras tanto, la herramienta donde quieres pegarlos tiene una única opinión. curl quiere una URL después de -x. requests de Python quiere un diccionario con un esquema en el valor. La mayoría de los frameworks de scraping quieren user:pass@host:port. Las extensiones de navegador suelen querer los cuatro campos en casillas separadas. Así que los primeros diez minutos con un proveedor nuevo se pasan reformateando una lista a mano en un editor de texto, lo cual es aburrido y el lugar más fácil posible para corromper una credencial.

Esta página hace esa conversión. Pega la lista con la forma en que haya llegado, elige la forma que necesites y pulsa Convertir.

Qué lee y qué escribe

No tienes que indicarle el formato de entrada. Deduce la forma de cada línea a partir de la propia línea, así que una lista inconsistente —y las listas exportadas a menudo lo son— sigue saliendo uniforme. Las disposiciones que reconoce:

• host:port
• host:port:user:pass
• user:pass:host:port
• user:pass@host:port
• host:port@user:pass
• cualquiera de las anteriores con un prefijo scheme://
• cualquiera de las anteriores separada por puntos y coma, barras verticales, comas, tabulaciones o espacios en lugar de dos puntos

A la salida puedes obtener una lista simple de host:port, cualquiera de las dos disposiciones de cuatro campos, una URL completa, un comando curl -x listo para ejecutar por línea, un dict de Python para requests por línea, o toda la lista como JSON con un objeto por proxy. Las salidas con forma de URL necesitan un protocolo, así que hay una lista desplegable para elegirlo; pero una línea que ya traía el suyo (socks5://…) lo conserva en lugar de que se sobrescriba, porque tu proveedor sabía qué puerto habla qué protocolo y la lista desplegable no.

Líneas que rechaza

Una línea que no puede interpretar se deja fuera y se cuenta; nunca se adivina. El recuento se muestra junto al resultado, porque descartar tres proxies de doscientos en silencio es la forma de acabar depurando un scraper a las dos de la mañana. Las líneas en blanco y las que empiezan por # o // se tratan como comentarios y no se cuentan como fallos.

El motivo habitual de un rechazo es un puerto que no es un número —una copia que se ha llevado por delante una cabecera de columna, o una nota al final de la línea—. El otro son cuatro campos en los que el host no está donde esperábamos y ningún campo parece un puerto, algo que no hay forma de resolver correctamente por mucho que se adivine.

Qué salida va dónde

Si no tienes claro cuál de las formas necesitas, así se usan más o menos:

• user:pass@host:port: Scrapy, Puppeteer y los argumentos de arranque de Playwright, la mayoría de los frameworks de scraping y casi cualquier caja de «pega aquí tus proxies» en un bot o en una herramienta SEO.
• URL completa con esquema: cualquier cosa que tome una sola cadena de proxy de una variable de entorno, incluidas HTTP_PROXY y HTTPS_PROXY.
• Comandos curl -x: para probar unos cuantos a mano. Pega el bloque en una terminal y observa qué endpoints responden.
• Diccionarios de requests de Python: se pegan tal cual en un argumento proxies=, uno por petición en una lista de rotación.
• JSON: para pasar un pool de proxies a tu propio código o a un archivo de configuración. El puerto sale como número y las credenciales vacías como null, así que carga sin más limpieza.
• host:port sin nada más: proxies autenticados por IP, donde las credenciales son tu propia dirección y no hay nada que llevar.

Nada de lo que pegues aquí sale de tu navegador

Una lista de proxies con credenciales es una lista de contraseñas. Pegarla en una página web debería darte mala espina, y en la mayoría de los sitios de conversión debería: el texto va a un servidor, se procesa y vuelve, y no tienes forma de saber qué ha pasado por el camino ni cuánto tiempo lo guarda el registro de peticiones.

Esta página está hecha para que la pregunta ni se plantee. La conversión es JavaScript que se ejecuta en tu pestaña. No hay formulario que enviar, ni endpoint detrás, ni petición alguna al pulsar Convertir: ni un evento de analítica, ni un guardado en segundo plano. Puedes comprobarlo en vez de fiarte de nuestra palabra: abre las herramientas de desarrollador del navegador, ve a la pestaña Red, pega una lista y conviértela. No aparece nada.

Lo mismo vale para las consecuencias obvias. No podemos guardar tu lista, porque nunca la tenemos. No se nos puede escapar. La página funciona con la conexión desconectada.

Acertar con la parte de las credenciales

Hay dos cosas que fallan lo bastante a menudo como para nombrarlas.

Contraseñas con dos puntos o con una @. Son las que rompen el reformateo a mano, y son realmente ambiguas: en alice:pa:ss@host:8080 la contraseña podría ser pa o pa:ss. Esta página corta las credenciales por el primer dos puntos y el endpoint por la última @, que es la lectura que coincide con cómo los emiten de verdad los proveedores. Si tu contraseña contiene una @, ningún formato por líneas puede representarla sin escapar: cambia la contraseña o usa una herramienta que tome los cuatro campos por separado.

El protocolo y el puerto. Un proxy SOCKS5 en el puerto 1080 entregado a una herramienta como http://…:1080 fallará de una forma que parece un proxy muerto. Si no tienes claro qué endpoint es cuál, nuestro comprobador de proxies te dirá por qué responde en realidad cada uno, junto con su latencia y si deja pasar tu dirección real en las cabeceras.