UDP via SOCKS5 : la commande UDP ASSOCIATE, pourquoi les proxies HTTP ne gèrent pas l'UDP et comment vérifier

Situation familière : vous avez configuré un proxy, le navigateur ouvre les sites, le scraper collecte les données, tout semble parfait. Puis vous lancez un appel vidéo, et votre interlocuteur ne vous entend pas. Ou vous rejoignez un jeu en ligne, et la partie ne se connecte pas. Ou vous démarrez un chat vocal, et il reste muet. Pourtant, le proxy fonctionne, non ? Il fonctionne. Mais quelque chose est cassé en profondeur, et le comprendre sans connaissances sur le transport est quasi impossible.

La cause est presque toujours la même : votre proxy ne laisse pas passer le trafic UDP. Et ce n’est pas une panne, mais une propriété fondamentale. Certains types de proxies savent gérer l’UDP selon la norme, d’autres ne le peuvent pas du tout. La différence entre ces deux mondes détermine si vous aurez une vraie communication en ligne ou seulement le chargement de pages web.

Dans ce guide, nous aborderons le sujet depuis les bases jusqu’aux outils pratiques de vérification. Vous découvrirez comment fonctionne la commande UDP ASSOCIATE dans le protocole SOCKS5, pourquoi un proxy HTTP utilisant la méthode CONNECT ne peut pas physiquement transmettre des datagrammes, ce qui se casse exactement chez l’utilisateur sans UDP, et comment vérifier par vous-même, en quelques minutes seulement, si un proxy supporte réellement l’UDP. Nous ne parlerons que de transport : pas de choix entre types de proxies, ni d’instructions de configuration d’applications spécifiques.

Les bases : TCP vs UDP, datagrammes et niveau d’action du proxy

Pour comprendre pourquoi l’UDP est si capricieux dans l’infrastructure proxy, il faut revenir aux notions de base de la couche transport. Pas de panique : on explique tout avec des analogies simples.

Deux protocoles de transport, deux philosophies

Sur Internet, les données sont transmises via deux protocoles de transport principaux : TCP (Transmission Control Protocol) et UDP (User Datagram Protocol). Tous deux fonctionnent au-dessus d’IP, mais se comportent de manière radicalement différente.

TCP ressemble à une conversation téléphonique avec accusé de réception permanent. Avant d’échanger des données, les deux parties établissent une connexion via une procédure de « handshake ». Chaque paquet envoyé est confirmé par le destinataire. Si quelque chose se perd, il est renvoyé. L’ordre des paquets est garanti. C’est un flux fiable, ordonné, mais relativement lent. TCP est idéal pour charger des pages web, télécharger des fichiers, envoyer des emails : partout où chaque donnée compte et doit être dans le bon ordre.

UDP ressemble à l’envoi de cartes postales sans accusé de réception. Vous lancez un datagramme sur le réseau et n’attendez pas de confirmation. Pas d’établissement de connexion, pas de garantie de livraison, pas de garantie d’ordre. Un paquet peut se perdre, arriver deux fois ou dans le désordre, et le protocole ne s’en soucie pas. Ça semble être un défaut ? Seulement à première vue. C’est cette simplicité qui donne à l’UDP son principal avantage : la vitesse et la latence minimale.

Qu’est-ce qu’un datagramme ?

Un datagramme est une unité de données autonome en UDP. Contrairement à TCP où les données coulent en un flux continu d’octets, en UDP chaque paquet est autosuffisant. Il contient l’adresse de destination, le port et la charge utile. Un datagramme ne sait rien des datagrammes envoyés avant ou après. C’est comme des lettres individuelles sans numérotation dans une correspondance.

Pourquoi est-ce important pour notre sujet ? Parce qu’un proxy qui sait relayer un flux continu TCP n’est pas du tout obligé de savoir relayer des datagrammes UDP disparates et indépendants. Ce sont des tâches fondamentalement différentes du point de vue de l’implémentation.

Où se situe exactement le proxy dans la chaîne ?

Imaginons le modèle réseau comme les étages d’un immeuble. Aux étages inférieurs, la transmission physique des signaux et l’adressage IP. Au-dessus, la couche transport avec TCP et UDP. Encore au-dessus, la couche application avec HTTP, DNS, les protocoles d’appels.

Le serveur proxy est un intermédiaire placé entre vous et la ressource cible. Mais à quel niveau exact il travaille dépend de son type. Et c’est là que ça devient intéressant.

• Le proxy HTTP comprend nativement la couche application HTTP. Il lit les requêtes HTTP, voit les en-têtes, sait les modifier et les mettre en cache. C’est un proxy taillé pour un protocole applicatif spécifique sur TCP.
• Le proxy SOCKS travaille plus bas, près de la couche transport. Il ne s’immisce pas dans le contenu du protocole applicatif, il se contente de relayer les connexions. C’est pourquoi SOCKS est plus universel : peu importe ce que vous transmettez, HTTP ou quelque chose d’exotique.

C’est cette différence de niveau de fonctionnement qui est à la base de toute l’histoire. Le proxy HTTP est enfermé dans le monde HTTP sur TCP. SOCKS5 a été conçu comme un intermédiaire de transport universel, et c’est pourquoi son cahier des charges inclut un mécanisme de transmission UDP.

Plongée en profondeur : comment SOCKS5 transmet l’UDP

Le protocole SOCKS5 est décrit dans la norme RFC 1928. C’est un protocole compact et élégant, et comprendre sa logique en vaut la peine pour quiconque travaille sérieusement avec des proxies. Décortiquons ses commandes et le mécanisme spécifique de transmission UDP.

Les trois commandes SOCKS5 : CONNECT, BIND, UDP ASSOCIATE

Après que le client s’est connecté au serveur SOCKS5 et a passé l’étape d’authentification, il envoie une requête avec l’une des trois commandes. Chaque commande définit le type d’opération souhaité.

