Détection des proxies résidentiels : ce que révèle la sortie

Acheter de la bande passante résidentielle ne transforme pas automatiquement un navigateur en client résidentiel. Un site peut lire des registres d’attribution, des données de routage, une délégation inverse, des mesures de temps et une poignée de main TLS avant de rendre une page, et ces observations divergent assez souvent pour qu’aucune ne constitue un verdict à elle seule. BotBrowser configure un profil de navigateur déclaré et un routage proxy configurable pour une tâche autorisée. Il ne peut pas modifier l’ASN de l’adresse de sortie, son routage ni sa délégation inverse, et il ne transforme pas une adresse de datacenter en adresse résidentielle, pas plus qu’il ne garantit la classification ou l’acceptation par un site.

TL;DR

• Registre, route annoncée et DNS inverse sont trois enregistrements différents. Une adresse peut avoir un registre de FAI grand public et être annoncée depuis un réseau d’hébergement.
• Une requête ASN répond à « à qui ce préfixe a-t-il été attribué », pas à « s’agit-il d’une connexion domestique ». Les données du RIR sont des données d’attribution.
• Les geofeeds auto-publiés peuvent être faux, et la norme demande aux consommateurs de vérifier leur exactitude plutôt que de la supposer.
• Latence et gigue décrivent un chemin dans les conditions du moment. La congestion, un datacenter éloigné et un lien bridé peuvent produire la même forme.
• Une valeur JA3 ou JA4 décrit une poignée de main TLS. Quand un proxy termine TLS, la poignée de main vue par le site appartient à ce proxy, pas au navigateur derrière lui.
• Notez quel composant détient chaque observation. Un changement de profil déplace des valeurs du navigateur ; il ne déplace pas un ASN, une annonce de route ni un pointeur délégué.

Sommaire

• Ce que le site observe avant le chargement
• Registre, routage et délégation inverse sont distincts
• Exécuter un classificateur sur des enregistrements fournis
• Les temps et la poignée de main sont plus faibles qu’ils n’en ont l’air
• Ce qu’un profil de navigateur change et ce qu’il ne change pas
• Conclusion pratique

Ce que le site observe avant le chargement

La première chose qu’un site apprend est l’adresse source de la connexion. Tout ce qui suit est une inférence rattachée à cette adresse, et ces inférences viennent de systèmes aux tâches plus étroites. Les registres régionaux d’internet attribuent de l’espace d’adressage à des organisations. Les systèmes de routage annoncent des préfixes. Les opérateurs de domaines publient des pointeurs et des fichiers de localisation. Chaque système répond à une question, et la réponse n’est précise que dans la mesure de cette question.

C’est pourquoi une question sur les « proxies résidentiels » devient souvent un désaccord de vocabulaire. Une équipe achète une adresse qui figure dans un bloc de FAI grand public et reçoit malgré tout une page de blocage. Une autre utilise une adresse de datacenter qui passe pendant des mois puis échoue après un changement de routage. Aucun des deux résultats n’est mystérieux une fois les observations séparées : l’adresse n’a pas changé, mais l’enregistrement consulté par le site, si.

Observation	Source typique	Ce qu’elle établit	Ce qu’elle ne peut pas établir	Qui peut la modifier
Registre du préfixe	RDAP ou WHOIS du RIR	Quelle organisation a reçu le bloc d’adresses	Si un client utilise cette adresse depuis un domicile ou un bureau	Le registre, par transfert ou réattribution
Annonce de route	Données de routage inter-réseaux	Quel réseau annonce actuellement le préfixe	La localisation physique ou la technologie d’accès	Le réseau qui l’annonce
Délégation inverse	Enregistrement PTR	Quel nom le titulaire a publié pour cette adresse	Que ce nom soit actuel ou véridique	L’opérateur de la zone inverse
Localisation auto-publiée	Fichier geofeed	La localité que l’éditeur revendique pour le préfixe	Que cette revendication soit exacte pour une adresse	L’éditeur
Temps de trajet	Mesures de requêtes	Comment le chemin s’est comporté pendant l’échantillon	Quel type de réseau d’accès l’a produit	Personne, pour un seul échantillon
Poignée de main TLS	ClientHello et échange de certificats	Quelle pile cliente a négocié la connexion	Quel navigateur ou appareil a émis la requête	Celui qui termine TLS

