SOCKS5 vs proxy HTTP : différences et lequel utiliser

Comment un proxy HTTP transporte-t-il le trafic HTTPS ?

Un proxy HTTP transporte le trafic HTTPS via un tunnel que votre client ouvre avec la méthode CONNECT de la RFC 9110. Le client indique l'hôte et le port, le proxy s'y connecte et répond 200, puis il ne fait plus que relayer des octets chiffrés.

L'échange se présente ainsi, avec des identifiants de documentation :

CONNECT api.ipify.org:443 HTTP/1.1
Host: api.ipify.org:443
Proxy-Authorization: Basic VVNFUk5BTUU6UEFTU1dPUkQ=

HTTP/1.1 200 Connection established

Comment un proxy SOCKS5 ouvre-t-il une connexion ?

Un proxy SOCKS5 ouvre une connexion en trois courts échanges binaires définis par la RFC 1928 : une salutation qui convient d'une méthode d'authentification, le login, et une demande de connexion avec l'adresse cible. Le tableau montre les octets pour un login avec nom d'utilisateur et mot de passe (RFC 1929) et une demande pour api.ipify.org sur le port 443.

La RFC 1929 envoie le nom d'utilisateur et le mot de passe en clair, chacun jusqu'à 255 octets. Comme l'authentification Basic sur HTTP, elle ne protège rien en soi ; la session TLS vers le site web s'exécute ensuite dans le relais. Une allowlist IP évite d'envoyer un mot de passe du tout. Options de login : Nom d'utilisateur et mot de passe, ou une liste d'IP autorisées (jusqu'à 10 IP).

Quelle est la différence entre socks5 et socks5h ?

Avec socks5://, votre propre machine résout le nom d'hôte et envoie une adresse IP au proxy ; avec socks5h://, le proxy reçoit le nom d'hôte et le résout. Le « h » signifie hostname. Ces noms viennent de curl et sont aussi utilisés par Python requests avec PySocks.

La différence compte à deux niveaux. D'abord, la résolution locale envoie une requête DNS depuis votre propre réseau, ce qui indique à votre résolveur quels sites vous visitez. Ensuite, la réponse DNS obtenue localement peut pointer vers un serveur proche de vous, et non du proxy, si bien qu'un CDN peut vous servir la mauvaise région. Utilisez socks5h:// sauf si vous avez une raison de faire autrement. Les proxies HTTP résolvent toujours du côté du proxy, car CONNECT transporte le nom d'hôte.

curl -x socks5h://USERNAME:[email protected]:PORT https://api.ipify.org
curl -x http://USERNAME:[email protected]:PORT https://api.ipify.org

SOCKS5 prend-il en charge UDP ?

La norme SOCKS5 définit le relais UDP via une commande appelée UDP ASSOCIATE, mais la prise en charge dépend du serveur et du client. Beaucoup de services proxy et de bibliothèques clientes n'implémentent que TCP.

RackProxies vend ses IP pour HTTP, HTTPS (CONNECT) et SOCKS5, et nous ne garantissons pas UDP. Si votre usage nécessite UDP, testez-le sur le plan 1 IP avant d'en acheter davantage, et demandez d'abord au support. Pour les requêtes web, les API et la surveillance en HTTPS, TCP suffit.

Lequel choisir pour mon outil ?

Choisissez HTTP quand votre outil parle HTTP, et SOCKS5 quand ce n'est pas le cas ou qu'il ne prend en charge que SOCKS. En pratique :

• Python requests, Node.js fetch avec undici, Playwright, Scrapy : HTTP fonctionne directement. SOCKS5 nécessite un package supplémentaire dans requests (requests[socks]).
• curl et wget : curl prend en charge les deux ; wget utilise les proxies HTTP.
• Navigateurs : les deux, mais le client SOCKS5 intégré de Chromium n'a historiquement pas pris en charge l'authentification par nom d'utilisateur et mot de passe, donc le choix sûr est la forme HTTP ou l'allowlist.
• Clients TCP non HTTP (outils de base de données, protocoles personnalisés) : SOCKS5.

Les exemples de code montrent chaque cas, et le guide de démarrage rapide teste les deux protocoles avec curl.