SOCKS5 ou HTTP : protocoles, DNS et compatibilité

SOCKS5 ou proxy HTTP expliqué : différence entre HTTP CONNECT et un tunnel SOCKS5, où le DNS est résolu, quels clients gèrent quelle authentification, et comment tester le protocole acheté.

Ce guide s'adresse à quiconque choisit entre un point d'accès HTTP et un point d'accès SOCKS5 sur une offre de proxy, ou essaie de comprendre pourquoi un client en refuse un. Nous ne distribuons pas de proxies gratuits et nous ne vendons pas d'IP. Ce qui suit couvre les protocoles eux-mêmes, où aboutissent vos résolutions DNS, et comment tester ce que vous avez réellement obtenu.

01HTTP CONNECT ou SOCKS5 : comment chaque tunnel fonctionne#

Avant d'entrer dans le détail, un point compte plus que le reste : le protocole n'est pas l'origine. Un pool résidentiel peut se vendre en HTTP, en SOCKS5, ou les deux. Les IP datacenter aussi. SOCKS5 n'est pas un grade de qualité. C'est une façon de porter des octets. Qu'un site cible fasse confiance à votre trafic dépend du réseau et de l'historique de l'IP, pas de la poignée de main utilisée par votre client pour joindre la passerelle.

Un proxy HTTP parle HTTP à votre client. Il traite deux sortes de trafic différemment.

Avec des URL http:// en clair, le client envoie la requête entière au proxy, qui la lit, la transmet, et peut ajouter, retirer ou mettre en cache des en-têtes en chemin. Peu de sites publics servent encore du HTTP en clair, donc ce chemin est rare en pratique.

Avec des URL https://, et avec tout ce qui n'est pas du HTTP en clair, le client utilise la méthode CONNECT. Selon la RFC 9110, section 9.3.6, CONNECT demande au proxy d'ouvrir un tunnel vers la destination nommée et, une fois cela réussi, d'arrêter d'interpréter le trafic et de relayer simplement les octets dans les deux sens jusqu'à ce qu'un côté ferme. La cible de la requête n'est qu'un hôte et un port, par exemple CONNECT example.com:443. Une fois que le proxy répond avec un statut 2xx, le TLS s'exécute de bout en bout entre votre client et le site. Le proxy peut voir l'hôte et le port demandés, mais il ne peut pas lire la page déchiffrée.

Un proxy SOCKS5 travaille une couche plus bas. La RFC 1928 définit une courte poignée de main binaire : le client propose des méthodes d'authentification, le serveur en choisit une, puis le client envoie une requête avec une commande et une destination. Il y a trois commandes : CONNECT pour un flux TCP ordinaire, BIND pour les connexions entrantes, et UDP ASSOCIATE pour le relais UDP. SOCKS5 se moque que la charge utile soit HTTP, TLS, SMTP ou un protocole de jeu. Il déplace des octets.

Donc « SOCKS5 ou HTTP CONNECT » n'est pas vraiment un choix entre un proxy intelligent et un proxy stupide. Pour le trafic HTTPS, les deux finissent en tunnel TCP opaque. Les vraies différences sont ce que chacun peut porter en plus du HTTPS, comment le nom de destination est transmis, et quels clients savent leur parler.

La RFC 9110 dit aussi que les proxies « SHOULD restrict » CONNECT aux ports connus ou à une liste de cibles configurée, parce qu'un CONNECT ouvert vers le port 25 pourrait servir à relayer du spam. Un point d'accès HTTP peut donc refuser un tunnel vers une base de données, un serveur de courrier ou un port TCP sur mesure, même avec des identifiants valides. Si vous avez besoin de ces ports, vérifiez dans la documentation du fournisseur les ports CONNECT autorisés, ou utilisez un point d'accès SOCKS5 qui les permet.

02DNS : résolu sur votre appareil ou à travers le proxy#

Le DNS est la partie qui change réellement ce qu'un site, ou votre FAI, peut apprendre sur vous, et c'est là que la configuration SOCKS5 se trompe le plus souvent.

Avec un proxy HTTP, le client remet le nom d'hôte dans la cible de la requête (CONNECT example.com:443), et le proxy fait la résolution pour cette connexion. Cela retire la résolution locale pour les requêtes qui passent réellement par le proxy. Cela ne garantit pas que votre appareil ne fasse plus aucune requête DNS : les navigateurs peuvent précharger le DNS, les listes de contournement et les règles « direct » envoient certains hôtes autour du proxy, WebRTC peut ouvrir ses propres connexions, et d'autres applications sur l'appareil continuent d'utiliser le résolveur système.

