Configuration proxy du navigateur : guide SOCKS5, HTTP et HTTPS

BotBrowser peut configurer le point de terminaison proxy du navigateur, accepter des identifiants dans une URL proxy et déduire le fuseau horaire, la locale et la langue depuis l'IP publique du proxy. Il ne contrôle pas le routage ou l'authentification du fournisseur, le DNS en amont ni la politique de destination. Traitez ces éléments comme des limites opérationnelles distinctes, puis utilisez la procédure de vérification de sortie proxy de Launcher pour noter ce que deux endpoints contrôlés observent réellement.

TL;DR

• Choisissez SOCKS5H lorsque le DNS doit être résolu via le proxy; utilisez HTTP ou HTTPS selon le fournisseur.
• Utilisez protocol://username:password@host:port et encodez les caractères réservés dans l'URL.
• Vérifiez l'IP publique, le fuseau horaire et la locale observés. N'appliquez une substitution que si la valeur attendue est documentée.
• En cas d'échec du proxy, arrêtez le flux; ne revenez pas silencieusement à une connexion directe.

Sommaire

• Introduction
• Impact sur la vie privée
• Contexte technique
• Configuration et utilisation
• Conclusion pratique

Introduction

Un profil d'empreinte seul ne suffit pas pour une identité de navigateur cohérente. Votre adresse IP, le comportement DNS et les métadonnées géographiques doivent tous s'aligner avec l'identité que votre profil présente. Si votre profil dit "utilisateur Windows à Berlin" mais que votre IP résout vers un centre de données en Virginie, l'incohérence est évidente.

BotBrowser fournit un support proxy amélioré intégré directement dans le moteur du navigateur. Contrairement au Chromium standard, BotBrowser accepte les identifiants intégrés dans les URL de proxy, dérive automatiquement les paramètres géographiques de votre IP de proxy, et prend en charge les protocoles SOCKS5, SOCKS5H, HTTP, HTTPS et QUIC lorsque le navigateur/client, le contexte autorisé et le fournisseur proxy les prennent en charge. La prise en charge de QUIC ne garantit pas la réussite de HTTP/3, ne fournit pas de repli vers une connexion directe et ne contrôle pas la route amont du fournisseur.

Impact sur la vie privée

Sans un proxy correctement configuré, votre véritable adresse IP est visible pour chaque site que vous visitez. Les adresses IP révèlent votre FAI, votre emplacement physique approximatif et peuvent être corrélées entre les sessions pour construire un profil de pistage persistant.

Même lors de l'utilisation d'un proxy, les mauvaises configurations peuvent compromettre votre vie privée. Les requêtes DNS peuvent fuiter en dehors du tunnel proxy, révélant votre activité de navigation à votre FAI. Les candidats ICE WebRTC peuvent exposer votre véritable IP via des requêtes STUN qui voyagent en dehors du chemin proxy. Les incohérences de fuseau horaire et de locale entre votre identité déclarée et la géolocalisation de votre IP créent des incohérences que les systèmes de pistage peuvent signaler.

--proxy-server configure la route proxy demandée par le navigateur; il ne vérifie ni DNS, ni WebRTC, ni la politique du fournisseur ou l'autorisation de destination. Si la détection de l'IP publique réussit, BotBrowser peut en dériver le fuseau horaire, la locale et la langue. Comparez ces valeurs visibles dans la page au relevé de route du fournisseur; elles ne prouvent pas une présence physique.

Contexte technique

Comment fonctionne le proxy de navigateur

Lorsqu'un navigateur utilise un proxy, le trafic HTTP et HTTPS est transmis via le serveur proxy au lieu de se connecter directement à la destination. La destination voit l'adresse IP du proxy, pas la vôtre.

Différents protocoles proxy gèrent cela différemment :

SOCKS5 transmet les connexions via un proxy. La résolution DNS locale ou côté proxy dépend du client et du schéma; vérifiez le résolveur avec le test approuvé par le fournisseur, sans le déduire d'une page chargée.