• CONNECT (code 0x01) est la commande la plus courante. Elle dit au proxy : établis pour moi une connexion TCP sortante vers l’adresse et le port spécifiés, puis relaye les octets dans les deux sens. C’est exactement cette commande qu’utilise votre navigateur lorsqu’il va sur Internet via SOCKS5. 99 % du trafic quotidien passe par CONNECT.
• BIND (code 0x02) est la commande pour les connexions entrantes. Elle est nécessaire pour des protocoles comme le FTP classique, où le serveur initie lui-même une connexion retour vers le client. Le proxy ouvre un port d’écoute et attend une connexion entrante. Aujourd’hui, BIND est rarement utilisé.
• UDP ASSOCIATE (code 0x03) est la star de notre discussion. Cette commande crée une association pour la transmission de datagrammes UDP via le proxy. C’est elle qui permet à SOCKS5 de gérer la voix, la vidéo, les jeux, QUIC et le DNS sur UDP.

Comment fonctionne UDP ASSOCIATE de l’intérieur

C’est là que se cache une belle astuce architecturale qui prête souvent à confusion. La commande UDP ASSOCIATE est envoyée via une connexion TCP. Oui, vous avez bien entendu : pour commencer à transmettre de l’UDP, le client établit une connexion TCP de contrôle avec le proxy et lui envoie la commande.

Pourquoi une connexion TCP de contrôle est-elle nécessaire si on veut transmettre de l’UDP ? Il y a plusieurs raisons, et elles sont géniales dans leur pragmatisme.

1. Via TCP, l’authentification et la négociation des paramètres se font de manière fiable. L’UDP n’est pas adapté pour cela, car il n’est pas fiable.
2. La connexion TCP de contrôle sert d’indicateur de vie de l’association UDP. Tant que la connexion TCP est ouverte, l’association UDP est active. Dès que le client ferme la connexion TCP de contrôle, le proxy doit immédiatement libérer les ressources et cesser de relayer les datagrammes. C’est une manière élégante de gérer la durée de vie.

Après avoir reçu la commande UDP ASSOCIATE, le serveur proxy alloue un port relay spécial pour l’UDP et communique au client son adresse et son numéro dans la réponse. C’est sur ce port relay que le client enverra ses datagrammes, et le proxy les relaiera vers la destination et renverra les réponses.

Rôle du port relay et de l’adresse de liaison

Dans la réponse à UDP ASSOCIATE, le serveur renvoie les champs BND.ADDR et BND.PORT. Ce sont l’adresse et le port vers lesquels le client doit envoyer ses datagrammes UDP pour qu’ils soient relayés. Nuance importante : l’adresse dans la réponse peut différer de l’adresse à laquelle le client s’est connecté en TCP. Un client bien conçu doit interpréter correctement cette adresse, surtout lorsque le serveur renvoie une adresse nulle, ce qui signifie d’utiliser le même hôte que pour la connexion de contrôle.

C’est à cette étape que de nombreuses implémentations trébuchent. Une mauvaise gestion de BND.ADDR fait que le client envoie ses datagrammes au mauvais endroit, et la transmission UDP échoue silencieusement alors que l’association est formellement établie.

Format d’encapsulation du datagramme UDP dans SOCKS5

On ne peut pas envoyer un datagramme UDP tel quel sur le port relay. Le proxy doit savoir où le relayer ensuite. C’est pourquoi chaque datagramme UDP envoyé par le client sur le port relay est enveloppé dans un en-tête spécial SOCKS5. Décortiquons-le champ par champ, car comprendre cette structure distingue celui qui maîtrise vraiment le sujet.

L’en-tête d’encapsulation UDP se compose des champs suivants :

• RSV (2 octets) – champ réservé, toujours rempli de zéros. Gardé pour le futur, mais inutilisé pour l’instant.
• FRAG (1 octet) – numéro de fragment. Ce champ est prévu pour la fragmentation des gros datagrammes. La valeur 0 signifie que le datagramme est indépendant et non fragmenté. En pratique, la fragmentation UDP via SOCKS5 n’est presque jamais implémentée, et la plupart des serveurs et clients ne travaillent qu’avec FRAG égal à zéro.
• ATYP (1 octet) – type d’adresse de destination. Peut être 0x01 pour IPv4, 0x03 pour un nom de domaine, 0x04 pour IPv6. Ce champ indique au proxy dans quel format lire le champ d’adresse suivant.
• DST.ADDR (longueur variable) – adresse de destination du datagramme. Sa longueur dépend d’ATYP : 4 octets pour IPv4, 16 octets pour IPv6, et pour un nom de domaine, le premier octet donne la longueur, suivie du nom lui-même.
• DST.PORT (2 octets) – port de destination dans l’ordre réseau.
• DATA – la charge utile proprement dite, c’est-à-dire le datagramme UDP d’origine de l’application.

Lorsque le proxy reçoit un datagramme ainsi encapsulé sur le port relay, il retire l’en-tête SOCKS5, lit l’adresse et le port de destination, puis envoie la charge utile brute vers la destination comme un paquet UDP normal. Lorsqu’une réponse arrive, le proxy fait l’opération inverse : il encapsule le datagramme de réponse dans le même en-tête et le renvoie au client sur le port relay.

Remarquez l’élégance du schéma. Le client ne communique jamais directement en UDP avec la destination. Tout passe par le port relay du proxy, et l’en-tête d’encapsulation sert d’étiquette d’adresse. C’est une méthode fiable et standardisée pour transporter des datagrammes disparates via un intermédiaire.

Pourquoi le champ FRAG est le plus souvent mort

Il vaut la peine de s’arrêter un instant sur la fragmentation. Théoriquement, SOCKS5 permet de découper de gros datagrammes UDP en fragments et de les reconstituer côté proxy. En pratique, cela crée une énorme complexité : il faut bufferiser les fragments, gérer les timeouts de reassembly, se protéger contre les attaques. C’est pourquoi la grande majorité des implémentations exigent simplement que FRAG soit égal à zéro et rejettent tout le reste. Pour les applications, cela signifie que le datagramme doit tenir dans un seul paquet. Heureusement, la plupart des protocoles réels utilisant l’UDP travaillent déjà avec de petits datagrammes.

Pourquoi les proxies HTTP et HTTPS via CONNECT ne peuvent pas transmettre l’UDP

