Performance · 4 min de lecture

Vitesse du proxy : comment nous mesurons la latence et pourquoi le ping ment.

La vitesse du proxy n'est pas un chiffre unique. La latence, le débit et le temps jusqu'au premier octet mesurent des choses différentes, et un ping ICMP brut vous induit en erreur sur tous ces aspects. Voici ce qui compte réellement et comment le mesurer.

La vitesse est trois chiffres différents

La latence, le débit et le TTFB ne sont pas interchangeables.

Lorsque quelqu'un demande "quelle est la vitesse de ce proxy ?", il veut généralement dire une chose mais en a besoin de trois. Les confondre est la raison pour laquelle un proxy qui "répond rapidement" semble toujours lent en utilisation réelle.

  • La latence est le délai aller-retour pour une petite requête — combien de temps avant que quelque chose ne revienne. Elle domine la sensation du travail interactif et de nombreuses petites requêtes, comme les appels API ou la navigation sur les pages.
  • Le débit est la quantité de données par seconde que le proxy peut déplacer une fois un transfert en cours. Il domine les gros téléchargements et le scraping intensif, et un proxy à faible latence peut toujours avoir un faible débit.
  • Le temps jusqu'au premier octet (TTFB) est toute la chaîne : DNS, la poignée de main de connexion, le proxy relayant votre requête, la réflexion de la destination, et l'arrivée du premier octet. C'est le chiffre unique le plus proche de "comment la requête a réellement été ressentie."

Pour la plupart des travaux de proxy, le chiffre qui compte est la latence et le TTFB, car vous faites de nombreuses requêtes, pas un énorme téléchargement. C'est la colonne que nous affichons sur la liste de proxies gratuits, et c'est ce que mesurent les scripts ci-dessous.

Les métriques qui comptent

Et quelle tâche chacun prédit.

Latence (aller-retour)

Le délai avant qu'une réponse ne commence. Meilleur prédicteur pour les appels API, la navigation et de nombreuses petites requêtes. Une faible latence est ce qui rend un proxy réactif plutôt que lent.

Débit (bande passante)

Données transférées par seconde pendant un transfert. Meilleur prédicteur pour les gros téléchargements et le scraping en masse. Un proxy peut avoir une faible latence mais un débit limité, donc mesurez celui dont dépend votre tâche.

Temps jusqu'au premier octet

La chaîne de requête complète incluant la poignée de main et le temps de réflexion du serveur. Le seul chiffre le plus proche de la sensation du monde réel, et ce qu'un rapport de temps curl vous indique.

Cohérence

Un seul échantillon rapide signifie peu. Un proxy qui a une bonne moyenne mais des pics mauvais bloquera vos tâches. Mesurez plusieurs fois et regardez l'écart, pas seulement le meilleur cas.

Pourquoi un ping brut ment

ICMP n'est pas ce que font vos requêtes.

L'instinct est de pinger un proxy et de faire confiance au chiffre en millisecondes. C'est trompeur pour plusieurs raisons concrètes. Un ping utilise ICMP, un protocole différent de ceux que votre trafic réel utilise, TCP et TLS — les réseaux priorisent, dépriorisent ou bloquent complètement l'ICMP, donc le chiffre du ping ne reflète rien de tout cela. Le ping mesure également le saut vers le proxy, pas le chemin complet à travers celui-ci jusqu'à votre véritable destination, ce qui est ce qui vous importe. Et il ignore complètement les coûts qui dominent les requêtes réelles : la poignée de main TCP, la négociation TLS, la résolution DNS et le temps que la destination elle-même met à répondre.

La manière honnête de mesurer un proxy est de mesurer une vraie requête à travers celui-ci, en chronométrant les étapes de connexion et du premier octet comme curl les rapporte. Cela capture la poignée de main, le relais et la destination — tout ce que le ping jette. C'est exactement ainsi que les chiffres de latence de notre liste sont produits, ce qui est le but de publier une méthodologie transparente plutôt qu'un chiffre marketing.

Mesurer la latence réelle du proxy

Enregistrez sous proxy-latency.sh. curl rapporte le temps de connexion et le temps jusqu'au premier octet — ce que ressent réellement une demande — pas un ping ICMP trompeur. Utilisation : bash proxy-latency.sh HOST:PORT

