Comment mesurer soi-même la vitesse et la disponibilité d'un proxy : une méthode reproductible

La vitesse d'un proxy n'est pas un nombre unique : c'est la latence (le temps jusqu'au premier octet), le débit (la vitesse à laquelle les octets arrivent) et le taux de succès (la fréquence à laquelle vous obtenez une réponse utilisable) — chacun variant selon l'heure, la cible et l'IP de sortie. Un seul test à un moment donné ne vous apprend presque rien, c'est pourquoi les chiffres marketing des fournisseurs et les avis ponctuels sont si faciles à produire et si difficiles à exploiter. Voici la méthode que nous utilisons pour nos propres classements : quoi mesurer, comment, à quelle fréquence, et comment résumer les résultats pour qu'ils aient du sens.

Les quatre chiffres

Métrique	Ce qu'elle répond	Comment l'obtenir	Valeur typique satisfaisante
Latence (TTFB)	Combien de temps chaque requête attend avant que les données commencent à arriver	`curl -w %{time_starttransfer}` sur une petite ressource	Datacenter : +10–50 ms par rapport au direct ; résidentiel/mobile : +80–300 ms
Débit	À quelle vitesse les données en masse se déplacent	Chronométrer un téléchargement de taille fixe (1–10 Mo)	Datacenter : proche de la vitesse de la ligne ; résidentiel : 5–50 Mbit/s ; mobile : 5–30 Mbit/s
Taux de succès	À quelle fréquence une requête aboutit avec un vrai 2xx	Compter les résultats sur de nombreuses requêtes	>98% sur des cibles neutres ; plus bas sur des cibles protégées est le fait de la cible
Disponibilité	À quelle fréquence le proxy est joignable tout court	Sonde de connectivité périodique sur plusieurs jours	>99,5% pour datacenter/FAI ; les pools rotatifs masquent les pannes individuelles

Les rapports qui donnent un seul chiffre de « vitesse » rapportent généralement le débit sur un gros téléchargement depuis un proxy datacenter à une heure creuse — la combinaison la plus flatteuse possible.

Principes avant les commandes

Mesurez la différence, pas l'absolu. Exécutez toujours la même requête en direct et via le proxy, l'une après l'autre, et rapportez l'écart. La variabilité de votre propre connexion serait sinon mélangée à celle du proxy.
Toujours la même cible. Utilisez un endpoint petit, rapide et stable qui ne limite pas le débit — un fichier statique sur un grand CDN, ou votre propre serveur. Ne faites jamais de benchmark contre le site que vous avez l'intention de scraper ; sa réponse anti-bot est une mesure différente.
De nombreux échantillons, répartis dans le temps. Au moins 20 requêtes par exécution ; des exécutions à plusieurs heures de la journée et sur une semaine. Les proxies sont une infrastructure partagée et la charge suit les heures de bureau dans les régions du fournisseur et des IP de sortie.
Rapportez les percentiles, pas les moyennes. Un seul timeout de 30 secondes détruit une moyenne. La médiane (p50) vous indique l'expérience typique ; le p95 vous indique l'expérience des mauvais jours ; les deux comptent plus que la moyenne.
Échauffez-vous. Écartez la première requête de chaque exécution — la configuration de la session DNS et TLS la rend plus lente que les autres.
Changez une chose à la fois. Comparer le datacenter du fournisseur A au résidentiel du fournisseur B compare des types, pas des fournisseurs.

Latence avec curl

# direct
curl -o /dev/null -s -w "dns %{time_namelookup}  connect %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}\n" \
     https://cdn.example.com/1kb.txt

# via proxy
curl -x http://user:pass@proxy.example.com:8080 -o /dev/null -s \
     -w "connect %{time_connect}  tls %{time_appconnect}  ttfb %{time_starttransfer}  total %{time_total}\n" \
     https://cdn.example.com/1kb.txt

Via un proxy, time_connect est le temps pour atteindre le proxy ; la connexion et le TLS de la destination se produisent à l'intérieur du tunnel et se retrouvent dans time_appconnect/time_starttransfer. Le nombre à comparer est ttfb : la différence entre le proxied et le direct est la latence ajoutée par le proxy. Bouclez-le :

