Les développeurs
Vers quel protocole pointer un client, et quel schéma, socks5 ou socks5h, y définir une fois le proxy basculé.
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.
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.
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.
Trois échanges courts, dont aucun n'exige que le proxy comprenne votre trafic.
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.
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.
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.
| Proxy HTTP | HTTPS via CONNECT | SOCKS5 | |
|---|---|---|---|
| Ce qu'il peut transporter | Uniquement des requêtes HTTP | Un tunnel TCP vers l'hôte et le port indiqués | N'importe quel flux TCP |
| Le proxy lit-il la charge utile | Oui, il analyse la requête | Non, une fois le tunnel ouvert | Non, à aucun moment |
| Peut-il modifier vos en-têtes | Oui, il les transmet et peut ajouter les siens, comme Via | Non, une fois le tunnel ouvert | Non, il n'a aucune notion d'en-tête |
| Où le nom d'hôte est résolu | Au proxy | Au proxy, car CONNECT nomme l'hôte | À votre choix, à l'une ou l'autre extrémité |
| Prise en charge habituelle par les clients | Universelle dans l'outillage HTTP | Universelle dans l'outillage HTTP | Courante dans les outils en ligne de commande ; certaines bibliothèques demandent un paquet supplémentaire |
| Le plus adapté à | Les requêtes web simples | La navigation et le scraping HTTPS ordinaires | Les protocoles non web et le trafic mixte |
Vers quel protocole pointer un client, et quel schéma, socks5 ou socks5h, y définir une fois le proxy basculé.
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.
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.
Ne réutilisez pas les valeurs avec lesquelles vous vous connectiez en HTTP.
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é.
curl -x socks5h://USERNAME:PASSWORD@HOST:PORT https://example.com/.
En Python, requests a besoin de son extra SOCKS, pip install requests[socks], avant qu’une URL de proxy socks5h:// fonctionne.
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)
}
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.
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.
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.
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.
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.
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.
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.
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
--socks5 résout le nom d’hôte localement, --socks5-hostname laisse le proxy le résoudresocks5:// et socks5h:// dans une URL de proxy, et quelle extrémité résout le nom d’hôte-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