Relais TCP vers une destination fixe avec portproxy de Windows
Une règle portproxy transmet un écouteur vers une destination fixe. Elle n'ajoute pas la négociation SOCKS ou HTTP CONNECT attendue par les clients compatibles proxy.
Une règle portproxy de Windows relaie TCP vers une destination configurée. Elle ne négocie pas la requête proxy HTTP d'un navigateur ni une requête de destination SOCKS.
| Service | Qui choisit la destination ? |
|---|---|
| Relais TCP fixe | La configuration de transfert de l'écouteur. |
| Proxy SOCKS5 | La requête du client, dans les limites de la politique du serveur. |
| Proxy HTTP direct | La requête proxy HTTP, y compris CONNECT pour le tunneling HTTPS courant. |
Inspectez un relais existant avec netsh interface portproxy show all. Comparez son backend configuré au protocole envoyé par votre client. La référence netsh décrit les adresses et ports de l'écouteur et de la destination ; accepter TCP n'établit pas de poignée de main HTTP ou SOCKS.
Une négociation SOCKS envoyée à un relais ordinaire atteint simplement ce backend fixe. Elle ne peut pas faire comprendre la requête à un service non SOCKS ni lui faire choisir une nouvelle cible.
Un relais placé devant un vrai proxy est différent. Le proxy amont négocie toujours les destinations et l'authentification ; le relais transporte la connexion jusqu'à lui. Un relais exposé au réseau peut étendre l'accès à ce backend, alors gardez la limite d'accès de l'écouteur délibérée.
Choisissez un service capable du protocole lorsque l'exigence est une sortie HTTP ou SOCKS générale. Un port transféré n'est qu'une partie de ce chemin.