Avec SOCKS5, c'est le client qui décide. La RFC 1928 permet au champ destination de porter une adresse IPv4 brute, une adresse IPv6 brute, ou un nom de domaine pleinement qualifié. Si le client résout le nom en local et n'envoie que l'IP, le résolveur de votre FAI (ou celui qu'utilise l'OS) voit encore chaque domaine visité, même si le trafic lui-même passe par le proxy. Si le client envoie le nom de domaine, le proxy le résout à son extrémité.

curl rend ce choix visible. Son manuel décrit --socks5 comme « use the specified SOCKS5 proxy - but resolve the hostname locally », tandis que --socks5-hostname, ou le schéma socks5h://, est décrit comme « let the proxy resolve the hostname ». Pour les requêtes proxifiées, cette seule lettre h décide si votre résolveur local voit le nom de destination. D'autres clients cachent le même interrupteur sous des noms comme « Proxy DNS when using SOCKS v5 » ou « remote DNS ». La même réserve que pour HTTP s'applique : le DNS distant couvre le trafic qui passe par le tunnel SOCKS, pas le préchargement, les hôtes contournés, WebRTC ou les autres applications. Confirmez avec un test de fuite plutôt que de supposer.

La résolution distante compte aussi pour le résultat, pas seulement pour la confidentialité. Un CDN qui répond selon l'emplacement du résolveur peut envoyer un nom résolu en local vers un edge près de vous au lieu de près de la sortie du proxy. La page se charge alors depuis la mauvaise région, même si l'IP a l'air correcte.

Exemple schématique, pas une mesure réseau : où le nom de destination est résolu pour les requêtes proxifiées dans chaque configuration. Il ne couvre pas le préchargement du navigateur, les règles de contournement, WebRTC ni les autres applications, qui peuvent encore faire des résolutions locales.

03Compatibilité des clients et authentification#

Choisissez le protocole que votre client parle déjà bien. Ajouter le support par des paquets ou des enveloppes supplémentaires est une source fréquente de tickets « le proxy est cassé ».

Navigateurs. Firefox a des champs HTTP et SOCKS dans ses propres réglages de proxy. Les navigateurs basés sur Chromium suivent les réglages système ou un drapeau --proxy-server. Les deux gèrent CONNECT sans histoire. SOCKS5 avec identifiant et mot de passe est le point faible : les réglages SOCKS intégrés du navigateur n'ont parfois nulle part où saisir des identifiants, ce qui est une raison d'utiliser des extensions de proxy ou des navigateurs anti-détection. Utilisez un protocole par profil. Mélanger un proxy HTTP système et une extension SOCKS5 dans le même profil est une façon simple de voir certaines requêtes emprunter une route et d'autres l'autre.

Scrapers et bibliothèques HTTP. Les clients HTTP courants comme curl acceptent d'emblée un proxy http://user:pass@host:port et utilisent CONNECT tout seuls pour le HTTPS. Dans certaines bibliothèques, SOCKS5 demande un paquet ou une option de compilation en plus. Si votre pile ne récupère que des pages web, le point d'accès HTTP est le chemin avec le moins de surprises. Notre guide de web scraping couvre le côté origine de ce choix.

Applications hors HTTP. Les messageries, les lanceurs de jeux, les clients de courrier, SSH et les outils de bases de données ne sont pas des clients HTTP. Quand ils prennent en charge un proxy, c'est souvent un champ SOCKS plutôt qu'un champ HTTP. C'est là que SOCKS5 convient mieux, et aussi pour le trafic UDP comme la voix lorsque la passerelle implémente réellement UDP ASSOCIATE. Le support SOCKS5 sur une offre ne veut pas dire à lui seul que l'UDP est pris en charge : confirmez-le avant d'acheter pour de l'UDP.

Authentification. Les proxies HTTP envoient les identifiants dans un en-tête Proxy-Authorization et répondent 407 Proxy Authentication Required quand ils manquent ou sont faux. SOCKS5 négocie d'abord une méthode. La RFC 1928 liste GSSAPI et USERNAME/PASSWORD comme méthodes ; une offre qui vous donne un identifiant et un mot de passe utilise la seconde, spécifiée dans la RFC 1929.