Nous arrivons maintenant à la question qui provoque le plus de malentendus. Les gens pensent souvent : puisque le proxy HTTPS sait tunneliser le trafic chiffré via la méthode CONNECT, il est universel et devrait donc gérer l’UDP. C’est une erreur, et nous allons expliquer pourquoi elle est fondamentale.

Comment fonctionne la méthode CONNECT dans un proxy HTTP

Quand un navigateur passe par un proxy HTTP pour accéder à un site sécurisé, il ne peut pas simplement envoyer une requête HTTP, car le contenu est chiffré. Au lieu de cela, il envoie au proxy une commande spéciale CONNECT avec l’hôte et le port. Le proxy établit une connexion TCP vers cet hôte et, en cas de succès, répond avec un statut indiquant la mise en place du tunnel. Ensuite, le proxy se contente de transférer les octets entre le client et le serveur dans les deux sens, sans se soucier du contenu.

Le mot clé ici est TCP. La méthode CONNECT, par sa spécification, crée exclusivement un tunnel TCP. Elle ouvre une connexion TCP en flux et relie deux flux d’octets. Dans la définition même de CONNECT, il n’existe aucun mécanisme pour travailler avec des datagrammes.

Trois raisons fondamentales d’incompatibilité

Voyons point par point pourquoi ce n’est pas un défaut technique, mais une impossibilité conceptuelle.

1. CONNECT est lié au modèle de flux. HTTP est un protocole sur TCP. La méthode CONNECT hérite de cette nature de flux. Elle sait relier deux flux TCP, mais l’UDP n’est pas un flux : c’est un ensemble de datagrammes indépendants. Il n’y a pas de correspondance entre eux. On ne peut pas fourrer une multitude de datagrammes disparates avec différentes adresses de destination dans un seul tunnel TCP sans un protocole d’encapsulation supplémentaire, lequel n’existe tout simplement pas dans HTTP CONNECT.
2. Pas de mécanisme d’adressage des datagrammes. En UDP, chaque datagramme peut être envoyé vers sa propre adresse et son propre port. Une application vocale peut communiquer simultanément avec plusieurs serveurs. Le tunnel TCP CONNECT vous relie à une seule adresse spécifique, définie au moment de l’établissement. Il ne prévoit pas de champ pour indiquer l’adresse de destination de chaque datagramme individuel, contrairement à SOCKS5 avec ses en-têtes d’encapsulation DST.ADDR et DST.PORT.
3. Pas de port relay pour l’UDP. SOCKS5 alloue spécifiquement un port relay UDP séparé et le communique au client. Le proxy HTTP ne possède pas du tout un tel mécanisme. Son architecture ne prévoit tout simplement pas d’ouvrir des sockets UDP côté serveur pour le relayage. Le code d’un proxy HTTP travaille avec des connexions TCP, et y ajouter l’UDP reviendrait à écrire un tout nouveau protocole.

Une conclusion à retenir pour toujours

Les proxies HTTP et HTTPS ne supportent pas l’UDP, non pas parce que les développeurs ont été paresseux, mais parce que leur protocole est construit exclusivement autour de TCP. La méthode CONNECT est un tunnel TCP, point final. Si vous avez besoin d’UDP via un proxy, la seule voie standard est SOCKS5 avec le support de la commande UDP ASSOCIATE. Aucun proxy HTTP, aussi avancé soit-il, ne laissera passer votre trafic vocal, vidéo ou de jeu en UDP.

Ce qui se casse exactement sans UDP : carte complète des symptômes

Passons maintenant à la partie la plus pratique. Voyons quelles technologies dépendent de l’UDP et à quoi ressemble leur panne du point de vue de l’utilisateur lambda. Cela vous aidera à diagnostiquer instantanément le problème à partir des symptômes.

WebRTC et le duo STUN/TURN

WebRTC est une technologie temps réel qui sous-tend les appels vidéo dans le navigateur, les chats vocaux, les partages d’écran et de nombreux services de conférence. La transmission du flux média repose sur l’UDP, car pour une conversation en direct, la vitesse prime sur la garantie de livraison de chaque paquet. Une petite perte de paquets dans la voix est quasi imperceptible, alors que les délais causés par les retransmissions TCP tuent la qualité.

Pour établir la connexion, WebRTC utilise les protocoles STUN et TURN. STUN permet de connaître votre adresse externe derrière un NAT, et TURN sert de relais lorsque la connexion directe est impossible. STUN comme les flux média vont par défaut sur UDP.

Symptôme côté utilisateur : l’appel semble s’établir, le voyant d’appel s’affiche, mais votre interlocuteur ne vous entend pas et ne vous voit pas, ou la communication est unidirectionnelle. Parfois l’appel se coupe au bout de quelques secondes. L’interface web fonctionne, le chat fonctionne, mais le son et l’image ne passent pas. C’est le signe classique d’un blocage UDP.

QUIC et HTTP/3 avec repli sur TCP

QUIC est un protocole de transport moderne construit sur UDP. C’est sur lui que repose HTTP/3, la version la plus récente du protocole web. QUIC offre une connexion plus rapide et gère mieux les pertes de paquets que le TCP classique. D’ici 2026, une part significative des grands sites et services prend en charge HTTP/3.

Quand l’UDP est indisponible, il se produit une chose intéressante : l’application ou le navigateur bascule généralement sur HTTP/2 ou HTTP/1.1 sur TCP. C’est un mécanisme de tolérance de panne intégré dans la conception.

Symptôme côté utilisateur : le plus souvent, pas de panne évidente, les sites s’ouvrent. Mais vous perdez les avantages de QUIC : les connexions s’établissent plus lentement, et sur un réseau instable, des ralentissements peuvent survenir. Un observateur averti remarquera que HTTP/3 n’est pas disponible alors que le serveur le supporte. Pour la plupart, c’est une dégradation cachée, pas un plantage flagrant.

DNS sur le port 53 via UDP

Les requêtes DNS classiques vont traditionnellement sur UDP au port 53. C’est rapide et efficace pour les courtes demandes de noms.

