Beyond HTTP: Warum Game Devs & VoIP-Ingenieure ngrok nicht nutzen können

Current comparison
Looking for the main ngrok alternative guide?
We keep the latest ngrok alternative comparison, CLI commands, pricing notes, and webhook examples on one canonical page.
Open the InstaTunnel ngrok alternative guideQuick answer
Beyond HTTP: Warum Game Devs & VoIP-Ingenieure ngrok nicht nutzen können: quick comparison answer
Choose the tunnel tool based on the network model: public HTTPS URLs for webhooks and demos, private mesh access for internal apps, and managed infrastructure when policy controls matter most.
Which tunnel tool is best for public webhook testing?
Use a public HTTPS localhost tunnel with stable URLs. InstaTunnel focuses on webhook testing, demos, OAuth callbacks, and MCP endpoint workflows.
When should I choose a private network tool instead?
Choose a private mesh or Zero Trust tool when every user and service should stay inside a controlled private network.
Wenn Sie in den letzten zehn Jahren eine Web-App gebaut, einen Webhook eingerichtet oder eine API lokal getestet haben, haben Sie wahrscheinlich ngrok http 3000 ausgeführt. Es ist das Standardwerkzeug für die lokale Entwicklungsproduktivität — ein Befehl, der einen lokalen HTTP- oder HTTPS-Port öffentlich zugänglich macht, Router-Konfigurationen und Carrier-Grade NAT (CGNAT) umgeht, ohne Aufwand.
Doch außerhalb des Web-Stacks ändert sich die Geschichte. Versuchen Sie, einen lokalen Minecraft-Server zu teilen, einen Multiplayer-Build mit Remote-Playtestern zu testen oder einen SIP/RTP VoIP-Server zu debuggen, und ngrok hilft einfach nicht. Seine Architektur basiert auf TCP- und HTTP-Streams, und Stand 2026 unterstützt es immer noch kein natives UDP-Tunneling — eine Einschränkung, die direkt in ngrok-Dokumentation bestätigt wird, die TCP-Endpunkte listet, aber nichts für UDP.
Dieser Beitrag erklärt, warum UDP für Echtzeitanwendungen unverzichtbar ist, warum das Tunneln von UDP über einen TCP-Reverse-Proxy die Leistung ruiniert, und welche Tools heute wirklich das Problem lösen.
1. TCP vs. UDP: Das Kern-Dilemma
| TCP (HTTP, Webhooks, REST APIs) | UDP (Voice, Video, Spielstatus) | |
|---|---|---|
| Verbindungsmodell | Verbindungsorientiert | Verbindungslos |
| Zustellung | Garantiert, in Reihenfolge | Best-Effort, “fire-and-forget” |
| Fehlerbehandlung | Verlieren Pakete, Retransmission | Keine Retransmission |
| Overhead | Höher (Handshakes, ACKs) | Minimal |
| Priorität | Korrektheit | Latenz |
TCP garantiert, dass jedes gesendete Byte ankommt, in der richtigen Reihenfolge. Wenn ein Paket verloren geht, stoppt TCP die Verarbeitung, fordert eine Retransmission an und wartet — ein Verhalten, das als Head-of-Line (HoL) Blocking bekannt ist. Das ist genau richtig bei Datenbankabfragen oder Dateidownloads, bei denen ein beschädigtes Byte die Nutzlast zerstört.
UDP opfert Zuverlässigkeit für Geschwindigkeit. Es gibt kein Handshake, keine Reihenfolge-Garantie, keine Retransmission. Das ist genau richtig für:
- Game-Server. Ein schnelles Spiel könnte Spielerpositionen 60–128 Mal pro Sekunde broadcasten. Wenn ein Positionspaket verloren geht, will der Client es nicht 150 ms später retransmitiert bekommen — es will das nächste Paket, jetzt. Stale State zu retransmitieren verursacht Rubber-Banding und Jitter, die jeder Multiplayer-Game-Entwickler irgendwann kennt.
- VoIP und WebRTC. Bei einem SIP/RTP-Sprachanruf ist ein verlorener Audio-Frame besser durch einige Millisekunden Stille ersetzt, als zu spät geliefert zu werden. Über TCP retransmittiertes Audio verursacht kumulative Verzögerung und roboterartiges Stottern statt eines sauberen Abbruchs.
2. Warum man UDP nicht einfach in einen TCP-Tunnel packen kann
Eine berechtigte Frage: Kann man UDP-Verkehr nicht einfach in einen TCP-Tunnel mit Tools wie socat kapseln? Technisch ja — praktisch führt das zu einem bekannten Fehlerfall, dem TCP-Meltdown (oder TCP-over-TCP).
Wenn Sie Verkehr über eine verbindungsorientierte TCP-Verbindung tunneln, löst Paketverlust auf der zugrunde liegenden Verbindung die Staukontrolle des Tunnels aus: Er pausiert, um neu zu übertragen. Das anwendungsseitige, das auf UDP-ähnliche sofortige Zustellung ausgelegt ist, hat keine Ahnung, dass der Tunnel gestoppt ist. Es entstehen zwei unabhängige TCP-Steuerkreise — innerer und äußerer — die gegeneinander kämpfen. Das Ergebnis, wie es in Netzwerkreferenzen beschrieben wird, ist eine äußere TCP-Verbindung mit einem kollabierten Congestion Window, einem erhöhten Retransmission-Timeout und einem vollen Sendepuffer, der in beide Richtungen nicht entleert werden kann. Dieses Phänomen ist in der Netzwerktechnik gut bekannt (weshalb die meisten VPN-Protokolle ihre Tunnel nicht über TCP laufen lassen), und kein spezielles Problem eines einzelnen Tunneling-Anbieters.
Da ngrok’s TCP-basierte Relay-Architektur keine End-to-End-UDP-Datagram-Weiterleitung unterstützt, verwandelt das Erzwingen von Echtzeit-UDP-Verkehr durch ngrok einen 30-ms-Spiel- oder Sprachstream in ein ruckelndes Chaos.
3. Praxisfälle, die wirklich UDP brauchen
Game-Server-Hosting. Heimrouter sitzen zunehmend hinter CGNAT, was bedeutet, dass keine öffentliche IPv4-Adresse vorhanden ist, um einen Port weiterzuleiten. Ein Minecraft-, Valheim- oder eigener Unity/Unreal-Server benötigt einen Proxy, der öffentlichen UDP-Verkehr akzeptiert und an 127.0.0.1:<port> weiterleitet, mit minimalem Overhead, während die private IP des Hosts vor DDoS-Angriffen geschützt bleibt.
VoIP, Telefonie und WebRTC. Die Telefonie teilt sich in zwei Protokolle: SIP (Signalisierung — läuft meist über TCP oder UDP, typischerweise Port 5060) und RTP (der eigentliche Audio-/Video-Transport, fast immer hoch nummerierte UDP-Ports, meist im Bereich 10000–20000). Wenn ein Tunnel SIP-Signalisierung proxyed, aber RTP-Medien fallen lässt, verbindet sich der Anruf, bleibt aber komplett stumm.
4. Unterstützt ngrok 2026 UDP? Noch immer Nein.
Das bleibt die größte Lücke von ngrok im Vergleich zum Rest des Tunneling-Marktes. Mehrere unabhängige Vergleiche im Jahr 2026 bestätigen: ngrok unterstützt immer noch kein natives UDP, sondern nur HTTP, HTTPS und TCP.
Wer einen Minecraft-Server, eine Valheim-Welt oder ein UDP-fähiges IoT-Gerät aufbauen möchte, wird feststellen, dass die beliebtesten Tunneling-Optionen — inklusive ngrok — für diesen Verkehr einfach nicht funktionieren.
Diese Lücke ist genau der Grund, warum eine kleine Gruppe von UDP-fähigen Alternativen gewachsen ist: Playit.gg, LocalXpose, Localtonet und — zunehmend relevant, wenn man sie bereits für andere Tunnel nutzt — Pinggy.
5. Vier UDP-fähige Tunneling-Tools im Vergleich
Playit.gg — Speziell für Game-Server
Playit.gg wurde speziell entwickelt, um CGNAT- und Port-Forwarding-Probleme für Gamer und Selbst-Hoster zu lösen, mit über einer Million registrierter Nutzer und 19 Rechenzentren auf fünf Kontinenten.
[ Externer Player ]
│ (UDP-Pakete)
▼
[ Playit.gg Anycast Edge ]
│ (kapselnder Tunnel)
▼
[ Playit.gg Local Agent ] ──▶ [ Lokaler Game-Server (127.0.0.1:25565) ]
Kostenlose Version: Eingebaute Ein-Klick-Unterstützung für beliebte Titel (Minecraft Java/Bedrock, Palworld, Terraria, Factorio, Valheim, 7 Days to Die, Project Zomboid und mehr), inklusive UDP, wo das Spiel es braucht, sowie statische IP-DDoS-Schutz auf dem kostenlosen Anycast-Netz.
Playit Premium ($3/Monat): Ermöglicht benutzerdefinierte TCP+UDP-Tunnel für Spiele ohne integrierte Unterstützung (Starbound, Unturned, Vintage Story, BeamMP und andere), regionale Tunnel-Auswahl (das kostenlose “Global Anycast” Routing kann gelegentlich einen entfernten Spieler durch ein entferntes Rechenzentrum schicken), mehr zuweisbare Ports (4 → 16), zusätzliche Firewall-Regeln und benutzerdefinierte .playit.plus Domains oder eigene externe Domains.
Wichtig: Da die kostenlose Version hier nur lose beschrieben wird: Benutzerdefinierte Domains und regionale Routing-Optionen sind Premium-Funktionen, nicht im kostenlosen Plan enthalten.
LocalXpose — Der nächstgelegene ngrok-ähnliche CLI mit nativen UDP
Wenn Sie die CLI- ergonomie von ngrok mögen und die nächstgelegene Ersatzlösung suchen, die tatsächlich UDP unterstützt, ist LocalXpose die richtige Wahl.
# Native UDP-Tunnel via die offizielle LocalXpose CLI
loclx tunnel udp --port 4545 --to 127.0.0.1:5060
Kostenlose “Starter”-Version ($0): 2 aktive HTTP/HTTPS-Tunnel — kein UDP, kein TCP. Für Testzwecke, nicht für Echtzeit-Workloads.
Pro ($8/Monat, $96/Jahr bei Jahresabrechnung): Diese Version entsperrt UDP — 10 Tunnel für HTTP, HTTPS, TCP, TLS und UDP, Port-Weiterleitung für TCP/UDP, benutzerdefinierte Subdomains und Domains, Wildcard-Tunnel, automatische Let’s Encrypt-Zertifikate und unbegrenzte Bandbreite (bei Einhaltung der Nutzungsbedingungen).
Wichtig: UDP-Tunneling ist eine kostenpflichtige Funktion, nicht im kostenlosen Plan enthalten.
Localtonet — Multi-Protokoll, Bezahlmodell nach Nutzung
Localtonet setzt auf ein Pay-as-you-go-Modell: Statt eines festen monatlichen Abos laden Sie ein Guthaben auf, das bei etwa $2 pro Tunnel pro Monat tatsächlicher Laufzeit abgezogen wird — Sie werden nicht berechnet, wenn der Tunnel gestoppt ist. Unterstützt HTTP/HTTPS, TCP und UDP, End-to-End-Verschlüsselung und läuft an 16+ globalen Standorten.
Kostenloser Plan: 1 Tunnel, 1 GB Bandbreite, 30 Minuten Sessions — ausreichend zum Testen, nicht für einen dauerhaften Server.
Neben dem Kern-Tunneling bietet Localtonet einige Extras: Webhook-Inspektor, Dateiserver, IP-Whitelist für Tunnelzugang und eine Android “Mobile Proxy”-Funktion, die das Telefon in einen HTTP/SOCKS5-Proxy über mobile Daten verwandelt — eine eher ungewöhnliche Funktion, nützlich für Geo-Testing.
Pinggy — Zero-Install UDP via SSH
Pinggy taucht in den meisten älteren UDP-Tunneling-Übersichten kaum auf, ist aber erwähnenswert für Nutzer, die bereits HTTP/TCP-Tunnel oder MCP-Server exponieren: Es hat UDP-Tunnel-Unterstützung ohne Client-Installation.
# UDP-Tunnel mit dem Pinggy CLI — kein Binary-Download nötig
pinggy tunnel udp --to localhost:8080
# Oder via reines SSH, funktioniert auf jedem System mit SSH-Client
ssh -p 443 -R0:localhost:8080 udp@a.pinggy.io
Kostenloser Plan: Vollständige Protokoll-Unterstützung (HTTP/HTTPS, TCP, UDP, TLS) mit unbegrenztem Datenverkehr, aber Tunnel-URLs sind zufällig und laufen nach 60 Minuten ab.
Pro (~$3/Monat, ca. $2.37–$2.50/Monat bei Jahresabrechnung): Fügt persistente Tunnel, benutzerdefinierte Subdomains und Domains, dauerhafte TCP/UDP-Portsreservierungen, Wildcard-Domains und Team/Remote-Geräte-Management hinzu.
Da der Tunnel-Client von Pinggy als kleines, SSH-kompatibles Binary ausgeliefert wird (und auch mit ssh auf Systemen funktioniert, die bereits SSH installiert haben), ist die Einrichtung sehr einfach — ideal für einmalige UDP-Tests ohne zusätzliche CLI-Installation.
6. Funktionsvergleich
| Tool | UDP-Unterstützung | Kostenloser Plan | UDP im kostenlosen Plan? | Bezahlt ab | Benutzerdefinierte Domains |
|---|---|---|---|---|---|
| ngrok | ✕ Nein (alle Pläne) | Eingeschränkt, temporär | ✕ | $10/Monat | Bezahlsysteme, nur TCP |
| Playit.gg | ✓ Ja | 4 TCP + 4 UDP (inkl. Spiele) | ✓ (inkl. Spiele) | $3/Monat (Premium) | Nur Premium |
| LocalXpose | ✓ Ja | 2 HTTP/HTTPS-Tunnel | ✕ (nur Pro) | $8/Monat ($96/Jahr) | Nur Pro |
| Localtonet | ✓ Ja | 1 Tunnel, 1GB, 30 Min. | ✓ | ca. $2/Tunnel/Monat (Pay-as-you-go) | Bezahlt |
| Pinggy | ✓ Ja | Unbegrenzte Daten, 60 Min. Sessions | ✓ | ca. $3/Monat | Nur Pro |
7. Schritt-für-Schritt-Anleitungen
Anleitung A: Minecraft-Server ohne Port-Forwarding teilen (Playit.gg)
- Starte deinen lokalen Server. Stelle sicher, dass er unter
127.0.0.1:25565erreichbar ist. - Lade den Playit-Agent herunter und starte ihn vom offiziellen Download-Portal für dein OS oder nutze Docker.
- Registriere deinen Agenten. Beim ersten Start zeigt die CLI eine Claim-URL wie
https://playit.gg/claim/xxxx-xxxx-xxxx. Öffne sie, melde dich an und bestätige die Claim-Anfrage. - Füge einen Tunnel hinzu. Im Dashboard geh zu Tunnels → Tunnel hinzufügen, wähle dein Spiel (oder Benutzerdefiniertes UDP/TCP), setze den lokalen Port auf
25565und erstelle den Tunnel. - Teile die Adresse. Playit weist eine öffentliche Adresse im Format
something.gl.at.ply.gg:PORTzu — diese kannst du an deine Spieler weitergeben; keine Router-Änderungen nötig.
Anleitung B: Lokalen SIP/RTP-Verkehr für Tests tunneln (LocalXpose)
- Installiere und authentifiziere:
bash loclx account login <dein-access-token>2. Öffne einen UDP-Tunnel zu deinem lokalen SIP-Port (benötigt einen Pro-Plan):bash loclx tunnel udp --port 4545 --to 127.0.0.1:5060 - Notiere die zugewiesene öffentliche Adresse aus der CLI-Ausgabe (z.B.
us.loclx.io:4545). - Verwende diese Adresse in deinem entfernten SIP-Client oder Softphone. Signalisierung und UDP-Medien im zugehörigen Bereich werden an deinen lokalen Port
5060weitergeleitet.
Anleitung C: Schnellster UDP-Tunnel, ohne Installation (Pinggy)
Für einen schnellen Einzeltetst, ohne etwas zu installieren:
ssh -p 443 -R0:localhost:5060 udp@a.pinggy.io
Funktioniert auf jedem System mit SSH-Client — ideal, um eine lokale UDP-Servicerecherche durchzuführen, bevor man einen dauerhaften Tunnel einrichtet. Beachte: Die kostenlose Session ist temporär: URL ist zufällig, Session endet nach 60 Minuten.
8. Leistung & Latenz optimieren
Das Tunneln fügt immer einen Netzwerk-Hops hinzu. Einige Tipps, um die Latenz bei Echtzeitverkehr zu minimieren:
- Wähle die nächste Edge-Region. Ein Host in Frankfurt, der durch eine US-Edge zu den Spielern in Berlin tunnelt, erhöht die Latenz um 100 ms+ ohne Grund. LocalXpose und Localtonet erlauben die Auswahl einer bestimmten Region; Playit nutzt globales Anycast, was meist gut ist, aber nicht garantiert optimal — regionale Pinning ist eine Premium-Funktion.
- Behalte die MTU im Auge. UDP-Tunnel kapseln Datagramme in Tunnel-Frames, was einige Bytes Overhead verursacht. Anwendungspakete um 1200–1300 Bytes lassen noch Spielraum, bevor IP-Fragmentierung bei der Ethernet-MTU von 1500 Byte droht.
- Nutze ein Mesh-VPN für geschlossene Gruppen. Wenn du keinen öffentlichen Dienst anbietest, sondern nur eine kleine vertrauenswürdige Gruppe verbindest, sind WireGuard, Tailscale oder ZeroTier oft schneller bei Latenz, da keine Drittanbieter-Relay im Datenpfad ist. Der Nachteil: Jeder braucht den Client installiert, im Gegensatz zu einem öffentlichen Tunnel.
9. Welches Tool solltest du wählen?
- Einen Game-Server für Freunde hosten, kostenlos? Playit.gg. Integrierte Unterstützung für die meisten Titel, UDP inklusive, DDoS-geschützte statische IP, kostenlos für Standardfälle.
- Ein ngrok-ähnliches CLI, das wirklich UDP kann, und du zahlst gern? LocalXpose Pro. Nächster Drop-in-Ersatz für ngrok, ab 8$/Monat, wenn UDP gebraucht wird.
- Benötigst du UDP plus ein breiteres Toolkit (Webhook-Inspektion, Mobile Proxy, IP-Whitelist) und zahlst nur, wenn du es nutzt? Localtonets Pay-as-you-go ist eine gute Option.
- Nur eine schnelle UDP-Überprüfung, ohne Installation? Pinggy via SSH — die einfachste Option, aber kostenlose Sessions sind zeitlich begrenzt und die URL nicht persistent.
ngrok bleibt hervorragend für HTTP-APIs, Webhooks und Request-Inspektion — das hat sich nicht geändert. Für alles, was UDP spricht — Game-Server, VoIP, Echtzeit-Telemetrie — ist es 2026 noch immer das falsche Werkzeug. Die vier oben genannten Alternativen sind speziell dafür gebaut.
Changelog
- Entfernt eingebettete SEO-Metadaten, strukturiert in klare Markdown-Überschriften.
- Bestätigt, dass ngrok 2026 immer noch kein natives UDP unterstützt, durch mehrere unabhängige Quellen inklusive ngrok-Dokumentation.
- Überprüft TCP-over-TCP-Meltdown-Mechanik, formuliert präzise.
- Korrigiert Playit.gg: Benutzerdefinierte Domains und regionale Tunnel-Optionen sind Premium-Funktionen ($3/Monat), nicht im kostenlosen Plan. Der kostenlose Plan unterstützt integrierte Spiel- und UDP-Unterstützung, 4 TCP + 4 UDP-Tunnel, DDoS-geschützte statische IP.
- Korrigiert LocalXpose: UDP-Tunneling ist nur im Pro-Plan ($8/Monat, $96/Jahr) verfügbar — der kostenlose “Starter”-Plan ist nur HTTP/HTTPS mit 2 Tunneln. Aktualisiert die CLI-Syntax entsprechend.
- Aktualisiert Localtonet: Preis auf Pay-as-you-go (~$2/Tunnel/Monat), mit Limits im kostenlosen Plan (1 Tunnel, 1GB, 30 Min. Sessions).
- Fügt Pinggy als vierte Alternative hinzu: inklusive SSH-basiertem UDP-Tunnel, aktuelle Preis- und Tarifinfos. Ein bedeutender Zusatz, da es zunehmend UDP unterstützt.
- Entfernt die unbestätigte Tabelle mit TCP+UDP-Features, ersetzt durch aktuelle, verifizierte Daten.
- Überarbeitet alle Feature-Listen, um kostenlose vs. kostenpflichtige Funktionen klar zu unterscheiden, da mehrere vorher ohne Tier-Qualifikation genannt wurden.
Related InstaTunnel pages
Continue from this article into the most relevant product guides and workflows.
Related Topics
Keep building with InstaTunnel
Read the docs for implementation details or compare plans before you ship.