La conséquence pratique est qu’une étiquette résidentielle est une affirmation sur des enregistrements, pas une propriété du câble. Une adresse qu’un site classe comme résidentielle aujourd’hui peut être reclassée après un transfert d’attribution, et une adresse qui passe toutes les vérifications statiques peut échouer sur une règle comportementale appliquée à la session.

Registre, routage et délégation inverse sont distincts

Les données de registre sont les plus citées et les plus mal lues. Un enregistrement décrit une attribution à une organisation. Il peut indiquer qu’un bloc appartient à un fournisseur d’accès et dans quel pays l’attribution a été faite. Il ne dit pas qu’un abonné précis dispose d’un type de connexion précis à une adresse précise ; un enregistrement RDAP pour 203.0.113.24 est un objet d’attribution. Lire un registre de FAI grand public et conclure « sortie résidentielle » saute l’étape où un fournisseur attribue cette adresse à un abonné, et les fournisseurs réattribuent des adresses en permanence.

Les données de routage répondent à une autre question. Un préfixe annoncé est joignable via un réseau, et le réseau qui l’annonce n’est pas nécessairement l’organisation titulaire du registre. Un fournisseur peut annoncer l’espace de ses clients depuis un autre système autonome, et un hébergeur peut originer un préfixe qu’un registre associe encore à un FAI régional. Traiter le réseau annonceur comme titulaire, ou le titulaire comme annonceur, produit des affirmations assurées que les données sous-jacentes ne soutiennent pas.

Le DNS inverse est le plus faible des trois comme signal d’identité, car c’est un pointeur délégué que quiconque contrôle la zone inverse peut publier. Un pointeur qui ressemble à un nom d’abonné peut être périmé, réattribué, ou simplement choisi par un opérateur qui aime cette convention. Un pointeur absent est tout aussi peu informatif : beaucoup de réseaux légitimes n’en publient jamais, et une requête PTR ne renvoie alors aucun nom. Si un site utilise des noms inverses, il les utilise comme une entrée dans une décision pondérée, pas comme une preuve.

Les fichiers de localisation méritent la même prudence. La RFC 8805 définit un format de géolocalisation IP auto-publiée, et la spécification précise que les inexactitudes surviennent à plusieurs niveaux. Elle demande aux consommateurs de vérifier la localité publiée dans la mesure du possible et de fixer leurs propres seuils d’écart. Un geofeed soutient donc une affirmation de localisation faite par son éditeur ; il ne certifie pas qu’une adresse donnée est une connexion domestique ni n’oblige un site à accepter cette affirmation.

Registre et routage divergent assez souvent pour qu’un classificateur à un seul champ étiquette mal du trafic réel : une observation à 203.0.113.24 peut porter un enregistrement de FAI et une annonce d’hébergement. La question utile n’est pas « cette adresse a-t-elle l’air résidentielle », mais « quels enregistrements concordent, lesquels divergent, et que signifie chaque écart pour la décision que je vais prendre ». Pour la mécanique de route derrière une requête du navigateur, configuration proxy et alignement géographique décrit comment un point de sortie est choisi et comment les valeurs visibles dans la page sont dérivées de l’adresse publique observée. La configuration choisit la route ; la décision porte sur ce que les enregistrements de cette route peuvent soutenir.

Exécuter un classificateur sur des enregistrements fournis

L’exemple ci-dessous classe cinq enregistrements synthétiques. Il n’émet aucune requête réseau, ne lit aucun site réel et n’affirme pas qu’une adresse réelle possède ces propriétés. Son but est de montrer la forme d’une décision défendable : chaque entrée devient son propre champ, les écarts sont comptés, et aucun champ n’est fusionné en un verdict résidentiel.

import assert from 'node:assert/strict';

const records = [
  {
    id: 'registered-residential-isp',
    asn: 64500,
    registeredUse: 'isp',
    announced: true,
    ptrSuffix: 'customer.example-isp.test',
    ptrOwner: 'example-isp.test',
  },
  {
    id: 'registered-host',
    asn: 64501,
    registeredUse: 'hosting',
    announced: true,
    ptrSuffix: 'cloud.example-host.test',
    ptrOwner: 'example-host.test',
  },
  {
    id: 'isp-asn-announced-by-host',
    asn: 64502,
    registeredUse: 'isp',
    announced: false,
    ptrSuffix: 'static.example-host.test',
    ptrOwner: 'example-host.test',
  },
  {
    id: 'stale-pointer',
    asn: 64503,
    registeredUse: 'isp',
    announced: true,
    ptrSuffix: 'customer.old-name.test',
    ptrOwner: 'other-owner.test',
  },
  { id: 'no-pointer', asn: 64504, registeredUse: 'isp', announced: true, ptrSuffix: null, ptrOwner: null },
];

