HTTP proxy et SOCKS5 : différences au niveau du protocole et choix selon la tâche

Un même serveur proxy est souvent fourni au client en deux modes : en tant que proxy HTTP et en tant que SOCKS5. Beaucoup y voient une astuce marketing. Ce n'est pas le cas. Derrière ces deux appellations se cachent deux protocoles de médiation fondamentalement différents, fonctionnant à des niveaux distincts de la pile réseau. Comprendre leur différence permet d'économiser des heures de débogage, de réduire la latence et de choisir le bon outil pour une tâche d'ingénierie précise.

Dans ce guide, nous allons décortiquer la mécanique des deux protocoles, du premier octet du handshake jusqu'au dernier en-tête. Nous verrons ce que l'intermédiaire voit réellement dans chaque mode, pourquoi SOCKS5 ne décompose délibérément pas le contenu du trafic, et comment la méthode CONNECT transforme un simple proxy HTTP en tunnel TCP transparent. À la fin, vous trouverez un tableau de correspondance tâche-protocole et une FAQ détaillée. Le ton reste technique : le minimum de verbiage, le maximum de code et de formulations précises.

Introduction : pourquoi un proxy est fourni en deux modes

Imaginez un bureau de poste. Dans le premier mode, l'employé lit l'adresse sur l'enveloppe, peut replacer la lettre dans une autre enveloppe, apposer un tampon, et parfois même vous signaler qu'une telle lettre est déjà arrivée hier et vous remettre une copie archivée. C'est le proxy HTTP : il comprend la langue dans laquelle la requête est écrite et traite son contenu comme des données signifiantes.

Dans le second mode, le même employé reçoit un conteneur scellé avec une instruction : livrer à telle adresse et tel port, le contenu ne le regarde pas. Il installe simplement un tuyau entre l'expéditeur et le destinataire et fait circuler les octets dans les deux sens. C'est SOCKS5 : un protocole de niveau session, indifférent au contenu du tunnel.

Pourquoi un fournisseur, par exemple Proxeon, propose-t-il les deux modes sur une même infrastructure ? Parce que les besoins des clients diffèrent. L'un a besoin d'un cache et d'un filtrage au niveau HTTP, l'autre d'un transport transparent pour un protocole TCP arbitraire. Un même serveur peut écouter sur plusieurs ports et répondre aux deux scénarios. C'est un choix technique, pas un jeu de mots.

L'idée clé à retenir dès le départ : le proxy HTTP fonctionne au niveau applicatif (L7), tandis que SOCKS5 se situe plus près de la couche session (L5 en pratique). D'où découlent toutes les autres différences : ce que le proxy voit, ce qu'il peut modifier, quels protocoles il supporte et quel surcoût il introduit.

Bases : deux niveaux de médiation

Avant d'aller plus loin, fixons les notions élémentaires. Un proxy est un intermédiaire entre le client et le serveur cible. Le client n'envoie pas sa requête directement mais au proxy, qui la relaie. La différence entre les types de proxy tient au niveau auquel ils comprennent ce qu'ils transmettent.

Couche applicative vs couche session

Un proxy HTTP décompose le message HTTP dans son intégralité. Il voit la méthode (GET, POST), le chemin, tous les en-têtes et, en l'absence de chiffrement, le corps. Cela le rend intelligent et en même temps limité : il ne sait travailler qu'avec le protocole qu'il comprend.

SOCKS5 ne décompose aucun protocole applicatif. Il reçoit du client une commande du type établis une connexion TCP avec l'hôte X sur le port Y et se contente ensuite de relayer les octets. C'est cette neutralité qui fait de SOCKS5 un transport universel pour tout protocole TCP : HTTP, HTTPS, SMTP, IMAP, ainsi que de nombreux protocoles propriétaires de vos propres applications.

Ce que signifie « le proxy voit le contenu »

Quand nous disons qu'un proxy HTTP voit le contenu, il s'agit de HTTP non chiffré. Si le trafic passe par HTTPS via la méthode CONNECT (détaillée plus bas), même un proxy HTTP ne voit qu'un flux chiffré et le nom d'hôte. Nuance importante : le web moderne est presque entièrement en TLS, donc la profondeur d'observation d'un proxy HTTP se limite en pratique à la phase d'établissement du tunnel.

Ports et schémas d'adressage

Côté client, la différence se manifeste dans la façon de configurer le proxy. Pour un proxy HTTP, le schéma est http://user:pass@host:port. Pour SOCKS5, c'est socks5://user:pass@host:port. Les ports des deux modes sont généralement différents, car ce sont des gestionnaires distincts qui écoutent. Un même serveur physique Proxeon peut fournir le proxy HTTP sur un port et SOCKS5 sur un autre.

Proxy HTTP : la requête à URI absolue

Commençons par le proxy HTTP classique et son trait le plus caractéristique : l'URI absolue dans la ligne de requête. C'est ce qui distingue visuellement une requête adressée au proxy d'une requête adressée directement au serveur.

