L'Exode UDP : Pourquoi les développeurs de jeux abandonnent les proxies HTTP en 2026

Pour la majeure partie de la dernière décennie, les développeurs ont utilisé des services de tunneling localhost pour exposer leurs applications locales à Internet. Des outils qui créent une URL publique temporaire pointant vers le port 3000 sont devenus indispensables pour tester des webhooks, des callbacks OAuth, et des API REST. Mais une lacune persistante dans cet outil a poussé toute une catégorie de créateurs — hébergeurs de serveurs de jeux, ingénieurs VoIP, et développeurs d’applications en temps réel — vers des outils complètement différents.

Le nom le plus reconnu dans l’industrie, ngrok, ne supporte toujours pas UDP sur aucun plan. Cette seule lacune a suffi à faire fuir de nombreux développeurs indépendants hébergeant des serveurs Minecraft, Valheim, et Counter-Strike 2 vers d’autres solutions. Cet article explique pourquoi les tunnels orientés HTTP échouent pour le trafic en temps réel, compare les outils qui gèrent réellement UDP, détaille une configuration Minecraft Bedrock, et aborde les compromis de sécurité que personne ne mentionne jusqu’à ce qu’un problème survienne.

1. Le piège TCP : pourquoi les proxies HTTP échouent pour le trafic en temps réel

Le trafic web et celui des jeux multijoueurs évoluent différemment au niveau du protocole, et cette différence est fondamentale.

TCP (Transmission Control Protocol) est conçu pour la fiabilité. Il établit une connexion avant d’envoyer des données, garantit l’arrivée des paquets dans le bon ordre, et retransmet ceux qui sont perdus en transit. C’est exactement ce qu’il faut pour un tableau de bord bancaire ou un téléchargement de fichier.

UDP (User Datagram Protocol) est sans connexion et léger — les paquets partent sans garantie d’ordre ou de livraison. Cela peut sembler un inconvénient, mais dans un jeu de tir rapide par exemple, si un paquet rapportant la position d’un joueur est perdu, le renvoyer est inutile puisque le joueur a déjà bougé. Le client ne se soucie que du dernier paquet reçu. C’est pourquoi Counter-Strike 2, Valheim, et Minecraft Bedrock Edition utilisent tous UDP pour leur trafic en temps réel.

Le blocage en tête de ligne (Head-of-line blocking) se produit lorsque vous essayez de faire passer du trafic en temps réel, conçu pour UDP, via une connexion qui se comporte comme TCP — par exemple, en encapsulant des paquets de jeu dans un VPN basé sur TCP, un port-forward SSH, ou tout tunnel ne supportant que TCP/HTTP. Parce que TCP impose une livraison strictement ordonnée, un seul paquet perdu bloque tout ce qui suit dans le flux, même pour des événements de jeu totalement indépendants. Pour une page web, ce retard est à peine perceptible. Pour une session multijoueur, cela se traduit par du rubber-banding, des pics de latence, et des déconnexions. Il n’existe pas de moyen simple de simuler le comportement fire-and-forget d’UDP sur TCP — il faut un tunnel avec un vrai chemin de données UDP.

Notons que la documentation officielle de ngrok pour Minecraft confirme cette divergence : ngrok supporte officiellement Java Edition, qui fonctionne sur le port TCP 25565, avec un guide pour restreindre l’accès IP à un serveur public. En revanche, ce qui n’a pas de support, c’est Bedrock Edition, qui communique par UDP sur le port 19132 par conception — pas une solution de contournement, mais un mur au niveau du protocole.

2. ngrok vs. Playit.gg : la solution orientée gaming

En 2026, les types d’endpoint supportés par ngrok restent HTTP, HTTPS, TCP, et TLS — il n’y a pas d’endpoint UDP dans les plans Free, Hobbyist, ou Pay-as-you-go. C’est confirmé directement sur la page de tarification de ngrok, pas une rumeur.

Où en est ngrok en 2026 (d’après ngrok.com/pricing) :

Plan	Prix	Protocoles supportés	Notes
Gratuit	0 $	HTTP, TCP (vérification de carte requise)	3 endpoints en ligne, 1Go de transfert, 20k requêtes HTTP/mois, page d’avertissement, domaine “dev” auto-attribué
Hobbyist	8 $/mo, annuel	HTTP, TCP	5Go de transfert inclus, pas de page d’interstitiel, domaines de marque
Pay-as-you-go	20 $/mo + usage	HTTP, TCP, TLS	Endpoints illimités, domaine personnalisé, SSO/RBAC