Les proxys HTTP utilisent la méthode CONNECT pour établir un tunnel pour le trafic HTTPS. Le proxy voit le nom d'hôte de destination mais pas le contenu chiffré. Les proxys HTTP ne gèrent pas le trafic UDP.

Les proxys HTTPS chiffrent la connexion entre votre navigateur et le serveur proxy lui-même. Cela empêche votre FAI de voir quelles commandes proxy vous envoyez, ajoutant une couche de confidentialité à la connexion proxy.

Gestion des identifiants

Le Chromium standard avec --proxy-server n'accepte que l'adresse du proxy sans identifiants. L'authentification nécessite une gestion séparée via des invites système ou des API spécifiques au framework comme page.authenticate().

BotBrowser étend --proxy-server pour accepter les identifiants intégrés directement dans l'URL :

protocol://username:password@host:port

Cela peut éviter une invite d'authentification séparée en gardant le point de terminaison proxy et les identifiants dans une seule valeur URL.

Types de proxy supportés et configuration

BotBrowser supporte cinq protocoles proxy via le flag --proxy-server :

Protocole	Format URL	Cas d'usage
SOCKS5	socks5://user:pass@host:port	Usage général, trafic TCP
SOCKS5H	socks5h://user:pass@host:port	Résolution DNS dans le tunnel
HTTP	http://user:pass@host:port	Largement disponible, trafic HTTP/HTTPS
HTTPS	https://user:pass@host:port	Connexion proxy chiffrée
QUIC	quic://user:pass@host:port	Seulement si le client et le fournisseur prennent QUIC en charge

La route quic:// n'est disponible que lorsque le navigateur/client et le fournisseur proxy prennent en charge les opérations QUIC requises. BotBrowser ne fournit pas automatiquement un service QUIC, ne peut pas forcer une origine à utiliser HTTP/3 et ne contrôle pas la route amont du fournisseur.

SOCKS5 vs. SOCKS5H

La différence entre socks5:// et socks5h:// est importante. Avec socks5://, la résolution DNS se fait localement sur votre machine avant que la connexion ne soit envoyée via le proxy. Avec socks5h://, le nom d'hôte est envoyé au serveur proxy, qui résout le DNS pour vous. Pour la vie privée, socks5h:// est le meilleur choix car il empêche les requêtes DNS de fuiter vers votre résolveur local.

Noms d'utilisateur proxy structurés

Certains fournisseurs encodent des paramètres de routage dans le nom d'utilisateur avec des séparateurs comme des virgules ou des barres verticales. BotBrowser prend en charge ces noms d'utilisateur structurés :

--proxy-server=socks5://user_abc,type_mobile,country_GB,session_1234:[email protected]:1080

C'est courant chez les fournisseurs de proxys résidentiels qui acheminent le trafic selon des paramètres intégrés aux identifiants. BotBrowser transmet cette valeur au fournisseur ; sa signification et sa validation restent de son ressort.

L'approche de BotBrowser pour l'intégration proxy

Alignement géographique automatique

Lorsque BotBrowser se connecte via un proxy, il détecte l'IP publique du proxy et configure automatiquement :

• Fuseau horaire : dérivé de la géolocalisation de l'IP
• Locale : correspondant au pays du proxy
• Langues : définies en fonction de la région du proxy
• Géolocalisation : coordonnées approximées depuis l'IP

Cela signifie qu'un lancement basique avec juste --proxy-server produit déjà une identité géographiquement cohérente :

chrome --bot-profile="path/to/profile.enc" \
       --proxy-server=socks5://user:pass@de-proxy:1080

BotBrowser détectera l'IP allemande et définira le fuseau horaire à Europe/Berlin, la locale à de-DE et les langues à de-DE,de,en automatiquement.

Substitutions géographiques manuelles

Lorsque vous avez besoin de paramètres géographiques spécifiques qui diffèrent de ce que l'IP suggère :

