Retransmisión TCP a destino fijo con portproxy de Windows
Una regla de portproxy reenvía un escucha a un destino fijo. No añade la negociación SOCKS o HTTP CONNECT que esperan los clientes conscientes de proxy.
Una regla portproxy de Windows retransmite TCP a un destino configurado. No negocia la solicitud de proxy HTTP de un navegador ni una solicitud de destino SOCKS.
| Servicio | ¿Quién elige el destino? |
|---|---|
| Retransmisor TCP fijo | La configuración de reenvío del escucha. |
| Proxy SOCKS5 | La solicitud del cliente, dentro de la política del servidor. |
| Proxy HTTP de reenvío | La solicitud de proxy HTTP, incluido CONNECT para el túnel HTTPS habitual. |
Inspeccione un retransmisor existente con netsh interface portproxy show all. Compare su backend configurado con el protocolo que envía su cliente. La referencia de netsh describe las direcciones y los puertos del escucha y del destino; aceptar TCP no establece un handshake HTTP ni SOCKS.
Una negociación SOCKS enviada a un retransmisor común simplemente llega a ese backend fijo. No puede hacer que un servicio que no es SOCKS entienda la solicitud ni elija un nuevo objetivo.
Un retransmisor delante de un proxy real es distinto. El proxy ascendente sigue negociando destinos y autenticación; el retransmisor lleva la conexión hasta él. Un retransmisor expuesto a la red puede ampliar el acceso a ese backend, así que mantenga el límite de acceso del escucha deliberado.
Elija un servicio capaz del protocolo cuando el requisito sea una salida HTTP o SOCKS general. Un puerto reenviado es solo una parte de ese camino.