SOCKS4 et SOCKS4a sont d'autres protocoles, sans support de mot de passe, et un client uniquement SOCKS4 ne peut pas terminer une poignée de main avec un point d'accès qui ne parle que SOCKS5. Une liste d'autorisation d'IP retire le besoin d'un mot de passe, mais ne change pas le protocole. Il vous faut soit un point d'accès que le fournisseur documente explicitement comme SOCKS4/SOCKS4a, en général associé à une liste d'autorisation d'IP, soit un client qui parle SOCKS5 ou HTTP.

Sur une connexion en clair, non chiffrée, entre votre client et le proxy, l'identifiant n'est pas protégé : les identifiants HTTP Basic ne sont que encodés en Base64, et l'identifiant/mot de passe SOCKS5 circule en clair. Quiconque est sur ce chemin réseau peut les lire. Un point d'accès proxy HTTPS, c'est-à-dire une connexion client-vers-proxy elle-même enveloppée en TLS, protège ce saut, identifiants compris. Dans les deux cas, ne réutilisez pas les identifiants de proxy pour quelque chose d'important.

Vitesse. On demande souvent « SOCKS5 ou proxy HTTP, lequel est plus rapide ». La différence est faible. Les deux ajoutent une poignée de main à l'ouverture de la connexion, et ensuite les deux transmettent des octets. En pratique, la distance jusqu'à la passerelle, la charge du fournisseur et l'IP de sortie décident de la vitesse, pas le protocole. Les proxies HTTP en clair peuvent sembler plus rapides quand ils mettent en cache, mais cela s'applique rarement au HTTPS.

SOCKS5 ou HTTPS. « Proxy HTTPS » veut dire deux choses différentes. En général, cela désigne un proxy HTTP qui tunnelise les sites HTTPS avec CONNECT, c'est-à-dire tout ce qui précède. Parfois, cela désigne le lien entre vous et le proxy lui-même, enveloppé en TLS, ce qui cache vos identifiants de proxy et les noms d'hôte cibles au réseau local. Les connexions proxy HTTP en clair et SOCKS5 ne chiffrent pas ce premier saut : si le cacher compte, utilisez un point d'accès proxy enveloppé en TLS si votre fournisseur et votre client en prennent un en charge, ou un VPN pour ce segment.

04Lequel choisir#

La dernière ligne est l'erreur que les acheteurs font le plus souvent. Passer une IP datacenter de HTTP à SOCKS5 ne la fait pas ressembler à une connexion de foyer. Si un site note votre réseau, changez le type de sortie. Comparez les proxies résidentiels, les proxies mobiles et les proxies datacenter, ou lisez d'abord résidentiel ou datacenter.

05Comment vérifier quel protocole vous avez acheté#

Ne vous fiez pas au numéro de port. 8080, 3128, 1080 et les ports hauts comme 60000 servent aux deux protocoles, et certaines passerelles répondent aux deux sur le même port.

1. Connaissez d'abord votre propre IP. Ouvrez Mon IP sans le proxy, pour avoir une base de comparaison.

2. Vérifiez que le point d'accès répond. Collez le point d'accès du fournisseur dans le vérificateur de proxies sous la forme HOST:PORT ou HOST:PORT:USER:PASS. Le vérificateur tourne sur notre serveur, essaie les protocoles pris en charge et signale le premier qui réussit. Un préfixe de protocole change lequel il essaie en premier, mais n'interdit pas le repli. Un seul résultat positif ne prouve donc pas que le point d'accès accepte à la fois HTTP et SOCKS5. Pour les comparer séparément, utilisez les deux commandes curl ci-dessous ou un client qui vous laisse forcer chaque protocole. Si une vérification échoue, inspectez l'erreur et vérifiez identifiants, liste d'autorisation d'IP et restrictions de l'offre avant de conclure que le protocole n'est pas pris en charge.

3. Vérifiez la même chose en ligne de commande. Utilisez une URL de test neutre pour les deux exécutions, afin que les résultats soient comparables :

   # HTTP proxy: curl sends CONNECT for an https:// URL
   curl -v -x http://USER:PASS@HOST:PORT https://example.com/ -o /dev/null
   
   # SOCKS5 with proxy-side DNS (no local lookup)
   curl -v -x socks5h://USER:PASS@HOST:PORT https://example.com/ -o /dev/null
   

   Dans la sortie verbeuse de la première commande, une ligne CONNECT example.com:443 suivie d'une réponse 200 confirme un tunnel HTTP. Un 407 veut dire que le proxy parle HTTP mais a rejeté les identifiants : c'est un problème d'authentification, pas de protocole. Si la tentative HTTP échoue tout de suite avec une réponse malformée alors que socks5h:// se connecte, le point d'accès parle très probablement SOCKS sur ce port ; confirmez dans la documentation du fournisseur.