chrome --bot-profile="path/to/profile.enc" \
       --proxy-server=socks5://user:pass@proxy:1080 \
       --bot-timezone=America/New_York \
       --bot-locale=en-US \
       --bot-languages=en-US,en \
       --bot-location=40.7128,-74.0060

Sauter la recherche IP avec --proxy-ip

Si vous connaissez déjà l'IP publique de votre proxy, vous pouvez sauter la recherche IP automatique lors de la première navigation avec le flag --proxy-ip (ENT Tier1) :

chrome --bot-profile="path/to/profile.enc" \
       --proxy-server=socks5://user:pass@proxy:1080 \
       --proxy-ip="203.0.113.1"

--proxy-ip accepte une adresse IPv4, une adresse IPv6, ou une paire IPv4 et IPv6 séparée par une virgule. Utilisez une paire lorsque le proxy a des identités de sortie IPv4 et IPv6 distinctes :

--proxy-ip="203.0.113.1,2001:db8::1009"

Limites de routage et échec fermé

Conservez le trafic prévu du navigateur sur le chemin proxy configuré, sauf si une politique réseau approuvée définit une autre route. Ce guide ne fournit pas d'instructions pour contourner un proxy ou affaiblir un contrôle. Si le proxy est indisponible, consignez l'échec et arrêtez le flux au lieu de revenir à une connexion directe.

Configuration et utilisation

Configuration Playwright de base

const { chromium } = require('playwright-core');

(async () => {
  const browser = await chromium.launch({
    executablePath: 'path/to/botbrowser/chrome',
    args: ['--bot-profile=path/to/profile.enc', '--proxy-server=socks5://user:pass@proxy-host:1080'],
    headless: true,
  });

  const context = await browser.newContext();
  const page = await context.newPage();
  await page.goto('https://example.com');
  await browser.close();
})();

Configuration Puppeteer avec substitutions géographiques

const puppeteer = require('puppeteer-core');

(async () => {
  const browser = await puppeteer.launch({
    executablePath: 'path/to/botbrowser/chrome',
    args: [
      '--bot-profile=path/to/profile.enc',
      '--proxy-server=socks5://user:pass@de-proxy:1080',
      '--bot-timezone=Europe/Berlin',
      '--bot-locale=de-DE',
      '--bot-languages=de-DE,de,en',
    ],
    headless: true,
    defaultViewport: null,
  });

  const page = await browser.newPage();
  await page.goto('https://example.com');
  await browser.close();
})();

Configurations régionales courantes

Région	Fuseau horaire	Locale	Langues
US Est	America/New_York	en-US	en-US,en
US Ouest	America/Los_Angeles	en-US	en-US,en
Royaume-Uni	Europe/London	en-GB	en-GB,en
Allemagne	Europe/Berlin	de-DE	de-DE,de,en
Japon	Asia/Tokyo	ja-JP	ja,en
Brésil	America/Sao_Paulo	pt-BR	pt-BR,pt,en
Corée du Sud	Asia/Seoul	ko-KR	ko-KR,ko,en

Service personnalisé de détection IP

Si vous utilisez votre propre point de terminaison, configurez --bot-ip-service avec une URL HTTPS approuvée. Vérifiez sa disponibilité et sa politique de conservation avec l'équipe réseau; BotBrowser ne valide pas le fournisseur ni ses données de géolocalisation.

chrome --bot-profile="path/to/profile.enc" \
       --proxy-server=socks5://user:pass@proxy:1080 \
       --bot-ip-service="https://ip.example.com"

Plusieurs points de terminaison peuvent être séparés par des virgules; utilisez uniquement des services approuvés et documentez le propriétaire de la résolution IP.

--bot-ip-service="https://ip1.example.com,https://ip2.example.com"

Vérification

Après le lancement de BotBrowser avec un proxy, vérifiez votre configuration :

const page = await context.newPage();

// Vérifier l'IP publique
await page.goto('https://httpbin.org/ip');
const ipData = await page.textContent('body');
console.log('Public IP:', ipData);

