Sans KYC — pas de pièce d'identité, pas de selfie, pas de documents · Ciblage par ASN, État, ville et ZIP sur tous les plans · Payez en crypto à partir de 25 $US
Langue: Français
Commencer

Cas d'usage · QA et support

Proxys résidentiels pour la reproduction de bugs propres à un FAI

Certains tickets n'ont de sens que sur un seul réseau. Ça échoue en fixed wireless, la mauvaise ville s'affiche, ou une image est obsolète chez un fournisseur câble. Une IP domestique sur ce réseau transforme le ticket en test reproductible.

Dernière mise à jour: · 9 min de lecture

Réponse rapide

Comment reproduire un bug qui ne se produit que chez un seul fournisseur d'accès ?

La reproduction d'un bug réseau consiste à rejouer la panne d'un client depuis le même type de connexion : même fournisseur, même ville, idéalement à la même heure. Broadband Proxies fournit aux équipes QA et support des IP résidentielles américaines par ASN et par ville. Les sessions sticky durent jusqu'à 30 minutes (l'IP peut changer plus tôt, par exemple si l'appareil domestique se déconnecte). Un forfait de 1 GB coûte 2,63 $US ; il n'y a pas de KYC et le paiement se fait en crypto.

Reproduction de bug en un coup d'œil

Tickets typiquesÉchoue uniquement en fixed wireless, mauvaise ville ou État détecté, contenu obsolète sur un seul réseau, bloqué comme suspect
CiblageASN plus État, ville ou ZIP, par ex. USERNAME-country-us-state-az-city-phoenix-asn-22773 (réseau Cox à Phoenix)
Sessions persistantesjusqu'à 30 minutes (l'IP peut changer plus tôt, par exemple si l'appareil domestique se déconnecte)
ProtocolesHTTP, HTTPS (CONNECT) et SOCKS5
Ce qu'il faut journaliserCiblage demandé, IP de sortie, ASN d'origine, fenêtre temporelle UTC, id de session
Ce qu'il ne peut pas reproduireLe routeur, le Wi-Fi, l'appareil et les paramètres DNS locaux du client
Prix2,63 $US pour 1 GB, 5,94 $US pour 10 GB, sous-utilisateurs par projet

Quels bugs propres à un ISP une IP résidentielle peut-elle reproduire ?

Une sortie résidentielle donne à votre service l'IP publique du réseau du client. Toute logique basée sur cette IP se comportera comme chez le client. Quatre types de tickets reviennent souvent.

  • Adresses partagées en fixed wireless. T-Mobile Home Internet (AS21928) et Verizon 5G Home (AS22394) utilisent du carrier-grade NAT, donc de nombreux foyers partagent une même adresse IPv4 publique. Une limite de débit par IP peut alors bloquer tout un groupe d'utilisateurs d'un coup. T-Mobile a déclaré 8 450 000 clients broadband 5G au 31 décembre 2025. Verizon a déclaré 6 208 000 connexions fixed wireless au 30 juin 2026.
  • Erreurs de géolocalisation. Une base d'IP peut situer un foyer dans la mauvaise ville ou le mauvais État. Les store finders, les lignes de taxe et le contenu local se trompent alors uniquement pour ce réseau.
  • Libellés de propriété obsolètes. Charter a finalisé son accord Cox le 19 août 2026. Les bases peuvent nommer AS22773 Cox ou Charter selon leur dernière mise à jour, ce qui casse les règles qui matchent sur le nom de l'ISP.
  • Différences d'edge CDN. Un CDN peut répondre aux utilisateurs Comcast et CenturyLink d'une même ville depuis des edges différents. À Denver, la FCC indique Comcast à 98,7 % et CenturyLink à 95,3 % des logements (données au 31 décembre 2025). Un objet obsolète ou une erreur TLS sur un seul edge n'apparaît que sur un seul réseau.

Qu'est-ce qu'un test avec proxy ne peut pas reproduire ?

Un proxy copie l'IP publique et son réseau, pas toute la connexion. Le routeur, le Wi-Fi, les extensions de navigateur et l'appareil du client restent hors de portée. Demandez la version du navigateur et une capture d'écran pour couvrir ces cas.

Le DNS est une autre limite. Via un proxy, les noms peuvent être résolus par le réseau du proxy plutôt que par le résolveur de l'ISP, donc les bugs purement DNS nécessitent une autre méthode.

