Au-delà de HTTP : pourquoi les devs de jeux et ingénieurs VoIP ne peuvent pas utiliser ngrok

Si vous avez créé une application web, configuré un webhook, ou testé une API en local ces dix dernières années, il y a de fortes chances que vous ayez lancé ngrok http 3000. C’est l’outil par défaut pour la productivité en développement local — une commande qui expose un port HTTP ou HTTPS local à Internet, sans configuration de routeur ni NAT de niveau opérateur (Carrier-Grade NAT).

Mais si vous sortez de la pile web, l’histoire change. Tenter de partager un serveur Minecraft local, tester un build multijoueur avec des testeurs distants, ou déboguer un serveur VoIP SIP/RTP, ngrok ne suffit pas. Son architecture repose sur TCP et HTTP, et en 2026, il ne supporte toujours pas nativement le tunneling UDP — une limitation confirmée dans la documentation officielle de ngrok, qui liste des points de terminaison TCP mais rien pour UDP.

Ce document explique pourquoi l’UDP est indispensable pour les applications en temps réel, pourquoi faire du tunneling UDP sur un proxy TCP dégrade la performance, et quels outils résolvent réellement le problème aujourd’hui.

1. TCP vs. UDP : le dilemme central

	TCP (HTTP, Webhooks, API REST)	UDP (Voix, Vidéo, État du jeu)
Modèle de connexion	Orienté connexion	Sans connexion
Livraison	Garantie, dans l’ordre	Meilleur effort, “fire-and-forget”
Gestion des erreurs	Retransmet les paquets perdus	Pas de retransmission
Surcharge	Plus élevée (handshakes, accusés de réception)	Minimale
Priorité	Exactitude	Latence

TCP garantit que chaque octet envoyé arrive, dans l’ordre. Si un paquet est perdu, TCP suspend le traitement en aval, demande une retransmission, et attend — un comportement connu sous le nom de blocage head-of-line (HoL). C’est parfait pour une requête de base de données ou un téléchargement de fichier, où un octet corrompu brise la charge utile.

UDP privilégie la vitesse au détriment de la fiabilité. Il n’y a pas de handshake, pas de garantie d’ordre, pas de retransmission. C’est exactement ce qu’il faut pour :

• Serveurs de jeux. Un titre rapide peut diffuser la position des joueurs 60 à 128 fois par seconde. Si un paquet de position est perdu, le client ne veut pas qu’il soit retransmis 150 ms plus tard — il veut le prochain paquet, maintenant. La retransmission d’un état obsolète cause le rubber-banding et la jitter que tout dev de jeu multijoueur a déjà rencontrés.
• VoIP et WebRTC. Lors d’un appel SIP/RTP, une trame audio perdue est mieux remplacée par quelques millisecondes de silence que livrée en retard. La retransmission audio via TCP entraîne un délai cumulatif et des saccades robotiques plutôt qu’une coupure nette.

2. Pourquoi vous ne pouvez pas simplement encapsuler UDP dans un tunnel TCP

Question légitime : ne peut-on pas encapsuler le trafic UDP dans un tunnel TCP avec quelque chose comme socat ? Techniquement oui — mais en pratique, cela déclenche un mode de défaillance bien documenté appelé TCP meltdown (ou TCP-over-TCP).

Lorsque vous tunnelisez du trafic sur une connexion TCP orientée, toute perte de paquet sur la connexion sous-jacente déclenche le contrôle de congestion du tunnel : il se met en pause pour retransmettre. Pendant ce temps, l’application au-dessus, qui attend une livraison immédiate en UDP, n’a aucune idée que le tunnel est bloqué. Vous vous retrouvez avec deux boucles de contrôle TCP indépendantes — interne et externe — qui se combattent. Le résultat, comme le décrivent les références réseau, est une connexion TCP externe avec une fenêtre de congestion effondrée, un timeout de retransmission gonflé, et un buffer d’envoi plein incapable de se vider dans les deux sens. Ce phénomène est bien connu en réseau (c’est pourquoi la plupart des VPN évitent de faire passer leur tunnel sur TCP), et ne concerne pas un fournisseur de tunneling en particulier.

Puisque l’architecture de relais TCP d’ngrok ne fait pas de forwarding de datagrammes UDP de bout en bout, forcer du trafic UDP en temps réel à passer par lui transforme un stream de jeu ou de voix de 30 ms en un chaos saccadé.

3. Cas d’usage réels nécessitant UDP