bash
#!/usr/bin/env bash
# proxy-latency.sh — measure REAL latency through a proxy, not ICMP ping.
# curl exposes connect + time-to-first-byte, which is what a request feels.
# Usage: bash proxy-latency.sh HOST:PORT [url] [runs]
PROXY="$1"
URL="${2:-https://api.ipify.org}"
N="${3:-5}"

fmt='connect=%{time_connect}s  ttfb=%{time_starttransfer}s  total=%{time_total}s\n'
echo "measuring $PROXY -> $URL ($N runs)"
for i in $(seq 1 "$N"); do
  curl -s -o /dev/null --max-time 10 \
       --socks5-hostname "$PROXY" \
       -w "$fmt" "$URL"
done

# Compare against no proxy to see the true added cost:
#   for i in $(seq 1 5); do curl -s -o /dev/null -w "$fmt" "$URL"; done

Mesurer les proxies de manière équitable

Une méthodologie courte que vous pouvez réutiliser.

Pour comparer les proxys de manière honnête, maintenez les variables constantes. Testez chaque proxy contre le même cible et depuis le même réseau, exécutez chacun plusieurs fois et rapportez la médiane plutôt que l'échantillon le plus chanceux, et mesurez toujours une ligne de base sans proxy afin de pouvoir attribuer la latence ajoutée au proxy plutôt qu'à votre propre connexion ou à la destination. La distance est une question de physique : un proxy géographiquement éloigné de vous ou de la cible ajoutera toujours une latence qu'aucun tunnel ne peut supprimer, donc prenez en compte la localisation plutôt que de blâmer le proxy.

C'est la même discipline derrière les chiffres de s4m. Les proxys de datacenter authentifiés sont conçus pour des performances constantes et à faible latence, et la colonne de latence de la liste gratuite est générée à partir de vraies requêtes chronométrées, pas d'ICMP. Vous voulez qu'un seul proxy soit vérifié instantanément ? Utilisez le vérificateur de proxy ; vous voulez valider toute une liste y compris la vitesse, voir comment vérifier la validité des proxys.

FAQ

Questions, réponses

Pourquoi le ping de mon proxy est-il bas mais il semble toujours lent ?

Parce que le ping mesure l'ICMP vers le proxy, pas votre vrai trafic à travers lui. Vos requêtes paient pour l'établissement de la connexion TCP, TLS, DNS et le temps de réponse de la destination — aucun de ces éléments n'est capturé par le ping. Un proxy avec un bon ping peut encore avoir un temps avant le premier octet lent ou un faible débit, ce que vous ressentez réellement.

Quelle est la différence entre la latence et le débit pour un proxy ?

La latence est le délai avant qu'une réponse ne commence ; le débit est la quantité de données qui se déplace par seconde une fois qu'il le fait. La latence domine de nombreuses petites requêtes comme les appels API et le scraping page par page ; le débit domine les gros téléchargements. Un proxy peut être fort dans l'un et faible dans l'autre, donc mesurez celui dont votre tâche a besoin.

Comment devrais-je évaluer correctement un proxy ?

Mesurez une vraie requête à travers cela, pas un ping. Chronométrez les étapes de connexion et de premier octet avec curl, testez contre la même cible depuis le même réseau, exécutez plusieurs fois et prenez la médiane, et comparez avec une référence sans proxy. Le script bash ci-dessus fait exactement cela.

La distance au proxy affecte-t-elle la vitesse ?

Oui, inévitablement. Un proxy éloigné de vous ou de votre cible ajoute un temps de trajet que aucun logiciel ne peut supprimer — c'est de la physique. Lors de la comparaison des proxies, tenez compte de l'emplacement et préférez une sortie qui est géographiquement sensée pour vous et la destination que vous atteignez.

Mesurez-le, ne le devinez pas

Évaluez les proxies comme les demandes se comportent réellement avec le script ci-dessus, ou commencez avec des proxies de centre de données authentifiés conçus pour une faible latence constante. Testez-en un gratuitement dans le vérificateur de proxy d'abord.

Les gens ont trouvé cette page en recherchant

Vraies phrases de recherche auxquelles cette page répond — les liens ouvrent la page qui les couvre en profondeur.