Comment vérifier qu'un proxy fonctionne (et s'il fuit votre IP)

Un proxy peut répondre et laisser quand même fuir votre IP réelle. Vérifiez la sortie, le DNS, WebRTC, le protocole et les listes noires avant de mettre le point d'accès en production.

Comment vérifier qu'un proxy fonctionne (et s'il fuit votre IP)

Un proxy « qui marche » veut dire deux choses différentes. La passerelle doit accepter votre client et récupérer une page. Le reste de l'appareil doit aussi cesser d'exposer l'IP réelle. Beaucoup de points d'accès passent le premier test et ratent le second.

Faites cette vérification avant de monter un forfait. Refaites-la après une rotation. Les pools changent. Le micrologiciel d'un navigateur mobile change. Un test réussi hier n'est pas un contrat.

01Confirmer d'abord l'IP de sortie#

Faites passer un client simple par le proxy. Utilisez le même protocole et la même authentification qu'en production. Demandez ensuite une page qui renvoie l'IP du client.

Le vérificateur de proxies teste si le point d'accès répond depuis le serveur de Top Proxy et indique le premier protocole qui réussit. Il essaie automatiquement SOCKS5, HTTP, SOCKS4 et HTTPS, dans cet ordre : un résultat positif ne prouve donc pas que tous les protocoles marchent. La vérification ne configure pas votre navigateur et ne teste ni son DNS, ni WebRTC, ni les connexions directes. Si votre fournisseur s'appuie sur une liste d'autorisation d'IP, un échec côté serveur peut vouloir dire que le serveur du vérificateur n'est pas autorisé ; vérifiez le même point d'accès depuis votre client autorisé avant de le déclarer mort.

Ouvrez Mon IP à travers le même proxy. Lisez le pays, l'ASN, et l'étiquette hébergement ou résidentiel si la page en affiche une. Comparez avec ce que vous avez acheté. Un produit « résidentiel US » qui sort sur un ASN cloud est le mauvais produit, pas un problème de réglages.

Répétez la recherche après une rotation. Un pool mélangé peut vous donner un autre pays au prochain identifiant de session. Si vous avez payé des proxies US, le second échantillon doit encore être aux États-Unis.

02Chercher les fuites autour du proxy#

Un proxy ne couvre que le trafic que votre client lui envoie. Tout le reste peut encore utiliser votre vrai réseau.

Le comportement DNS dépend du protocole et du client. Pour curl, socks5:// résout les noms de destination en local, tandis que socks5h:// demande au proxy SOCKS5 de les résoudre. Un résolveur DNS séparé change qui reçoit votre requête ; il ne prouve pas que la requête transite par votre proxy. Vérifiez les réglages proxy et DNS du navigateur, puis lancez un test de fuite DNS dans ce même profil. Comparez le résultat avec le résolveur que vous vouliez utiliser. Voir la documentation proxy de curl pour le comportement selon le schéma.

WebRTC peut emprunter des chemins de connexion en dehors d'un proxy HTTP. Inspectez les adresses candidates dans un test WebRTC, dans le vrai profil du navigateur. Si votre IP publique d'origine apparaît, relisez les réglages de confidentialité WebRTC de ce navigateur et recommencez le test. Les restrictions du navigateur et le masquage d'adresse varient : le résultat du vérificateur de proxies ne suffit pas à établir que WebRTC est couvert. MDN explique les adresses candidates ICE et la confidentialité.

IPv4 et IPv6 demandent des observations séparées. Une connexion IPv4 vers une passerelle HTTP ou SOCKS n'implique pas que la connexion vers la destination soit en IPv4, et le fait qu'un appareil ait de l'IPv6 ne veut pas dire, à lui seul, qu'un site contourne le proxy. Testez des points d'écho IPv4 et IPv6 à travers le client réel, puis inspectez les règles de contournement et les applications qui peuvent se connecter directement. Choisissez un fournisseur qui prend en charge la famille d'adresses dont votre tâche a besoin.

Les applications peuvent contourner les proxies système. Une application native peut ignorer le réglage de l'OS et se connecter directement. Configurez un proxy par la méthode que l'application prend réellement en charge, puis testez cette application. Voir SOCKS5 ou HTTP si le client prend les deux.

03Vérifier la réputation, pas seulement l'accessibilité#

Une IP peut récupérer une page et rester inutile pour votre tâche. Drapeaux d'hébergement, listes noires et abus antérieurs vivent sur l'adresse.

Si la tâche est du courrier, une inscription, ou tout ce que d'autres ont déjà brûlé, passez la sortie dans les listes noires d'IP. Une inscription est un avertissement. Ce n'est pas un jugement moral. Les pools résidentiels partagés ramassent des inscriptions. Les IP datacenter dédiées aussi.

Si la tâche est du scraping, récupérez l'URL cible réelle, pas seulement un service d'écho. Certains hôtes autorisent https://httpbin.org et bloquent quand même votre page catalogue. Enregistrez le code de statut, la longueur du corps, et si un défi est apparu. C'est le seul score qui compte.

Si la tâche est un contrôle de géo, comparez la page que vous vouliez avec celle que vous avez obtenue. Devise, langue et catalogue doivent correspondre au pays acheté. Un ASN correct avec la mauvaise vitrine veut dire que le site s'appuie sur un autre signal.

04Rendre la vérification reproductible#

Écrivez les étapes. Même client, même authentification, même URL d'écho, même URL cible, mêmes pages de fuite. Lancez-les à l'achat. Lancez-les à la rotation. Lancez-les quand une tâche commence à échouer.

Notez l'IP de sortie, l'ASN, le protocole, et si le DNS ou WebRTC a montré votre adresse réelle. Quand un fournisseur remplace un port, vous saurez ce qui a changé.

Ne passez pas à côté des erreurs d'authentification. Identifiant et mot de passe dans le mauvais champ ressemblent à un proxy mort. L'authentification par liste d'autorisation d'IP ressemble à un proxy mort depuis un nouveau réseau de bureau. Corrigez l'authentification avant d'ouvrir un ticket.

Avant de monter un achat, comparez les proxies résidentiels et les proxies datacenter au protocole, au pays et au comportement de session que vous venez de tester. Confirmez ces exigences dans l'offre publiée du fournisseur, puis commencez par un petit forfait.

Une vérification serveur réussie établit l'accessibilité pour ce test. Une configuration qui marche demande aussi que le client réel utilise la sortie attendue et renvoie la page cible visée, avec des contrôles séparés pour les chemins de connexion que vous voulez couvrir. Notez chaque résultat plutôt que de traiter un statut vert comme une garantie complète de confidentialité.