Hébergement de serveurs de jeux. Les routeurs domestiques se trouvent de plus en plus derrière du Carrier-Grade NAT, ce qui signifie qu’il n’y a pas d’adresse IPv4 publique pour faire du port forwarding. Un serveur Minecraft, Valheim ou Unity/Unreal personnalisé doit utiliser un proxy acceptant le trafic UDP public et le transférant vers 127.0.0.1:<port> avec un minimum de surcharge, tout en protégeant l’IP résidentielle contre le DDoS.

VoIP, téléphonie, et WebRTC. La téléphonie se divise en deux protocoles : SIP (signalisation — peut fonctionner sur TCP ou UDP, généralement port 5060) et RTP (le flux audio/vidéo réel, presque toujours des ports UDP en haute plage, souvent 10000–20000). Si un tunnel proxy la signalisation SIP mais laisse tomber le média RTP, l’appel se connecte puis devient totalement silencieux.

4. Ngrok supporte-t-il UDP en 2026 ? Toujours non.

C’est le plus grand écart constant d’ngrok par rapport au reste du marché du tunneling. Plusieurs comparatifs indépendants de 2026 confirment la même chose : ngrok ne supporte toujours pas nativement UDP, et ne gère que HTTP, HTTPS, et TCP en 2026. Toute personne souhaitant faire tourner un serveur Minecraft, un monde Valheim, ou un device IoT parlant UDP découvrira que la majorité des options de tunneling — ngrok compris — ne fonctionneront tout simplement pas pour ce trafic.

Ce vide explique pourquoi un petit groupe d’alternatives capables de faire du tunneling UDP ont gagné une communauté dédiée : Playit.gg, LocalXpose, Localtonet, et — de plus en plus pertinent si vous l’utilisez déjà pour d’autres tunnels — Pinggy.

5. Quatre outils de tunneling UDP, en revue

Playit.gg — Spécialement conçu pour les serveurs de jeux

Playit.gg a été conçu spécifiquement pour résoudre les problèmes de CGNAT et de port forwarding pour les gamers et auto-hébergeurs, avec plus d’un million d’utilisateurs inscrits et 19 datacenters répartis sur cinq continents.

[ Joueur Externe ]
       │ (paquets UDP)
       ▼
[ Playit.gg Anycast Edge ]
       │ (tunnel encapsulé)
       ▼
[ Playit.gg Agent Local ] ──▶ [ Serveur de jeu local (127.0.0.1:25565) ]

Niveau gratuit : Support intégré en un clic pour les titres populaires (Minecraft Java/Bedrock, Palworld, Terraria, Factorio, Valheim, 7 Days to Die, Project Zomboid, et autres), y compris UDP quand nécessaire, plus protection DDoS avec IP statique sur le réseau anycast gratuit.

Playit Premium (3$/mois) : Débloque des tunnels TCP+UDP personnalisés pour les jeux sans support intégré (Starbound, Unturned, Vintage Story, BeamMP, etc.), sélection régionale de tunnel (le routage “anycast global” du niveau gratuit peut parfois envoyer un joueur proche via un datacenter éloigné), plus de ports allouables (4 → 16), règles de pare-feu supplémentaires, domaines .playit.plus ou votre propre domaine externe.

À noter : la prise en charge de domaines personnalisés et de routage régional sont des fonctionnalités Premium, non incluses dans le plan gratuit.

LocalXpose — La CLI la plus proche d’ngrok avec support UDP natif

Si vous aimez l’ergonomie de la CLI ngrok et souhaitez le remplaçant le plus proche qui supporte réellement UDP, c’est LocalXpose.

# Tunnel UDP natif via la CLI officielle LocalXpose
loclx tunnel udp --port 4545 --to 127.0.0.1:5060

Niveau “Starter” gratuit (0$) : 2 tunnels HTTP/HTTPS actifs seulement — pas de UDP, pas de TCP. Destiné à l’évaluation du produit, pas aux charges en temps réel.

Pro (8$/mois, 96$/an facturé annuellement) : Ce niveau débloque réellement UDP — 10 tunnels pour HTTP, HTTPS, TCP, TLS, et UDP, forwarding de ports TCP/UDP, sous-domaines et domaines personnalisés, tunnels wildcard, certificats Let’s Encrypt automatiques, et bande passante illimitée (sous réserve d’une politique d’utilisation acceptable).

Important : la prise en charge du tunneling UDP est une fonctionnalité payante, non disponible dans le plan gratuit.

Localtonet — Multi-protocol, paiement à l’usage

Localtonet a recentré son offre sur un modèle payant à l’usage : plutôt qu’un abonnement mensuel fixe, vous alimentez un solde qui se vide à environ 2$ par tunnel par mois d’activité réelle — vous n’êtes pas facturé si le tunnel est arrêté. Supporte HTTP/HTTPS, TCP, et UDP, chiffrement de bout en bout, et fonctionne depuis plus de 16 emplacements serveurs mondiaux.

