Réseau25 mars 2026

UDP sur SOCKS5 : Tunneliser le trafic QUIC et STUN pour prevenir les fuites d'IP

Guide complet sur le tunneling UDP via proxy SOCKS5. Decouvrez comment le trafic QUIC et WebRTC STUN peut exposer votre veritable IP, et comment BotBrowser tunnelise automatiquement l'UDP via SOCKS5.

Introduction

La plupart des configurations de proxy se concentrent sur le trafic TCP. HTTP, HTTPS et les requetes web standard utilisent TCP, et tous les protocoles de proxy les gerent bien. Mais les navigateurs modernes n'utilisent pas exclusivement TCP. Deux protocoles critiques, QUIC (HTTP/3) et WebRTC STUN, reposent sur UDP. Quand votre proxy ne gere que le TCP, ces paquets UDP voyagent directement de votre machine vers leur destination, completement en dehors du tunnel proxy. Le resultat : votre veritable adresse IP fuit via le trafic UDP alors que votre trafic TCP est securise par le proxy.

Ce n'est pas un risque theorique. Chrome utilise QUIC par defaut pour les connexions aux services Google, YouTube et tout site supportant HTTP/3. Les requetes WebRTC STUN utilisent UDP pour decouvrir votre adresse IP publique pour les connexions pair-a-pair. Ces deux protocoles revelent activement votre veritable IP s'ils ne sont pas routes via votre proxy.

BotBrowser comble cette lacune avec un support automatique d'UDP sur SOCKS5. Quand votre proxy SOCKS5 supporte UDP ASSOCIATE, BotBrowser tunnelise automatiquement le trafic QUIC et STUN a travers lui. Quand il ne le supporte pas, BotBrowser bascule elegamment vers des alternatives basees sur TCP sans modification de configuration.

Impact sur la vie privee

Les implications du trafic UDP non protege sur la vie privee sont significatives. Considerez ce qui se passe quand vous configurez un navigateur standard avec un proxy SOCKS5 :

Le trafic QUIC/HTTP/3 divulgue votre IP aux serveurs de destination. Quand Chrome se connecte a un site supportant HTTP/3, il tente une connexion QUIC via UDP. Si le proxy ne gere que le TCP, cette connexion QUIC passe en direct. Le serveur de destination voit votre veritable adresse IP sur les paquets QUIC, meme si votre trafic de repli HTTP/2 passe par le proxy. Les services Google, YouTube, les sites heberges par Cloudflare et de nombreuses autres plateformes majeures supportent QUIC.

Les requetes WebRTC STUN exposent votre IP publique. STUN (Session Traversal Utilities for NAT) est un protocole base sur UDP qui decouvre votre adresse IP publique. Quand du JavaScript sur une page cree un RTCPeerConnection, le navigateur envoie des requetes de liaison STUN aux serveurs STUN. Ces paquets UDP passent en dehors du chemin du proxy TCP, et le serveur STUN renvoie votre veritable IP publique. N'importe quel site peut collecter cette information via l'API WebRTC sans permission de l'utilisateur.

L'incoherence elle-meme est un signal. Si un systeme de suivi observe que votre trafic HTTP provient d'une IP (le proxy) mais que votre trafic QUIC ou STUN revele une IP differente (la votre), la discordance indique clairement l'utilisation d'un proxy. Cette incoherence peut etre plus dommageable pour la vie privee que de ne pas utiliser de proxy du tout.

Contexte technique

QUIC (HTTP/3) : Protocole web base sur UDP

QUIC est le protocole de transport derriere HTTP/3. Contrairement a HTTP/2, qui fonctionne sur TCP, QUIC utilise UDP pour reduire la latence de connexion et ameliorer les performances. Chrome utilise QUIC par defaut quand le serveur le supporte. Les principales plateformes, dont Google Search, YouTube, Gmail, Google Cloud et tous les sites heberges par Cloudflare, supportent QUIC.

Quand un navigateur envoie un paquet QUIC, c'est un datagramme UDP. Les configurations de proxy standard qui ne gerent que les connexions TCP n'interceptent pas ce trafic. Le paquet QUIC va directement de votre machine au serveur de destination, portant votre veritable IP dans l'adresse source.