const registeredUseLabels = { isp: 'isp-registration', hosting: 'hosting-registration' };

function classify(record) {
  const registration = registeredUseLabels[record.registeredUse] ?? 'unknown-registration';
  const routing = record.announced ? 'announced' : 'not-announced-in-sample';
  const reverseDns = record.ptrSuffix
    ? record.ptrOwner && record.ptrSuffix.endsWith(`.${record.ptrOwner}`)
      ? 'delegated-to-registrant'
      : 'not-delegated-to-registrant'
    : 'absent';
  const disagreements = [
    registration === 'isp-registration' && reverseDns === 'not-delegated-to-registrant',
    registration === 'isp-registration' && routing === 'not-announced-in-sample',
  ].filter(Boolean).length;
  return { registration, routing, reverseDns, disagreements };
}

for (const record of records) {
  const result = classify(record);
  console.log(
    `${record.id} registration=${result.registration} routing=${result.routing} ptr=${result.reverseDns} disagreements=${result.disagreements}`
  );
}

Collez-le dans un fichier .mjs local et exécutez-le avec node. La sortie compte cinq lignes, une par enregistrement, avec les mêmes noms de champs que le tableau. Lisez-les comme une petite comparaison, pas comme un verdict.

registered-residential-isp registration=isp-registration routing=announced ptr=delegated-to-registrant disagreements=0
registered-host registration=hosting-registration routing=announced ptr=delegated-to-registrant disagreements=0
isp-asn-announced-by-host registration=isp-registration routing=not-announced-in-sample ptr=delegated-to-registrant disagreements=1
stale-pointer registration=isp-registration routing=announced ptr=not-delegated-to-registrant disagreements=1
no-pointer registration=isp-registration routing=announced ptr=absent disagreements=0

Deux des cinq enregistrements divergent, et les deux écarts sont informatifs. Le troisième a un registre de FAI grand public mais n’est pas annoncé dans l’échantillon, ce qui correspond au cas d’un préfixe réattribué ou d’une observation prise depuis une vue de routage incomplète. Le quatrième porte un pointeur qui n’appartient plus au titulaire, ce à quoi ressemble une adresse périmée ou réémise. Aucun des deux cas ne produit « résidentiel » ou « datacenter » comme réponse, car les entrées ne soutiennent pas cette réponse.

Le cinquième enregistrement est celui qui surprend les équipes. Un registre grand public sans pointeur inverse totalise zéro écart selon ces règles, et pourtant il n’apprend presque rien à un site. Un site qui pondère fortement les noms inverses le traiterait différemment d’un site qui les ignore. Cet écart est un choix de politique du site, pas un fait sur l’adresse.

Ce classificateur est volontairement minimal. Il ne résout pas de préfixes réels, ne valide pas les enregistrements du registre, ne pondère pas les écarts en score et ne modélise pas la décision d’un fournisseur. Tout seuil ajouté relève de votre politique, avec son propre taux d’erreur, et ce seuil doit figurer à côté de la décision qu’il a produite.

Les temps et la poignée de main sont plus faibles qu’ils n’en ont l’air

Les temps ressemblent à une mesure directe, d’où la confiance excessive qu’on leur accorde. Une requête depuis une connexion grand public affiche souvent une latence plus élevée et plus variable qu’une requête depuis un datacenter, si bien que les équipes lisent une distribution serrée comme un signal d’hébergement. L’inférence va dans les deux sens. Un lien domestique congestionné peut sembler lent et erratique, et un datacenter de la même ville peut sembler rapide et stable ; enregistrez p50 et p95 avec la taille d’échantillon au lieu d’un seul nombre. Un réseau mobile ajoute sa propre variabilité, et un proxy ajoute un saut dont le comportement appartient au fournisseur plutôt qu’au client.