Plan gratuit : 1 tunnel, 1 Go de bande passante, sessions de 30 minutes — suffisant pour tester, pas pour un serveur persistant.

Au-delà du tunneling, Localtonet inclut quelques fonctionnalités habituellement séparées : inspecteur de webhook, serveur de fichiers, liste blanche IP pour l’accès au tunnel, et une fonction “proxy mobile” Android qui transforme un téléphone en proxy HTTP/SOCKS5 via données mobiles — une fonctionnalité peu courante, utile pour des tests géographiques.

Pinggy — UDP sans installation via SSH

Pinggy n’apparaît pas dans la plupart des anciens comparatifs UDP, mais mérite d’être mentionné pour ceux qui l’utilisent déjà pour des tunnels HTTP/TCP ou l’exposition MCP : il a ajouté le support du tunnel UDP sans nécessiter d’installation client.

# Tunnel UDP avec la CLI Pinggy — pas besoin de télécharger un binaire
pinggy tunnel udp --to localhost:8080

# Ou via SSH brut, fonctionnant depuis n'importe quelle machine avec un client SSH
ssh -p 443 -R0:localhost:8080 udp@a.pinggy.io

Plan gratuit : Support complet des protocoles (HTTP/HTTPS, TCP, UDP, TLS) avec transfert de données illimité, mais les URLs de tunnel sont aléatoires et expirent après 60 minutes.

Pro (~3$/mois, ou environ 2,37–2,50$/mois facturé annuellement) : Ajoute des tunnels persistants, sous-domaines et domaines personnalisés, réservations de ports TCP/UDP persistantes, support de domaines wildcard, gestion d’équipe/appareils distants.

Parce que le client tunnel de Pinggy se présente sous forme d’un petit binaire compatible SSH (et fonctionne via ssh classique si un client SSH est déjà installé), il offre la friction d’installation la plus faible des quatre — vraiment utile pour un test UDP ponctuel sans vouloir installer une autre CLI.

6. Comparatif des fonctionnalités

Outil	Support UDP	Plan gratuit	UDP dans le plan gratuit ?	À partir de	Domaines personnalisés
ngrok	✕ Non (tous niveaux)	Limité, éphémère	✕	10$/mois	Payant, TCP uniquement
Playit.gg	✓ Oui	4 TCP + 4 UDP (jeux intégrés)	✓ (jeux intégrés)	3$/mois (Premium)	Premium uniquement
LocalXpose	✓ Oui	2 tunnels HTTP/HTTPS	✕ (plan Pro uniquement)	8$/mois (96$/an)	Pro uniquement
Localtonet	✓ Oui	1 tunnel, 1 Go, sessions 30 min	✓	~2$/tunnel/mois (pay-as-you-go)	Payant
Pinggy	✓ Oui	Données illimitées, sessions 60 min	✓	~3$/mois	Pro uniquement

7. Guides étape par étape

Guide A : Partager un serveur Minecraft sans port forwarding (Playit.gg)

1. Démarrez votre serveur local. Vérifiez qu’il est accessible à 127.0.0.1:25565.
2. Téléchargez et lancez l’agent Playit depuis la page officielle pour votre OS, ou via Docker.
3. Réclamez votre agent. Lors du premier lancement, la CLI affiche une URL de réclamation comme https://playit.gg/claim/xxxx-xxxx-xxxx. Ouvrez-la, connectez-vous, et acceptez.
4. Ajoutez un tunnel. Dans le tableau de bord, allez dans Tunnels → Ajouter un tunnel, choisissez votre jeu (ou Custom UDP/TCP), définissez le port local à 25565, et créez.
5. Partagez l’adresse. Playit attribue une adresse publique sous la forme something.gl.at.ply.gg:PORT — donnez-la à vos joueurs ; pas besoin de changer le routeur.

Guide B : Tunneliser le trafic SIP/RTP local pour test (LocalXpose)

1. Installer et authentifier : bash loclx account login <votre-token-d'accès> 2. Ouvrir un tunnel UDP vers votre port SIP local (nécessite un plan Pro) : bash loclx tunnel udp --port 4545 --to 127.0.0.1:5060
2. Noter l’endpoint public attribué depuis la sortie CLI (quelque chose comme us.loclx.io:4545).
3. Configurer votre client SIP ou softphone distant pour pointer vers cet hôte et port. La signalisation et le média UDP associé seront routés vers votre 5060 local.

Guide C : Tunnel UDP ultra-rapide, sans installation (Pinggy)

Pour un test rapide sans rien installer :

ssh -p 443 -R0:localhost:5060 udp@a.pinggy.io

