Un proxy qui répond ne suffit pas. Avant de lui confier un robot de collecte, un suivi de positions ou des comptes clients, vous devez savoir quelle IP il présente, depuis quel pays, à quelle vitesse, et s'il laisse fuiter votre véritable adresse par un autre chemin. Ces contrôles prennent quelques minutes et évitent des jours de résultats faussés.

Voici la méthode, étape par étape, avec les deux outils gratuits d'Airproxy (sans compte) et quelques commandes simples.

Vérifier l'IP de sortie et le pays

Premier contrôle : l'adresse que les sites voient réellement. Configurez le proxy dans votre navigateur ou dans le profil concerné, puis ouvrez Quelle est mon IP. L'outil affiche l'IP publique, le pays, la ville, l'opérateur, l'ASN et le fuseau horaire. Vérifiez trois points :

  • L'IP affichée n'est pas la vôtre. Si vous voyez l'adresse de votre box ou de votre serveur, le trafic ne passe pas par le proxy : reprenez la configuration avec notre guide pour configurer un proxy.
  • Le pays est le bon. Il doit correspondre à la localisation achetée et à votre cible.
  • L'opérateur est cohérent. Pour un proxy ISP, on attend un fournisseur d'accès grand public plutôt qu'un hébergeur.

Les bases de géolocalisation diffèrent d'un service à l'autre, surtout pour la ville : voir notre guide pour choisir le pays de son proxy.

Tester la disponibilité, la latence et le débit

Le testeur de proxy vérifie un proxy HTTP, HTTPS ou SOCKS5 sans toucher à votre configuration. Collez l'accès au format ip:port:identifiant:motdepasse, choisissez le protocole et lancez le test. Vous obtenez :

  • la disponibilité : le proxy répond-il et accepte-t-il vos identifiants ?
  • le ping : le temps d'établissement de la connexion jusqu'au proxy ;
  • la latence : la durée d'une vraie requête HTTPS qui traverse le proxy ;
  • l'IP de sortie, la localisation, l'opérateur et le niveau d'anonymat.

Ces mesures partent du serveur de l'outil. Elles disent si le proxy est en bonne santé, mais la latence que vous constaterez dépend aussi de la distance entre votre machine et le proxy, puis entre le proxy et votre cible. Refaites donc un test depuis votre propre infrastructure, à plusieurs moments de la journée : une latence régulière compte plus qu'une bonne mesure isolée.

Mesurer le débit

Téléchargez un fichier de taille connue à travers le proxy et laissez curl faire le calcul :

curl -x "http://IDENTIFIANT:MOTDEPASSE@HOTE:PORT" -s -o /dev/null \
  -w "connect: %{time_connect}s\nttfb: %{time_starttransfer}s\nspeed: %{speed_download} B/s\n" \
  https://example.com/fichier-test.bin

Ici, connect mesure la connexion au proxy, ttfb l'arrivée du premier octet envoyé par le site, et speed le débit moyen en octets par seconde. Choisissez un fichier hébergé près de votre cible réelle et répétez la mesure : le débit varie avec la charge du réseau. Pour intégrer ces contrôles à vos scripts, consultez notre guide pour utiliser un proxy en Python, Node.js et curl.

Comprendre les niveaux d'anonymat

Un proxy HTTP peut ajouter des en-têtes à vos requêtes. Deux d'entre eux trahissent sa présence : Via, qui signale qu'un intermédiaire a relayé la requête, et X-Forwarded-For, qui peut transmettre l'adresse d'origine du client. Selon ce que le proxy ajoute, on distingue trois niveaux.

NiveauCe que voit le sitePour un usage pro
TransparentVotre IP réelle, transmise dans X-Forwarded-ForÀ proscrire
AnonymeL'IP du proxy, mais un en-tête comme Via signale un intermédiaireAcceptable pour des tâches simples
ÉliteL'IP du proxy, sans en-tête révélateurRecommandé

Le testeur de proxy déduit ce niveau automatiquement : il appelle une page qui renvoie les en-têtes reçus et regarde ce que le proxy a ajouté. En SOCKS5, le proxy relaie la connexion sans réécrire vos en-têtes HTTP : ce que reçoit le site dépend alors de votre logiciel. Un proxy élite ne masque pas pour autant le reste de votre empreinte : cookies, langue, fuseau horaire et WebRTC restent à contrôler.

Détecter les fuites DNS et WebRTC

Une fuite, c'est une information qui sort par un autre chemin que le proxy. Les deux plus courantes concernent le DNS et WebRTC.

Les fuites DNS

Avant de joindre un site, votre logiciel doit traduire son nom en adresse IP. Si cette résolution se fait sur votre machine, votre résolveur habituel, souvent celui de votre fournisseur d'accès ou de votre hébergeur, voit passer la liste des domaines visités. Le site ne voit pas votre IP, mais cette information sort sans passer par le proxy, et la position du résolveur peut contredire celle de l'IP.

Avec un proxy HTTP(S), le nom du site est en général transmis au proxy, qui le résout lui-même. En SOCKS5, tout dépend du client : il faut demander la résolution distante. Avec curl et de nombreuses bibliothèques, c'est le rôle du schéma socks5h:// (le « h » signifie hostname) ; avec socks5://, le nom est résolu localement.