for i in $(seq 1 20); do
  curl -x http://user:pass@proxy.example.com:8080 -o /dev/null -s -w "%{time_starttransfer}\n" https://cdn.example.com/1kb.txt
done | sort -n | awk '{a[NR]=$1} END{print "p50", a[int(NR*0.5)], "p95", a[int(NR*0.95)]}'

Débit

curl -x http://user:pass@proxy.example.com:8080 -o /dev/null -s -w "%{speed_download} bytes/s  %{size_download} bytes  %{time_total}s\n" \
     https://cdn.example.com/5mb.bin

Utilisez un fichier suffisamment grand pour que la configuration de la connexion ne représente qu'une petite fraction (5–10 Mo), mais suffisamment petit pour ne pas épuiser une allocation résidentielle au Go sur de nombreuses exécutions. Sur les pools rotatifs, le débit varie avec la connexion de l'hôte de sortie ; exécutez suffisamment d'échantillons pour voir la distribution, et rappelez-vous que sur les forfaits au Go, le débit détermine aussi la vitesse à laquelle vous dépensez de l'argent.

Taux de succès

Chaque requête se termine par l'un des résultats suivants : un 2xx avec un corps de la taille attendue ; un 4xx/5xx de la cible ; une erreur de proxy (407, connexion refusée, timeout) ; ou une page de défi (CAPTCHA/interstitiel) avec un statut 200 — ce dernier est celui que les compteurs naïfs manquent, donc vérifiez le corps, pas seulement le code. En Python :

import requests, time, statistics as st

PROXY = {"https": "http://user:pass@proxy.example.com:8080"}
URL, N = "https://cdn.example.com/1kb.txt", 50
lat, outcomes = [], {"ok": 0, "http_err": 0, "proxy_err": 0, "timeout": 0, "challenge": 0}

for i in range(N):
    t = time.perf_counter()
    try:
        r = requests.get(URL, proxies=PROXY, timeout=15)
        dt = time.perf_counter() - t
        if r.status_code == 200 and len(r.content) > 500 and b"captcha" not in r.content.lower():
            outcomes["ok"] += 1; lat.append(dt)
        elif r.status_code == 200:
            outcomes["challenge"] += 1
        else:
            outcomes["http_err"] += 1
    except requests.exceptions.ProxyError:
        outcomes["proxy_err"] += 1
    except requests.exceptions.Timeout:
        outcomes["timeout"] += 1
    time.sleep(0.5)