STUN (WebRTC) : Decouverte d'IP basee sur UDP

STUN est un protocole qui aide les appareils derriere un NAT a decouvrir leur adresse IP publique. Les navigateurs utilisent STUN dans le cadre du processus ICE (Interactive Connectivity Establishment) de WebRTC. Quand du JavaScript cree un RTCPeerConnection, le navigateur envoie une requete de liaison STUN (UDP) a un serveur STUN. Le serveur repond avec l'adresse IP publique qu'il observe.

C'est une fonctionnalite deliberee de WebRTC, pas un bug. Mais du point de vue de la vie privee, cela signifie que n'importe quelle page web peut decouvrir votre veritable IP publique en initiant une requete STUN, meme quand tout votre trafic HTTP passe par un proxy.

UDP ASSOCIATE : Le relais UDP de SOCKS5

Le protocole SOCKS5 (RFC 1928) definit trois types de commandes :

CONNECT (0x01) : Etablit une connexion TCP a travers le proxy. C'est ce que la plupart des outils utilisent.
BIND (0x02) : Configure un ecouteur TCP sur le proxy pour les connexions entrantes.
UDP ASSOCIATE (0x03) : Etablit un relais UDP a travers le proxy.

UDP ASSOCIATE est la cle pour tunneliser le trafic UDP. Voici comment cela fonctionne :

Le client envoie une requete UDP ASSOCIATE au proxy SOCKS5 via TCP
Le proxy alloue un point de relais UDP et renvoie son adresse
Le client envoie des paquets UDP a ce point de relais, enveloppes dans un en-tete UDP SOCKS5
Le proxy desenveloppe l'en-tete et transmet le paquet UDP a la destination prevue
Les reponses de la destination reviennent par le relais du proxy

Le serveur de destination voit des paquets UDP provenant de l'IP du proxy, pas de votre machine. Le trafic QUIC et STUN peuvent tous deux utiliser ce mecanisme.

Le flux complet

Quand UDP sur SOCKS5 fonctionne correctement, le flux complet ressemble a ceci :

Negociation : BotBrowser etablit une connexion TCP au proxy SOCKS5 et s'authentifie
Requete UDP ASSOCIATE : BotBrowser envoie une commande UDP ASSOCIATE pour demander un relais UDP
Allocation du relais : Le proxy cree un relais UDP et renvoie l'adresse du relais
Tunnelisation : Tout le trafic UDP (QUIC, STUN) est envoye via le relais avec encapsulation SOCKS5
Candidats ICE : Les reponses STUN de WebRTC renvoient l'IP du proxy, donc les candidats ICE refletent l'identite du proxy

Approche de BotBrowser

Detection automatique d'UDP ASSOCIATE

BotBrowser detecte automatiquement si votre proxy SOCKS5 supporte UDP ASSOCIATE. Aucun drapeau ni configuration supplementaire n'est necessaire. Quand vous specifiez un proxy SOCKS5 avec --proxy-server, BotBrowser :

Etablit la connexion de controle TCP au proxy
Envoie une requete UDP ASSOCIATE pour tester le support UDP
Si le proxy accepte, BotBrowser cree le tunnel de relais UDP
Si le proxy refuse (ou ne supporte pas UDP ASSOCIATE), BotBrowser bascule vers des alternatives TCP

Cette detection se fait de maniere transparente pendant l'initialisation du proxy.

Trafic QUIC a travers le tunnel

Quand UDP ASSOCIATE est disponible, le trafic QUIC se route automatiquement a travers le tunnel UDP SOCKS5. L'implementation QUIC de Chrome traite le tunnel comme son chemin reseau, donc les connexions QUIC vers Google, YouTube, Cloudflare et d'autres serveurs HTTP/3 utilisent toutes l'IP du proxy.

Cela signifie que vous beneficiez des avantages de performance de QUIC (latence reduite, meilleure migration de connexion, reduction du blocage en tete de file) tout en maintenant une identite IP coherente.

WebRTC STUN a travers le tunnel

Les requetes de liaison STUN passent egalement par le tunnel UDP. Quand une page initie WebRTC et que le navigateur envoie des requetes STUN, ces paquets UDP passent par le relais SOCKS5. Le serveur STUN voit l'adresse IP du proxy et la renvoie comme candidat reflexif du serveur. Les candidats ICE generes par WebRTC refletent l'IP du proxy, pas votre veritable IP.

