BotBrowser Launcher : configurer le proxy et vérifier l’IP de sortie

BotBrowser Launcher peut démarrer un profil autorisé avec un proxy déclaré, mais il ne peut pas réparer la route d’un fournisseur ni prouver qu’une IP appartient à une personne. Cet article ajoute une vérification répétable de l’IP de sortie au guide BotBrowser Launcher, au lieu de répéter la présentation du démarrage.

BotBrowser Launcher prend en charge le démarrage d’un profil autorisé avec un proxy configuré et l’enregistrement de la route observée ; il ne garantit ni la disponibilité du fournisseur, ni l’anonymat, ni une IP de destination précise.

TL;DR

• Saisissez le point de terminaison dans Launcher et notez le protocole effectif avec un libellé sans secret.
• Vérifiez l’IP publique depuis une page contrôlée, puis comparez-la avec un second service indépendant.
• Traitez DNS, WebRTC, fuseau horaire et langue comme des observations distinctes.
• Ne mettez jamais les identifiants dans une capture ou un JSON. Un échec décrit une configuration ou un fournisseur, pas une identité.

Sommaire

• Ce que cet article ajoute
• Exécuter la vérification de sortie
• Conserver un petit artefact
• Diagnostiquer un écart
• Conclusion

Ce que cet article ajoute

Le guide Launcher décrit les profils, le démarrage et la forme générale d’une URL de proxy. La question opérationnelle est plutôt de savoir quel endpoint le navigateur a réellement utilisé. Une requête contrôlée et datée y répond. Elle ne remplace pas les différences de protocole de la configuration proxy ni la vérification des familles d’adresses de la cohérence IPv4 et IPv6.

Utilisez un profil temporaire neuf pour le premier essai. Donnez-lui un identifiant comme proxy-check-20261016-01 et notez version, système, protocole et cycle du profil. Le libellé décrit l’essai, pas un utilisateur.

Exécuter la vérification de sortie

1. Dans Launcher, choisissez le profil et saisissez un endpoint masqué, par exemple socks5h://user:***@proxy.example.test:1080.
2. Ouvrez une page HTTPS d’écho que vous contrôlez et notez l’adresse publique, la famille, l’heure et le statut HTTP.
3. Ouvrez un second endpoint dans le même contexte. Une différence peut venir de la route ou de la famille d’adresses ; elle ne prouve pas quel service est fautif.
4. Vérifiez sur votre endpoint si un nom de test est résolu par le proxy, localement ou de manière inconnue.
5. Comparez langue et fuseau observés avec la région attendue avant de modifier le profil.

Conservez un tableau avec Écho A, Écho B, limite DNS, résultat WebRTC et langue. Chaque ligne doit préciser l’observation permise et sa limite.

Conserver un petit artefact

{
  "runId": "proxy-check-20261016-01",
  "browser": "Chrome 155.0.8059.80",
  "hostOs": "macOS 15",
  "profile": "fresh-temporary",
  "protocol": "socks5h",
  "echoA": { "status": 200, "family": "ipv6" },
  "echoB": { "status": 200, "family": "ipv6" },
  "dns": "proxy-side",
  "webrtc": "no-public-candidate",
  "localeMatch": true,
  "testedOn": "2026-10-16"
}

Ce relevé exclut identifiants, cookies et données complètes du resolver. Il ne décrit que le fixture nommé. Pour les détails de protocole, consultez la configuration proxy et la cohérence des proxys IPv4 et IPv6.

Diagnostiquer un écart

Si les deux échos montrent l’adresse de l’hôte, vérifiez le schéma et le port enregistrés par Launcher, puis répétez avec un profil neuf. Si un seul service diffère, comparez sa chaîne de redirection et sa famille d’adresses. Si DNS est local avec socks5h, confirmez le support du fournisseur avant de changer le navigateur.

Si WebRTC expose un candidat public, notez le navigateur et la route exacts. Une préférence ICE ne réécrit pas la route amont du fournisseur. Si la langue ou le fuseau diffère, conservez cette différence et décidez quelle source fait autorité pour l’essai.

Ne publiez pas d’identifiants proxy ni de traces de trafic. Timeout, authentification refusée et repli direct ont des responsables différents ; l’artefact doit le montrer sans conserver de secret.

Conclusion

La configuration Launcher devient vérifiable avec une IP observée, deux réponses d’écho, la limite DNS, le résultat WebRTC et le profil qui a produit la mesure. C’est une observation limitée d’un parcours autorisé, pas une promesse d’anonymat ni de contrôle du fournisseur.

Sources publiques

• Proxies et tunnels (MDN)
• WebRTC (W3C)
• DNS sur HTTPS (RFC 8484)