La forme absolue de la requête

Quand un navigateur accède à un site en direct, il envoie un chemin relatif. La ligne de requête ressemble à ceci :

GET /index.html HTTP/1.1\nHost: example.com

Mais quand ce même navigateur est configuré pour un proxy HTTP, il envoie au proxy la forme absolue de l'URI. Le proxy doit savoir exactement où transmettre la requête, c'est pourquoi l'adresse complète figure dans la première ligne :

GET http://example.com/index.html HTTP/1.1\nHost: example.com\nProxy-Connection: keep-alive

C'est une différence fondamentale. Le proxy lit http://example.com/index.html, extrait l'hôte, établit une connexion avec le serveur cible et transmet la requête sous sa forme habituelle, relative. La RFC 7230 prescrit explicitement aux clients d'utiliser la forme absolue lors d'une requête à un proxy et la forme origin lors d'une requête directe.

Ce que le proxy voit et peut modifier

En mode HTTP non chiffré, le proxy voit énormément de choses. Énumérons :

• L'URL complète, y compris le chemin et les paramètres de requête.
• Tous les en-têtes de requête : User-Agent, Accept, Cookie, Referer.
• Le corps de la requête en cas de POST ou PUT.
• La réponse du serveur dans son intégralité : statut, en-têtes, corps.

De plus, le proxy peut légitimement et utilement modifier le trafic. Opérations typiques d'un proxy HTTP d'entreprise ou de service :

• Ajout d'en-têtes de service, par exemple X-Forwarded-For ou Via.
• Suppression d'en-têtes hop-by-hop qui ne doivent pas aller plus loin (Connection, Proxy-Authorization).
• Mise en cache des réponses pour les requêtes répétées.
• Compression ou transformation du contenu en configuration explicite.

En-têtes spécifiques au proxy

Certains en-têtes n'ont de sens que dans le dialogue client-proxy et ne doivent pas fuiter vers le serveur cible. Le principal est Proxy-Authorization, qui porte les identifiants d'accès au proxy lui-même. Ne le confondez pas avec Authorization, destiné au serveur cible. Il existe aussi une paire de statuts : 407 Proxy Authentication Required signifie que le proxy exige une authentification, contrairement à 401 provenant du serveur cible.

Exemple pratique : proxy HTTP explicite via curl

Voyons comment adresser une requête au proxy HTTP Proxeon avec curl. L'option -x définit le proxy, et -v affiche le dialogue :

curl -v -x http://user:pass@proxy.proxeon.net:8080 http://example.com/

Dans la sortie, vous verrez la ligne de requête en forme absolue et l'en-tête Proxy-Authorization avec les identifiants encodés en Base64. Cela démontre clairement que curl communique bien avec le proxy, pas directement avec le serveur cible.

Limite : uniquement la sémantique HTTP

Un proxy HTTP classique dans sa forme première ne sait transmettre que des requêtes HTTP. Il ne sait pas quoi faire d'un flux TCP arbitraire SMTP ou d'un protocole binaire de votre application. Pour du HTTP non chiffré, cela fonctionne parfaitement. Mais dès qu'apparaît HTTPS ou un autre protocole, un mécanisme de tunnelisation devient nécessaire. C'est là qu'entre en scène la méthode CONNECT.

La méthode CONNECT : le proxy HTTP comme tunnel TCP

La méthode CONNECT est ce qui permet à un proxy HTTP de servir HTTPS et, plus généralement, tout flux TCP. Elle transforme un intermédiaire applicatif intelligent en tuyau transparent. Détaillons la mécanique étape par étape.

Pourquoi CONNECT a été nécessaire

HTTPS chiffre l'intégralité du message, y compris les en-têtes et le chemin. Si le proxy tentait de lire une URI absolue, il se heurterait à des octets chiffrés. Le handshake TLS doit se dérouler directement entre le client et le serveur cible, sinon le chiffrement de bout en bout est perdu. Le proxy doit donc non pas lire, mais simplement connecter deux points et s'écarter.

À quoi ressemble une requête CONNECT

Le client envoie au proxy une requête spéciale où, au lieu d'une URL, il indique une paire hôte-port en forme authority :

CONNECT example.com:443 HTTP/1.1\nHost: example.com:443\nProxy-Authorization: Basic dХNlcjpwYXNz

Le proxy établit une connexion TCP avec example.com:443 et, si tout se passe bien, répond :

HTTP/1.1 200 Connection Established

Après cette ligne se produit l'événement crucial : le proxy cesse d'être un analyseur HTTP. Il devient un relais d'octets bidirectionnel. Tout ce que le client envoie ensuite est copié vers le serveur, et inversement. C'est sur ce tunnel que le navigateur lance le handshake TLS avec le serveur cible directement.

Ce que l'intermédiaire voit après l'établissement du tunnel

C'est la question centrale de confidentialité et de sécurité. Après 200 Connection Established, le proxy HTTP voit :