4. Comparez les IP de sortie, pas seulement succès/échec. Vérifiez que chaque protocole sort dans le pays et le type de réseau que vous avez payés. Sur un pool rotatif, deux tests peuvent montrer des IP différentes, voire des réseaux différents, quel que soit le protocole : un écart à lui seul ne prouve pas des pools séparés. Une session sticky rend une comparaison à conditions égales plus probable, mais elle ne garantit pas que la même IP soit gardée entre les tests ou après une reconnexion.

5. Surveillez le DNS pendant la même session. Utilisez le DNS distant (socks5h://, ou « Proxy DNS » dans le client) et lancez un test de fuite. Le guide comment vérifier qu'un proxy fonctionne parcourt les contrôles DNS et WebRTC.

6. Testez l'IPv6 à part. SOCKS5 peut porter une destination IPv6, mais seulement si la passerelle a une sortie IPv6. Une fiche dual-stack demande un test dual-stack.

Voici un exemple chiffré hypothétique de lecture des résultats. Disons qu'une offre liste un hôte de passerelle avec deux ports, et que vous lancez les deux commandes curl ci-dessus contre la même URL de test. Ces motifs sont des illustrations, pas des résultats d'un fournisseur réel :

Une courte liste avant de vous arrêter sur un protocole :

• Votre client a un réglage natif pour ce protocole, y compris un champ identifiant et mot de passe si l'offre les utilise.
• Le DNS des requêtes proxifiées est résolu au proxy (socks5h:// ou « Proxy DNS » pour SOCKS5), et un test de fuite a été lancé avec le vrai navigateur ou la vraie application.
• Les ports dont vous avez besoin sont autorisés : cibles CONNECT sur un point d'accès HTTP, UDP sur un point d'accès SOCKS5 si vous en avez besoin.
• Le pays de sortie et le type de réseau correspondent à l'offre, jugés séparément du protocole.
• Le lien de votre appareil vers le proxy est protégé (point d'accès proxy TLS ou VPN) si le passage des identifiants sur ce réseau est un souci.

Le protocole est un choix de compatibilité, l'origine un choix d'accès, et le mode de session (sticky ou rotatif) un choix de parcours. Décidez-les dans cet ordre et vous ne paierez pas SOCKS5 en croyant que c'est une IP plus propre.

06Fournisseurs qui proposent HTTP et SOCKS5#

Avant d'acheter, vérifiez dans la documentation de chaque fournisseur quels protocoles l'offre inclut, les ports ou noms d'hôte de chacun, le support UDP, et si une liste d'autorisation d'IP est disponible si votre client en a besoin.

SOAX — proxies résidentiels et mobiles3.8218

SOAX vend des proxies résidentiels et mobiles rotatifs sur un pool de crédits partagé, avec datacenter et ISP dans les mêmes forfaits. Builder commence à $200/mois + TVA (200 crédits) ; le trafic Tier 1 est à $3/GB sur Builder.

85 pays

3,00 $US

par 1 GB

Bright Data — proxies résidentiels et datacenter4.41442

Bright Data est un grand réseau de proxies pour la collecte de données : IP résidentielles, mobiles, ISP et datacenter dans environ 195 pays. Le trafic résidentiel peut se payer à l'usage sans abonnement, et les adresses datacenter et ISP se vendent par packs dès 10 IP. L'accès résidentiel et mobile exige une vérification d'identité.

10 pays

5,00 $US

par 1 GB

Oxylabs — proxies résidentiels et datacenter4.0771

Oxylabs vend des proxies résidentiels, mobiles, ISP et datacenter sous un seul abonnement mensuel dès $30. Paiements acheteur : cartes, virement, AliPay, PayPal.

10 pays

0,45 $US

par 1 GB

Decodo (Smartproxy) — proxies résidentiels et datacenter4.22118

Decodo (anciennement Smartproxy) vend des proxies résidentiels et datacenter. Résidentiel : $4/GB sans forfait mensuel, ou packs mensuels dès $3.75/GB pour 3 GB. Paiements : cartes, PayPal, Alipay, Google/Apple Pay, crypto (avec limites).

83 pays

0,38 $US

par 1 GB