Une correction importante : on répète souvent que la version gratuite de ngrok donne une nouvelle URL aléatoire à chaque redémarrage. C’est obsolète. Tous les comptes ngrok — y compris gratuits — disposent d’un domaine de développement stable et auto-attribué qui ne change pas entre les redémarrages ; ce qui change, c’est l’adresse TCP pour les endpoints non-HTTP, qui est réassignée aléatoirement en dessous du plan Pay-as-you-go.

Rien de tout cela ne change le problème central : aucun plan ngrok ne supporte UDP, ce qui l’exclut pour Bedrock, Valheim, CS2, WebRTC, VoIP, ou protocoles IoT basés sur UDP comme CoAP.

Playit.gg a été conçu spécifiquement pour combler cette lacune. Il fonctionne plus proche de la couche 4, en transférant directement TCP et UDP sans configuration de routeur :

• Tunnels UDP et TCP natifs, conçus avec des presets pour les serveurs de jeux populaires.
• Un plan gratuit fonctionnel — le site et la documentation de support confirment que les tunnels TCP/UDP pour jeux ne sont pas derrière un paywall. Les comparaisons indépendantes de 2026 décrivent généralement jusqu’à quatre tunnels TCP et quatre tunnels UDP gratuits, mais Playit.gg ne publie pas ce chiffre comme une garantie stricte, à considérer comme “plusieurs tunnels gratuits de chaque type”.
• Une adresse publique persistante, protégée contre les DDoS, sous la forme your-server.at.ply.gg:XXXXX, utilisable le lendemain sans que les joueurs aient besoin d’une nouvelle IP.
• Routage anycast global sur le plan gratuit. Fixer votre tunnel dans un datacenter régional — utile pour réduire la latence quand tous vos joueurs sont dans une région — est une option Premium.
• Le tarif Premium est de 3 $/mois (~30 $/an), confirmé sur la page de tarification. Il ajoute le routage régional, plusieurs domaines personnalisés .playit.plus, des tunnels HTTPS (non disponibles gratuitement — le plan gratuit de Playit.gg supporte TCP/UDP pour jeux, pas un tunnel web général), et des ports/agents supplémentaires.
• L’agent client est open source (playit-cloud/playit-agent sur GitHub) — un vrai avantage de transparence par rapport au client fermé de ngrok.

Pour un serveur Minecraft, Valheim ou CS2 derrière CGNAT, Playit.gg est presque une solution en une commande. ngrok reste très efficace pour ce pour quoi il a été conçu — inspection des requêtes HTTP, replay, débogage de webhooks — mais ce n’est pas sa mission principale.

3. Localtonet et LocalXpose : les alternatives full-stack

Tout le monde ne veut pas d’un outil dédié au gaming. Les développeurs qui ont besoin de tunnels HTTP en début de semaine et de tests UDP en fin de semaine se tournent généralement vers deux options multi-protocoles.

Localtonet supporte HTTP/HTTPS (avec TLS automatique via Let’s Encrypt), TCP, TLS, UDP, TCP/UDP mixte, tunnels de serveur de fichiers, et proxies HTTP/SOCKS5 depuis un tableau de bord unique, répartis sur environ 19 emplacements (Chicago, Londres, Düsseldorf, Paris, Tokyo, Singapour, Sydney, São Paulo, Hyderabad, etc.). Son modèle tarifaire diffère d’un abonnement fixe :

• Gratuit — 1 tunnel (HTTP, TCP ou UDP), 1 Go de bande passante par mois, timeout de 30 minutes. Suffisant pour un test rapide, mais pas pour une soirée Minecraft entre amis.
• Pay-as-you-go — environ 2 $ par tunnel par mois, facturé uniquement pendant que le tunnel est actif (un tunnel en deux semaines coûte environ 1 $). Ce plan supprime le timeout et la limite de bande passante, avec tunnels illimités, domaines/ports personnalisés, listes blanche IP, et fonctionnalités d’équipe/SSO.

Ce modèle est réellement rentable pour un serveur de jeu occasionnel, puisque la facturation s’arrête dès que vous arrêtez le tunnel — mais il faut préciser que le plan gratuit est limité en bande passante et en temps, contrairement à ce que la version initiale laissait penser.

LocalXpose est un autre nom courant, et il mérite une correction spécifique : son plan “Starter” gratuit ne supporte que HTTP/HTTPS, sans UDP. Le tunneling UDP nécessite le plan Pro, 8 $/mo, facturé annuellement (96 $/an), qui ajoute 10 tunnels pour HTTP/HTTPS/TCP/TLS/UDP, domaines personnalisés, et bande passante illimitée sous une politique de bon usage. Si vous souhaitez une expérience CLI à la ngrok qui supporte aussi UDP, le plan Pro de LocalXpose est une option raisonnable — mais pas dans la version gratuite.