• Le nom d'hôte et le port de la commande CONNECT elle-même, avant l'établissement du tunnel.
• Le flux d'octets chiffré et rien d'autre.
• Le SNI (Server Name Indication) à l'intérieur du ClientHello TLS, si le chiffrement du SNI n'est pas utilisé, ce qui révèle aussi le nom d'hôte.
• Les métadonnées de connexion : volume de données transmises, durée, timings.

Ce que le proxy ne voit pas après le tunnel : le chemin de l'URL, les paramètres de requête, les en-têtes, les cookies, le corps des requêtes et des réponses. Tout cela est protégé par TLS. Ainsi, pour le trafic HTTPS, un proxy HTTP en mode CONNECT se comporte presque comme SOCKS5 : il n'est qu'un transport. La différence reste dans la manière dont le client négocie le tunnel.

En pratique : CONNECT en action

Quand vous faites une requête HTTPS via un proxy HTTP, curl utilise automatiquement CONNECT. Observez le dialogue :

curl -v -x http://user:pass@proxy.proxeon.net:8080 https://example.com/

Dans la sortie verbose, vous verrez d'abord la ligne CONNECT example.com:443 HTTP/1.1, puis la réponse 200 Connection Established, et seulement ensuite les lignes du handshake TLS et la requête GET qui circule dans le tunnel chiffré. Le proxy, lui, n'a vu que la première partie.

CONNECT n'est pas limité au port 443

Bien que CONNECT mène le plus souvent au port 443, la spécification ne le lie pas à HTTPS. Techniquement, CONNECT permet de tunneliser tout protocole TCP sur n'importe quel port, si le proxy l'autorise. En pratique, les administrateurs limitent souvent la liste des ports autorisés pour des raisons de sécurité, en laissant 443 et parfois 22 ou d'autres. Une tentative de faire passer, disons, SMTP via CONNECT peut donc se heurter à la politique du proxy.

SOCKS5 : handshake, authentification et ATYP

Passons à SOCKS5, défini dans la RFC 1928. C'est un protocole de philosophie radicalement différente. Il ne sait pas, et ne veut pas savoir, ce que vous transmettez. Sa tâche est d'établir une connexion et de devenir un tuyau.

Logique générale du handshake

Le dialogue SOCKS5 est binaire, contrairement au HTTP qui est textuel. Il se compose de plusieurs courts échanges de messages. Schématiquement :

1. Le client envoie la liste des méthodes d'authentification prises en charge.
2. Le serveur choisit une méthode et la communique.
3. Si nécessaire, l'authentification a lieu.
4. Le client envoie une demande de connexion : commande, type d'adresse, adresse, port.
5. Le serveur répond avec le résultat.
6. La transmission transparente des données commence.

Le message d'accueil et le choix de méthode

Le premier message du client est très compact. Il contient le numéro de version (0x05), le nombre de méthodes proposées et les méthodes elles-mêmes. Les deux plus utilisées : 0x00 pour aucune authentification et 0x02 pour l'authentification par identifiant et mot de passe (RFC 1929). Le serveur répond avec deux octets : version et méthode choisie. Si le serveur renvoie 0xFF, aucune méthode proposée ne convient et la connexion est fermée.

Authentification par identifiant et mot de passe

Si la méthode 0x02 est choisie, le client envoie un message distinct avec la version du sous-protocole, la longueur et la valeur du nom d'utilisateur, puis la longueur et la valeur du mot de passe. Le serveur répond par un statut. Nuance technique importante : dans SOCKS5 classique, ces données sont transmises sans chiffrement intégré. Il ne faut donc faire confiance à de tels proxy que via des canaux sécurisés ou dans un environnement contrôlé. Pour les proxy de service comme Proxeon, l'authentification peut être complétée par une liaison à l'IP, ce qui réduit les risques de fuite d'identifiants.

Commandes : CONNECT, BIND et UDP ASSOCIATE

SOCKS5 prend en charge trois commandes. La plus fréquente est CONNECT (0x01), qui établit une connexion TCP sortante. Il y a BIND (0x02) pour les connexions entrantes dans des protocoles comme l'ancien FTP. Et il y a UDP ASSOCIATE (0x03) pour proxyfier des datagrammes UDP. Nous ne détaillons pas ici la mécanique d'UDP ASSOCIATE ni les différences entre les schémas socks5 et socks5h, ce sont de vastes sujets traités dans des articles dédiés. Concentrons-nous sur le point le plus fondamental pour la comparaison avec le proxy HTTP : le champ ATYP.

ATYP : domaine contre IP et pourquoi c'est crucial pour la résolution

Dans la demande de connexion SOCKS5, il existe un champ ATYP (address type) qui détermine comment interpréter l'adresse qui suit. Trois valeurs possibles :

• 0x01 : adresse IPv4, quatre octets.
• 0x03 : nom de domaine, premier octet pour la longueur, puis la chaîne elle-même.
• 0x04 : adresse IPv6, seize octets.

