Changer de langue
Français English Русский Deutsch Español Italiano Українська Tiếng Việt Türkçe Bahasa Indonesia हिन्दी 日本語 中文
Menu
Tarifs
Proxys
TYPES DE PROXY
PAR EMPLACEMENT77 emplacements
Solutions
Ressources

Proxys SOCKS5

SOCKS5 est un protocole de proxy de niveau transport : il ouvre une connexion pour votre compte et fait circuler des octets, sans lire ni réécrire ce qu'ils contiennent. Chaque proxy ISP statique que nous vendons peut être basculé entre HTTP et SOCKS5 sur la commande que vous détenez déjà.

Changer de protocole n'est pas changer de produit : vous basculez le proxy que vous détenez déjà, depuis le tableau de bord ou l'API, et la commande est mise à jour avec le nouveau port et les identifiants de connexion.

En bref : SOCKS5 est un protocole de proxy, pas un type d’adresse : il relaie une connexion TCP sans lire ni réécrire ce qu’elle contient. Chaque proxy résidentiel statique (ISP) que vend ProxyJam fonctionne en HTTP, qui transporte HTTPS, ou en SOCKS5, et vous passez de l’un à l’autre sur la commande que vous détenez déjà ; après la bascule, connectez-vous avec le port et les identifiants qu’affiche la commande.

SOCKS5 transporte tout ce pour quoi votre client peut ouvrir une connexion TCP, y compris un trafic qu’un proxy HTTP ne peut pas transmettre, et il fait passer les octets sans y toucher. Cela en fait le choix naturel pour un client de base de données, une session SSH ou tout outil qui ne parle pas HTTP. Ce qu’il ne fait pas, c’est changer ce qu’est l’adresse. Le protocole de proxy se parle entre votre client et le proxy ; le site à l’autre bout voit une connexion venant de l’adresse du proxy, plus les en-têtes qu’un proxy HTTP a choisi d’ajouter. La question qui mérite d’être posée n’est donc pas de savoir quel protocole acheter. C’est de savoir à quel réseau appartient l’adresse, et là, la réponse est un fournisseur d’accès nommé, 19 aux États-Unis.

Ce que disent les spécifications

La version 5 de SOCKS a été publiée en 1996 sous le nom de RFC 1928, un protocole de traversée de pare-feu qui étendait la version 4 de SOCKS avec UDP, un cadre pour les méthodes d’authentification, et des destinations sous forme de noms de domaine ou d’adresses IPv6. Un client propose les méthodes d’authentification qu’il prend en charge et le serveur en choisit une ; le client demande ensuite une connexion sortante (CONNECT), un port en écoute (BIND) ou un relais UDP (UDP ASSOCIATE). La connexion par identifiant et mot de passe fait l’objet de sa propre courte spécification, le RFC 1929, qui envoie le mot de passe en clair : gardez donc chiffré le trafic à l’intérieur du tunnel quand cela compte.

C’est l’option du nom de domaine que les schémas socks5 et socks5h activent ou non. Le manuel de curl décrit --socks5 comme l’utilisation du proxy « but resolve the hostname locally » (mais en résolvant le nom d’hôte localement), et --socks5-hostname comme la variante qui laisse « the proxy resolve the hostname » (le proxy résoudre le nom d’hôte). Dans une URL de proxy, socks5:// donne le premier comportement et socks5h:// le second, comme l’expose le tableau d’Everything curl. Un proxy HTTP qui transporte du HTTPS reçoit normalement le nom à la place : une requête CONNECT nomme l’hôte et le port de destination, et le proxy ouvre le tunnel vers eux (RFC 9110, section 9.3.6). Le relais UDP fait partie de la spécification SOCKS5, mais les implémentations divergent sur ce point ; la FAQ ci-dessous dit ce que cela signifie sur nos proxys.

Utiliser SOCKS5 via SSH

Si vous avez déjà un accès SSH à un serveur, vous avez un proxy SOCKS5 sans en acheter un. ssh -N -D 1080 user@server met en place ce que le manuel ssh d’OpenBSD appelle une redirection de port locale « dynamic » (dynamique) au niveau applicatif : ssh écoute sur le port 1080 de votre machine et « will act as a SOCKS server » (agira comme un serveur SOCKS), en transportant chaque connexion sur le canal SSH chiffré et en l’ouvrant depuis la machine distante. -N la limite à la redirection, sans shell distant. Pointez un client vers socks5h://127.0.0.1:1080 et son trafic sort depuis le serveur.