L'IPv6 demande aussi de l'attention. La vérification ci-dessous utilise api.ipify.org, qui ne répond qu'en IPv4. Si un bug n'apparaît qu'en IPv6, un test par proxy peut confirmer ou exclure le chemin IPv4. Il vous faut quand même une ligne IPv6 native pour confirmer le reste.

Comment reproduire un ticket sur un seul réseau ?

  1. Récupérer les faits réseau

    Demandez le nom de l'ISP, la ville ou le ZIP, l'heure de la panne et le texte de l'erreur. Une recherche comme notre guide des IP de sortie donne l'ASN sans partager de mots de passe ni d'accès au routeur.

  2. Construire un nom d'utilisateur sticky

    Pour un client Cox à Phoenix : USERNAME-country-us-state-az-city-phoenix-asn-22773-session-bug4521-ttl-30.

  3. Confirmer et journaliser la sortie

    Lancez le script ci-dessous. Il enregistre l'IP de sortie, l'ASN d'origine et le préfixe, puis surveille tout changement d'IP.

  4. Reproduire dans la session

    Utilisez le même nom d'utilisateur dans le navigateur ou le test runner. Terminez dans la fenêtre de session et notez tout changement d'IP.

  5. Lancer un réseau témoin

    Répétez les étapes sur un autre ASN dans la même ville. Si le bug disparaît, le réseau fait partie de la cause.

Enregistrement de session sticky pour un ticket (Python, requests)
# Keep one sticky exit for a bug reproduction and write a record for the ticket.
import json
import time
from datetime import datetime, timezone

import requests

GATEWAY = "gw.broadbandproxies.com"
PORT = 7777
TARGET = "country-us-state-az-city-phoenix-asn-22773"  # Cox network in Phoenix
SESSION = "bug4521"
USERNAME = "USERNAME-" + TARGET + "-session-" + SESSION + "-ttl-30"
PASSWORD = "PASSWORD"

proxy = "http://%s:%s@%s:%d" % (USERNAME, PASSWORD, GATEWAY, PORT)
proxies = {"http": proxy, "https": proxy}


def now():
    return datetime.now(timezone.utc).isoformat(timespec="seconds")


def exit_ip():
    r = requests.get("https://api.ipify.org?format=json", proxies=proxies, timeout=30)
    r.raise_for_status()
    return r.json()["ip"]


def origin(ip):
    r = requests.get(
        "https://stat.ripe.net/data/prefix-overview/data.json",
        params={"resource": ip, "sourceapp": "bug-repro"},
        timeout=30,
    )
    r.raise_for_status()
    data = r.json()["data"]
    return [a["asn"] for a in data.get("asns", [])], data.get("resource")


ip = exit_ip()
asns, prefix = origin(ip)
record = {"target": TARGET, "session": SESSION, "start_utc": now(), "exit_ip": ip,
          "origin_asns": asns, "prefix": prefix, "ip_changes": []}

# Reproduce the bug in the browser now, with the same username.
# This loop only checks every 5 minutes that the exit IP has not moved.
for _ in range(5):
    time.sleep(300)
    current = exit_ip()
    if current != ip:
        record["ip_changes"].append({"time_utc": now(), "new_ip": current,
                                     "origin_asns": origin(current)[0]})
        ip = current

record["end_utc"] = now()
print(json.dumps(record, indent=2))

Que doit contenir un enregistrement de reproduction ?

ChampExemplePourquoi c'est important
Ciblage demandécountry-us-state-az-city-phoenix-asn-22773Un collègue peut relancer le même test plus tard
IP de sortie203.0.113.24 (plage de documentation)À rechercher dans vos logs serveur et CDN
ASN d'origine et préfixeAS22773, d'après RIPEstatProuve le réseau, pas seulement la requête
Fenêtre temporelle UTC2026-10-18 14:05 à 14:30 UTCCorrespond aux lignes de log quel que soit le fuseau horaire
Id de session et TTLbug4521, 30 minutesIndique si l'IP est restée la même
RésultatHTTP 403 sur /checkout/Le bug, reproduit ou non
ContrôleMême ville sur AS209 : aucune erreurSépare les causes réseau des causes de code

Quels systèmes puis-je tester de cette façon ?

Testez votre propre site, app ou API, ou un système dont le propriétaire vous a demandé de le faire. La reproduction d'un ticket doit prendre une poignée de requêtes, pas un crawl. Notre Politique d'utilisation acceptable interdit les floods et les scans de systèmes sans l'autorisation du propriétaire.