C'est là que se cache l'une des différences pratiques les plus importantes. Quand le client envoie un nom de domaine (ATYP 0x03), la résolution DNS est effectuée par le serveur proxy, pas par le client. Quand le client envoie une adresse IP déjà résolue, la résolution a eu lieu côté client. La différence influe sur le DNS utilisé, l'IP que recevra finalement le serveur cible et la précision du routage géodépendant.

Pour l'ingénieur, cela signifie ceci : si vous tenez à ce que le nom soit résolu dans le réseau du proxy, vous devez transmettre le domaine, pas l'IP. Beaucoup de bibliothèques résolvent d'abord le nom localement, puis contactent le proxy, ce qui modifie le comportement. L'analyse détaillée des différences entre résolution locale et distante, ainsi que des schémas socks5 et socks5h, est traitée dans un article séparé. Nous nous contentons ici de constater le simple fait de l'existence du champ ATYP comme levier de contrôle clé.

En pratique : SOCKS5 via curl

L'appel à un proxy SOCKS5 dans curl ressemble à la variante HTTP, seul le schéma change :

curl -v --socks5 user:pass@proxy.proxeon.net:1080 https://example.com/

Notez que curl n'enverra aucune ligne CONNECT sous forme textuelle : il effectuera un handshake SOCKS5 binaire, puis fera circuler le trafic TLS dans le tunnel établi. Pour l'application, la différence est presque imperceptible, mais au niveau du protocole, c'est un tout autre dialogue qui se déroule.

Pourquoi SOCKS5 ne décompose pas le contenu, et c'est sa force

La philosophie de SOCKS5 est le minimalisme. Il ne cherche pas à comprendre s'il y a du HTTP, du SMTP ou votre propre protocole à l'intérieur. Cela le rend :

• Universel : tout protocole TCP passe sans support spécial.
• Léger : handshake court, aucune analyse de la couche applicative.
• Transparent : le proxy n'intervient pas dans les données, ne modifie rien et ne met rien en cache.

Le revers de la médaille : SOCKS5 ne sait pas mettre en cache, filtrer par URL ou ajouter des en-têtes, tout simplement parce qu'il ne les voit pas. L'universalité a pour prix le renoncement à l'intelligence applicative.

Comparaison par critères : ce qui compte en pratique

Rassemblons les différences dans une comparaison structurée selon les paramètres qui influent réellement sur le choix dans les tâches d'ingénierie.

Prise en charge des protocoles non-HTTP

SOCKS5 fonctionne avec tout protocole TCP : IMAP et SMTP, bases de données, protocoles de jeu, vos propres échanges binaires. Le proxy HTTP classique ne comprend nativement que HTTP. Via CONNECT, il peut tunneliser d'autres protocoles TCP, mais seulement si le proxy autorise le port correspondant. En pratique, cela se limite souvent à 443. Conclusion : pour les protocoles arbitraires, SOCKS5 est préférable.

UDP

Le proxy HTTP ne gère aucunement l'UDP, son modèle repose sur des requêtes TCP. SOCKS5 dispose de la commande UDP ASSOCIATE et peut proxyfier des datagrammes. Nous n'en détaillons pas ici la mécanique, mais le fait même est important : si la tâche exige de l'UDP, le proxy HTTP est immédiatement écarté.

Surcoût

Le handshake SOCKS5 se compose de quelques courts messages binaires. Pour une nouvelle connexion, c'est très bon marché. Le proxy HTTP en mode CONNECT dépense un aller-retour supplémentaire pour la paire requête CONNECT et réponse 200 avant le début de TLS. Dans un scénario de nombreuses connexions courtes, la différence de latence peut s'accumuler. En revanche, avec un keep-alive constant et une réutilisation des connexions, la différence s'estompe. Pour le trafic HTTP, le proxy HTTP peut tirer son épingle du jeu grâce au cache et au pool de connexions.

Mise en cache

Ici, le proxy HTTP est sans concurrence. Puisqu'il comprend la sémantique HTTP, il peut mettre en cache les réponses, respecter les en-têtes Cache-Control et ETag, renvoyer 304 Not Modified. Pour des requêtes répétées vers des ressources statiques, cela réduit sensiblement le trafic et la latence. SOCKS5 ne peut pas mettre en cache physiquement, il ne voit pas ce qu'il y a à l'intérieur. Si votre objectif est d'accélérer des requêtes HTTP massives vers des ressources récurrentes, un proxy HTTP avec cache apporte un gain réel.

Journalisation et observabilité

Un proxy HTTP peut tenir un journal d'accès détaillé : méthode, URL, code de réponse, taille, User-Agent. C'est précieux pour l'audit, le débogage et l'analytique, en HTTP non chiffré. Pour HTTPS via CONNECT, le niveau de détail descend à hôte-port-volume. SOCKS5 ne journalise que les métadonnées de connexion : adresse de destination, heure, volume de trafic. Si vous avez besoin d'observabilité applicative sur HTTP, choisissez un proxy HTTP ; si les métriques de transport suffisent, SOCKS5 fera l'affaire.