Cela rend un échantillon unique inutilisable comme classificateur. Si les temps servent, ils appartiennent à une distribution avec la taille d’échantillon, la fenêtre temporelle et la route enregistrées, et même alors ils ne soutiennent que « ce chemin s’est comporté ainsi pendant la fenêtre ». Un site qui compare une session à un appareil déclaré dispose d’une question plus forte : le comportement typique de l’appareil déclaré correspond-il à ce que la session a produit ? Un profil de bureau qui revendique la fibre alors que chaque requête arrive avec la forme d’un relais lointain est un écart qui mérite explication, et l’explication peut être le relais plutôt que le réseau d’accès.

La poignée de main est l’observation que les équipes se trompent le plus souvent dans l’autre sens. JA3 et JA4 sont des valeurs dérivées d’une poignée de main TLS, et la documentation du fournisseur précise qu’elles sont calculées pendant cette poignée de main et peuvent manquer lorsqu’aucune n’est calculée pour une requête. Ce que la valeur décrit est la pile cliente qui a négocié la connexion. Que cette pile soit le navigateur de la machine du lecteur dépend entièrement de l’endroit où TLS se termine.

Quand un proxy relaie avec CONNECT, la spécification décrit le proxy comme un transfert aveugle de données dans les deux sens une fois le tunnel ouvert. Dans ce mode, la poignée de main TLS du site se fait avec le navigateur, et le pair TCP du site est le proxy. Quand un proxy termine TLS sur le port 443 puis le réémet, la poignée de main du site appartient au proxy, et celle du navigateur est une connexion séparée que le site ne voit jamais. Les deux dispositions sont courantes et produisent des conclusions opposées à partir de la même observation « JA3 a changé ». L’article sur TLS et HTTP/2 explique comment les valeurs sont assemblées et pourquoi un hachage non trié mesure un ordre que le client ne fixe pas ; la question décisive est plus étroite : identifiez le terminateur avant d’attribuer une poignée de main à un navigateur.

Il existe aussi un piège d’ordre. Un site peut comparer la poignée de main à une version de navigateur déclarée, puis la version déclarée au User-Agent et aux Client Hints, puis le registre de l’adresse au pays déclaré. Ces comparaisons sont des règles distinctes avec des taux d’erreur distincts. Une session qui échoue à l’une n’a pas nécessairement échoué aux autres, et un rapport qui les fusionne en « écart d’empreinte » ne peut pas dire à une équipe quelle règle s’est déclenchée ; JA3 et User-Agent sont deux champs distincts du rapport.

Les données de réputation se situent à côté de ces observations, pas au-dessus. Un site peut tenir des listes qui marquent des plages d’adresses ou des systèmes autonomes et les appliquer avant tout chargement de page. C’est une entrée de politique sur un comportement antérieur attribué à une plage, pas une mesure de la session actuelle, et elle change quand la liste change, pas quand le client change. Une équipe qui répond à un blocage de réputation en ajustant un profil de navigateur traite une décision de liste comme un problème de navigateur.

Ce qu’un profil de navigateur change et ce qu’il ne change pas

Un profil déclaré contrôle des valeurs que le navigateur génère et expose. User-Agent et Client Hints, fuseau horaire et langue, métriques d’écran, sortie canvas et WebGL, énumération des polices, caractéristiques du traitement audio et cohérence entre ces surfaces sont à l’intérieur de cette limite. Un profil peut les garder alignées entre elles et avec un appareil déclaré, ce qui rend une session cohérente. Un exemple concret est la valeur renvoyée par navigator.userAgentData.

L’adresse de sortie est en dehors de cette limite ; --proxy-server choisit cette adresse et le profil ne la change pas. Un profil ne peut pas changer quel système autonome annonce l’adresse, ni le registre du préfixe, ni publier un pointeur inverse, ni faire appartenir une adresse d’hébergement à un FAI grand public. Il ne peut pas non plus changer la route des paquets ni les listes de réputation qu’un site consulte. Quand le problème est l’un de ceux-là, le travail de profil produit une session cohérente en interne et malgré tout classée comme l’adresse est classée.