Gardez les données client hors des noms d'utilisateur et des identifiants de session. Utilisez un numéro de ticket tel que bug4521, jamais un e-mail ou un nom. Les sites bancaires, gouvernementaux et de portails de paiement sont bloqués sur tous les plans, donc les pages des prestataires de paiement ne peuvent pas être testées via la passerelle.

De quel trafic une équipe support a-t-elle besoin ?

Une seule reproduction représente souvent quelques chargements de page plus les vérifications du script. 1 GB (2,63 $US) couvre un essai sur un ISP et une ville. 10 GB (5,94 $US) convient à une équipe QA avec un sous-utilisateur par testeur. Le trafic n'expire jamais.

Test

1 GB

2,63 $US

2,63 $US/GB

  • Vérifiez d'abord un ISP dans une ville
  • Ciblage par ASN, état, ville et ZIP
  • HTTP, HTTPS, SOCKS5
Choisir 1 GB

Starter

5 GB

3,75 $US

0,75 $US/GB

  • Comparez deux ou trois réseaux
  • Sessions rotatives ou persistantes
  • Le trafic n'expire jamais
Choisir 5 GB

Équipe

10 GB

5,94 $US

0,59 $US/GB

  • Vérifications régulières sur plusieurs ISP
  • Sous-utilisateurs par projet
  • Le trafic n'expire jamais
Choisir 10 GB

Dans chaque formule: Protocoles: HTTP, HTTPS, SOCKS5 · Ciblage: ASN (ISP), État, ville et ZIP aux États-Unis ; pays ailleurs ; disponibilité des villes variable · Sessions: Rotation ou session persistante (jusqu'à 30 minutes) · Authentification: Nom d'utilisateur et mot de passe, ou une liste d'IP autorisées (jusqu'à 10 IP) · Expiration du trafic: N'expire jamais

Reproduction de bug réseau : questions

Puis-je garder la même IP pendant tout le test ?

Oui, dans une session sticky : jusqu'à 30 minutes (l'IP peut changer plus tôt, par exemple si l'appareil domestique se déconnecte). Placez -session-<id>-ttl-<minutes> à la fin du nom d'utilisateur et réutilisez le même id dans chaque outil. Notez l'IP de sortie au début et à la fin. Si elle a changé, indiquez-le dans le ticket, car une nouvelle IP peut être sur un préfixe différent.

Puis-je reproduire un bug de NAT opérateur (carrier-grade NAT) ?

Souvent, oui. Ciblez AS21928 pour T-Mobile Home Internet ou AS22394 pour Verizon 5G Home. Les sorties sur ces réseaux partagent généralement des adresses avec d'autres utilisateurs, comme la ligne du client. Broadband Proxies ne peut pas dire si une sortie donnée est une passerelle domestique ou un téléphone, donc notez l'ASN plutôt que le type d'appareil.

Le test couvre-t-il l'IPv6 ?

Pas comme montré ici. L'exemple vérifie la sortie avec api.ipify.org, qui répond uniquement en IPv4. Si la panne du client ne survient qu'en IPv6, le test proxy vous dit si le chemin IPv4 est correct. Confirmez le côté IPv6 depuis une connexion IPv6 native.

Que dois-je demander au client ?

Le nom de l'ISP, la ville ou le ZIP, l'heure de la panne, le navigateur et l'erreur exacte. L'ASN aide le plus : une page de lookup l'affiche sans aucun identifiant. Ne demandez jamais de mots de passe, d'accès au routeur ou de contrôle à distance de l'appareil du client. Ce n'est pas nécessaire pour tester le côté réseau.

Plusieurs testeurs peuvent-ils partager un seul plan ?

Oui. Créez un sous-utilisateur par testeur ou par projet. Chaque sous-utilisateur a ses propres identifiants, plafond de trafic et totaux d'usage. Vous pouvez aussi autoriser jusqu'à 10 IPs au lieu d'un mot de passe, ce qui convient aux runners CI avec des adresses fixes. Le trafic provient du plan que vous avez acheté.

Et si aucune IP n'est en ligne sur cet ASN dans cette ville ?

La disponibilité des ASN varie selon le réseau, la ville et l'heure ; le checkout affiche ce qui est en ligne, et aucun nombre d'IP par ISP n'est publié. Retirez d'abord le ZIP, puis la ville, et gardez l'ASN avec l'État. Un petit fournisseur peut n'être en ligne qu'à certaines heures, donc réessayez à l'heure de la journée où le client a signalé le problème. Notez dans le ticket le niveau de ciblage que vous avez utilisé.

1 GB 2,63 $US · ASN inclus · sans KYC

Commencer