Comment tester la vitesse, le taux de réussite et la précision de localisation d'un proxy résidentiel

« À quelle vitesse va-t-il ? » est la mauvaise première question à poser sur un proxy résidentiel. Un proxy qui répond en 200ms mais se fait bloquer la moitié du temps est inutile ; un un peu plus lent qui renvoie la vraie page à chaque fois est exactement ce que vous voulez. Avant de faire confiance à un fournisseur, ou de déboguer pourquoi votre scraper sous-performe, vous devez mesurer trois choses objectivement : taux de réussite, distribution de latence, et précision de localisation. Ce guide vous donne des tests à copier-coller pour chacune et, tout aussi important, comment lire les chiffres sans vous tromper vous-même.

Tout ci-dessous tourne contre le gateway résidentiel de Shifter (un point de terminaison, p.shifter.io:443, ciblage encodé dans le nom d’utilisateur), mais les tests sont agnostiques au fournisseur, changez l’hôte et les identifiants et ils fonctionnent partout. Les exemples sont en Python ; la configuration du client reflète proxys résidentiels avec Python.

Les trois métriques qui comptent vraiment

La vitesse brute est la métrique sur laquelle les gens se fixent et la moins utile isolément. Les IP résidentielles passent par de vrais appareils grand public, elles sont donc intrinsèquement un peu plus lentes que le datacenter, c’est attendu, et pas un défaut. Ce qui détermine vraiment si un proxy est bon pour votre travail :

• Taux de réussite — parmi les requêtes que vous envoyez, combien renvoient la vraie page (pas un blocage, un CAPTCHA, ou une erreur). C’est le chiffre qui décide si votre pipeline de données est complet.
• Distribution de latence — pas la moyenne, la dispersion. Le p95 et la queue vous disent à quel point vos requêtes lentes deviennent mauvaises, ce qui fait mal à grande échelle.
• Précision de localisation — quand vous ciblez un pays ou une ville, l’IP de sortie résout-elle vraiment là-bas ? Pour tout cas d’usage avec geo-targeting, des données de mauvaise localisation sont des données silencieusement fausses.

Mesurez les trois. Un seul chiffre, surtout la vitesse moyenne, cache les problèmes qui comptent.

Configuration

Gardez les identifiants dans des variables d’environnement, et définissez un helper qui construit une URL de proxy avec ciblage :

import os, time, statistics, requests

USER = os.environ["SHIFTER_USER"]
PASS = os.environ["SHIFTER_PASS"]
GATEWAY = "p.shifter.io:443"

def proxy(country="us", city=None, sid=None, ttl=600):
    parts = [USER, "country", country]
    if city: parts += ["city", city]
    if sid:  parts += ["sid", sid, "ttl", str(ttl)]
    url = f"http://{'-'.join(parts)}:{PASS}@{GATEWAY}"
    return {"http": url, "https": url}

D’abord, vérifiez que vous passez vraiment par le proxy, un nombre surprenant de rapports « le proxy est lent » sont du trafic qui n’a jamais quitté la machine locale :

r = requests.get("https://api.ipify.org?format=json", proxies=proxy("us"), timeout=30)
print(r.json())   # devrait être une IP résidentielle, pas la vôtre

Test 1 : Précision de localisation

Ciblez un pays (et optionnellement une ville), demandez à un endpoint de géo-IP où est l’IP de sortie, et mesurez le taux de correspondance sur de nombreux échantillons. Tournez à chaque requête (sans sid) pour échantillonner le pool, pas une IP :

def test_geo(country="us", n=50):
    hits = 0
    for _ in range(n):
        try:
            r = requests.get("http://ip-api.com/json", proxies=proxy(country), timeout=30)
            data = r.json()
            if data.get("countryCode", "").lower() == country.lower():
                hits += 1
        except requests.RequestException:
            pass
    print(f"{country}: {hits}/{n} = {hits/n:.0%} country-accurate")

test_geo("us")
test_geo("de")

Comment le lire. La précision de pays devrait être très élevée (pensez au haut des 90%). La précision de ville est intrinsèquement plus floue, les bases de données de géo-IP sont en désaccord sur la ville à laquelle appartient une IP, donc un « raté » peut être un désaccord de base de données, pas un proxy qui vous envoie au mauvais endroit. Deux réserves qui vous sauvent de conclusions fausses : testez la précision de ville contre la même source de géo-IP que celle qu’utilise votre site cible si vous le pouvez, et ne faites jamais confiance à un seul fournisseur de lookup comme vérité de terrain.