// Vérifier le fuseau horaire
const tz = await page.evaluate(() => Intl.DateTimeFormat().resolvedOptions().timeZone);
console.log('Timezone:', tz);

// Vérifier la langue
const lang = await page.evaluate(() => navigator.language);
console.log('Language:', lang);

Confirmez que :

1. L'IP correspond à l'adresse attendue de votre proxy
2. Le fuseau horaire s'aligne avec la région géographique du proxy
3. La langue et la locale sont cohérentes avec le fuseau horaire
4. Aucune fuite DNS n'est visible

Choisissez le prochain diagnostic selon l'observation en échec. Un résultat visible dans le navigateur précise la question, mais chaque couche réseau doit être vérifiée séparément.

Observation	Ce qu'elle établit	Vérification suivante
L'IP de sortie diffère du relevé de route	Le point de sortie observé et la route attendue divergent	Comparez le proxy configuré, la famille d'adresses et l'étiquette de session du fournisseur
L'IP correspond, mais le fuseau ou la locale diffère	Les valeurs visibles du navigateur diffèrent du profil attendu	Vérifiez les substitutions --bot-timezone et --bot-locale
La page se charge, mais le propriétaire DNS est inconnu	La requête a renvoyé du contenu; le chemin du résolveur n'est pas vérifié	Lancez le test DNS approuvé par le fournisseur et notez le résolveur
CONNECT réussit, mais TLS échoue	Le tunnel proxy a répondu; TLS de destination a échoué	Vérifiez séparément le certificat et la politique TLS de destination

Lecture de la limite réseau

Le proxy modifie le chemin demandé par le navigateur, mais ne prouve pas la politique du fournisseur ou de la destination. Séparez l'IP observée, le résolveur DNS et le résultat applicatif dans vos vérifications.

Le proxy modifie le chemin des requêtes du navigateur, mais ne prouve ni la politique du fournisseur ni celle de la destination. Avec socks5://, le résolveur local peut résoudre le nom avant l'entrée dans le proxy; avec socks5h://, le nom est envoyé au proxy pour résolution. --bot-local-dns sélectionne la gestion DNS locale de BotBrowser; il ne transforme pas socks5:// en socks5h:// et ne contrôle pas le résolveur amont du fournisseur. Pour un sujet voisin sur les limites du réseau, consultez Protection contre le sondage des ports locaux par le navigateur.

WebRTC peut recueillir des candidats ICE via d'autres services réseau. Un contrôle au niveau de la page montre ce que cette page voit, sans certifier chaque hôte, VPN ou équipement du fournisseur. CORS est une autre couche: le navigateur peut bloquer l'exposition d'une réponse même si le proxy a atteint le serveur. Pour HTTPS, distinguez le tunnel navigateur-proxy de la connexion proxy-destination: CONNECT prouve l'accès et l'authentification de cette requête, pas le certificat de destination ni sa politique TLS.

Les identifiants intégrés à l'URL sont une commodité de configuration. Masquez les mots de passe dans les journaux et faites-les tourner selon le processus du fournisseur. La vérification décrit seulement ce qui a été observé: une IP de sortie ne prouve pas l'autorisation d'un compte, un fuseau ne prouve pas une présence physique et une page chargée ne prouve pas que chaque requête a suivi le même chemin. Conservez navigateur, protocole, IP, résolveur, fuseau, locale, heure et résultat, sous réserve du fournisseur et du test effectué.

Bonnes pratiques

1. Choisissez explicitement la route DNS. socks5h:// demande la résolution du nom côté proxy; --bot-local-dns sélectionne la gestion DNS locale de BotBrowser, sans contrôler le résolveur amont du fournisseur.

2. Vérifiez la géographie dérivée. Comparez le fuseau horaire et la locale visibles dans la page au relevé du fournisseur avant de vous y fier.

3. Encodez les caractères spéciaux dans les mots de passe en URL. Les caractères comme @, # et % doivent être encodés. Par exemple, p@ss devient p%40ss.