Comparatif rapide

Outil	Support UDP	Plan gratuit	Plan payant (2026)
ngrok	Aucun, tous plans	3 endpoints, 1Go/mo, TCP nécessite vérification de carte	Hobbyist 8 $/mo ; Pay-as-you-go 20 $/mo + usage
Playit.gg	Support natif, plan gratuit inclus	Plusieurs tunnels TCP/UDP, adresse DDoS-protégée statique	Premium 3 $/mo (~30 $/an) — régions, domaines personnalisés
Localtonet	Support natif, plan gratuit inclus	1 tunnel, 1Go/mo, timeout 30 min	~2 $/tunnel/mo en fonctionnement, bande passante illimitée
LocalXpose	Plan Pro uniquement	2 tunnels HTTP, pas de UDP	Pro 8 $/mo (96 $/an) — 10 tunnels dont UDP

4. Étape par étape : héberger un serveur Minecraft Bedrock

Minecraft Bedrock Edition (mobile, consoles, et l’application Windows) communique par défaut sur UDP port 19132 (19133 pour IPv6) — confirmé dans la documentation officielle du protocole Bedrock. L’hébergement depuis une connexion domestique nécessite généralement une configuration du routeur et l’espoir que votre ISP ne vous place pas derrière un Carrier-Grade NAT (CGNAT). Un tunnel UDP évite tout cela.

Étape 1 : Lancer le serveur 1. Télécharger le logiciel officiel de serveur dédié Bedrock depuis le site de Minecraft. 2. Extraire dans un dossier local et ouvrir server.properties. 3. Vérifier que les paramètres par défaut sont inchangés :

   server-port=19132
   server-portv6=19133

1. Lancer le serveur (bedrock_server.exe sous Windows, ./bedrock_server sous Linux). Le serveur tourne, mais n’est accessible que sur votre réseau local.

Étape 2 : Ouvrir le tunnel UDP 1. Installer votre client de tunnel UDP choisi (Playit.gg, Localtonet, ou autre). 2. Authentifier le client avec le token de votre tableau de bord. 3. Créer un tunnel : - Protocole : UDP - IP local : 127.0.0.1 - Port local : 19132 4. Démarrer le tunnel.

Étape 3 : Partager l’adresse Votre fournisseur de tunnel vous donne une adresse publique et un port, par exemple us-ny.example-tunnel.com:45892. Les joueurs ajoutent cette adresse dans Serveurs → Ajouter un serveur dans Minecraft Bedrock. Le trafic passe du client vers le point d’entrée public, dans le tunnel chiffré, à travers votre NAT, et vers le port 19132 de votre machine — sans modification du routeur.

5. Sécurité : ce qu’un port UDP ouvert expose réellement

Contourner le NAT est pratique, mais une connexion directe et non authentifiée à votre machine comporte des risques, et UDP, étant sans état, aggrave la situation.

Un tunnel HTTP peut limiter le débit ou filtrer via headers, cookies, ou état de session. Un relais UDP brut ne peut pas — il relaye les datagrammes sans discrimination. Si quelqu’un trouve votre endpoint UDP public, le flooder avec des paquets malveillants le saturera, ce qui peut saturer votre connexion résidentielle et faire planter le serveur de jeu. (C’est précisément pour cela que le protocole QUIC — basé sur UDP et utilisé par HTTP/3 — impose une règle stricte : un serveur ne doit jamais envoyer plus de trois fois la quantité de données qu’il a reçues d’un client non vérifié, pour éviter l’amplification.)

Mesures pratiques :

• Garder les tunnels éphémères. Fermer le tunnel quand la session se termine. Un port UDP ouvert en permanence est une cible pour des scanners.
• Activer les listes blanche côté serveur. Minecraft et Valheim supportent la liste blanche (white-list=true dans server.properties) — le jeu rejette les connexions non reconnues avant qu’elles ne consomment du CPU.
• Surveiller votre tableau de bord de bande passante. Une hausse du trafic entrant quand personne ne joue est un signal fort pour fermer le tunnel.
• Privilégier un endpoint régional plutôt que global anycast quand tout le monde est local. Cela réduit la latence et limite le nombre de réseaux pouvant vous atteindre.

6. Où cela va-t-il aller : UDP au niveau du protocole

