UDP via proxy : pourquoi HTTP ne convient pas, il faut SOCKS5.

Si vous avez connecté un proxy HTTP et que le jeu ne trouve pas le serveur, l'appel Discord ne se connecte pas, et YouTube et les sites sur HTTP/3 se chargent de manière aléatoire — ce n'est pas un problème de « mauvaise qualité » du proxy. C'est une question de protocole. Les proxies HTTP ne peuvent physiquement pas gérer le trafic UDP, qui est précisément la base des jeux, des appels VoIP et du QUIC moderne (HTTP/3). Dans cet article, nous allons examiner pourquoi cela se produit et comment choisir un proxy qui laissera vraiment passer tout le trafic — pas seulement les requêtes de navigateur.

TCP vs UDP : quelle est la différence fondamentale

Tout le transfert de données sur le réseau repose sur deux protocoles de transport de base — TCP et UDP. TCP établit une connexion, garantit la livraison des paquets dans le bon ordre, retransmet les paquets perdus et confirme la réception de chaque fragment. C'est fiable, mais lent : avant que les données ne soient envoyées, il faut effectuer une « poignée de main » (handshake), et chaque perte de paquet entraîne une retransmission et un délai.

UDP fonctionne différemment : les paquets sont envoyés sans établir de connexion, sans confirmations et sans garantie de livraison. Si un paquet est perdu, personne ne le retransmet, l'application décide elle-même quoi faire en cas de perte. Cela peut sembler un inconvénient, mais pour les tâches en temps réel, c'est un énorme avantage : il vaut mieux perdre une image vidéo ou un tick de jeu que d'attendre une retransmission et d'avoir un lag de demi-seconde.

C'est pourquoi le UDP est utilisé pour :

Jeux en ligne (Counter-Strike, Dota 2, Fortnite, tireurs mobiles) — la latence minimale (ping) est plus importante que la livraison à 100 % de chaque paquet ;
VoIP et appels vidéo — Discord, Zoom, Google Meet, les appels WhatsApp utilisent UDP pour la voix et la vidéo ;
Streaming en temps réel — WebRTC, diffusions via OBS avec faible latence ;
Requêtes DNS — la plupart des résolveurs DNS fonctionnent sur UDP ;
QUIC / HTTP/3 — un nouveau protocole de transport que Google et Cloudflare promeuvent comme un remplacement de TCP+TLS pour le trafic web.

HTTP et HTTPS dans leur forme classique (HTTP/1.1, HTTP/2) fonctionnent sur TCP. C'est pourquoi la navigation web ordinaire via un proxy HTTP fonctionne sans problème — mais tout ce qui est sur la liste ci-dessus commence à poser problème.

Pourquoi le proxy HTTP fonctionne uniquement avec TCP

Le proxy HTTP a été conçu à l'origine pour une seule tâche — transmettre des requêtes HTTP. Lorsque vous ouvrez un site HTTPS via un proxy HTTP, le navigateur envoie au serveur proxy la commande CONNECT host:port, le proxy établit un tunnel TCP vers le serveur cible, et ensuite tout le trafic chiffré passe par ce tunnel. Cela fonctionne uniquement parce que le client, le proxy et le serveur utilisent TCP à toutes les étapes.

Le protocole HTTP CONNECT n'a tout simplement pas de mécanisme pour faire passer des datagrammes UDP. La spécification du proxy ne prévoit pas la création d'un « tunnel sans connexion » — alors qu'UDP est précisément une transmission sans connexion. Par conséquent, lorsque le jeu ou Discord essaie d'envoyer un paquet UDP via le proxy HTTP configuré dans le système, le système d'exploitation ignore soit les paramètres du proxy pour ce trafic (et le paquet part directement, contournant le proxy), soit la connexion ne s'établit tout simplement pas.

En pratique, cela se manifeste ainsi : l'application indique « pas de connexion au serveur », la voix dans l'appel disparaît toutes les quelques secondes, le ping dans le jeu dépasse 300-500 ms ou le matchmaking ne trouve tout simplement pas de serveur. Le problème ne vient pas de la vitesse du proxy ni du fournisseur — le protocole HTTP proxy ne sait tout simplement pas travailler avec UDP d'un point de vue architectural.

QUIC et HTTP/3 : un nouveau casse-tête pour les proxies