lat.sort()
print(outcomes, "success %.1f%%" % (100 * outcomes["ok"] / N))
if lat: print("p50 %.3fs  p95 %.3fs" % (lat[len(lat)//2], lat[int(len(lat)*0.95)]))

Séparez les échecs de proxy (407, erreurs de connexion, timeouts vers le proxy) des échecs de cible (403, 429, défis). Les premiers sont le problème du fournisseur ; les seconds concernent la réputation de l'IP sur cette cible et appartiennent à un test différent — voir comment les systèmes anti-bot notent les requêtes.

Disponibilité

La disponibilité est le taux de succès sur le temps calendaire. Planifiez une sonde légère — la commande de latence ci-dessus, ou un simple CONNECT — toutes les 5–15 minutes pendant au moins une semaine, journalisez le résultat avec un horodatage, et calculez la fraction des sondes qui ont réussi. Deux subtilités :

Les pools rotatifs masquent les pannes. Si une sortie meurt, vous en obtenez une autre ; c'est la passerelle elle-même qui a une disponibilité. Sondez la passerelle, et séparément, suivez la fréquence à laquelle l'IP assignée change lorsque vous avez demandé une session collante — un changement inattendu est une panne douce.
Les IP statiques (datacenter, FAI) sont celles pour lesquelles on revendique généralement « 99,9% ». 99,9% représente 43 minutes d'indisponibilité par mois ; 99,5% représente 3,6 heures. Les deux sont faciles à distinguer avec une semaine de sondes toutes les 15 minutes.

Planification des exécutions

Un calendrier minimal mais significatif : latence + succès (20–50 requêtes) à 03:00, 09:00, 14:00 et 20:00 dans le fuseau horaire local des IP de sortie, tous les jours pendant sept jours ; débit une fois par exécution ; une sonde de connectivité toutes les 15 minutes tout au long. Cela représente quelques centaines de kilooctets par jour et par proxy pour la latence et quelques dizaines de mégaoctets pour le débit — abordable même sur les forfaits au Go si vous utilisez un petit fichier. Exécutez-le depuis une machine qui reste allumée (un petit VPS est idéal) avec cron, et écrivez une ligne CSV par requête. Nos classements publiés — par exemple le classement de vitesse et le classement de fiabilité — sont construits à partir exactement de ce type de séries sur une semaine, pas d'un seul après-midi.

Interprétation des résultats

Latence p50 proche de la norme du type et p95 dans ~3× p50 : sain. Un p95 plusieurs fois le p50 signifie une congestion intermittente — le fournisseur est sursouscrit aux heures de pointe.
Taux de succès inférieur à ~97% sur une cible neutre avec des erreurs côté proxy : problème d'infrastructure, pas le vôtre.
Beaucoup plus mauvais le jour que la nuit : capacité partagée ; demandez des options dédiées ou acceptez-le dans la planification.
Excellents chiffres en datacenter, médiocres en résidentiel chez le même fournisseur : normal — produits différents ; comparez résidentiel à résidentiel.
Disponibilité inférieure à la revendication : vous avez maintenant un journal à montrer au support, ce qui vaut plus qu'une plainte.

Enfin, gardez le type à l'esprit. Les proxies résidentiels et mobiles sont plus lents par construction — le trafic traverse réellement une ligne domestique ou une antenne de téléphonie mobile — et les acheter pour la vitesse est une erreur de catégorie ; voir la comparaison des types de proxies. Mesurez-les par rapport à leur propre classe et par rapport à ce dont votre tâche a réellement besoin. Notez aussi qu'une connexion proxifiée utilise HTTP/2, pas HTTP/3, donc comparez ce qui est comparable lorsque la ligne de base directe est sur un site compatible QUIC (détails).

Questions fréquemment posées

Comment tester la vitesse d'un proxy ?

Demandez la même petite ressource directement et via le proxy, de nombreuses fois, à plusieurs heures de la journée ; comparez le temps jusqu'au premier octet (latence) et, séparément, chronométrez un téléchargement de taille fixe (débit). Rapportez les médianes et les 95e percentiles, pas les moyennes.

Quelle est une bonne latence de proxy ?

Par rapport à une connexion directe : les proxies datacenter ajoutent des dizaines de millisecondes ; les résidentiels et mobiles ajoutent environ 80–300 ms car le trafic passe par une connexion grand public. Jugez chaque type par rapport à sa propre norme.

Comment vérifier la disponibilité d'un proxy ?

Sondez-le selon un calendrier (toutes les 5–15 minutes) pendant au moins une semaine, journalisez chaque résultat, et calculez la fraction des sondes réussies. Pour les pools rotatifs, sondez la passerelle ; pour les IP statiques, sondez l'IP elle-même.

Pourquoi mes résultats diffèrent-ils des affirmations du fournisseur ?

Les affirmations sont généralement le meilleur cas : produit datacenter, heure creuse, gros téléchargement, échantillon unique. Votre mesure inclut les heures de pointe, les IP de sortie spécifiques que vous recevez, et les percentiles. Le vôtre est le nombre qui prédit votre expérience.

Dois-je faire un benchmark contre le site que je veux scraper ?

Pas pour la vitesse. Sa couche anti-bot ajoutera des défis et des blocages qui mesurent la réputation de l'IP, pas la performance du proxy. Utilisez une ressource statique neutre pour la vitesse et testez la réputation séparément.

De combien d'échantillons ai-je besoin ?

Au moins 20 par exécution pour obtenir une médiane stable, plusieurs exécutions par jour sur une semaine pour voir les effets de l'heure et du jour de la semaine. La disponibilité nécessite la semaine de toute façon.