La différence avec un proxy SOCKS5 acheté tient à l’endroit où la connexion ressort. À travers un tunnel SSH, le site à l’autre bout voit l’adresse du serveur SSH et le réseau auquel ce serveur appartient, généralement celui d’un hébergeur pour un serveur loué. SSH chiffre le tronçon entre vous et le serveur ; du serveur jusqu’au site, le trafic est ce qu’il était déjà. Un proxy ProxyJam basculé en SOCKS5 sort depuis une adresse sur le réseau d’un fournisseur d’accès nommé, choisie par pays et par opérateur au paiement, et vous vous y connectez directement avec le port et les identifiants de la commande, sans SSH entre les deux et sans serveur à vous à faire tourner.

Les deux répondent donc à des questions différentes. Un tunnel SSH fait sortir le trafic d’une machine que vous contrôlez déjà. Un proxy SOCKS5 sur une adresse ISP sert au travail où l’adresse de sortie elle-même compte, c’est-à-dire le réseau qu’affiche une recherche sur cette adresse.

Ce qui se passe entre votre client et le nôtre

Trois échanges courts, dont aucun n'exige que le proxy comprenne votre trafic.

Étape 01

Votre client salue le proxy et s’accorde avec lui sur l’authentification. Il propose les méthodes qu’il prend en charge ; le proxy nomme celle qu’il veut. Sur nos adresses, c’est un identifiant et un mot de passe, ou rien du tout si vous avez plutôt placé votre propre IP sur liste blanche.

Étape 02

Votre client demande une destination. Un hôte et un port, envoyés soit sous forme d’adresse, soit sous forme de nom. L’envoi du nom est le cas intéressant : c’est le proxy qui le résout, donc la requête DNS part du réseau du proxy et non du vôtre.

Étape 03

Ensuite, le proxy se contente de faire circuler des octets. Il n’analyse pas la charge utile, n’ajoute pas d’en-têtes et ne sait pas s’il transporte une page web, une session de base de données ou un transfert de courrier. Cette indifférence est toute la raison de préférer SOCKS5 à un proxy HTTP.

Commencer

SOCKS5 ou proxy HTTP : ce que chacun transporte, et ce que le proxy peut voir

Un proxy ProxyJam fonctionne en HTTP, qui transporte HTTPS via CONNECT, ou en SOCKS5, basculé sur la commande. Le choix dépend de ce que votre client doit envoyer.
Proxy HTTPHTTPS via CONNECTSOCKS5
Ce qu'il peut transporterUniquement des requêtes HTTPUn tunnel TCP vers l'hôte et le port indiquésN'importe quel flux TCP
Le proxy lit-il la charge utileOui, il analyse la requêteNon, une fois le tunnel ouvertNon, à aucun moment
Peut-il modifier vos en-têtesOui, il les transmet et peut ajouter les siens, comme ViaNon, une fois le tunnel ouvertNon, il n'a aucune notion d'en-tête
Où le nom d'hôte est résoluAu proxyAu proxy, car CONNECT nomme l'hôteÀ votre choix, à l'une ou l'autre extrémité
Prise en charge habituelle par les clientsUniverselle dans l'outillage HTTPUniverselle dans l'outillage HTTPCourante dans les outils en ligne de commande ; certaines bibliothèques demandent un paquet supplémentaire
Le plus adapté àLes requêtes web simplesLa navigation et le scraping HTTPS ordinairesLes protocoles non web et le trafic mixte

Pour décider vers quel protocole pointer un client

Les développeurs

Vers quel protocole pointer un client, et quel schéma, socks5 ou socks5h, y définir une fois le proxy basculé.

Les opérateurs

Vers quel protocole pointer un client, et comment basculer le proxy que vous détenez déjà depuis le tableau de bord ou l'API.

Passer un proxy ProxyJam en SOCKS5

  1. Basculez le proxy lui-même

    Depuis le tableau de bord ou par un appel API sur la commande ; modifier seulement le client ne suffit pas. Le proxy peut être brièvement indisponible pendant la bascule.

  2. Copiez le port, l'identifiant et le mot de passe qu'affiche la commande après la bascule

    Ne réutilisez pas les valeurs avec lesquelles vous vous connectiez en HTTP.

  3. Définissez le schéma dans votre client

    socks5h://USERNAME:PASSWORD@HOST:PORT pour que le proxy résolve les noms d’hôte, ou socks5:// pour les résoudre de votre côté.

  4. Testez depuis un terminal avant de toucher au code

    curl -x socks5h://USERNAME:PASSWORD@HOST:PORT https://example.com/.

  5. Installez l'extra SOCKS en Python

    En Python, requests a besoin de son extra SOCKS, pip install requests[socks], avant qu’une URL de proxy socks5h:// fonctionne.