Il y a ici une subtilité qui dépend de la façon dont l’application résout les noms. Si la résolution est effectuée côté proxy, le problème peut ne pas se poser. Mais si l’application veut elle-même envoyer une requête DNS UDP via le proxy, et que l’UDP n’est pas supporté, la résolution échoue.

Symptôme côté utilisateur : les noms de sites ne sont pas résolus, l’application signale que l’hôte est introuvable alors qu’Internet est accessible. Parfois, des délais se produisent lorsque le système essaie l’UDP, ne reçoit pas de réponse et bascule sur la version TCP du DNS.

VoIP et communication vocale

VoIP est la transmission de la voix sur Internet. Les protocoles vocaux utilisent presque toujours l’UDP pour transmettre le son, car la latence est critique. Une conversation en direct est impossible si chaque paquet attend un accusé de réception.

Symptôme côté utilisateur : l’appel aboutit, mais le son est absent, haché ou très retardé. Audibilité unilatérale, artefacts métalliques, coupure après quelques secondes de conversation. Tout cela sont des signes de problèmes avec le transport UDP.

Jeux en ligne

De nombreux jeux en ligne, en particulier les shooters dynamiques et les projets compétitifs, utilisent l’UDP pour transmettre l’état du monde du jeu. La raison est toujours la même : le délai prime sur la garantie de livraison. Un paquet obsolète avec la position du joueur est inutile, mieux vaut en avoir un frais.

Symptôme côté utilisateur : le jeu ne se connecte pas à la partie, reste bloqué sur l’écran de connexion, ou se déconnecte par timeout. Ou la connexion a lieu, mais le jeu est saccadé, les personnages se téléportent, les actions ne sont pas enregistrées. Le menu et la boutique peuvent fonctionner, car ils utilisent souvent HTTP sur TCP.

Torrents et P2P

De nombreux protocoles P2P utilisent activement l’UDP pour échanger des informations de service et des données. Sans UDP, les fonctionnalités se dégradent : une partie des mécanismes de découverte de pairs et de transfert ne fonctionne plus.

Symptôme côté utilisateur : ralentissements, problèmes de recherche de sources, fonctionnalités incomplètes.

Tableau récapitulatif de la dépendance des scénarios à l’UDP

Voici un tableau pratique à conserver. Il vous indiquera instantanément à quoi vous attendre dans chaque scénario.

• Appel vidéo et visioconférence. Utilise l’UDP : oui, de manière critique. Sans support UDP : l’appel s’établit visuellement, mais pas de son ni de vidéo, communication unidirectionnelle ou coupure. Fonctionnalité principale inopérante.
• Jeu en ligne. Utilise l’UDP : oui, pour la plupart des jeux dynamiques. Sans support UDP : pas de connexion à la partie, timeouts, saccades, téléportations. Le gameplay est impossible ou fortement dégradé.
• Requêtes DNS. Utilise l’UDP : oui, DNS classique sur le port 53. Sans support UDP : problèmes de résolution ou délais si l’application résout elle-même ; pas de problème si la résolution se fait côté proxy.
• QUIC et HTTP/3. Utilise l’UDP : oui, entièrement construit sur UDP. Sans support UDP : repli discret sur TCP HTTP/2, perte de vitesse et d’avantages, mais les sites s’ouvrent.
• Torrent et P2P. Utilise l’UDP : oui, pour de nombreux mécanismes. Sans support UDP : dégradation des fonctions, problèmes de recherche de sources et de transfert.
• Scraping et navigation web classique. Utilise l’UDP : non, généralement du TCP pur via HTTP. Sans support UDP : tout fonctionne normalement, l’UDP n’est pas nécessaire.
• Appel VoIP. Utilise l’UDP : oui, pour le flux vocal. Sans support UDP : pas de son, coupures, délais, audition unilatérale.

Notez la dernière ligne. Pour les tâches classiques comme le scraping ou la navigation web ordinaire, l’UDP n’est pas du tout nécessaire. C’est pourquoi beaucoup de gens utilisent des proxies sans UDP pendant des années sans soupçonner la limitation, jusqu’à ce qu’ils tombent sur un appel ou un jeu.

Pratique de la vérification : comment savoir si un proxy supporte l’UDP

Place aux outils. Nous allons voir plusieurs méthodes de vérification, des plus simples aux plus avancées, et expliquer pourquoi les approches populaires induisent souvent en erreur.

Pourquoi curl ne vérifie que le TCP

Beaucoup tentent de tester un proxy avec une commande curl via socks5-hostname vers un site quelconque. Si la requête passe, ils concluent que le proxy fonctionne, donc l’UDP aussi. C’est un piège.

En effet, une requête HTTP via curl passe par TCP. La commande avec le flag socks5-hostname vérifie que le proxy SOCKS5 sait exécuter la commande CONNECT et résoudre le nom de son côté. Mais CONNECT, c’est du TCP. Le succès d’un tel test indique seulement que le TCP fonctionne via le proxy. Il ne donne strictement aucune information sur le support de UDP ASSOCIATE.

Retenez cette règle de fer : un outil de test TCP ne teste pas l’UDP. Pour tester l’UDP, il faut explicitement initier la commande UDP ASSOCIATE et tenter de transmettre un datagramme.

Méthode 1 : script Python via sockets

La manière la plus transparente de comprendre et de tester UDP ASSOCIATE est d’écrire un petit script travaillant directement avec les sockets. Décrivons la logique pas à pas, sans code spécifique, pour que vous saisissiez l’essentiel.

