Una IP y un puerto de una lista de proxies suelen identificar un lugar al que se conecta tu aplicación. No son un puerto público reservado para que otras personas lleguen a tu ordenador.

Esa distinción importa si quieres recibir una conexión entrante. Una solicitud saliente a través del proxy dice, en la práctica: conéctate a este destino por mí. Un oyente público exige que el intermediario acepte la conexión de otra persona y la asocie con tu servicio.

Busca una función entrante real

HTTP CONNECT establece un túnel hacia el destino indicado en la solicitud. No pide al proxy que publique un puerto de escucha arbitrario en tu nombre.

SOCKS5 define un comando BIND aparte. El intercambio BIND del protocolo proporciona un extremo vinculado y después informa de una conexión entrante. No es el comando CONNECT habitual que usa un cliente web. Un servicio que anuncia compatibilidad con SOCKS5 puede restringir u omitir el comando; el software cliente también debe admitir el intercambio previsto.

Ni siquiera una negociación BIND correcta garantiza un puerto publicado permanente y de uso general. La política del servicio, el interlocutor esperado, el tiempo de vida y la ruta de red circundante siguen importando.

Un proxy HTTP no es un servidor SSH

El reenvío remoto por SSH es otra forma en que un operador puede ofrecer acceso entrante de manera explícita. Requiere un servicio SSH, una cuenta y permiso de reenvío. Dirigir un comando SSH a un puerto público de proxy HTTP no puede crear esas capacidades.

Antes de elegir un servicio, define la dirección que necesitas: solicitudes salientes por otra salida o conexiones entrantes a una aplicación que ejecutas. Si es lo segundo, busca una función de reenvío entrante documentada dentro de un acuerdo que controles. Una fila normal de una lista de proxies no demuestra que esa función exista.

Artículos relacionados