Cela offre la meme protection que --bot-webrtc-ice mais par un mecanisme different : au lieu de controler la generation des candidats ICE au niveau du moteur, les requetes STUN elles-memes transitent par le proxy.

Repli elegant quand UDP n'est pas disponible

Tous les proxies SOCKS5 ne supportent pas UDP ASSOCIATE. De nombreux fournisseurs de proxy residentiels et certains proxies commerciaux ne gerent que TCP CONNECT. Quand BotBrowser detecte que UDP ASSOCIATE n'est pas disponible, il bascule elegamment :

QUIC bascule vers HTTP/2 sur TCP. Chrome a deja ce repli integre. Quand QUIC n'est pas disponible (ou quand UDP est bloque), Chrome utilise HTTP/2 sur la connexion TCP du proxy. Il n'y a aucune perte de fonctionnalite. Les pages chargent le meme contenu, juste avec un transport TCP.

STUN peut etre controle avec --bot-webrtc-ice. Si les requetes STUN UDP ne peuvent pas passer par le proxy, utilisez le drapeau --bot-webrtc-ice pour controler la generation des candidats ICE au niveau du moteur :

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

Cela garantit que les candidats ICE WebRTC affichent l'IP du proxy quel que soit le support UDP.

Configuration et utilisation

Configuration CLI de base

La configuration la plus simple ne necessite que --proxy-server avec un proxy SOCKS5 :

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

Si le proxy supporte UDP ASSOCIATE, le trafic QUIC et STUN sera automatiquement tunnelise. Aucun drapeau supplementaire n'est necessaire.

Configuration complete de confidentialite

Pour une protection reseau complete, combinez avec les controles DNS et WebRTC :

chrome --bot-profile="/path/to/profile.enc" \
       --proxy-server="socks5://user:pass@proxy:1080" \
       --bot-local-dns \
       --bot-webrtc-ice="google"

Cette configuration couvre toutes les voies de fuite reseau : le trafic TCP via le proxy, le trafic UDP via UDP ASSOCIATE (ou repli), le DNS via la resolution locale, et WebRTC via les candidats ICE controles.

Integration Playwright

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:1080',
      '--bot-local-dns',
      '--bot-webrtc-ice=google',
    ],
    headless: true,
  });

  const context = await browser.newContext();
  const page = await context.newPage();
  await page.goto('https://www.youtube.com');

  // Le trafic QUIC vers YouTube passe par le tunnel UDP
  // Les requetes STUN passent par le tunnel UDP
  // Tout le trafic utilise l'IP du proxy

  await browser.close();
})();

Integration Puppeteer

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@proxy:1080',
      '--bot-local-dns',
      '--bot-webrtc-ice=google',
    ],
    headless: true,
    defaultViewport: null,
  });

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

Proxy par contexte avec Playwright

Pour gerer plusieurs identites, chaque contexte de navigateur peut utiliser un proxy SOCKS5 different avec un tunneling UDP independant :

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

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

  // Contexte 1 : Proxy US avec support UDP
  const context1 = await browser.newContext({
    proxy: {
      server: 'socks5://user1:pass1@us-proxy:1080',
    },
  });

  // Contexte 2 : Proxy DE avec support UDP
  const context2 = await browser.newContext({
    proxy: {
      server: 'socks5://user2:pass2@de-proxy:1080',
    },
  });

  const page1 = await context1.newPage();
  const page2 = await context2.newPage();

  await page1.goto('https://example.com');
  await page2.goto('https://example.com');

  await browser.close();
})();

Verification du tunneling UDP

Pour confirmer que le trafic UDP passe par le tunnel du proxy, verifiez les comportements QUIC et WebRTC :

const page = await context.newPage();

// 1. Verifier que l'IP HTTP correspond au proxy
await page.goto('https://httpbin.org/ip');
const httpIp = await page.textContent('body');
console.log('IP HTTP :', httpIp);