1. Ouvrez une connexion TCP vers le proxy. Connectez-vous à l’hôte et au port du serveur SOCKS5 avec une socket TCP classique.
2. Passez l’étape de handshake. Envoyez la version du protocole et la liste des méthodes d’authentification supportées. Recevez la méthode choisie par le serveur. Si nécessaire, effectuez l’authentification par login et mot de passe.
3. Envoyez la commande UDP ASSOCIATE. Formez une requête avec la version, le code commande 0x03, un octet réservé et l’adresse. En général, on met des zéros pour l’adresse et le port, ce qui signifie que le client ne connaît pas encore l’adresse depuis laquelle il enverra les datagrammes.
4. Lisez la réponse du serveur. C’est le moment clé. Le premier champ après la version est le code de réponse. La valeur 0x00 signifie succès. Si vous voyez 0x07, c’est Command not supported, c’est-à-dire que le proxy ne sait pas gérer UDP ASSOCIATE. D’autres codes non nuls signalent aussi une erreur.
5. Extrayez l’adresse relay. En cas de succès, lisez BND.ADDR et BND.PORT dans la réponse. Ce sont l’adresse et le port pour envoyer vos datagrammes.
6. Envoyez un datagramme de test. Créez une socket UDP, enveloppez une charge utile de test dans un en-tête SOCKS5 avec les champs RSV, FRAG, ATYP, DST.ADDR, DST.PORT et envoyez-la sur le port relay. Comme destination, prenez un service public qui répond en UDP.
7. Attendez la réponse. Si une réponse correctement encapsulée arrive, l’UDP via le proxy fonctionne réellement. Si silence, malgré un code de réponse réussi, l’association existe formellement mais le relayage effectif des datagrammes ne se produit pas.

Cette méthode donne une image complète. Vous vérifiez séparément si le serveur accepte la commande UDP ASSOCIATE, et séparément si les datagrammes circulent effectivement.

Méthode 2 : requête STUN via le proxy

Un excellent test pratique consiste à utiliser une requête STUN comme charge utile. STUN est un protocole léger, les serveurs STUN publics répondent rapidement, et ce test se rapproche le plus du scénario réel WebRTC.

La logique est la même : établissez une association UDP, enveloppez une requête STUN de type Binding Request dans l’en-tête d’encapsulation SOCKS5, envoyez-la sur le port relay avec l’adresse d’un serveur STUN public. Si une réponse STUN avec votre adresse externe arrive, alors le chemin UDP via le proxy est complètement fonctionnel, y compris la transmission bidirectionnelle. C’est le test le plus convaincant pour les scénarios temps réel.

Méthode 3 : dig via le proxy pour le DNS sur UDP

Une requête DNS est aussi un bon test, car c’est un datagramme UDP compact avec une réponse compréhensible. L’idée est d’envoyer une requête DNS via UDP à travers le proxy SOCKS5 vers un serveur DNS public.

Le dig standard ne sait pas passer par SOCKS5 en UDP, on utilise donc généralement une enveloppe auxiliaire qui dirige le trafic UDP via le proxy, ou on implémente l’encapsulation manuellement selon le schéma décrit ci-dessus. Si la réponse DNS arrive, le canal UDP fonctionne. Si la requête part dans le vide alors que le TCP fonctionne, la conclusion est évidente : l’UDP n’est pas supporté.

Méthode 4 : socat et utilitaires auxiliaires

L’utilitaire socat est un couteau suisse puissant pour les sockets. Avec lui, on peut construire des chaînes de redirection, y compris des liaisons UDP et SOCKS. Cependant, il faut comprendre une limitation : toutes les versions et modes de socat ne supportent pas directement UDP ASSOCIATE. Souvent, socat est utilisé en combinaison avec une couche intermédiaire qui prend en charge l’encapsulation UDP SOCKS5, tandis que socat gère la redirection UDP locale.

Approche pratique : montez un récepteur UDP local, dirigez le trafic UDP via la couche intermédiaire vers le proxy, et vérifiez si la charge utile atteint la destination et si une réponse revient. C’est une voie plus technique, utile pour le débogage d’infrastructure.

Comment interpréter correctement le code de réponse 0x07

Le code 0x07 Command not supported est le signal le plus honnête et direct. Il signifie que le serveur SOCKS5 a reçu votre commande UDP ASSOCIATE, l’a reconnue, mais répond : je n’exécute pas cette commande. Une telle réponse est typique des proxies qui n’implémentent que CONNECT.

Cependant, méfiez-vous d’un scénario plus sournois. Parfois, le serveur répond avec le code de succès 0x00 à la commande UDP ASSOCIATE, mais le relayage effectif des datagrammes ne fonctionne pas. Les raisons peuvent varier : filtre réseau entre le proxy et la destination, mauvaise gestion de l’adresse relay, limitations de l’hébergement. Il ne suffit donc pas de vérifier le code de réponse. La véritable vérification, c’est la transmission réussie d’un datagramme de bout en bout avec réception d’une réponse. C’est pourquoi nous insistons tant sur le test STUN ou DNS avec une réponse réelle.

Check-list de vérification du support UDP d’un proxy

• Assurez-vous de tester un proxy SOCKS5, et non HTTP, car ce dernier ne gère pas l’UDP par définition.
• Établissez une connexion TCP de contrôle et passez l’authentification.
• Envoyez la commande UDP ASSOCIATE et vérifiez le code de réponse. 0x00 bon, 0x07 signifie absence de support.
• Extrayez et interprétez correctement BND.ADDR et BND.PORT, en tenant compte du cas d’adresse nulle.
• Envoyez un vrai datagramme de test, encapsulé selon le format.
• Attendez une réponse correctement encapsulée. Seule cela confirme le fonctionnement de l’UDP.
• Répétez le test plusieurs fois pour exclure une perte de paquets aléatoire.

L’UDP dans les réseaux mobiles : timeouts NAT et keepalive

Un sujet à part et très important : le comportement de l’UDP dans les réseaux mobiles. Là se cache la cause de nombreuses coupures mystérieuses qui semblent inexplicables.

Pourquoi une session UDP se termine plus tôt qu’une session TCP

Entre votre appareil et Internet se trouve toujours un NAT, mécanisme de traduction d’adresses réseau. Le NAT conserve une table de correspondance entre adresses et ports internes et externes. Pour chaque connexion, une entrée est créée dans cette table, et elle a une durée de vie limitée.

Et voici la différence clé. Pour TCP, le NAT dispose de signaux clairs de début et de fin de connexion : il voit le handshake et voit la fermeture. Ainsi, les entrées TCP dans la table NAT vivent généralement longtemps, parfois des dizaines de minutes ou plus.