Modification du trafic

Le proxy HTTP peut légitimement ajouter et retirer des en-têtes, ce qui est utile à des fins de service. SOCKS5 ne touche pas du tout aux données. Pour les scénarios où toute intervention est inacceptable par principe, la transparence de SOCKS5 est un atout.

Tableau récapitulatif des différences

• Niveau du modèle : proxy HTTP applicatif L7 ; SOCKS5 session L5.
• Format du dialogue : HTTP textuel ; SOCKS5 binaire.
• Protocoles non-HTTP : HTTP uniquement via CONNECT et avec restrictions ; SOCKS5 nativement.
• UDP : HTTP non ; SOCKS5 oui.
• Mise en cache : HTTP oui ; SOCKS5 non.
• Journalisation applicative : HTTP oui pour le non chiffré ; SOCKS5 métadonnées uniquement.
• Modification des en-têtes : HTTP oui ; SOCKS5 non.
• Surcoût par connexion : HTTP CONNECT aller-retour supplémentaire ; SOCKS5 minimal.

Que choisir selon la tâche : cadre pratique

La théorie prend de la valeur quand elle se transforme en décision. Voici un cadre de choix et le tableau de correspondance principal. Commençons par trois questions à se poser avant de choisir.

Trois questions avant de choisir

1. Quel protocole je transmets ? Uniquement HTTP et HTTPS : les deux conviennent, mais le proxy HTTP offre le cache et les logs en bonus. TCP arbitraire ou UDP : SOCKS5 uniquement.
2. Ai-je besoin d'observabilité applicative ou de cache ? Si oui, proxy HTTP. Si un tuyau transparent pur suffit, SOCKS5.
3. Où doit avoir lieu la résolution DNS ? S'il est important de résoudre les noms côté proxy, tenez compte du comportement d'ATYP et de la configuration du client.

Tableau principal : tâche, protocole, pourquoi

• Navigateur web, navigation ordinaire : proxy HTTP ou SOCKS5, les deux fonctionnent ; le proxy HTTP ajoute le cache et la compatibilité avec les politiques d'entreprise, SOCKS5 est plus simple pour les ports non standard.
• Client HTTP pour intégrations API : proxy HTTP, support natif, configuration simple via variables d'environnement, logs détaillés pour le débogage.
• Collecte massive de données via HTTPS : SOCKS5 ou proxy HTTP, en HTTPS les deux ne sont que transport ; SOCKS5 économise un aller-retour sur les connexions courtes, le proxy HTTP est pratique grâce au pool de connexions.
• Client mail (SMTP, IMAP, POP3) : SOCKS5, les protocoles mail ne sont pas HTTP ; le proxy HTTP via CONNECT est souvent bloqué par port.
• Logiciel maison avec protocole TCP binaire : SOCKS5, transport universel pour tout TCP sans support spécial.
• Application nécessitant UDP : SOCKS5, seule option via UDP ASSOCIATE ; le proxy HTTP ne gère pas UDP.
• Accélération de l'accès à des ressources statiques récurrentes : proxy HTTP avec cache, capable de renvoyer des réponses mises en cache et d'économiser du trafic.
• Audit et log détaillé des requêtes HTTP : proxy HTTP, voit les méthodes, URL et codes en HTTP non chiffré.
• Travail avec plusieurs protocoles simultanément depuis une seule application : SOCKS5, un transport unique couvre tous les échanges TCP.

Check-list de sélection

• Identifiez le protocole de l'application : HTTP, autre TCP, ou UDP.
• Décidez si le cache et le log applicatif sont nécessaires.
• Vérifiez que votre client prend en charge le schéma proxy voulu.
• Renseignez-vous auprès du fournisseur sur les ports ouverts pour CONNECT si vous comptez tunneliser autre chose que 443.
• Réfléchissez à l'endroit où doit se faire la résolution DNS.
• Prévoyez l'authentification : identifiant-mot de passe ou liaison IP.

Compatibilité dans les clients et bibliothèques populaires

Le choix du protocole n'a pas de sens sans comprendre comment le configurer dans les outils concrets. Passons en revue les principaux.

curl

curl prend en charge les deux protocoles. Pour un proxy HTTP, utilisez -x http://..., pour SOCKS5, --socks5 ou -x socks5://.... Il existe aussi une variante avec résolution du nom côté proxy SOCKS5, définie par un schéma distinct ; les détails sont traités dans un article spécialisé. Exemple :

curl -x socks5://user:pass@proxy.proxeon.net:1080 https://api.example.com/v1/status

Variables d'environnement

Beaucoup d'outils CLI et de bibliothèques respectent les variables http_proxy, https_proxy et all_proxy. Cette dernière accepte souvent un schéma SOCKS5. Pratique pour une configuration globale sans modifier le code :

export https_proxy=http://user:pass@proxy.proxeon.net:8080\nexport all_proxy=socks5://user:pass@proxy.proxeon.net:1080