curl -x "socks5h://IDENTIFIANT:MOTDEPASSE@HOTE:PORT" https://example.com

Dans Firefox, l'option qui confie le DNS au proxy SOCKS v5 se trouve dans les paramètres de connexion (préférence network.proxy.socks_remote_dns). Pour vérifier, ouvrez une page de test de fuite DNS à travers le proxy : elle liste les résolveurs qui l'ont interrogée. Si celui de votre fournisseur d'accès apparaît, la résolution se fait encore en local. Notre guide proxy HTTP ou SOCKS5 détaille les différences entre les deux protocoles.

Les fuites WebRTC

WebRTC permet aux navigateurs d'établir des appels audio et vidéo directs. Pour trouver le meilleur chemin, il interroge des serveurs extérieurs en UDP, un trafic que la plupart des proxies ne relaient pas. Une page peut ainsi découvrir votre IP publique réelle alors que toute la navigation passe par le proxy. Les navigateurs récents masquent les adresses du réseau local, pas forcément l'IP publique.

Ouvrez une page de test WebRTC à travers le proxy : si votre vraie IP apparaît, il y a fuite. Pour la limiter :

  • dans Firefox, désactivez WebRTC avec la préférence media.peerconnection.enabled de about:config ;
  • dans les navigateurs basés sur Chromium, la règle d'administration WebRtcIPHandling réglée sur disable_non_proxied_udp interdit à WebRTC l'UDP hors proxy ;
  • dans un navigateur à profils multiples, vérifiez le réglage WebRTC de chaque profil et refaites le test après chaque mise à jour.

Vérifier la réputation de l'IP

Une IP peut fonctionner parfaitement et être mal vue. Si une adresse a servi à du spam ou à des abus, elle peut figurer sur des listes de blocage, et certains sites lui imposent des CAPTCHA ou la refusent.

  • Consultez les listes de blocage publiques. Des services de consultation gratuits indiquent si une adresse figure sur les listes DNSBL. Ces listes visent surtout l'e-mail : une IP listée n'est pas forcément bloquée par votre cible, et une IP absente n'est pas forcément bien accueillie.
  • Contrôlez l'ASN. L'outil Quelle est mon IP affiche l'opérateur et l'ASN : une plage d'hébergeur est plus souvent filtrée qu'une plage d'opérateur grand public.
  • Faites un essai réel. Quelques requêtes manuelles sur votre cible en disent plus que n'importe quelle liste : page normale, CAPTCHA systématique, erreur 403 ou 429 ?

Avec une IP dédiée, la réputation ne dépend que de votre usage : vous n'héritez pas du comportement d'autres utilisateurs. C'est l'un des arguments de notre comparatif proxy dédié ou partagé.

Checklist avant la mise en production

  1. L'IP de sortie n'est pas la vôtre et se situe dans le pays attendu.
  2. L'opérateur affiché correspond au type de proxy acheté.
  3. Le proxy répond dans le protocole que vous utiliserez (HTTP, HTTPS ou SOCKS5), avec vos identifiants.
  4. Le niveau d'anonymat est « élite ».
  5. La latence reste régulière sur plusieurs mesures prises depuis votre infrastructure, et le débit suffit pour le volume prévu.
  6. Aucune fuite DNS (résolution distante en SOCKS5 avec socks5h://) ni WebRTC dans les profils de navigateur.
  7. Le fuseau horaire et la langue des profils correspondent au pays de l'IP.
  8. L'IP ne déclenche pas de blocage systématique sur votre cible.
  9. Votre usage respecte les conditions des sites visés, leur robots.txt et le RGPD.
En résumé : vérifiez l'IP et le pays, mesurez latence et débit depuis votre infrastructure, exigez un niveau élite, fermez les fuites DNS et WebRTC, puis contrôlez la réputation sur votre cible réelle. Un proxy qui passe ces étapes est prêt pour la production.

Les proxies ISP dédiés d'Airproxy sont livrés au format hôte:port:identifiant:mot de passe, avec le même accès en HTTP(S) et en SOCKS5 : vous pouvez dérouler cette checklist dès la livraison. Les localisations disponibles sont sur la page des offres.

Questions fréquentes

Quelle différence entre le ping et la latence du testeur ?

Le ping mesure seulement l'établissement de la connexion jusqu'au proxy. La latence mesure une requête complète qui traverse le proxy jusqu'à un site : elle est plus élevée, et plus proche de ce que vivront vos outils.

Un proxy SOCKS5 est-il plus anonyme qu'un proxy HTTP ?

Pas en soi. SOCKS5 relaie la connexion sans modifier vos en-têtes, mais il faut activer la résolution DNS distante, et aucun des deux ne protège contre WebRTC ou les cookies.

Mon IP réelle apparaît malgré le proxy : pourquoi ?

Les causes les plus fréquentes sont un logiciel qui ne passe pas par le proxy, une fuite WebRTC ou une extension qui contourne vos réglages. Vérifiez l'IP depuis le logiciel concerné, puis faites le test WebRTC.

À quelle fréquence faut-il tester ses proxies ?

À la livraison, avant chaque mise en production, puis régulièrement. Le plus simple est d'automatiser dans vos scripts un contrôle de l'IP de sortie et de la latence.