QUIC est un protocole de transport développé par Google qui sous-tend HTTP/3. Il fonctionne sur UDP, mais met en œuvre son propre mécanisme de fiabilité, de chiffrement (TLS 1.3 intégré) et de multiplexage de flux — c'est-à-dire qu'il prend le meilleur de TCP, mais sans les délais d'établissement de connexion. Les sites sur Cloudflare, Google, YouTube, de nombreux CDN utilisent déjà massivement QUIC par défaut.

Le problème est que le navigateur essaie par défaut de se connecter au site via QUIC (port 443/UDP), et si le proxy HTTP ne prend pas en charge le passage de l'UDP, l'une des deux choses se produit :

Le navigateur fait un retour (fallback) vers HTTP/2 via TCP — le trafic passe toujours par le proxy, mais cela prend du temps supplémentaire pour renégocier le protocole, ce qui ralentit considérablement le chargement des pages ;
Ou les paquets UDP QUIC passent directement en contournant le proxy avec l'IP réelle — cela est critique pour les tâches où l'anonymat est important : multi-comptes, navigateurs anti-détection, tests géographiques de publicité. Le site voit une partie du trafic avec l'IP du proxy, et une autre partie avec l'IP réelle de l'utilisateur ;

Le deuxième scénario est particulièrement dangereux pour les arbitragistes et les spécialistes SMM qui utilisent des navigateurs anti-détection (Dolphin Anty, AdsPower, Multilogin, GoLogin). Si le navigateur « fuit » en QUIC en contournant le proxy, une plateforme comme Facebook ou Google Ads peut lier plusieurs comptes à l'IP réelle, même si les paramètres du proxy sont corrects. La plupart des navigateurs anti-détection modernes désactivent donc de force QUIC ou bloquent l'UDP pour les proxies HTTP — mais si vous configurez le proxy manuellement dans Chrome ordinaire, vous devez vous en occuper vous-même.

SOCKS5 et UDP ASSOCIATE : comment cela fonctionne

SOCKS5 est un protocole de proxy de niveau inférieur par rapport à HTTP. Il n'est pas lié à un protocole applicatif spécifique (HTTP, FTP, etc.) et fonctionne au niveau des sockets, ce qui signifie qu'il peut faire passer à la fois le trafic TCP et UDP. Dans la spécification SOCKS5 (RFC 1928), il existe une commande UDP ASSOCIATE, qui est spécialement conçue pour faire passer des datagrammes UDP via un serveur proxy.

Cela fonctionne ainsi : le client établit d'abord une connexion TCP ordinaire avec le serveur SOCKS5 et envoie la commande UDP ASSOCIATE. Le serveur, en réponse, alloue un port UDP par lequel l'échange de datagrammes aura lieu. Ensuite, le client encapsule chaque paquet UDP dans un en-tête SOCKS5 spécial et l'envoie à ce port, et le serveur transmet le contenu à destination, en retirant l'en-tête. Le trafic retour suit le même schéma.

Une remarque importante : tous les proxies SOCKS5 sur le marché ne prennent pas réellement en charge UDP ASSOCIATE. De nombreux fournisseurs vendent « SOCKS5 » simplement comme un moyen alternatif d'authentification pour le trafic TCP, sans mettre en œuvre le passage de l'UDP. Par conséquent, si vous avez besoin de prendre en charge l'UDP pour les jeux, les appels ou QUIC — demandez spécifiquement au fournisseur la disponibilité de l'UDP ASSOCIATE, et non simplement le protocole SOCKS5 dans la liste.

Pour les tâches où la stabilité et l'IP réelle de l'utilisateur final sont importantes — par exemple, le test de publicité dans TikTok Ads ou Facebook Ads depuis une région spécifique en tenant compte du trafic mobile — les proxies mobiles sont plus appropriés : le réseau opérateur et la rotation des IP réduisent le risque de blocages lors de sessions prolongées, y compris lors d'appels vocaux et de streaming.

HTTP vs SOCKS5 : tableau comparatif

Pour ne pas se tromper sur le type de proxy à choisir pour une tâche spécifique, comparons les protocoles selon des paramètres clés.