Pour l’UDP, c’est différent. L’UDP n’a pas de notion de connexion, donc le NAT ne sait pas quand la session a commencé et quand elle s’est terminée. Il conserve simplement l’entrée tant qu’il y a du trafic, et la supprime après une période de silence. Cette période de silence s’appelle le timeout NAT UDP, et dans les réseaux mobiles, elle est souvent très courte, parfois seulement quelques dizaines de secondes.

Résultat : si aucun trafic ne passe sur le canal UDP pendant un certain temps, le NAT supprime silencieusement l’entrée. Vos datagrammes suivants n’ont plus de chemin de retour, et la session se coupe. Pendant ce temps, une connexion TCP dans les mêmes conditions continuerait à vivre.

Pourquoi un keepalive est nécessaire

Le keepalive est l’envoi régulier de petits paquets pour que le NAT considère la session active et ne supprime pas l’entrée. Pour l’UDP, le keepalive est particulièrement critique justement à cause des timeouts courts.

Les protocoles temps réel bien conçus envoient eux-mêmes des keepalives périodiques ou des paquets de service. Par exemple, dans WebRTC, le mécanisme de vérification de connectivité confirme en permanence le chemin. Mais si l’application reste silencieuse et que le timeout NAT est court, la coupure est inévitable. C’est pourquoi, lorsqu’on travaille avec l’UDP via un proxy dans les réseaux mobiles, il faut prévoir de maintenir le canal actif.

Observations pratiques sur les réseaux mobiles

• Les opérateurs mobiles appliquent souvent une politique plus agressive sur l’UDP que sur le TCP, pour économiser les ressources NAT.
• Le timeout NAT UDP peut varier selon les opérateurs et changer avec le temps, il n’y a donc pas de valeur unique.
• Symptôme d’un timeout court : la connexion fonctionne parfaitement en phase active, mais se coupe pendant les pauses, par exemple lorsque votre interlocuteur se tait lors d’un appel.
• La connexion TCP de contrôle de l’association UDP SOCKS5 doit également être maintenue active, sinon le proxy fermera toute l’association.

C’est un point subtil qui distingue une compréhension superficielle d’une compréhension approfondie. Même lorsque le proxy supporte correctement UDP ASSOCIATE, l’instabilité peut provenir du NAT mobile, et non du proxy lui-même. Lors du diagnostic de coupures, gardez toujours à l’esprit le facteur des timeouts.

Erreurs typiques lors du travail avec l’UDP via un proxy

Rassemblons ici les idées reçues les plus courantes. En les évitant, vous économiserez des heures de débogage.

Erreur 1 : confondre socks5 et socks5h

Dans les paramètres de nombreux outils, il existe deux variantes pour écrire SOCKS5. Le schéma socks5 signifie généralement que la résolution du nom de domaine est effectuée localement, côté client, et que le proxy reçoit une adresse IP déjà prête. Le schéma socks5h signifie que la résolution est effectuée côté serveur proxy.

Pourquoi est-ce important ? D’une part, la résolution locale peut fuiter via votre DNS habituel, ce qui n’est pas souhaitable pour la confidentialité de la tâche. D’autre part, un mauvais choix de schéma peut faire que la logique se comporte différemment de ce que vous attendez. La confusion entre socks5 et socks5h génère des bugs difficiles à cerner, où le proxy semble fonctionner par intermittence. Choisissez toujours consciemment où le nom doit être résolu.

Erreur 2 : penser que si c’est SOCKS5, alors l’UDP fonctionne

C’est sans doute l’idée reçue la plus fréquente et la plus dangereuse. La norme SOCKS5 prévoit la commande UDP ASSOCIATE, mais n’oblige pas chaque implémentation à la supporter. Un très grand nombre de proxies SOCKS5 n’implémentent que CONNECT et BIND, et répondent à UDP ASSOCIATE avec le code 0x07.

Autrement dit, l’étiquette SOCKS5 n’est pas une garantie d’UDP. C’est seulement une possibilité, qui peut être implémentée ou non. La seule façon d’en être sûr est de tester, comme nous l’avons décrit. Ne vous fiez jamais à une étiquette marketing, fiez-vous à un test réel.

Erreur 3 : tester l’UDP avec un navigateur

Certains tentent de vérifier le support UDP en ouvrant simplement un site via le proxy dans le navigateur. Mais le navigateur va sur les sites en TCP. Même si le site supporte HTTP/3 sur UDP, en cas d’indisponibilité de l’UDP, le navigateur bascule silencieusement sur TCP, et vous ne remarquez rien. L’ouverture réussie d’une page ne prouve pas le fonctionnement de l’UDP.

De plus, WebRTC dans le navigateur a sa propre logique complexe de contournement des limitations réseau et peut utiliser TURN sur TCP dans certaines configurations, ce qui brouille encore plus le tableau. Le navigateur est donc un mauvais outil pour un test pur du transport UDP. Utilisez des tests directs par sockets.

Erreur 4 : ignorer la vérification de bout en bout

Comme nous l’avons souligné, une réponse 0x00 à UDP ASSOCIATE n’est pas égale à un UDP fonctionnel. C’est une erreur de se fier uniquement au code de réponse. Menez toujours le test jusqu’à un échange réel de datagrammes avec réception d’une réponse. Cela sépare le support formel du fonctionnement effectif.

Erreur 5 : ne pas tenir compte du keepalive et des timeouts

Après avoir configuré l’UDP, il est facile d’oublier les timeouts NAT. Le canal fonctionne au moment du test, mais se coupe pendant les pauses en utilisation réelle. Prévoyez toujours un mécanisme pour maintenir le canal actif, surtout dans les réseaux mobiles.

Erreur 6 : mal gérer l’adresse relay

Comme indiqué, le serveur peut renvoyer une adresse nulle dans BND.ADDR, sous-entendant le même hôte que la connexion de contrôle. Les clients qui envoient aveuglément des datagrammes à l’adresse nulle se cassent. Une implémentation correcte substitue l’adresse du proxy à partir de la connexion TCP. Cette subtilité est à l’origine de nombreux échecs silencieux.

