Nuestra posición, que dejamos clara desde el principio: somos Geonode y vendemos proxies, por lo que recibimos muchos mensajes del tipo «mi proxy no funciona». Lo más honesto que se puede decir, antes que nada, es que el puerto casi nunca es el problema. Según nuestra experiencia, el orden de probabilidad es el siguiente: credenciales incorrectas, una lista de direcciones IP permitidas que te has olvidado de actualizar, utilizar el puerto HTTP sin cifrar para una solicitud HTTPS, que el servidor de destino te bloquee y, solo entonces, un número de puerto realmente incorrecto. Si estás depurando el problema, ve revisando esa lista en lugar de probar números de puerto al azar; este último enfoque parece productivo, pero casi nunca lo es.
Dicho esto, comprender qué función tiene cada número hace que toda la taxonomía de los errores resulte comprensible.
¿Qué es realmente un puerto?
Un equipo tiene una dirección y muchos programas que pueden necesitar tráfico de red. El número de puerto es lo que permite al sistema operativo saber a qué programa pertenece una conexión determinada.
La dirección hace llegar el paquete al equipo. El puerto lo dirige al proceso adecuado de ese equipo. Un mismo servidor puede ejecutar simultáneamente un servidor web en el puerto 443, un demonio SSH en el 22 y un proxy en el 8080, ya que cada conexión lleva un puerto de destino que la enruta al oyente adecuado.
En el caso concreto de un proxy, el puerto tiene una función adicional: un mismo servidor proxy suele estar a la escucha en varios puertos, cada uno de ellos configurado de forma diferente. El mismo software, la misma máquina, pero un comportamiento diferente según el número al que te conectes. Por eso tu proveedor te facilita una lista en lugar de un único valor, un punto al que volveremos más adelante.
Los tres rangos de puertos
Los puertos van del 0 al 65535, y la RFC 6335 divide ese espacio en tres rangos:
| Rango | Nombre | Números | Asignación |
|---|
| Sistema | Puertos conocidos | 0–1023 | Asignados por la IANA |
| Usuario | Puertos registrados | 1024–49151 | Asignados por la IANA |
| Dinámico | Puertos privados o efímeros | 49152–65535 | Nunca se asignan |
Hay dos consecuencias importantes en la práctica.
Los puertos del sistema suelen requerir privilegios elevados para su asignación. En sistemas tipo Unix, la asignación de un puerto por debajo de 1024 suele requerir privilegios de root. Esta es la razón directa por la que los proxies suelen utilizar los puertos 8080 o 3128 en lugar del 80: ejecutar un proxy como root para ocupar un puerto bajo es un mal intercambio a cambio de una ventaja meramente estética.
Los puertos dinámicos son el origen de tus propias conexiones. Cuando te conectas a un proxy en el 8080, tu equipo elige un puerto de origen efímero del rango superior. Esto pasa desapercibido hasta que lees el registro del cortafuegos y te preguntas por qué tu tráfico parece provenir del puerto 51423.
Los puertos de proxy más comunes y lo que realmente dice la IANA
Aquí es donde la creencia popular y los datos oficiales divergen, y esta divergencia resulta instructiva. Estas entradas proceden del Registro de nombres de servicios y números de puerto de protocolos de transporte de la IANA, extraídas directamente del archivo CSV publicado.
| Puerto | Cómo lo llama la gente | Lo que realmente registra la IANA |
|---|
| 8080 | El puerto de proxy predeterminado | http-alt — «HTTP alternativo (véase el puerto 80)» |
| 3128 | El puerto de Squid | ndl-aas — «Puerto del servidor API activo» |
| 1080 | SOCKS | socks — «Socks» |
| 8118 | Privoxy | privoxy — «Proxy HTTP de Privoxy» |
| 8888 | Puerto de proxy alternativo | ddi-tcp-1 — «Servidor NewsEDGE TCP (TCP 1)» |
| 9050 | Tor SOCKS | versiera — «Versiera Agent Listener» |
| 8081 | Puerto de proxy secundario | sunproxyadmin — «Servicio de administración de proxy de Sun» |
Vuelve a leer esa tabla, porque echa por tierra una suposición habitual. De los puertos que todo el mundo considera «puertos de proxy», solo el 1080 y el 8118 están registrados para algo relacionado con los proxies.
El puerto 3128 —universalmente descrito como el predeterminado de Squid, y de hecho lo es— está registrado para algo que no tiene nada que ver. El puerto 8888, utilizado por herramientas de proxy en todas partes, pertenece a un producto de noticias. El puerto 9050, que todo usuario de Tor conoce, está registrado para un agente de monitorización.
La lección no es que estas herramientas estén haciendo algo mal. El registro recoge asignaciones solicitadas, y gran parte del software ampliamente utilizado simplemente eligió un número conveniente y se convirtió en una convención por el uso, más que por el registro. La convención y el registro son sistemas diferentes, y cuando entran en conflicto, tu software sigue la convención.
La conclusión práctica: el número de puerto no te dice nada definitivo sobre lo que está a la escucha. Un proxy puede ejecutarse en cualquier puerto. Los números convencionales existen porque alguien tiene que elegir un valor por defecto, no porque el número tenga algún significado.
El puerto no determina el protocolo
El error conceptual más habitual en este ámbito.
Conectarse al puerto 1080 no significa que la conexión sea SOCKS. Conectarse al 8080 no significa que sea HTTP. El puerto determina qué servicio receptor atiende tu conexión; el protocolo es aquel que utilice dicho servicio. Si no coinciden, la conexión falla de una forma que suele resultar confusa: se produce un tiempo de espera agotado, un restablecimiento de la conexión o una ráfaga de bytes ilegibles, en lugar de un mensaje de error útil.
Por eso, cuando tu proveedor te proporciona un punto final, necesitas tres datos, y el puerto es solo uno de ellos:
- El host
- El puerto
- El protocolo que utiliza ese puerto: HTTP, HTTPS, SOCKS4 o SOCKS5
La configuración del cliente debe especificar el protocolo de forma explícita. En curl, el esquema del argumento «-x» lo indica:
curl -x http://proxy.example.com:8080 https://example.com
curl -x socks5://proxy.example.com:1080 https://example.com
curl -x socks5h://proxy.example.com:1080 https://example.com
Esta tercera forma es más importante que la diferencia entre las dos primeras. «socks5h» le indica a curl que envíe el nombre de host al proxy para su resolución; «socks5» sin más resuelve el nombre localmente y envía la dirección. La consecuencia es una fuga de DNS: tu tráfico sale a través del proxy, mientras que tus consultas DNS se dirigen a tu propio resolutor, lo cual es precisamente el tipo de inconsistencia que hace que se marque una sesión. Si utilizas SOCKS5 para cualquier fin en el que sea importante que parezca que te encuentras en otro lugar, utiliza socks5h.
Cómo se comporta el mismo puerto con HTTP, HTTPS y SOCKS
Los tres casos difieren en aspectos que explican la mayoría de los síntomas confusos.
HTTP sin cifrar a través de un proxy HTTP. Tu cliente envía la URL completa en la línea de solicitud y el proxy la recupera en tu nombre. El proxy ve y puede modificar todo.
HTTPS a través de un proxy HTTP. Tu cliente envía una solicitud CONNECT y, si el proxy lo permite, este abre un túnel TCP y retransmite los bytes sin poder leerlos. Por eso un proxy HTTP gestiona el tráfico HTTPS y por eso el mismo puerto da servicio a ambos.
De ello se derivan directamente dos modos de fallo. Algunos proxies restringen CONNECT a puertos de destino específicos —normalmente el 443—, por lo que se rechaza una solicitud HTTPS a un puerto no estándar, mientras que la navegación habitual funciona. Y algunos puertos están configurados solo para HTTP sin cifrar, con CONNECT desactivado por completo; el síntoma es que las solicitudes HTTP funcionan y las HTTPS fallan, lo que parece un problema de certificado, pero no lo es.
SOCKS. RFC 1928 define SOCKS5 como un protocolo que opera por debajo de la capa de aplicación. No entiende HTTP en absoluto: retransmite conexiones TCP, lo que lo hace más general que un proxy HTTP. Funciona con protocolos que un proxy HTTP no puede gestionar, y no puede realizar ninguna acción específica de HTTP, como el almacenamiento en caché o la reescritura de encabezados.
A la hora de elegir: utiliza proxies HTTP para el tráfico web en el que puedas necesitar gestionar los encabezados; utiliza SOCKS5 cuando necesites redirigir algo que no sea HTTP, o cuando quieras que el proxy sepa lo menos posible.
Por qué los proveedores te ofrecen varios puertos
Los puntos de conexión con varios puertos pueden resultar confusos para los principiantes, pero la lógica es sencilla: el proveedor codifica la configuración en el número de puerto para que no tengas que indicarla de otra forma.
Esquemas habituales:
Comportamiento de rotación. Un puerto proporciona una nueva dirección de salida en cada solicitud; otro mantiene la misma dirección durante una sesión de unos minutos. Mismas credenciales, mismo host, puerto diferente.
Segmentación geográfica. Un bloque de puertos se asigna a países o regiones.
Identidad de sesión. Un rango de puertos en el que cada número corresponde a una sesión persistente, de modo que al conectarse repetidamente al mismo puerto se obtiene la misma dirección de salida.
Protocolo. Un puerto utiliza HTTP, otro SOCKS5.
Algunos proveedores hacen lo mismo mediante la sintaxis del nombre de usuario: añaden parámetros al nombre de usuario en lugar de variar el puerto. Ambos enfoques existen y ninguno es mejor que el otro; simplemente tienes que leer la documentación del que hayas adquirido, porque el riesgo de adivinar a ciegas es que la solicitud se realice con éxito, pero haciendo algo distinto de lo que pretendías.
Vale la pena hacer hincapié en este último punto. Un puerto incorrecto en un esquema de rotación no suele generar un error. Genera una solicitud que funciona, pero con un comportamiento erróneo: una persistencia de sesión que no deseabas o un país que no habías solicitado. Se trata de la clase de fallo silencioso sobre la que escribimos en por qué es importante probar los proxies, y la confusión con los puertos es una de sus causas más comunes.
Solución de problemas: qué indica cada error
Los distintos errores apuntan a causas diferentes, y interpretarlos correctamente evita tener que hacer conjeturas.
| Síntoma | Causa probable | Comprobación |
|---|
| Conexión rechazada, de forma inmediata | No hay ningún servicio a la escucha en ese puerto | Número de puerto, host |
| Tiempo de espera agotado, sin respuesta | El cortafuegos descarta paquetes de forma silenciosa | Reglas de salida, estado del proveedor |
| 407 Se requiere autenticación de proxy | Credenciales incorrectas o ausentes | Nombre de usuario, contraseña, lista de direcciones IP permitidas |
| 403 procedente del propio proxy | Autenticado, pero sin permiso | Límites del plan, restricciones de destino |
| HTTP funciona, HTTPS no | «CONNECT | |
» desactivado o restringido en ese puerto | Puerto del protocolo, documentación del proveedor |
| Bytes basura o errores de protocolo | Discrepancia de protocolo | ¿Este puerto es HTTP o SOCKS? |
| Funciona, pero país o sesión incorrectos | Puerto incorrecto en un esquema multipuerto | Asignación de puertos del proveedor |
La distinción entre «conexión rechazada» y «tiempo de espera agotado» es la más útil y la más pasada por alto. «Rechazado» significa que algo respondió y lo rechazó: se puede acceder al equipo y no hay nada a la escucha en ese puerto. «Tiempo de espera agotado» significa que no respondió nada en absoluto: normalmente es un cortafuegos que descarta paquetes, ya sea en tu lado o entre tú y el proxy. El primero apunta a un número de puerto incorrecto; el segundo, casi nunca.
Una prueba rápida de aislamiento:
nc -zv proxy.example.com 8080
Si se conecta, el puerto está abierto y es accesible, y cualquier fallo restante se debe a la autenticación o al protocolo, más que a la red. Si no se conecta, deja de depurar tu aplicación: el problema está más abajo.
Y el caso del 407 merece una mención especial porque es el más común de todos y, a quienes no lo han visto antes, les parece un problema de puerto. No lo es. Significa que has llegado al proxy correctamente y que este te pide unas credenciales que no has proporcionado o que has proporcionado de forma incorrecta. El puerto era correcto.
Puertos que no debes dejar expuestos
Esto es relevante si utilizas tu propio proxy en lugar de adquirir uno.
Nunca expongas un proxy sin autenticación a Internet. Un proxy abierto se detecta en cuestión de horas —el espacio de direcciones completo se escanea continuamente— y se utilizará para retransmitir tráfico que tú no has autorizado, atribuyéndolo a tu dirección. Las consecuencias van desde que tu dirección acabe en listas de bloqueo hasta situaciones considerablemente peores. Si se puede acceder a un proxy desde Internet, es necesario que requiera autenticación.
Restringe el acceso por dirección de origen siempre que puedas. Una lista de direcciones IP permitidas, junto con las credenciales, supone una mejora significativa respecto al uso exclusivo de credenciales, y no cuesta nada.
No des por sentado que un puerto inusual supone protección. Trasladar un servicio al puerto 47281 no lo oculta. Escanear todo el rango de puertos de un único host lleva segundos. La oscuridad no te aporta nada tangible en este caso.
Restringe los destinos CONNECT. Un proxy que redirija CONNECT a cualquier puerto de cualquier host es un relé de uso general. Limitarlo al 443 y a los destinos que realmente necesitas reduce sustancialmente los posibles usos maliciosos en caso de fuga de credenciales.
Configurar la conexión a localhost cuando solo se necesita el entorno local. Un proxy utilizado únicamente por software de la misma máquina debería escuchar en 127.0.0.1, no en 0.0.0.0. Esta única línea de configuración evita toda una categoría de problemas y es el error más común en las configuraciones autohospedadas.
Preguntas frecuentes
¿Cuál es el puerto predeterminado del proxy?
No existe un valor predeterminado universal. El 8080 es el más habitual para los proxies HTTP, el 3128 para las instalaciones de Squid y el 1080 para SOCKS. Ninguno de ellos es obligatorio —un proxy puede escuchar en cualquier puerto— y el registro de la IANA ni siquiera recoge el 8080 ni el 3128 como servicios de proxy. Utiliza siempre el puerto que especifique tu proveedor.
¿Es el 8080 un puerto de proxy?
Por convención, con frecuencia. Oficialmente, la IANA registra el 8080 como http-alt, descrito como «HTTP Alternate (véase el puerto 80)», es decir, un puerto alternativo para servidores web, no un puerto de proxy. Se convirtió en una convención para proxies porque es fácil de recordar y no requiere privilegios de root para la asignación, no porque tenga ningún significado específico como proxy.
¿Qué puerto utiliza SOCKS5?
El 1080 por convención, y es uno de los pocos casos en los que la convención coincide con el registro: la IANA incluye el 1080 como socks. Las implementaciones individuales varían: el puerto SOCKS de Tor tiene por defecto el 9050, que la IANA registra para algo que no tiene nada que ver.
¿Por qué mi proxy funciona con HTTP pero no con HTTPS?
Casi siempre se debe a que ese puerto no permite el método CONNECT, que es la forma en que el tráfico HTTPS se canaliza a través de un proxy HTTP, o porque CONNECT está restringido a puertos de destino específicos. Comprueba si tu proveedor ofrece un puerto independiente para HTTPS y confirma que el puerto de destino al que te estás conectando está permitido.
¿Cómo puedo averiguar qué puerto de proxy debo utilizar?
Consúltalo en la documentación de tu proveedor. No hay forma de determinarlo de manera fiable mediante una simple inspección, ya que el número de puerto no indica de forma concluyente qué servicio está a la escucha. Si necesitas comprobarlo, nc -zv host port te indica si hay algo a la escucha, pero no qué protocolo utiliza.
¿Cuál es la diferencia entre un puerto de proxy y un servidor proxy?
El servidor es el software y la máquina que gestiona tu tráfico. El puerto es uno de los puntos de entrada numerados de esa máquina al que te conectas. Un servidor suele estar a la escucha en varios puertos con diferentes configuraciones —diferentes comportamientos de rotación, diferentes países, diferentes protocolos—, por lo que los proveedores te facilitan una lista en lugar de un único número.
¿Puedo utilizar cualquier puerto para un proxy?
Técnicamente sí, cualquier puerto comprendido entre 1024 y 65535 sin necesidad de privilegios especiales. En la práctica, se utilizan los puertos que asigna el proveedor, ya que estos se corresponden con la configuración de su lado. Si gestionas tu propio proxy, evita el rango dinámico por encima de 49152, ya que tu sistema operativo asigna puertos de origen efímeros a partir de ahí y las colisiones provocan problemas intermitentes que resultan realmente difíciles de diagnosticar.
¿Afecta el número de puerto a la velocidad del proxy?
No. El puerto es un detalle de direccionamiento que no tiene características de rendimiento propias. Si diferentes puertos del mismo proveedor ofrecen un rendimiento distinto, se debe a que se enrutan a través de una infraestructura diferente o a un comportamiento de rotación distinto, no al número en sí.
Conclusión
El puerto del proxy es un detalle de enrutamiento: le indica al equipo de destino qué proceso en escucha debe gestionar tu conexión, y nada más. El número en sí mismo no tiene ningún significado oficial, como demuestra claramente el registro de la IANA: el 3128 no está registrado para Squid, el 8888 pertenece a un producto de noticias y el 9050 es un agente de supervisión. Se trata de convenciones establecidas por el uso, y tu software sigue esas convenciones.
¿Qué significa esto cuando algo falla? Lee el mensaje de error en lugar de adivinar números. «Conexión rechazada» apunta a un puerto incorrecto. Un «tiempo de espera agotado» apunta a un cortafuegos. Un 407 significa que el puerto era correcto, pero tus credenciales no lo eran. Los errores de protocolo significan que te conectaste a un servidor SOCKS que esperaba HTTP, o al revés. Cada síntoma identifica una capa diferente, y cambiar los números de puerto solo ayuda en el primer caso.
Y cuando se te ofrezcan varios puertos para un mismo punto final, consulta la documentación en lugar de elegir uno al azar. El modo de fallo en este caso no es un mensaje de error, sino una solicitud que funciona utilizando silenciosamente un país incorrecto o un comportamiento de sesión erróneo, lo cual es un tipo de error mucho más costoso.