Paramètre	Proxy HTTP/HTTPS	SOCKS5 avec UDP ASSOCIATE
Support TCP	Oui	Oui
Support UDP	Non	Oui (si UDP ASSOCIATE est implémenté)
Fonctionnement avec QUIC/HTTP3	Retour à HTTP/2 ou fuite de trafic	Passage complet du trafic
Jeux (CS, Dota, Fortnite)	Ne fonctionne pas	Fonctionne
VoIP/appels vidéo (Discord, Zoom)	Coupures et délais	Connexion stable
Navigation web ordinaire	Fonctionne	Fonctionne
Configuration dans les navigateurs anti-détection	Simple	Simple, pris en charge par tous les principaux

Pratique : jeux, appels, streaming via SOCKS5

Examinons des scénarios spécifiques où la différence entre un proxy HTTP et SOCKS5 se manifeste dans la pratique.

Jeux en ligne. Si vous devez changer de région de matchmaking ou contourner une restriction géographique dans un jeu, un proxy HTTP ne conviendra tout simplement pas — le client de jeu utilise son propre protocole UDP pour communiquer avec les serveurs de jeu, et le trafic contournera le proxy. Vous avez besoin d'un proxy SOCKS5 avec prise en charge confirmée de l'UDP ASSOCIATE, qui est configuré soit dans les paramètres du jeu lui-même (s'il existe une telle option), soit au niveau système à l'aide d'outils de tunneling tiers.

Appels Discord et Zoom. Les canaux textuels de Discord fonctionnent via HTTPS (TCP) et passent parfaitement par un proxy HTTP. Mais les appels vocaux et vidéo utilisent un canal UDP séparé — c'est pourquoi il est souvent possible d'écrire dans le chat, mais l'appel ne se connecte pas ou la voix « coupe ». La solution consiste à utiliser un SOCKS5 avec UDP, configuré au niveau de l'application Discord (dans les paramètres, il y a une section Proxy où vous pouvez spécifier le type SOCKS5) ou au niveau de l'ensemble du système via un client proxy.

Streaming et WebRTC. Des services comme OBS avec sortie WebRTC intégrée, ainsi que les appels vidéo dans le navigateur (Google Meet, WhatsApp Web) utilisent UDP pour minimiser la latence. Pour ces tâches, les proxies résidentiels avec prise en charge de SOCKS5 sont optimaux — ils fournissent une IP réelle du fournisseur domestique, ce qui réduit la probabilité de blocage en raison d'une plage d'adresses « suspecte » de centres de données, tout en laissant passer le trafic UDP sans pertes.

Parsing et automatisation avec des points de terminaison WebSocket/QUIC. Si vous parsez des données à partir de sites qui utilisent HTTP/3 par défaut (de nombreux sites sur Cloudflare), et que vous obtenez des réponses instables ou des bans via un proxy HTTP, essayez SOCKS5 — cela éliminera le retour de protocole inutile et rendra le comportement du parseur plus proche de celui d'un vrai navigateur.

Comment configurer SOCKS5 dans les applications et les navigateurs

La configuration de SOCKS5 varie en fonction de l'application. Examinons les principales options auxquelles sont confrontés les arbitragistes, les spécialistes SMM et les utilisateurs ordinaires.

Navigateur anti-détection (Dolphin Anty, AdsPower, GoLogin, Multilogin, Octo Browser). Dans les paramètres du profil, vous devez choisir le type de proxy « SOCKS5 » au lieu de « HTTP », spécifier l'hôte, le port, le nom d'utilisateur et le mot de passe. Tous les navigateurs mentionnés prennent en charge SOCKS5 par défaut — la différence par rapport à HTTP est minimale au niveau de l'interface, mais fondamentale en termes de prise en charge des protocoles au sein du moteur du navigateur.

Discord. Paramètres → Voix et vidéo → Proxy. Vous choisissez le type SOCKS5, entrez l'adresse et le port du serveur. Si le fournisseur exige une authentification par nom d'utilisateur et mot de passe, vous les spécifiez dans les champs correspondants.

Clients de jeu et niveau système. La plupart des jeux n'ont pas de paramètre proxy intégré, donc un redirectionnement du trafic au niveau système via un client proxy (par exemple, Proxifier ou des utilitaires similaires) est utilisé, qui peut travailler avec SOCKS5 et faire passer à la fois les paquets TCP et UDP d'un processus de jeu spécifique dans le système.

Navigateur Chrome/Firefox manuellement. Dans Chrome, il n'y a pas de prise en charge native de SOCKS5 dans les paramètres — vous devez soit lancer le navigateur avec le drapeau --proxy-server="socks5://host:port", soit utiliser une extension. Dans Firefox, la prise en charge est intégrée : Paramètres → Réseau → Paramètres de connexion → Configuration manuelle du proxy → Hôte SOCKS, version SOCKS v5, et cochez « Utiliser SOCKS v5 pour résoudre DNS via le proxy » — c'est important pour que les requêtes DNS passent également par le tunnel, et non directement.

Exemples de code : vérification UDP via SOCKS5

Pour les développeurs qui souhaitent vérifier si le proxy passe réellement l'UDP, voici quelques exemples pratiques.

Vérification de la connexion TCP via SOCKS5 avec curl :

curl -x socks5h://user:pass@proxy_host:1080 https://ifconfig.me

Vérification en Python via la bibliothèque PySocks, qui permet d'encapsuler un socket dans un tunnel SOCKS5, y compris le mode UDP :

import socks
import socket

s = socks.socksocket(socket.AF_INET, socket.SOCK_DGRAM)
s.set_proxy(socks.SOCKS5, "proxy_host", 1080, username="user", password="pass")
s.sendto(b"ping", ("8.8.8.8", 53))
data, addr = s.recvfrom(1024)
print(data)

Si le serveur prend en charge UDP ASSOCIATE, vous recevrez une réponse. Si la bibliothèque génère une erreur de connexion ou un délai d'attente — cela signifie que le proxy spécifique ne met en œuvre que la partie TCP de SOCKS5, et qu'il ne conviendra pas pour les jeux ou les appels. Pour les tests automatisés des points de terminaison QUIC, vous pouvez utiliser curl --http3 en combinaison avec un tunnel SOCKS5, en vous assurant au préalable que vous avez installé une version de curl prenant en charge HTTP/3.

Liste de contrôle pour choisir un proxy pour le trafic UDP

Demandez au fournisseur non seulement « y a-t-il SOCKS5 », mais spécifiquement le support de la commande UDP ASSOCIATE ;
Pour les jeux et les appels VoIP, testez la connexion à l'avance — le ping réel et la stabilité sont plus importants que la vitesse annoncée ;
Pour les tâches de multi-comptes dans les navigateurs anti-détection, vérifiez que QUIC est désactivé ou passe complètement par le proxy — sinon, une fuite de l'IP réelle est possible ;
Pour le streaming et les appels vidéo, privilégiez les proxies avec un ping faible vers la région souhaitée — pour de tels scénarios, les proxies résidentiels conviennent bien, car ils utilisent des adresses IP réelles des fournisseurs de services ;
Si la tâche consiste à parser rapidement sans nécessiter l'UDP (requêtes HTTP/HTTPS ordinaires), vous pouvez vous contenter de proxies de centres de données moins chers et plus rapides — il n'est pas nécessaire de payer plus pour le support de l'UDP dans ce cas ;
Testez toujours le proxy sur l'application spécifique avant une utilisation à grande échelle — il n'existe pas de proxy « fonctionne toujours », le comportement dépend de l'implémentation du côté du fournisseur.

Conclusion

Les proxies HTTP gèrent très bien le trafic web ordinaire, mais architecturale ne peuvent pas faire passer l'UDP — ce qui signifie qu'ils ne conviennent pas pour les jeux, les appels VoIP, le streaming et le QUIC/HTTP3 moderne. Si vous rencontrez des coupures d'appels, des lags dans les jeux ou un comportement étrange des sites sur Cloudflare via un proxy — ce n'est pas un problème de qualité de connexion, mais du protocole même du proxy. La solution est un SOCKS5 avec un support confirmé de l'UDP ASSOCIATE, que vous devez vérifier à l'avance, et non deviner après coup.

Si votre tâche est liée aux appels vidéo, au streaming ou à l'utilisation de navigateurs anti-détection, où il est important d'éviter toute fuite de trafic en contournant le proxy, prêtez attention aux proxies mobiles — les adresses IP opérateurs assurent une haute confiance des plateformes et un support stable des protocoles modernes, y compris SOCKS5 avec UDP.