4. Déclarez la propriété du DNS. --bot-local-dns sélectionne la gestion locale de BotBrowser; aucun flag ne contrôle le résolveur amont du fournisseur.

5. Testez d'abord avec curl. Avant de configurer BotBrowser, vérifiez la connectivité proxy : curl --proxy socks5://user:pass@host:port https://httpbin.org/ip.

6. Utilisez --proxy-ip quand l'IP est connue. Cela élimine la recherche IP lors de la première navigation et accélère le démarrage.

Questions fréquentes

Quel protocole proxy dois-je utiliser ?

SOCKS5H est recommandé pour la plupart des cas d'usage. Il supporte le trafic TCP, gère la résolution DNS via le proxy et fonctionne avec le plus large éventail de fournisseurs de proxy.

Puis-je utiliser un proxy qui nécessite une liste blanche d'IP ?

Oui. Assurez-vous que l'IP de votre machine est sur la liste blanche du fournisseur de proxy, puis utilisez l'URL du proxy sans identifiants si le fournisseur authentifie par IP.

BotBrowser supporte-t-il le chaînage de proxy ?

BotBrowser se connecte au proxy spécifié dans --proxy-server. Si vous avez besoin de chaînage de proxy, configurez-le côté infrastructure proxy.

Pourquoi mon fuseau horaire ne correspond-il pas à l'emplacement de mon proxy ? Si vous avez défini --bot-timezone manuellement, cela substitue la détection automatique. Retirez la substitution manuelle pour laisser BotBrowser dériver le fuseau horaire depuis l'IP du proxy.

Puis-je utiliser des proxys différents pour des onglets différents ? Oui. Utilisez le browser.newContext({ proxy: ... }) de Playwright pour assigner différents proxys par contexte; consignez chaque changement de route.

Que se passe-t-il si la connexion proxy échoue ? BotBrowser ne se rabattra pas sur une connexion directe. Si le proxy est injoignable, les chargements de page échoueront, ce qui est le comportement le plus sûr pour la vie privée.

Ce que BotBrowser fournit

BotBrowser intègre les identifiants du serveur proxy directement dans le flag --proxy-server et configure automatiquement le fuseau horaire, la locale et la langue à partir de l'adresse IP publique du serveur proxy, éliminant le besoin d'API d'authentification séparées et de configuration géographique manuelle. Cependant, BotBrowser ne peut pas contrôler comment le fournisseur du serveur proxy achemine le trafic, vérifier la précision de la base de données IP-vers-emplacement du fournisseur, authentifier les identifiants sur l'infrastructure du fournisseur, ou gérer le comportement DNS et WebRTC en dehors du tunnel navigateur-serveur proxy. La détection automatique de la géographie dépend entièrement de la précision de la base de données IP du fournisseur; si la détection échoue ou ne correspond pas à votre identité prévue, des remplacements géographiques manuels utilisant les flags --bot-timezone, --bot-locale et --bot-languages sont nécessaires.

Sources publiques

• W3C : WebRTC
• MDN : serveurs proxy et tunneling
• MDN : en-tête Proxy-Authorization

Conclusion pratique

La configuration proxy est une composante de la cohérence d'identité du navigateur. BotBrowser simplifie les identifiants, fournit des signaux d'alignement géographique et prend en charge SOCKS5, SOCKS5H, HTTP, HTTPS et QUIC lorsque le navigateur/client, le contexte autorisé et le fournisseur proxy les prennent en charge. La prise en charge de QUIC ne garantit pas la réussite de HTTP/3, ne fournit pas de repli vers une connexion directe et ne contrôle pas la route amont du fournisseur. Avec un profil documenté et des vérifications du fournisseur, elle aide à aligner IP, fuseau, locale et langue; le résultat dépend du fournisseur et des tests.

Pour les workflows multi-proxy, voir Dynamic Proxy Switching. Appliquez séparément les politiques documentées pour DNS et WebRTC.