Les proxies gratuits échouent plus souvent qu'ils ne fonctionnent. Une liste publique passe en revue des dizaines de milliers de candidats et votre travail consiste à trouver le petit sous-ensemble qui est actuellement en vie, suffisamment rapide et non malveillant. Cinq tests, chacun peu coûteux, exécutés dans l'ordre.
Test 1 : Accessibilité TCP
curl --connect-timeout 5 --proxy http://1.2.3.4:8080 \
-s -o /dev/null -w "%{http_code}\n" \
https://api.ipify.orgUn code de sortie non nul ou une réponse vide signifie que le proxy est mort. Environ 60 à 80 % de toute liste gratuite échouera à ce test à un moment donné. Ignorez immédiatement et ne réessayez pas.
Test 2 : Vérification de l'IP de sortie
Le même appel renvoie l'IP publique depuis laquelle la requête est sortie. Si elle est égale à 1.2.3.4 — l'adresse du proxy — le proxy transmet correctement le trafic. Si elle est égale à votre IP locale, le proxy est cassé ou transparent : il a accepté la connexion mais n'a pas réellement relayé via lui-même. Considérez cela comme un échec même si TCP a réussi.
Test 3 : Transparence des en-têtes
curl --proxy http://1.2.3.4:8080 https://httpbin.org/headersLa réponse renvoie les en-têtes que la destination a reçus. Recherchez X-Forwarded-For, Via ou Forwarded avec votre vraie IP. Si vous les trouvez, le proxy est en mode transparent ou anonyme plutôt qu'élite. Pour HTTPS via CONNECT, cela n'a pas d'importance — la destination ne voit que la poignée de main TLS, pas les en-têtes applicatifs — mais pour HTTP en clair, cela détermine si le proxy est adapté à l'usage prévu.
Test 4 : Latence sous charge
La mesure ponctuelle est bruyante. Exécutez dix requêtes en série via le proxy et prenez la médiane. Tout ce qui dépasse deux secondes est inutilisable pour un travail interactif. En dessous de 500 millisecondes, c'est comparable à l'absence de proxy. Entre ces valeurs, le proxy convient au scraping par lots mais pas à la navigation.
Test 5 : Intégrité de l'empreinte TLS
Connectez-vous via le proxy à un point de terminaison TLS connu et vérifiez que la chaîne de certificats correspond à celle que vous obtenez sans le proxy. Une différence signifie que le proxy intercepte TLS — il agit en homme du milieu et votre trafic « chiffré » n'est en réalité pas chiffré à partir du proxy. Cela est rare sur les proxies SOCKS correctement configurés (ils ne peuvent pas voir TLS) mais apparaît sur les proxies HTTPS d'entreprise mal configurés et sur certains nœuds publics malveillants. openssl s_client -proxy 1.2.3.4:8080 -connect example.com:443 affiche la chaîne.
Un flux de travail pratique
Récupérez la liste, filtrez par pays et protocole, répartissez les cinq tests sur un pool parallèle d'environ 50 workers, et conservez les survivants. Sur 100 candidats bruts, une exécution typique donne 5 à 15 entrées utilisables. Le taux de dégradation est d'environ 30 à 60 minutes pour HTTP et HTTPS, un peu plus long pour SOCKS — planifiez un rafraîchissement à cette cadence et alimentez votre scraper ou configuration de navigateur avec l'ensemble survivant. Mettez en cache les résultats des tests pour la durée d'un lot et retestez au lot suivant.