Cette distinction rend la question résidentielle traitable. Demandez à quelle couche appartient l’observation qui a échoué. Si le site a rejeté la session parce que l’appareil déclaré et les valeurs observées du navigateur divergeaient, la couche du profil est pertinente. S’il l’a rejetée parce que l’adresse se trouve dans une plage d’hébergement, ou parce qu’un pointeur inverse nomme un fournisseur cloud, aucun changement de profil ne déplace ce résultat. Si le site a refusé la requête avant rendu, l’échec peut ne pas concerner l’identité.

Pour les équipes qui exécutent plusieurs contextes via un fournisseur, cohérence des proxies IPv4 et IPv6 couvre les échecs de route qui ressemblent à des problèmes d’identité : une famille qui bascule silencieusement, un résolveur qui répond depuis un autre chemin, une route qui change en cours de session. Ces échecs produisent des observations incohérentes du même navigateur et se diagnostiquent à la couche de route, pas en ajustant un profil.

La même discipline s’applique au compte. L’historique d’un site avec un compte, ses sessions antérieures et les données qu’il détient déjà sont hors de toute couche navigateur et réseau évoquée ici. Une sortie propre ne réinitialise pas l’historique du compte, et une adresse résidentielle ne fait pas se comporter un compte établi comme un compte neuf. Traitez l’état du compte comme une entrée à part, avec son propre propriétaire.

Conclusion pratique

Enregistrez les entrées de classification de sortie avec la tâche : l’adresse, l’enregistrement d’attribution et sa date, le réseau annonceur, la délégation inverse le cas échéant, la fenêtre d’échantillonnage des temps et le terminateur TLS. Nommez ensuite le composant qui détient chacune et la décision qu’elle soutient. Cet enregistrement répond à la question qu’un achat de proxy résidentiel est censé résoudre, et il montre quand la réponse dépend d’un enregistrement plutôt que du navigateur.

Questions fréquentes

Un ASN résidentiel garantit-il qu’un site traite la session comme résidentielle ?

Non. Un ASN identifie le réseau attribué à une organisation. Un site peut pondérer registre, routage, délégation inverse, temps, listes de réputation et comportement de session dans n’importe quelle combinaison, et modifier cette pondération sans préavis. Un registre résidentiel supprime un signal possible ; il ne contrôle pas la décision.

Pourquoi un proxy affiche-t-il un JA3 ou JA4 différent de celui du navigateur derrière lui ?

Parce que la valeur décrit la pile qui a terminé la poignée de main TLS avec le site. Si le proxy termine TLS et ouvre une nouvelle connexion en amont, le site voit la poignée de main du proxy. S’il relaie un tunnel CONNECT, le site voit celle du navigateur. Capturez l’endroit où la poignée de main se termine avant de conclure sur le client.

Un geofeed ou un enregistrement WHOIS peut-il prouver qu’une adresse est une connexion domestique ?

Aucun des deux n’est conçu pour cela. Un geofeed publie la localisation que son opérateur revendique, et la norme demande aux consommateurs de vérifier l’exactitude. Un enregistrement décrit une attribution à une organisation. Les deux peuvent être exacts et ne rien dire sur l’usage d’une ligne d’abonné précise à un instant précis.

Une connexion lente et variable prouve-t-elle une sortie résidentielle ?

Elle prouve quelque chose sur le chemin pendant l’échantillon. Congestion, distance, lien mobile, saut de relais et lien bridé produisent tous de la variation. Sans distribution, fenêtre d’échantillonnage et route, les temps soutiennent une description du chemin, pas une classification du réseau d’accès.

Que doit faire une équipe quand un site bloque une session avec une adresse résidentielle ?

Commencez par l’observation réellement utilisée par le site, si elle est disponible, et rattachez-la à la couche qui la détient. Un refus avant rendu peut être une règle de réputation ou d’accès ; un défi dans la page peut être comportemental ; un rapport d’écart peut nommer les champs comparés. Changer le profil ne traite que la couche navigateur : confirmez la couche en échec avant d’acheter plus de bande passante de sortie.

Sources

• RFC 8805 : format de géolocalisation IP auto-publiée
• RFC 9110 : sémantique HTTP, CONNECT et tunnels
• RFC 1035 : noms de domaine et délégation inverse
• ARIN : protocole d’accès aux données d’enregistrement
• Cloudflare : empreintes JA3 et JA4
• Cloudflare : règles d’accès IP par adresse, ASN ou pays
• Configuration proxy de BotBrowser
• Cohérence d’automatisation de BotBrowser