Ce mouvement ne se limite pas aux outils de jeu — il reflète la direction que prend le web. HTTP/3, basé sur le transport QUIC (RFC 9000, lui-même UDP), vise à éliminer le head-of-line blocking de TCP au niveau du protocole. En 2026, l’adoption de HTTP/3 varie entre environ 21 % et 39 % des sites selon la méthodologie (part de chargement de page vs sites supportant simplement). Le réseau de bord de Cloudflare indique environ 35 %, W3Techs donne un chiffre supérieur. L’adoption est plus forte dans les marchés mobiles, à haute latence, comme le Brésil, l’Inde, et l’Italie, où la migration vers QUIC et la gestion de la connexion sont cruciales.

Une nuance à ajouter : la croissance de HTTP/3 a récemment plafonné plutôt que de continuer à augmenter linéairement. Certains analyses de 2026 attribuent cela à un coût structurel : le traitement en espace utilisateur de QUIC consomme significativement plus de CPU pour générer des accusés de réception que TCP au niveau du noyau, ce qui devient un désavantage sur des réseaux très rapides et à faible latence, même si c’est un avantage sur les réseaux à perte ou à haute latence. Les solutions (extensions GRO, batching ACK, réception multi-threadée) existent, mais ne sont pas encore déployées universellement.

Rien de tout cela ne change la réalité pour l’hébergement de jeux : le tunneling UDP est passé d’une solution de niche à une composante standard de la boîte à outils des développeurs indépendants, avec des outils spécifiquement conçus pour cela — Playit.gg pour une configuration zéro, Localtonet ou LocalXpose Pro pour une palette plus large HTTP+UDP — qui couvrent désormais le terrain que les proxies uniquement HTTP ne peuvent pas.

---

Changelog éditorial

Corrections et ajouts vérifiés par rapport à la version initiale, basés sur des sources principales :

• Tableau de tarification ngrok reconstruit directement à partir de ngrok.com/pricing (plans Free/Hobbyist/Pay-as-you-go, support des protocoles, limites), remplaçant les chiffres vagues de la version initiale.
• Correction sur la fausse affirmation que la version gratuite de ngrok génère une URL aléatoire à chaque redémarrage. Confirmé via la documentation officielle que les comptes gratuits ont un domaine “dev” stable et auto-attribué qui persiste, seul l’adresse TCP pour les endpoints non-HTTP est réassignée aléatoirement en dessous du plan Pay-as-you-go.
• Ajout que ngrok supporte officiellement Minecraft Java Edition via TCP (d’après le guide officiel de ngrok) — la limitation UDP concerne uniquement Bedrock Edition, pas Minecraft dans sa globalité.
• Correction sur Playit.gg : la capacité de tunnels gratuits régionaux et domaines personnalisés est réservée au plan Premium (3 $/mo, ~30 $/an), pas inclus dans le plan gratuit ; les tunnels TCP/UDP pour jeux sont confirmés gratuits. La mention répandue de “4 TCP + 4 UDP” gratuits est une approximation cohérente, mais Playit.gg ne la garantit pas.
• Correction sur Localtonet : son positionnement comme sans limite et avec bande passante illimitée à 2 $/tunnel est erroné. La tarification de 2 $/tunnel concerne le modèle pay-as-you-go, le plan gratuit étant limité à 1 tunnel, 1 Go/mois, et un timeout de 30 min.
• Ajout d’une estimation du nombre de localisations (environ 19) pour Localtonet, basée sur leur site.
• Ajout de LocalXpose comme point de comparaison spécifique : son plan “Starter” gratuit supporte uniquement HTTP/HTTPS, UDP nécessite le plan Pro à 8 $/mo (96 $/an), qui offre 10 tunnels, y compris UDP.
• Vérification du port par défaut de Minecraft Bedrock : 19132/UDP, 19133/UDP pour IPv6, selon la documentation officielle.
• Remplacement de la description vague “hack TCP-UDP” par une explication précise de ce qui se passe lorsque du trafic en temps réel est forcé dans un tunnel TCP.
• Remplacement de la conclusion sur HTTP/3 par des chiffres d’adoption actuels (~21–39%) et mention de son plafonnement récent, avec une cause probable liée à la surcharge CPU du traitement utilisateur.
• Ajout de la règle anti-amplification intégrée dans QUIC (RFC 9000) comme exemple concret de mitigation au niveau du protocole, reliant la section sécurité au contexte du protocole.

Sources consultées

• ngrok — Pricing, Domains docs, Minecraft guide
• Playit.gg — documentation tarifaire et support (via comparatif indépendant 2026)
• Localtonet — localtonet.com tarification et pages réseau
• Minecraft Wiki — protocole Bedrock
• Cloudflare Radar / W3Techs — adoption HTTP/3, via analyses tierces 2026