// 2. Verifier les candidats ICE WebRTC avec l'IP du proxy
const candidates = await page.evaluate(() => {
  return new Promise((resolve) => {
    const ips = [];
    const pc = new RTCPeerConnection({
      iceServers: [{ urls: 'stun:stun.l.google.com:19302' }]
    });
    pc.createDataChannel('test');
    pc.onicecandidate = (e) => {
      if (e.candidate) {
        const match = e.candidate.candidate.match(
          /([0-9]{1,3}\.){3}[0-9]{1,3}/
        );
        if (match) ips.push(match[0]);
      } else {
        resolve(ips);
      }
    };
    pc.createOffer().then(o => pc.setLocalDescription(o));
  });
});
console.log('IPs des candidats ICE :', candidates);

// Les deux doivent afficher l'IP du proxy, pas votre IP reelle

Scenarios courants

Scenario 1 : Proxy SOCKS5 avec support UDP

C'est la configuration ideale. Votre proxy SOCKS5 supporte UDP ASSOCIATE, et BotBrowser tunnelise automatiquement tout le trafic.

Type de trafic	Chemin	Resultat
HTTP/HTTPS (TCP)	Navigateur -> Proxy -> Destination	IP du proxy visible
QUIC/HTTP/3 (UDP)	Navigateur -> Relais UDP du Proxy -> Destination	IP du proxy visible
STUN (UDP)	Navigateur -> Relais UDP du Proxy -> Serveur STUN	IP du proxy retournee
DNS	Controle par --bot-local-dns	Pas de fuite

Configuration :

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

Scenario 2 : Proxy SOCKS5 sans support UDP

De nombreux proxies SOCKS5, en particulier les residentiels, ne supportent que TCP CONNECT. BotBrowser le detecte et bascule automatiquement.

Type de trafic	Chemin	Resultat
HTTP/HTTPS (TCP)	Navigateur -> Proxy -> Destination	IP du proxy visible
QUIC/HTTP/3	Bascule vers HTTP/2 sur TCP	IP du proxy visible
STUN (UDP)	Controle par --bot-webrtc-ice	IP du proxy dans les candidats
DNS	Controle par --bot-local-dns	Pas de fuite

Configuration :

chrome --bot-profile="/path/to/profile.enc" \
       --proxy-server="socks5://user:pass@proxy:1080" \
       --bot-webrtc-ice="google" \
       --bot-local-dns

Le drapeau --bot-webrtc-ice assure la protection WebRTC meme sans tunneling UDP.

Scenario 3 : Proxy HTTP/HTTPS (pas de support UDP)

Les proxies HTTP et HTTPS utilisent la methode CONNECT pour le tunneling TCP. Ils ne supportent pas du tout l'UDP. BotBrowser gere cela de la meme maniere qu'un proxy SOCKS5 sans support UDP.

Type de trafic	Chemin	Resultat
HTTP/HTTPS (TCP)	Navigateur -> Proxy (CONNECT) -> Destination	IP du proxy visible
QUIC/HTTP/3	Bascule vers HTTP/2 sur TCP	IP du proxy visible
STUN (UDP)	Controle par --bot-webrtc-ice	IP du proxy dans les candidats
DNS	Controle par --bot-local-dns	Pas de fuite

Configuration :

chrome --bot-profile="/path/to/profile.enc" \
       --proxy-server="http://user:pass@proxy:8080" \
       --bot-webrtc-ice="google" \
       --bot-local-dns

Bonnes pratiques

Utilisez des proxies SOCKS5 avec support UDP quand c'est possible. Cela offre la protection la plus complete avec le minimum de configuration. Le trafic QUIC et STUN est tunnelise automatiquement.
Ajoutez toujours --bot-webrtc-ice comme filet de securite. Meme avec le tunneling UDP, le drapeau --bot-webrtc-ice fournit une couche supplementaire de protection WebRTC au cas ou le tunnel UDP serait interrompu.
Combinez avec --bot-local-dns pour une couverture complete. Le tunneling UDP, le controle WebRTC et la prevention des fuites DNS ferment ensemble toutes les principales voies de fuite reseau.
Testez le support UDP de votre proxy. Tous les proxies n'annoncent pas clairement leur capacite UDP ASSOCIATE. Utilisez les etapes de verification ci-dessus pour confirmer que le trafic UDP passe effectivement par le tunnel.
Ne desactivez pas QUIC manuellement. Certains guides suggerent de desactiver QUIC avec --disable-quic. C'est inutile avec BotBrowser. Quand UDP ASSOCIATE est disponible, QUIC fonctionne a travers le tunnel. Quand il ne l'est pas, QUIC bascule automatiquement vers HTTP/2. Desactiver completement QUIC peut creer une empreinte detectable.
Consultez la documentation de votre fournisseur de proxy. Demandez a votre fournisseur de proxy s'il supporte SOCKS5 UDP ASSOCIATE. Les fournisseurs qui le supportent incluent la plupart des proxies SOCKS5 de centres de donnees et certains fournisseurs residentiels premium.