Test 2 : Latence, mesurée comme une distribution

Mesurez le temps total de requête sur de nombreux échantillons et rapportez des percentiles, pas la moyenne. Une moyenne lisse justement la queue lente qui vous fait mal à grande échelle :

def test_latency(country="us", n=50, url="https://api.ipify.org"):
    times = []
    for _ in range(n):
        start = time.perf_counter()
        try:
            requests.get(url, proxies=proxy(country), timeout=30).raise_for_status()
            times.append((time.perf_counter() - start) * 1000)  # ms
        except requests.RequestException:
            pass
    times.sort()
    p = lambda q: times[min(len(times)-1, int(q*len(times)))]
    print(f"n={len(times)}  p50={p(0.5):.0f}ms  p95={p(0.95):.0f}ms  max={times[-1]:.0f}ms")

test_latency("us")

Comment le lire. Regardez le p50 face au p95 : une dispersion serrée (p95 proche du p50) signifie une performance prévisible ; un p95 plusieurs fois le p50 signifie une queue lourde qui bloquera les workers concurrents. Pour séparer le surcoût du proxy de la lenteur de la cible, lancez le même test contre un endpoint rapide et neutre (comme un echo d’IP) et contre votre vraie cible, la différence est en gros la latence propre de la cible. Et ne comparez pas le p50 résidentiel au p50 datacenter comme s’ils étaient le même produit ; le résidentiel ajoute un saut d’appareil réel par conception (voir proxys résidentiels vs datacenter).

Test 3 : Taux de réussite, celui qui compte le plus

Lancez les requêtes contre votre vraie cible (le succès est spécifique à la cible) et classez chaque résultat. Le piège ici est de faire confiance au statut HTTP : un 200 OK peut quand même être un blocage doux, une page de CAPTCHA ou « veuillez vérifier » servie avec un 200. Donc validez le contenu, pas seulement le code :

def looks_like_real_page(html):
    # À ajuster à votre cible : présence du markup attendu, absence de marqueurs de blocage.
    block_markers = ("captcha", "are you a robot", "access denied", "unusual traffic")
    low = html.lower()
    return len(html) > 1000 and not any(m in low for m in block_markers)

def test_success(url, country="us", n=100):
    ok, soft_block, errors = 0, 0, 0
    for _ in range(n):
        try:
            r = requests.get(url, proxies=proxy(country), timeout=30)
            if r.status_code == 200 and looks_like_real_page(r.text):
                ok += 1
            else:
                soft_block += 1        # 200-mais-blocage, 403/429/503, etc.
        except requests.RequestException:
            errors += 1                # timeouts, échecs de connexion
    print(f"success={ok/n:.0%}  blocked={soft_block/n:.0%}  errors={errors/n:.0%}")

test_success("https://your-target.example/page", country="us")

Comment le lire. Le taux de réussite est la métrique phare pour le scraping, c’est la fraction des requêtes qui ont renvoyé des données utilisables. Divisez les échecs en bloqués (la cible vous a refusé) contre erreurs (réseau/timeout), car ils ont des correctifs différents : les blocages constants pointent vers la qualité d’IP ou le comportement des requêtes (pourquoi les scrapers se font bloquer), tandis que les erreurs pointent vers des timeouts ou des filtres géo trop serrés. Notez que la rotation à chaque requête et une boucle de réessai augmentent votre taux de réussite effectif, mesurez donc à la fois le brut (un seul tir) et l’avec-réessai si c’est ainsi que vous tournerez en production.

Tout assembler

Un harness minimal lance les trois et imprime un rapport :

if __name__ == "__main__":
    for cc in ("us", "de", "gb"):
        print(f"\n== {cc.upper()} ==")
        test_geo(cc, n=50)
        test_latency(cc, n=50)
        test_success("https://your-target.example/page", country=cc, n=100)

Lisez-le dans cet ordre : taux de réussite d’abord (les données reviennent-elles seulement ?), puis la queue de latence (tiendra-t-il sous la concurrence ?), puis la précision géo (sont-ce les bonnes données ?). Un fournisseur qui gagne au p50 mais perd au taux de réussite est le mauvais choix pour le scraping.