Ce que SOCKS5 vous apporte sur nos adresses

Protocole
SOCKS5 ou HTTP (qui transporte HTTPS), basculé sur la commande
Authentification
Identifiant et mot de passe, ou liste blanche d'IP
Adresse vue par la cible
Une adresse ISP statique sur le réseau d'un opérateur nommé
Choix de l'opérateur
19 opérateurs nommés aux États-Unis ; une liste plus courte ailleurs
Couverture
77 pays au catalogue, chacun avec l'opérateur nommé
Rotation
Aucune : l'adresse ne change pas pendant la période
Sessions simultanées
100 par proxy, 10 au-delà de 50 Go par mois
Décompte du trafic
Par IP et par période ; le transfert n'est mesuré sur aucun protocole
import requests

# HOST, PORT, USERNAME, PASSWORD come with your order (dashboard or API)
proxy = "http://USERNAME:PASSWORD@HOST:PORT"

proxies = {
    "http": proxy,
    "https": proxy,
}

response = requests.get(
    "https://example.com/",
    proxies=proxies,
)

print(response.status_code)
# HOST, PORT, USERNAME, PASSWORD come with your order (dashboard or API)
curl -x http://USERNAME:PASSWORD@HOST:PORT \
     https://example.com/
import axios from "axios";
import { HttpsProxyAgent } from "https-proxy-agent";

// HOST, PORT, USERNAME, PASSWORD come with your order (dashboard or API)
const proxy = "http://USERNAME:PASSWORD@HOST:PORT";
const agent = new HttpsProxyAgent(proxy);

const response = await axios.get(
  "https://example.com/",
  {
    httpAgent: agent,
    httpsAgent: agent,
  },
);

console.log(response.status);
package main

import (
    "fmt"
    "net/http"
    "net/url"
)

func main() {
    // HOST, PORT, USERNAME, PASSWORD come with your order (dashboard or API)
    proxy, _ := url.Parse(
        "http://USERNAME:PASSWORD@HOST:PORT")

    client := &http.Client{Transport: &http.Transport{
        Proxy: http.ProxyURL(proxy),
    }}

    res, _ := client.Get("https://example.com/")
    fmt.Println(res.Status)
}

Connectez-vous d'abord, puis changez de schéma

Les exemples ci-dessous se connectent en HTTP, le protocole sur lequel démarre une commande. Pour utiliser SOCKS5, basculez d'abord le proxy lui-même, depuis le tableau de bord ou par un appel API ; la commande affiche alors le port et les identifiants à utiliser désormais. Dans le client, changez le schéma en socks5, ou en socks5h si vous voulez que le proxy résolve le nom d'hôte, avec ce port et ces identifiants. Python a besoin pour cela de requests[socks], et Node.js d'un agent SOCKS à la place de l'agent HTTPS.

Documentation complète de configuration

Questions sur SOCKS5

Les réponses ci-dessous énoncent les conditions auxquelles nous vendons, et chacune de celles qui le font renvoie au document qui nous y engage.

Qu'est-ce qu'un proxy SOCKS5 ?

SOCKS5 est un protocole de proxy défini dans le RFC 1928, qui fonctionne au niveau de la couche transport. Votre client demande au proxy d'ouvrir une connexion vers un hôte et un port, le proxy l'ouvre, et à partir de là il transmet des octets dans les deux sens sans les interpréter. Comme il n'analyse jamais ce qu'il transporte, il ne se limite pas au trafic web : tout ce qui passe par TCP peut le traverser.

En quoi diffère-t-il d'un proxy HTTP ?

Un proxy HTTP comprend HTTP. Il lit la ligne de requête et les en-têtes, et il est libre de les ajouter, de les supprimer ou de les réécrire, ce qui explique que certains proxys s'annoncent discrètement dans un en-tête que vous n'avez pas défini. SOCKS5 n'a aucune notion d'en-tête : il voit une destination et un flux d'octets. Si votre trafic n'est pas du HTTP, ou si vous préférez que rien au milieu ne puisse le modifier, SOCKS5 est celui qu'il faut choisir.

