Démarrer l'essai gratuitSe connecter

Glossaire

Qu'est-ce qu'un proxy SOCKS5 ?

Un proxy SOCKS5 est un serveur proxy qui utilise le protocole SOCKS5 pour transférer du trafic TCP et UDP arbitraire entre un client et une destination, sans analyser ni modifier la charge utile de la couche applicative.

Comprenez en quoi SOCKS5 diffère des proxies HTTP, pourquoi il prend en charge n'importe quel protocole TCP/UDP (pas seulement HTTP), et quand les scrapers, les clients de jeux et les utilisateurs de torrents préfèrent SOCKS5.

Expliqué

SOCKS5 est un protocole proxy de couche transport défini dans la RFC 1928. Contrairement à un proxy HTTP, qui comprend et analyse les requêtes et réponses HTTP, un proxy SOCKS5 opère à un niveau inférieur : il transfère des paquets TCP ou UDP bruts entre vous et la destination sans inspecter ni modifier la charge utile. Cela signifie qu'un proxy SOCKS5 peut transporter n'importe quel protocole fonctionnant sur TCP ou UDP, pas seulement le trafic web.

SOCKS5 est la version moderne du protocole proxy SOCKS, ajoutant la prise en charge d'IPv6, du transfert UDP et des méthodes d'authentification (sans authentification, nom d'utilisateur/mot de passe, GSS-API). La plupart des fournisseurs de proxies résidentiels et ISP exposent leurs points de terminaison via HTTP et SOCKS5 afin que les clients puissent choisir le protocole adapté à leur infrastructure.

Pour le scraping web via HTTPS, un proxy HTTP CONNECT et un proxy SOCKS5 se comportent de manière presque identique — les deux finissent par tunneliser du trafic TCP chiffré. Les différences deviennent significatives lorsque votre client utilise des protocoles non HTTP (FTP, SMTP, IRC, BitTorrent, jeux) ou lorsque vous avez spécifiquement besoin de la prise en charge UDP.

Comment ça fonctionne

Lorsque votre client se connecte à un proxy SOCKS5, il envoie une petite négociation spécifiant la méthode d'authentification, puis une commande CONNECT avec l'hôte et le port de destination. Le proxy ouvre une connexion TCP vers cette destination et se contente ensuite de relayer les octets entre le client et la destination. Il n'y a pas de couche HTTP — le proxy ne lit pas l'URL, les en-têtes ni le corps de la réponse.

Cette transparence au niveau de la couche transport explique pourquoi SOCKS5 fonctionne avec n'importe quel protocole basé sur TCP. La prise en charge UDP utilise un flux UDP ASSOCIATE séparé où le client envoie des datagrammes UDP au proxy et le proxy les transfère vers la cible. L'authentification, si elle est utilisée, se produit une seule fois lors de la négociation initiale et s'applique à toute la session.

Types

SOCKS5 authentifié (nom d'utilisateur/mot de passe)

SOCKS5 avec authentification par identifiants, le mode standard pour les services proxy payants. Le nom d'utilisateur encode souvent le ciblage géographique et les paramètres de session (par exemple `USER-country-us-session-12345`).

SOCKS5 non authentifié

SOCKS5 sans authentification, généralement utilisé pour les proxies internes auto-hébergés sur des réseaux privés où le contrôle d'accès par IP est suffisant.

SOCKS5 avec TLS / SOCKS5 tunnelisé via TLS

SOCKS5 encapsulé dans TLS, utilisé dans les services de type VPN axés sur la confidentialité pour chiffrer le canal de contrôle SOCKS5 lui-même. Moins courant dans les services proxy commerciaux car le SOCKS5 résidentiel est déjà utilisé via TLS de bout en bout pour les cibles HTTPS.

Cas d'utilisation courants

Web scraping dans les clients qui préfèrent SOCKS à HTTP CONNECT
Protocoles non-HTTP (FTP, SMTP, IRC, IMAP)
Clients BitTorrent et P2P
Clients de jeux et de voix (où la prise en charge UDP est importante)
Navigateurs sans interface graphique et outils d'automatisation compatibles SOCKS5
Routage au niveau réseau lorsque le client ne parle pas HTTP
FAQ

Foire aux questions

Questions fréquentes sur socks5 proxy.

Un proxy HTTP comprend HTTP et opère au niveau de la couche applicative ; un proxy SOCKS5 opère au niveau de la couche transport et transfère du TCP/UDP brut sans analyser la charge utile. Pour le scraping HTTPS, la différence est surtout cosmétique (les deux tunnelisent des octets chiffrés), mais SOCKS5 l'emporte lorsque vous devez proxifier des protocoles non-HTTP.

Légèrement, dans certains cas. SOCKS5 n'a pas la surcharge liée à l'analyse HTTP, ce qui peut économiser une petite quantité de latence sur des charges de travail à volume élevé. En pratique, le goulot d'étranglement est presque toujours la latence réseau plutôt que l'analyse, donc la différence de vitesse est rarement significative.

Oui. Shifter expose des points de terminaison proxy résidentiels et ISP via HTTP/HTTPS et SOCKS5. Vous pouvez choisir le protocole le mieux pris en charge par votre client et vos outils. Les mêmes identifiants d'authentification et le ciblage géographique fonctionnent sur les deux protocoles.

Oui. SOCKS5 prend en charge UDP via la commande UDP ASSOCIATE, mais en pratique de nombreux services proxy commerciaux ne transfèrent que du TCP car la plupart des cas d'usage (web scraping, gestion de comptes, vérification de publicités) sont basés sur HTTPS. La prise en charge UDP est surtout utile pour les jeux, la voix et certains protocoles personnalisés.

Pas intrinsèquement. Les deux protocoles peuvent transporter du trafic chiffré (TLS) de bout en bout, et les deux peuvent utiliser l'authentification. La « sécurité » d'un proxy dépend principalement du fait que vous utilisez HTTPS vers la destination, et non du protocole proxy. SOCKS5 est parfois préféré pour la confidentialité car il n'ajoute ni ne modifie les en-têtes HTTP.

Oui. Playwright, Puppeteer, Selenium et d'autres pilotes de navigateurs sans interface graphique prennent tous en charge les proxies SOCKS5 via les options de lancement. De nombreux ingénieurs en automatisation préfèrent SOCKS5 avec les navigateurs sans interface graphique car il achemine tout le trafic du navigateur (HTTP, HTTPS, WebSockets, polices, etc.) via le proxy de manière uniforme.