Vérifier que votre proxy marche — et pourquoi la moitié des tests mentent

Le test en une commande

curl -x socks5h://IDENTIFIANT:MOTDEPASSE@frproxy.com:15002 https://api64.ipify.org

Sortie attendue : une adresse IP. Si c'est celle de votre proxy et pas la vôtre, tout va bien.

socks5h, pas socks5. Le h demande à curl de faire résoudre le nom de domaine par le proxy. Sans lui, votre machine résout en local et votre fournisseur d'accès voit ce que vous consultez. Voir HTTP ou SOCKS5.

Pour un port HTTP :

curl -x http://IDENTIFIANT:MOTDEPASSE@frproxy.com:15001 https://api64.ipify.org

⚠️ Le piège qui fait conclure à tort

api.ipify.org ne répond qu'en IPv4.

Si votre proxy sort en IPv6 — ce qui est le cas de nos offres dual-stack, et le cas normal chez plusieurs opérateurs mobiles français — le test échoue alors que le proxy fonctionne parfaitement. Le service ne sait simplement pas répondre.

Nous avons perdu une campagne de mesure entière sur ce détail : un proxy déclaré « en panne » servait du trafic sans une seule erreur.

Utilisez api64.ipify.org (IPv4 et IPv6), ou croisez avec un test qui ne dépend pas d'un service tiers :

# 301 = le TCP passe jusqu'à Cloudflare. Aucun DNS, aucune API tierce en jeu.
curl -x socks5h://ID:MDP@frproxy.com:15002 -o /dev/null -w '%{http_code}\n' -k https://1.1.1.1

Ce qu'il faut vérifier, dans l'ordre

#	Question	Comment
1	Le proxy répond-il ?	La commande `curl` ci-dessus
2	L'IP est-elle française ?	https://ipinfo.io/json à travers le proxy — champ `country`
3	Est-elle vue comme mobile ?	Le champ `org` doit nommer un opérateur (Orange, SFR, Free, Bouygues)
4	Le DNS fuit-il ?	https://dnsleaktest.com depuis le navigateur configuré
5	WebRTC fuit-il ?	https://browserleaks.com/webrtc — voir l'article dédié

Les points 4 et 5 sont ceux qu'on oublie, et ce sont les deux qui trahissent réellement.

Depuis le panel

Mes proxies affiche pour chaque ligne l'IP publique vue par le moteur — donc la vérité côté serveur, sans dépendre de ce que votre machine croit. Si le panel affiche une IP et que votre test en affiche une autre, c'est votre configuration locale qui est en cause, pas le proxy.

Trois règles de méthode

Validez l'outil avant de qualifier la panne. Un test négatif ne devient une conclusion qu'une fois l'outil qualifié. Lancez d'abord la commande sans proxy : si elle échoue déjà, le problème n'est pas le proxy.
Un échantillon ne fait pas une règle. Un débit mesuré une fois ne dit rien de la variance : le même téléphone a donné 152 puis 75 Mbit/s à dix minutes d'écart.
Distinguez mesuré, corrélé et supposé. « Le proxy est lent » et « la page met du temps à s'afficher » ne sont pas la même affirmation.

Voir aussi : Les erreurs fréquentes · Changer d'IP