Cela fonctionne depuis n’importe quelle machine avec un client SSH — ce qui est la majorité. C’est une méthode très rapide pour vérifier qu’un service UDP local est accessible avant de s’engager dans un tunnel persistant ailleurs. Rappel : les tunnels gratuits ici sont éphémères : l’URL est aléatoire et la session se termine après 60 minutes.

8. Optimisation des performances & latence

Le tunneling ajoute toujours un saut réseau, donc quelques bonnes pratiques permettent de réduire la latence pour le trafic en temps réel :

• Choisir la région edge la plus proche. Un hôte à Francfort passant par un edge US pour atteindre des joueurs à Berlin ajoute 100 ms+ inutilement. LocalXpose et Localtonet permettent de sélectionner une région spécifique ; le mode anycast global de Playit est généralement efficace mais pas garanti optimal — le pinning régional est une fonctionnalité Premium.
• Surveiller votre MTU. Les tunnels UDP encapsulent vos datagrammes dans un cadre spécifique, ce qui ajoute quelques octets de surcharge. Maintenir la taille des paquets autour de 1200–1300 octets laisse de la marge avant de risquer la fragmentation IP (MTU Ethernet standard de 1500 octets).
• Envisager un VPN mesh pour les groupes fermés. Si vous n’exposez pas un service publiquement — juste connectez une petite équipe de confiance — WireGuard, Tailscale ou ZeroTier peuvent surpasser un tunnel reverse-proxy en termes de latence, puisqu’il n’y a pas de relais tiers dans le chemin des données pour des connexions peer-to-peer privées. La contrepartie : tout le monde doit installer le client, contrairement à un tunnel public où les joueurs se connectent sans rien d’autre.

9. Le bon choix selon votre besoin

• Héberger un serveur de jeu pour des amis, gratuit ? Playit.gg. Support intégré pour la majorité des titres populaires, UDP inclus, IP statique DDoS-protégée, zéro coût pour l’usage courant.
• Chercher une CLI style ngrok qui supporte vraiment UDP, et ne pas vouloir payer ? LocalXpose Pro. La solution la plus proche d’un remplacement direct, à 8$/mois dès que vous avez besoin d’UDP.
• Besoin d’UDP + une boîte à outils plus large (inspection webhook, proxy mobile, liste blanche IP) et payer uniquement quand vous utilisez ? Le modèle pay-as-you-go de Localtonet vaut le coup.
• Juste vérifier un service UDP rapidement, sans installation ? Pinggy via SSH — la solution la plus simple et rapide, avec la limite que les sessions gratuites sont temporaires et l’URL non persistante.

ngrok reste excellent pour les API HTTP, webhooks, et l’inspection des requêtes — cela n’a pas changé. Mais pour tout ce qui parle UDP — serveurs de jeux, VoIP, télémétrie en temps réel — c’est encore le mauvais outil en 2026, et les quatre alternatives ci-dessus sont celles conçues pour cette tâche.

---

Changelog

• Suppression des métadonnées SEO intégrées et restructuration en Markdown clair.
• Vérification que le manque de support UDP natif d’ngrok est toujours confirmé en 2026, croisé avec plusieurs sources indépendantes y compris la documentation officielle.
• Vérification des mécanismes de TCP-over-TCP meltdown, avec reformulation pour précision.
• Correction des affirmations sur Playit.gg : la prise en charge de domaines personnalisés et la sélection régionale sont des fonctionnalités Premium (3$/mois), non incluses dans le plan gratuit. La portée du plan gratuit (support de jeux intégrés, 4 TCP + 4 UDP, IP statique DDoS) est confirmée par le site et la documentation.
• Correction sur LocalXpose : le tunneling UDP est réservé au plan Pro (8$/mois, 96$/an) — le plan “Starter” gratuit est limité à HTTP/HTTPS avec 2 tunnels. La syntaxe loclx tunnel udp a été mise à jour selon la documentation officielle.
• Mise à jour du modèle de tarification de Localtonet : remplacé par le modèle pay-as-you-go (~2$/tunnel/mois d’activité réelle), avec limites précises du plan gratuit (1 tunnel, 1Go, sessions 30 min).
• Ajout de Pinggy comme quatrième alternative, avec ses options de tunnel UDP via SSH et ses détails de tarification actuels — une omission notable étant donné sa croissance dans le support UDP.
• Suppression de la cellule de tableau sur les fonctionnalités TCP+UDP de Localtonet qui surévaluait la réservation de ports dans le plan gratuit ; mise à jour avec des données vérifiées.
• Réécriture des listes à puces “Caractéristiques clés” pour distinguer clairement les claims gratuits vs payants, car plusieurs étaient précédemment non spécifiés par niveau.