HTTP ou SOCKS5 : quelle IP de proxy choisir ?
Choisissez selon votre application, le trafic pris en charge et le besoin de faire résoudre le DNS par le proxy.
Ouvrez d’abord les paramètres de proxy de votre application. Les protocoles pris en charge déterminent les entrées utilisables ; une étiquette impressionnante ou un numéro de port familier ne peut pas ajouter une fonction au client.
| Votre application ou tâche | Choix et vérifications |
|---|---|
| Elle propose seulement un champ de proxy HTTP | Un point de connexion adapté dans la liste de proxys HTTP. Testez aussi HTTPS CONNECT si vous devez atteindre des destinations HTTPS. |
| Elle prend en charge SOCKS5 et exige des options de connexion ou DNS | Un point SOCKS5 dont les deux extrémités prennent en charge les options requises. |
| Elle exige UDP | Vérifiez UDP côté client et côté proxy ; la seule étiquette SOCKS5 ne suffit pas. |
| Elle exige SOCKS4 | Un point SOCKS4 compatible et le mode client correspondant. |
| Elle ne prend pas en charge les proxys | Une IP tirée d’une liste ne configure pas l’application à elle seule. |
Pour les requêtes web et API, un proxy HTTP suffit souvent. Il relaie HTTP et, si cela est autorisé, transporte HTTPS via CONNECT. Le chargement réussi d’une page HTTP simple ne prouve pas la prise en charge du tunnel : le service peut exiger son authentification ou limiter destinations et ports.
SOCKS fonctionne sous la couche des requêtes HTTP. Une application compatible lui demande d’établir une connexion sans interprétation de requête HTTP, ce qui convient aussi à d’autres trafics pris en charge. SOCKS5 définit des adresses IPv4, IPv6 et par nom de domaine, l’authentification et l’association UDP. Une application ou un point gratuit peut n’en implémenter qu’une partie. La route TCP SOCKS d’un navigateur ne couvre pas automatiquement une autre application ou un service UDP.
Où le nom de destination est-il résolu ?
Dans curl, l’écriture de l’URL SOCKS5 détermine où le DNS de destination est résolu : socks5:// résout les destinations localement ; socks5h:// demande au proxy de les résoudre. Des vues DNS différentes peuvent faire réussir un choix et échouer l’autre. D’autres clients utilisent une case ou une option distincte. Sélectionner SOCKS5 ne prouve pas que toutes les résolutions DNS passent par lui.
SOCKS4 offre moins de possibilités ; SOCKS4a ajoute les noms d’hôte. Si client et service prennent en charge SOCKS5 et que rien n’impose l’ancien protocole, une entrée SOCKS5 adaptée constitue un premier choix raisonnable. Saisir un point SOCKS4 en laissant le client en mode SOCKS5 est une incompatibilité de protocole.
Une fois le protocole adapté, testez la destination réelle et repérez le premier échec. Ni HTTP ni SOCKS5 ne mesure l’anonymat : la confiance envers l’opérateur, TLS à destination et la route réelle de l’application déterminent toujours la protection obtenue.