Outils et ressources pour travailler avec l’UDP via SOCKS5

Récapitulons l’arsenal pratique à garder sous la main.

Outils de diagnostic

• Script Python maison avec sockets. L’outil le plus flexible et transparent. Donne un contrôle total sur la formation de la commande UDP ASSOCIATE et l’encapsulation des datagrammes. Idéal pour un diagnostic précis.
• Client STUN via le proxy. Le meilleur test pour les scénarios temps réel. Réponse rapide, résultat clair, au plus proche de WebRTC.
• Test DNS sur UDP. Compact et visuel, parfait pour vérifier le transfert de bout en bout de petits datagrammes.
• socat et couches intermédiaires pour l’encapsulation UDP. Outillage technique pour construire et déboguer des chaînes de redirection UDP via SOCKS5.
• Analyseur de trafic. Observer les paquets aide à voir si les datagrammes partent bien vers le port relay et si des réponses arrivent. Indispensable pour un débogage approfondi.

Ce qu’il faut savoir sur les normes

Le document clé sur SOCKS5 est la RFC 1928, qui décrit les commandes, le format des requêtes et réponses, ainsi que l’encapsulation UDP. Comprendre cette norme distingue un expert d’un utilisateur qui agit à l’aveugle. Il est également utile de connaître les principes de STUN, QUIC et du fonctionnement du NAT, car c’est à l’intersection de ces technologies que surviennent les problèmes pratiques avec l’UDP.

Mini-framework de prise de décision

1. Déterminez si vous avez besoin de l’UDP. Pour le scraping et le web classique, non ; pour les appels, les jeux, le temps réel, oui.
2. Si l’UDP est nécessaire, vérifiez que le proxy est bien SOCKS5, et non HTTP.
3. Testez le support réel d’UDP ASSOCIATE par un test de bout en bout, pas sur l’étiquette.
4. Tenez compte du keepalive et des timeouts NAT, surtout dans les réseaux mobiles.
5. Gérez correctement l’adresse relay et le format d’encapsulation.

Cas d’usage et résultats

Examinons quelques situations typiques montrant comment la connaissance du transport résout de vrais problèmes.

Cas 1 : appel vidéo muet

Situation. Un utilisateur se plaint que tous les sites s’ouvrent via le proxy, le chat de la conférence fonctionne, mais pendant l’appel, ni le son ni la vidéo ne passent. Les interlocuteurs voient l’indicateur de connexion, mais il n’y a pas de communication.

Diagnostic. Le test TCP via le proxy réussit, ce qui déroute au début. Ensuite, un test STUN de bout en bout via UDP ASSOCIATE est effectué. Le serveur répond à la commande avec le code 0x07 Command not supported.

Conclusion. Le proxy n’implémente que CONNECT, l’UDP n’est pas du tout supporté. Le flux média WebRTC ne passe pas en UDP, d’où le silence. Solution au niveau transport : un SOCKS5 avec un véritable support d’UDP ASSOCIATE, confirmé par un test de bout en bout.

Cas 2 : coupure de communication pendant les pauses sur réseau mobile

Situation. La communication vocale via un proxy sur réseau mobile fonctionne parfaitement en conversation active, mais dès que les interlocuteurs se taisent une trentaine de secondes, la communication se coupe.

Diagnostic. Le test UDP de bout en bout réussit, les datagrammes circulent dans les deux sens. Le proxy supporte donc l’UDP. L’observation du comportement montre que les coupures surviennent précisément pendant les pauses sans trafic.

Conclusion. Le coupable est le court timeout NAT UDP de l’opérateur mobile. L’entrée dans la table NAT est supprimée pendant le silence. Solution au niveau transport : assurer un keepalive qui maintient le canal et la connexion TCP de contrôle actifs.

Cas 3 : fausse confiance à cause du code 0x00

Situation. Un ingénieur teste un proxy en envoyant la commande UDP ASSOCIATE, reçoit le code de succès 0x00 et annonce que l’UDP fonctionne. Mais les utilisateurs se plaignent toujours d’appels qui ne marchent pas.

Diagnostic. Un nouveau test va plus loin que le code de réponse : on envoie un vrai datagramme STUN sur le port relay. Aucune réponse n’arrive, malgré le code de succès.

Conclusion. Le support formel existe, mais le relayage effectif est absent, probablement à cause d’un filtrage entre le proxy et le réseau externe, ou d’une erreur de gestion de l’adresse relay. Leçon : le code 0x00 ne suffit pas, seul un transfert de datagramme de bout en bout prouve le fonctionnement.

Cas 4 : dégradation cachée de HTTP/3

Situation. Tout semble fonctionner, les sites s’ouvrent, pas de plaintes, mais l’équipe remarque que les connexions sont plus lentes que prévu et que HTTP/3 n’est jamais utilisé.

Diagnostic. Le test montre que l’UDP ne passe pas via le proxy, donc QUIC est indisponible, et les clients basculent silencieusement sur TCP.

Conclusion. Ce n’est pas une panne, mais une perte de performance cachée. Comprendre le transport permet de décider consciemment si QUIC est important pour la tâche, et si nécessaire, d’assurer le support UDP.

FAQ : questions fréquentes

Peut-on transmettre de l’UDP via un proxy HTTP d’une manière ou d’une autre ?

Non, par les moyens standard. La méthode CONNECT d’un proxy HTTP crée exclusivement un tunnel TCP et ne dispose d’aucun mécanisme d’adressage et de relais de datagrammes. Toute tentative de faire passer de l’UDP via un proxy HTTP pur se heurte à l’absence du protocole correspondant. Pour l’UDP, c’est SOCKS5 avec la commande UDP ASSOCIATE qui est le chemin correct et standardisé.

Si le proxy s’appelle SOCKS5, est-ce qu’il supporte forcément l’UDP ?

Non, et c’est une nuance cruciale. La norme prévoit UDP ASSOCIATE mais n’exige pas son implémentation obligatoire. De nombreux proxies SOCKS5 ne supportent que CONNECT. Le seul moyen fiable de s’en assurer est de faire un test de bout en bout avec une vraie transmission de datagramme, et non de se fier au nom ou au marketing.