Python : requests et httpx

La bibliothèque requests se configure avec un dictionnaire proxies. Pour SOCKS5, un paquet supplémentaire avec support SOCKS est nécessaire :

import requests\nproxies = {"http": "http://user:pass@proxy.proxeon.net:8080", "https": "http://user:pass@proxy.proxeon.net:8080"}\nr = requests.get("https://example.com/", proxies=proxies, timeout=10)\nprint(r.status_code)

Pour SOCKS5, le schéma devient socks5, et pour la résolution distante un schéma distinct s'applique. La bibliothèque httpx fonctionne de façon similaire et gère les requêtes asynchrones, pratique pour les opérations massives.

Node.js

Dans l'écosystème Node, le proxy est défini via des agents spéciaux. Pour un proxy HTTP, on utilise https-proxy-agent, pour SOCKS, socks-proxy-agent. Schématiquement :

const { SocksProxyAgent } = require('socks-proxy-agent');\nconst agent = new SocksProxyAgent('socks5://user:pass@proxy.proxeon.net:1080');\nfetch('https://example.com/', { agent }).then(r => console.log(r.status));

Navigateurs

Les navigateurs prennent en charge les deux types via les paramètres système ou des fichiers PAC. La famille Chromium accepte un drapeau de lancement indiquant le serveur proxy, et Firefox dispose de ses propres paramètres, dont une option pour proxyfier le DNS avec SOCKS. C'est justement dans les navigateurs que la question de savoir qui résout le nom se pose le plus souvent ; les détails sont dans un article dédié aux schémas SOCKS.

Clients mail

Les clients mail classiques prennent généralement en charge SOCKS5 comme transport pour SMTP et IMAP. Le proxy HTTP pour le mail s'applique rarement, et seulement via CONNECT, ce qui se heurte souvent aux limitations de ports. Conclusion pratique : pour le mail, considérez par défaut SOCKS5.

Logiciel maison

Si vous écrivez votre application vous-même, SOCKS5 s'implémente par une bibliothèque de transport ou une enveloppe au-dessus du socket. Pour un client HTTP intégré à l'application, il est plus simple de s'appuyer sur le support natif du proxy HTTP dans la bibliothèque HTTP utilisée. Conseil clé : n'implémentez pas à la main le décodage du handshake SOCKS, utilisez des bibliothèques éprouvées, car un protocole binaire est facile à implémenter de façon erronée dans les cas limites.

Idées fausses courantes

Beaucoup de mythes se sont accumulés autour du sujet. Décortiquons-les sous forme de liste, pour que vous ne perdiez pas de temps sur de fausses prémisses.

• « SOCKS5 est toujours plus rapide qu'un proxy HTTP ». Pas toujours. Sur les connexions courtes, SOCKS5 économise un aller-retour, mais un proxy HTTP avec cache et pool de connexions peut le dépasser sur des requêtes HTTP répétées.
• « SOCKS5 chiffre le trafic ». Non. SOCKS5 n'ajoute aucun chiffrement. La confidentialité est assurée par TLS à l'intérieur du tunnel, pas par SOCKS5 lui-même. Même les identifiants en SOCKS5 classique sont transmis sans chiffrement intégré.
• « Le proxy HTTP voit tout, y compris HTTPS ». Non. Pour HTTPS via CONNECT, le proxy ne voit que le nom d'hôte, le port et le volume. Le contenu est protégé par TLS.
• « Proxy HTTP et SOCKS5, c'est la même chose sur des ports différents ». Non. Ce sont des protocoles différents. La coïncidence d'adresse du serveur ne les rend pas identiques.
• « SOCKS5 ne gère pas l'authentification ». Si, par la méthode username/password de la RFC 1929, et une liaison à l'IP est également possible.
• « On ne peut pas travailler avec des protocoles non-HTTP via un proxy HTTP ». On peut, via CONNECT, mais à condition que le proxy autorise le port requis.
• « Si le navigateur est configuré en SOCKS5, le DNS est toujours résolu par le proxy ». Pas toujours. Cela dépend des paramètres du client et du fait qu'un domaine ou une IP déjà résolue soit transmis dans le champ ATYP.
• « CONNECT ne fonctionne que pour le 443 ». Techniquement non, mais les administrateurs limitent souvent les ports par politique.
• « SOCKS5 sait mettre en cache ». Non. Il ne voit pas le contenu et ne peut physiquement pas mettre en cache.

Outils et ressources pour le travail

Pour travailler sereinement avec les deux protocoles, il est utile d'avoir sous la main un ensemble d'outils de diagnostic et de vérification.

Diagnostic des connexions

• curl avec l'option -v : le meilleur moyen de voir le dialogue réel : la ligne CONNECT, la réponse du proxy, le handshake TLS.
• Analyseur de trafic : montre le handshake binaire SOCKS5 et la différence avec le dialogue HTTP textuel au niveau des paquets.
• Utilitaires de vérification d'ouverture de ports : aident à comprendre quels ports sont accessibles pour CONNECT sur votre proxy.