Questions frequentes

UDP sur SOCKS5 necessite-t-il des drapeaux speciaux de BotBrowser ? Non. BotBrowser detecte automatiquement le support UDP ASSOCIATE quand vous utilisez --proxy-server avec un proxy SOCKS5. Aucun drapeau supplementaire n'est necessaire pour le tunneling UDP.

Que se passe-t-il si mon proxy ne supporte pas UDP ASSOCIATE ? BotBrowser bascule elegamment. Le trafic QUIC descend vers HTTP/2 sur TCP (toujours via le proxy). Pour la protection WebRTC, ajoutez --bot-webrtc-ice pour controler les candidats ICE au niveau du moteur.

Cela fonctionne-t-il avec les proxies SOCKS5H ? Oui. Le schema socks5h:// indique a BotBrowser de resoudre le DNS via le proxy. UDP ASSOCIATE fonctionne de la meme maniere avec les schemas socks5:// et socks5h://.

Puis-je utiliser UDP sur SOCKS5 avec des proxies par contexte dans Playwright ? Oui. Chaque contexte de navigateur peut avoir son propre proxy SOCKS5, et BotBrowser testera le support UDP ASSOCIATE independamment pour chaque connexion proxy.

Le tunneling UDP affecte-t-il les performances ? La surcharge est minimale. L'encapsulation UDP de SOCKS5 ajoute un petit en-tete a chaque paquet UDP. Pour le trafic QUIC, vous beneficiez toujours des avantages de latence de HTTP/3 par rapport au repli HTTP/2. Le relais ajoute un saut reseau, similaire au proxy TCP.

UDP ASSOCIATE est-il identique au support UDP complet ? UDP ASSOCIATE est le mecanisme specifique de SOCKS5 defini dans la RFC 1928 pour relayer le trafic UDP. C'est la methode standard pour tunneliser l'UDP a travers SOCKS5. Certains fournisseurs de proxy peuvent decrire leur support UDP differemment, mais au niveau du protocole, c'est UDP ASSOCIATE.

Les proxies HTTP/HTTPS supportent-ils l'UDP ? Non. Les proxies HTTP et HTTPS utilisent la methode HTTP CONNECT, qui ne supporte que le TCP. Si vous avez besoin de tunneling UDP, vous devez utiliser un proxy SOCKS5.

Comment savoir si mon trafic QUIC passe par le tunnel ? Naviguez vers chrome://net-internals/#quic dans BotBrowser. Si les sessions QUIC sont actives et que votre proxy supporte l'UDP, le trafic est correctement tunnelise. Vous pouvez aussi verifier chrome://flags/#enable-quic pour confirmer que QUIC est active.

Resume

Le trafic UDP est une lacune de confidentialite significative et souvent negligee dans les configurations basees sur proxy. QUIC et WebRTC STUN utilisent tous deux l'UDP, et les deux peuvent exposer votre veritable IP quand votre proxy ne gere que le TCP. BotBrowser comble cette lacune en detectant automatiquement le support SOCKS5 UDP ASSOCIATE et en tunnelisant tout le trafic UDP a travers le proxy. Quand le support UDP n'est pas disponible, BotBrowser bascule vers des alternatives TCP sans aucune configuration manuelle.

Pour une confidentialite reseau complete, combinez UDP sur SOCKS5 avec la Configuration de Proxy, la Prevention des fuites WebRTC et la Prevention des fuites DNS.

#udp#socks5#quic#webrtc#stun#proxy#privacy#network