Pourquoi curl montre que le proxy fonctionne, mais l’appel ne passe pas ?

Parce que curl teste le TCP via la commande CONNECT, alors que l’appel utilise l’UDP. Ce sont deux transports différents. Le succès du test TCP ne dit rien sur l’UDP. Pour tester l’UDP, il faut initier UDP ASSOCIATE et transmettre un datagramme, par exemple une requête STUN, et attendre une réponse.

Que signifie le code de réponse 0x07 lors d’une tentative UDP ASSOCIATE ?

C’est Command not supported. Le proxy a reçu votre commande, l’a reconnue, mais indique qu’il n’exécute pas UDP ASSOCIATE. Pratiquement, cela signifie que le proxy ne sait pas relayer l’UDP. Vous avez besoin d’un autre proxy avec un véritable support de cette commande.

Pourquoi UDP ASSOCIATE utilise-t-il une connexion TCP alors que nous transmettons de l’UDP ?

La connexion TCP de contrôle sert à deux fins. D’une part, elle permet de passer l’authentification et la négociation de manière fiable. D’autre part, elle définit la durée de vie de l’association UDP : tant que le TCP est ouvert, l’association est active ; dès qu’il se ferme, le proxy libère les ressources. C’est une manière élégante de gérer la session et le nettoyage.

Pourquoi la communication UDP se coupe-t-elle sur un réseau mobile alors que le TCP tient ?

À cause des spécificités du NAT. Pour TCP, le NAT a des signaux clairs de début et de fin, donc les entrées vivent longtemps. L’UDP n’a pas de notion de connexion, et le NAT supprime l’entrée après une courte période de silence. Dans les réseaux mobiles, le timeout UDP est particulièrement court. Solution : un keepalive régulier qui maintient le canal actif.

Peut-on vérifier le support UDP directement dans le navigateur ?

Non, de manière fiable. Le navigateur va sur les sites en TCP, et lorsque l’UDP est indisponible, il bascule silencieusement sur TCP pour QUIC. WebRTC dans le navigateur a une logique complexe et peut utiliser des mécanismes de contournement. Tout cela masque l’état réel de l’UDP. Pour un test pur, utilisez des tests directs par sockets, STUN ou DNS via UDP ASSOCIATE.

Quelle est la différence entre socks5 et socks5h en pratique ?

La différence réside dans l’endroit où le nom de domaine est résolu. Avec socks5, le nom est généralement résolu localement côté client ; avec socks5h, c’est côté proxy. Cela affecte à la fois la confidentialité de la résolution et le comportement dans certains scénarios. Un choix conscient du schéma évite des erreurs difficiles à cerner.

Est-il obligatoire d’implémenter la fragmentation des datagrammes dans SOCKS5 ?

En pratique, non. Le champ FRAG est prévu par la norme, mais l’écrasante majorité des implémentations ne fonctionne qu’avec FRAG égal à zéro, c’est-à-dire sans fragmentation. Les datagrammes doivent tenir dans un seul paquet. Les protocoles réels utilisant l’UDP manipulent généralement de petits datagrammes, donc cela crée rarement des problèmes.

Comment distinguer un problème de proxy d’un problème de NAT mobile ?

Effectuez un test UDP de bout en bout. S’il échoue complètement, et que la commande retourne 0x07 ou que les datagrammes n’arrivent pas, le problème vient du proxy. Si le test réussit, mais que des coupures surviennent uniquement pendant les pauses en exploitation réelle, alors le coupable est probablement un court timeout NAT UDP. Cette analyse localise précisément la source.

Conclusion : le transport est roi

Nous avons parcouru le chemin depuis les notions de base de TCP et UDP jusqu’aux subtilités de l’encapsulation des datagrammes dans SOCKS5 et aux perfides timeouts NAT des réseaux mobiles. Résumons les points principaux qui font passer d’un utilisateur tâtonnant à une personne comprenant exactement ce qui se passe au niveau transport.

Premièrement, UDP et TCP sont deux mondes différents. L’UDP transporte des datagrammes disparates sans garanties, pour la vitesse, et c’est sur lui que reposent les appels, les jeux, QUIC et le DNS classique. Un proxy qui sait relayer le TCP n’est pas obligé de savoir relayer l’UDP.

Deuxièmement, seul SOCKS5 via la commande UDP ASSOCIATE offre un chemin standard pour l’UDP. Le mécanisme est élégant : une connexion TCP de contrôle, un port relay dédié, et l’encapsulation de chaque datagramme dans un en-tête avec les champs RSV, FRAG, ATYP, DST.ADDR et DST.PORT.

Troisièmement, les proxies HTTP et HTTPS ne laissent pas passer l’UDP du tout. La méthode CONNECT crée exclusivement un tunnel TCP ; son architecture ne prévoit ni adressage de datagrammes, ni port relay, ni mécanisme de relais UDP.

Quatrièmement, l’étiquette SOCKS5 ne garantit pas l’UDP. Testez toujours de bout en bout, jusqu’à la transmission réelle d’un datagramme et la réception d’une réponse. Un code 0x00 sans échange effectif ne prouve rien, tandis qu’un code 0x07 annonce honnêtement l’absence de support.

Cinquièmement, dans les réseaux mobiles, l’UDP est plus capricieux à cause des timeouts NAT courts. Un keepalive et le maintien de la connexion de contrôle active évitent les coupures mystérieuses pendant les pauses.

Vos prochaines étapes sont simples. Déterminez si vous avez besoin de l’UDP pour votre tâche spécifique, en vous appuyant sur notre tableau des scénarios. Si oui, assurez-vous de travailler avec SOCKS5, et vérifiez le support réel d’UDP ASSOCIATE par un test personnel, que ce soit STUN, DNS ou un script socket direct. Prévoyez un keepalive et gérez correctement l’adresse relay. Ce faisant, vous ne vous retrouverez plus jamais dans une situation où le proxy semble fonctionner mais l’appel reste muet. Maintenant, vous savez exactement où chercher la cause et comment la résoudre au niveau transport.