Bibliothèques

• Pour Python : requests et httpx avec extension de support SOCKS.
• Pour Node.js : les agents https-proxy-agent et socks-proxy-agent.
• Pour l'intégration système : les variables d'environnement http_proxy, https_proxy, all_proxy.

Ce qu'il faut vérifier lors de la connexion à Proxeon

• Le bon schéma : http pour le proxy HTTP, socks5 pour SOCKS5.
• Le bon port pour chaque mode, ils diffèrent.
• La méthode d'authentification : identifiant-mot de passe ou liaison IP.
• La liste des ports autorisés pour CONNECT, si vous comptez tunneliser autre chose que 443.
• Le comportement DNS : où vous voulez exactement résoudre les noms.

Mini-cadre de débogage

1. Répétez la requête directement sans proxy : assurez-vous que la cible est accessible.
2. Répétez avec le proxy et l'option -v : étudiez le dialogue.
3. Si HTTPS ne s'établit pas, vérifiez si le port est autorisé pour CONNECT.
4. Si le nom ne se résout pas, vérifiez si un domaine ou une IP part vers le proxy.
5. Si erreur 407, vérifiez les identifiants et l'en-tête Proxy-Authorization.

Cas et résultats d'application

Examinons quelques scénarios d'ingénierie typiques et la façon dont le choix du protocole influe sur le résultat. Les chiffres sont indicatifs et servent à illustrer les dépendances, pas de promesse publicitaire.

Cas 1 : intégration API avec un service externe

Une équipe a intégré son backend avec une API REST externe via le proxy Proxeon pour contrôler l'adresse sortante. Au départ, SOCKS5 avait été choisi, mais la bibliothèque HTTP standard se configurait plus simplement sur un proxy HTTP via variables d'environnement. Le passage au proxy HTTP a simplifié la configuration, et des logs d'accès détaillés sur les appels de service non chiffrés ont aidé à identifier rapidement les causes d'erreurs 5xx chez le partenaire. Conclusion : pour une API HTTP pure, le proxy HTTP est plus pratique.

Cas 2 : passerelle mail

Un service envoyait des notifications par SMTP via une adresse sortante fixe. La tentative d'utiliser un proxy HTTP via CONNECT a échoué : le proxy n'autorisait que le 443. Le passage à SOCKS5 a résolu la question instantanément, car SOCKS5 est neutre vis-à-vis du protocole et a établi la connexion sur le 587 sans restriction au niveau applicatif. Conclusion : pour les protocoles non-HTTP, SOCKS5 est le choix naturel.

Cas 3 : collecte massive de données publiques via HTTPS

Lors de la collecte d'un grand nombre de pages en HTTPS, les ingénieurs ont comparé les deux modes. Sur de nombreuses connexions courtes, SOCKS5 donnait une latence d'établissement moyenne légèrement inférieure grâce à l'absence d'aller-retour CONNECT supplémentaire. Mais lorsqu'ils ont activé la réutilisation des connexions et le keep-alive via le proxy HTTP, la différence a presque disparu. Conclusion : sur des connexions courtes, SOCKS5 économise au handshake, sur les longues, la différence est négligeable.

Cas 4 : protocole binaire de télémétrie maison

Une entreprise transmettait de la télémétrie via son propre protocole TCP. Le proxy HTTP ne convenait pas conceptuellement : le protocole n'est pas HTTP. SOCKS5 est devenu le seul transport raisonnable : l'application ouvrait un socket ordinaire via un agent SOCKS5, et le protocole fonctionnait sans modification. Conclusion : pour tout TCP arbitraire, SOCKS5 est irremplaçable.

Cas 5 : accélération de l'accès à des ressources statiques

Un service interne accédait fréquemment au même ensemble de ressources statiques en HTTP. Un proxy HTTP avec cache a sensiblement réduit le trafic sortant et le temps de réponse grâce à la restitution des représentations mises en cache et au traitement correct des requêtes conditionnelles. SOCKS5 ne pouvait en aucun cas offrir une telle optimisation. Conclusion : là où les requêtes HTTP sont répétitives, un proxy HTTP avec cache apporte un bénéfice mesurable.

FAQ : questions fréquentes

Peut-on utiliser le même compte Proxeon pour HTTP et SOCKS5 ?

En règle générale, oui, seuls le schéma et le port de connexion changent. Vérifiez dans votre panneau quels ports correspondent à chaque mode et quelle méthode d'authentification est configurée. Techniquement, c'est la même ressource fournie en deux modes.

Que choisir si je ne suis pas sûr du protocole dont j'ai besoin ?

Si votre application fonctionne exclusivement en HTTP et HTTPS, commencez par le proxy HTTP : il est plus simple à configurer et offre des logs avec cache. S'il apparaît ne serait-ce qu'un protocole non-HTTP ou de l'UDP, choisissez SOCKS5 comme transport plus universel.