Pièges courants qui produisent des chiffres trompeurs

• Rapporter la latence moyenne. Utilisez des percentiles, la queue est ce qui casse les jobs concurrents.
• Faire confiance au statut 200. Les blocages doux renvoient 200 avec une page de CAPTCHA. Validez le contenu.
• Échantillons trop petits. 5 requêtes ne vous disent rien ; utilisez-en assez (50 à 100+) pour voir la distribution et la queue.
• Mauvaise vérité de terrain géo. Différentes bases de données de géo-IP sont en désaccord, surtout au niveau de la ville. Testez contre la source qu’utilise votre cible, et traitez la précision de ville comme intrinsèquement plus floue que celle du pays.
• Comparer résidentiel et datacenter sur la vitesse brute. Produits différents ; le résidentiel échange un peu de latence contre la confiance d’un vrai utilisateur et un taux de réussite plus élevé sur les cibles défendues (quels proxys sont meilleurs pour le scraping).
• Ne pas confirmer que vous êtes sur le proxy. Vérifiez que l’IP de sortie a changé avant de benchmarker quoi que ce soit.

Une note sur le faire de façon responsable

Benchmarkez contre des endpoints que vous êtes autorisé à frapper, des services publics d’echo d’IP pour la vitesse et la géo, et vos propres cibles autorisées pour le taux de réussite. Gardez des tailles d’échantillon raisonnables, ne martelez pas un site pour le mesurer, et respectez les rate limits. Notre politique d’usage acceptable est la source de vérité pour ce qui est permis sur Shifter.

FAQ

Quel est un bon taux de réussite pour les proxys résidentiels ? Cela dépend entièrement de la cible, un site bien défendu bloquera plus qu’un site ouvert. Ce qui compte, c’est de le mesurer contre votre cible et de comparer les fournisseurs sur la même cible. Divisez les échecs en blocages contre erreurs pour savoir quoi corriger.

Pourquoi mon proxy résidentiel est-il plus lent qu’un datacenter ? Parce qu’il passe par un vrai appareil grand public, ce saut ajoute de la latence par conception. C’est le compromis pour la confiance d’un vrai utilisateur et des taux de réussite plus élevés sur les sites qui bloquent les IP de datacenter. Jugez le résidentiel sur le taux de réussite et la distribution de latence, pas sur le p50 brut face au datacenter.

Comment tester la précision de localisation au niveau de la ville ? Ciblez la ville et vérifiez l’IP de sortie contre une source de géo-IP, idéalement la même qu’utilise votre cible. Attendez-vous à ce que la précision de pays soit très élevée et celle de ville plus floue, puisque les bases de données de géo-IP sont en désaccord sur les limites de ville. Voir quand le ciblage au niveau de la ville compte.

Pourquoi une réponse 200 compte-t-elle quand même comme un échec ? Parce que les sites servent des blocages doux, des pages de CAPTCHA ou « vérifiez que vous êtes humain », avec un statut 200. Si vous ne vérifiez que le code de statut, vous enregistrerez les blocages comme des succès. Validez que le contenu correspond à ce à quoi ressemble une vraie page.

Devrais-je tester avec des sessions rotatives ou sticky ? Les deux, selon votre charge de travail. Rotative (sans sid) échantillonne le pool et convient au scraping large ; sticky (sticky vs rotative) teste les flux à plusieurs étapes. Mesurez le mode dans lequel vous tournerez vraiment en production.

En résumé

Bien tester un proxy résidentiel signifie refuser de le réduire à un seul chiffre de vitesse. Mesurez le taux de réussite contre votre vraie cible avec validation de contenu, la latence comme une distribution avec un regard sur la queue p95, et la précision de localisation avec une vérité de terrain géo-IP sensée, et vous saurez si un fournisseur convient vraiment à votre travail au lieu de deviner à partir d’un chiffre marketing. La qualité du pool est ce qui bouge les trois, alors comprendre la réputation d’IP aide à interpréter les résultats.

Si vous benchmarkez des fournisseurs ou déboguez votre propre taux de réussite, lancez ces tests contre le gateway résidentiel et votre cible de choix. La page tarifs propose des forfaits au Go pour l’essayer contre les marchés et sites qui vous importent.