SOCKS5 chiffre-t-il mon trafic ?

Non, et un proxy HTTP non plus. SOCKS5 vous authentifie auprès du proxy, puis transmet des octets. La spécification permet à une méthode d'authentification d'ajouter sa propre protection, mais l'authentification par identifiant et mot de passe (RFC 1929) envoie le mot de passe en clair et ne protège rien ensuite. Si le trafic transporté est du HTTPS ou du SSH, il est déjà chiffré de bout en bout, et le proxy ne peut pas le lire. Si le trafic transporté est en clair, il reste en clair : ne traitez donc pas SOCKS5 comme une couche de chiffrement.

Que fait socks5h que socks5 ne fait pas ?

Il déplace la résolution DNS. Avec socks5, votre client résout le nom d'hôte localement et demande au proxy de se connecter à l'adresse obtenue. Avec socks5h, votre client envoie le nom et c'est le proxy qui le résout. Cela compte de deux façons : votre propre résolveur ne voit jamais quels hôtes vous visitez, et vous obtenez la réponse qu'obtient le réseau du proxy, qui, pour un nom d'hôte variant selon la géographie, n'est souvent pas celle que vous obtiendriez chez vous.

Prend-il en charge UDP ?

UDP ASSOCIATE figure dans le RFC 1928 ; qu'un client ou un serveur donné l'implémente varie, alors vérifiez les deux extrémités plutôt que de le supposer. Nous n'avons pas publié de prise en charge d'UDP pour nos proxys : prévoyez donc TCP, et interrogez le support avant de construire quoi que ce soit qui dépende d'UDP.

Me faut-il un autre proxy pour utiliser SOCKS5 ?

Non. Vous basculez le proxy que vous détenez déjà entre HTTP, qui transporte aussi HTTPS, et SOCKS5, depuis le tableau de bord ou par un appel à l'API sur la même commande. Ce n'est pas qu'un réglage du client : la bascule se fait sur le proxy, la commande est mise à jour avec le nouveau protocole, le nouveau port et les nouveaux identifiants, et le proxy peut être brièvement indisponible pendant l'opération. Le proxy reste le vôtre pendant toute la période payée, il est remplacé gratuitement s'il cesse de répondre ou s'il est bloqué sur une cible que vous avez indiquée, jusqu'à 20 % de la commande par mois civil, et la première commande bénéficie d'un remboursement sous 24 heures couvrant jusqu'à 10 IP, que les tests n'annulent pas. Conditions d'utilisation

HTTP ou SOCKS5 ?

Restez en HTTP quand vous n’envoyez que du trafic web et que vos outils parlent déjà aux proxys HTTP. Passez à SOCKS5 quand un client doit transporter autre chose que du HTTP, ou quand vous voulez que les noms d’hôte soient résolus au proxy sans que rien au milieu ne puisse modifier vos en-têtes. Dans les deux cas, c’est le même produit, commandé sur proxys ISP et décrit aussi comme proxys résidentiels statiques, sans commande séparée et sans frais de bascule. Les questions de configuration trouvent leur réponse dans la FAQ. Les nombres d’opérateurs et de pays de cette page sont lus dans l’instantané du catalogue à partir duquel le site est construit, comme le décrit notre politique éditoriale.

Sources

  • RFC 1928, SOCKS Protocol Version 5 : la spécification de 1996, avec la négociation de l’authentification, les commandes CONNECT, BIND et UDP ASSOCIATE, et des destinations sous forme de noms de domaine ou d’adresses IPv6
  • RFC 1929, Username/Password Authentication for SOCKS V5 : la méthode de connexion, qui envoie le mot de passe en clair
  • RFC 9110, HTTP Semantics : section 9.3.6, une requête CONNECT nomme l’hôte et le port de destination, et le proxy ouvre le tunnel vers eux
  • curl man page : --socks5 résout le nom d’hôte localement, --socks5-hostname laisse le proxy le résoudre
  • Everything curl, SOCKS proxy : socks5:// et socks5h:// dans une URL de proxy, et quelle extrémité résout le nom d’hôte
  • OpenBSD manual, ssh(1) : -D met en place une redirection de port dynamique locale, ssh jouant le rôle de serveur SOCKS4 et SOCKS5, et -N redirige des ports sans exécuter de commande distante