Pourquoi la différence entre proxy HTTP et SOCKS5 est-elle presque invisible en HTTPS ?

Parce qu'en HTTPS le contenu est protégé par TLS, et les deux types de proxy ne sont que transport. Le proxy HTTP, dans ce cas, devient via CONNECT un tuyau identique à SOCKS5. Seul diffère le mode de négociation du tunnel : CONNECT textuel contre handshake binaire.

Le choix du protocole influe-t-il sur qui effectue la résolution DNS ?

Oui, indirectement. En SOCKS5, cela est réglé par le champ ATYP : si un domaine est transmis, c'est le proxy qui résout ; si une IP, c'est le client. En proxy HTTP, le nom de l'URL ou de la ligne CONNECT peut aussi être résolu côté proxy. Le comportement exact dépend du client et de ses paramètres, et l'analyse détaillée est traitée dans un article séparé.

Est-il sûr de transmettre identifiant et mot de passe en SOCKS5 ?

Le SOCKS5 classique ne chiffre pas les identifiants de manière intégrée. Utilisez-le donc dans un environnement de confiance ou en combinaison avec des mesures de protection supplémentaires. Pour les proxy de service, une liaison à l'IP est souvent disponible, ce qui réduit la dépendance à la transmission du mot de passe à chaque connexion.

Peut-on tunneliser n'importe quel port via CONNECT ?

Techniquement, la spécification ne l'interdit pas, mais en pratique l'administrateur du proxy limite souvent la liste des ports pour des raisons de sécurité. Le plus souvent, seul le 443 est autorisé. Si vous avez besoin d'un port non standard, renseignez-vous sur la politique ou envisagez SOCKS5, qui est neutre vis-à-vis des ports.

SOCKS5 offre-t-il une anonymisation supérieure au proxy HTTP ?

En soi, non. L'anonymat n'est pas déterminé par le type de protocole, mais par les métadonnées transmises et journalisées, et par la protection du trafic par TLS. Le proxy HTTP peut ajouter des en-têtes de service révélant le client, mais une configuration correcte permet de l'éviter. SOCKS5 n'ajoute pas d'en-têtes applicatifs tout simplement parce qu'il ne les voit pas.

Que se passe-t-il si le serveur cible derrière le proxy est injoignable ?

Le proxy HTTP renverra un code d'erreur HTTP, par exemple 502 ou 504. SOCKS5 renverra un code d'erreur dans la réponse à la commande de connexion, par exemple hôte injoignable ou connexion refusée. Dans les deux cas, le client reçoit un signal clair, mais sous une forme différente : textuelle en HTTP et binaire en SOCKS5.

Faut-il un proxy distinct pour l'UDP ?

Seul SOCKS5 prend en charge l'UDP via la commande UDP ASSOCIATE. Le proxy HTTP ne fonctionne pas avec l'UDP. Nous détaillons la mécanique de cette commande dans un article séparé ; ici, il suffit de retenir le fait même : si vous avez besoin d'UDP, c'est le domaine de SOCKS5.

Comment savoir si le proxy fonctionne vraiment dans le mode voulu ?

Le moyen le plus fiable est d'exécuter une requête via curl avec l'option -v et d'observer le dialogue. Pour un proxy HTTP, vous verrez une URI absolue ou une ligne CONNECT ; pour SOCKS5, l'absence de dialogue HTTP textuel avant la requête elle-même et un code de réponse correct. Vous pouvez en outre vérifier l'adresse sortante via un service affichant votre IP.

Conclusion : comment prendre la bonne décision

Nous avons parcouru le chemin de la philosophie des deux protocoles jusqu'à des lignes de code concrètes. Résumons de manière technique et sans détour.

Le proxy HTTP est un intermédiaire applicatif intelligent. Il comprend HTTP, voit et peut modifier les requêtes non chiffrées, sait mettre en cache et tenir des logs détaillés. Sa méthode CONNECT le transforme en tunnel TCP pour HTTPS et d'autres protocoles, avec la réserve des ports autorisés. Choisissez-le quand vous travaillez principalement en HTTP et HTTPS et que vous appréciez l'observabilité et le cache.

SOCKS5 est un transport minimaliste et universel. Il ne voit rien du contenu, ne met rien en cache, ne filtre rien, mais il fait passer n'importe quel TCP, y compris les protocoles propriétaires, et gère l'UDP via UDP ASSOCIATE. Ses coûts d'établissement sont minimes. Choisissez-le pour tout ce qui n'est pas HTTP, pour l'UDP, pour un transport binaire propre et pour la simplicité d'un mécanisme unique couvrant différents protocoles.

Si vous deviez retenir une seule règle pratique, ce serait celle-ci : partez du protocole de votre application, pas des caractéristiques du proxy. Le protocole détermine ce qui est possible en principe, et la politique du fournisseur détermine ce qui est possible en pratique. Combinez les deux, et le choix du bon mode cessera d'être une loterie.