Warum Entwickler ngrok durch Rust-basierte Tunnel ersetzen

Wenn Sie schon einmal Webhooks entwickelt, APIs getestet oder versucht haben, einen Heimlabor-Server remote zu erreichen, kennen Sie das Standardverfahren: ngrok installieren, einen Befehl ausführen, eine öffentliche URL erhalten, die an Ihren localhost weiterleitet. Seit Jahren war dies die Standardlösung für NAT-Traversal und lokale Tunneling.

Doch ein Wandel ist im Gange, vor allem bei Edge-Computing-Ingenieuren, IoT-Hobbyisten und Heimlaboranten. Während kommerzielle Tunneling-SaaS-Produkte immer mehr Enterprise-Features (und entsprechende Preise) hinzufügen, wägen Entwickler zunehmend Open-Source-Alternativen ab — viele davon in Rust geschrieben.

Go-basierte frp (Fast Reverse Proxy) ist seit langem die dominierende Open-Source-Option und bleibt mit großem Abstand das größte Projekt in diesem Bereich. Neben ihm haben sich eine kleinere Gruppe von Rust-Tools — rathole, bore und der gehostete Dienst tunnelto — etabliert, die durch den Verzicht auf Funktionsvielfalt zugunsten eines kleineren Footprints und, im Fall von rathole, speziell besserem Verhalten unter Last auf eingeschränkter Hardware, echte Anhängerschaften gewonnen haben.

Hier ein ehrlicher Blick darauf, was diese Tools tatsächlich gut machen, wo das “Rust schlägt Go”-Narrativ standhält und wo es übertrieben wird.

Die Free-Tier-Frage: Was ngrok im kostenlosen Plan wirklich bietet

Viele Inhalte zum “Wechsel zu X” bei ngrok wiederholen eine Behauptung, die seit einigen Jahren nicht mehr stimmt: Dass Nutzer im kostenlosen Tarif eine zufällige Subdomain erhalten, die sich bei jeder Tunnel-Neuverbindung ändert. Das war in den frühen Jahren von ngrok noch so, doch seit 2023 weist ngrok jedem kostenlosen Konto eine persistente Entwickler-Domain zu (wie dein-zugewiesener-name.ngrok-free.app), die bei Neustarts gleich bleibt. Die eigene Dokumentation bestätigt, dass kostenlose Endpunkte keine Session-Timeouts haben und unbegrenzt im Hintergrund laufen können.

Was der kostenlose Plan nicht beinhaltet, ist die Möglichkeit, einen eigenen Subdomain-Namen zu wählen oder eine eigene Domain zu verwenden — das ist nur bei kostenpflichtigen Plänen möglich (Hobbyist für einen benutzerdefinierten *.ngrok.app-Namen, Pay-as-you-go für eigene Domains). Die eigentliche Hürde ist also nicht URL-Rotation, sondern die Tatsache, dass man ohne Bezahlung keinen eigenen Namen/Domain branden oder wiederverwenden kann, und TCP-Endpunkte eine verifizierte Kreditkarte benötigen, selbst im kostenlosen Tarif.

Diese Unterscheidung ist wichtig, weil sie der eigentliche Grund ist, warum Entwickler nach Alternativen suchen — nicht ein Mythos von 2-Stunden-Sessions oder ständig wechselnden URLs.

Der Fall für Rust am Edge

Der Garbage Collector von Go führt zu nicht-deterministischen Pausenverhalten. Das ist auf einer Cloud-VM kaum bemerkbar, aber bei dauerhaft hoher Verbindungszahl auf eingeschränkter Hardware — etwa einem OpenWrt-Router oder einem frühen Raspberry Pi — können GC-Pausen und Puffergroßwerden den Speicherverbrauch so hoch treiben, dass der Linux OOM-Killer aktiviert wird.

Rust erreicht Speichersicherheit ohne Garbage Collector, wodurch keine GC-Pausen entstehen und der Speicherverbrauch auch bei Verbindungsspitzen relativ konstant bleibt. Zusammen mit tokio’s asynchronem Runtime ermöglicht dies, dass Rust-Tunnel kleine, dependency-arme Binärdateien mit vorhersehbarer Latenz liefern.

Das ist die Theorie. Hier die praktische Umsetzung bei jedem Tool.

1. rathole: Der schlankere frp-Alternativ

Ursprünglich vom GitHub-Nutzer rapiz1 entwickelt und jetzt unter der Organisation rathole-org gepflegt, hat rathole aktuell 14.000 GitHub-Sterne und 800 Forks (Stand heute), lizenziert unter Apache-2.0.

Was es weglässt

rathole verzichtet bewusst auf das Web-Dashboard, Load Balancer und Plugin-System von frp und konzentriert sich auf TCP/UDP-Weiterleitung mit einer Client/Server-TOML-Konfiguration.

Die Benchmark-Behauptung, mit Kontext

Das README von rathole gibt an, dass es eine ähnliche Latenz wie frp erreicht, aber mehr Verbindungen mit weniger Speicher verarbeitet. Die genauen Zahlen stammen aus docs/benchmark.md von rathole: Bei QPS-Werten von 1 bis 3.000 zeigten rathole und frp nahezu identische Latenz; bei 4.000 QPS begann frp Fehler zu melden, die Latenz stieg in den Sekundenbereich, während ratholes Latenz konstant blieb. Bei einem 30-sekündigen Dauerbelastungstest wuchs der Speicherverbrauch von frp deutlich, während rathole stabil blieb.

Zwei Dinge vorweg: Der Benchmark wurde einmal auf einer einzelnen Maschine (einem Arch Linux-Rechner mit Dual Xeon E5-2620) im Dezember 2021 durchgeführt und verglich eine frühe rathole-Version mit frp v0.38.0 — einer Version, die heute etwa 30 Releases hinter der aktuellen v0.70.x-Reihe von frp liegt. Es ist außerdem ein Loopback-Test, der laut rathole-Dokumentation eher CPU-gebunden ist als echte Netzbedingungen. Die Richtungserkennung (geringer, konstanter Speicherverbrauch unter Last) ist plausibel, aber es gibt keine aktuellen unabhängigen Benchmarks, die die genauen Zahlen gegen modernes frp bestätigen.

Herausragende Features

• Das Noise-Protokoll: rathole kann optional das Noise-Protokoll für Transportverschlüsselung verwenden, anstelle selbstsignierter TLS-Zertifikate. Noise sichert auch den Handshake von WireGuard, und es schützt die Client-zu-Server-Transportlayer von WhatsApp — die tatsächliche Ende-zu-Ende-Verschlüsselung von WhatsApp ist jedoch ein separates System, das Signal Protocol. Der Vergleich mit WireGuard ist also präzise; der Vergleich mit WhatsApp ist korrekt, aber enger gefasst als “die gleiche Verschlüsselung, die WhatsApp für Ihre Nachrichten nutzt.”
• Kleines Binary: ratholes eigener Build-Guide ermöglicht einen minimalen x86_64-Build von 574 KiB, verglichen mit etwa 10 MiB für frpc im gleichen Build-Prozess.
• Pflicht-Token pro Dienst: Jeder Dienst benötigt ein eigenes Token, was eine deny-by-default-Strategie ist.
• Hot-reloadable Konfiguration: Dienste können ohne Neustart hinzugefügt oder entfernt werden.

Wartungsstatus

Das Wichtigste vorweg: Das letzte gekennzeichnete Release von rathole, v0.5.0, wurde am 1. Oktober 2023 veröffentlicht — vor knapp drei Jahren. Das stimmt mit häufig behaupteten Angaben überein. Es ist aber nicht veraltet: Das Repository hat einen aktiven Entwicklungszweig mit automatischen Builds (zuletzt Anfang 2026), und Issues/PRs werden noch bis 2025 und 2026 geöffnet und gemerged. Es ist also treffender, rathole als “stabil und leicht gewartet, ohne neue stabile Tags” zu bezeichnen, als “aktuell in Entwicklung” oder “veraltet”.

2. bore: Das minimalistische TCP-Tunnel-Tool

Erstellt von Eric Zhang und MIT-lizenziert, hat bore aktuell 11.100 GitHub-Sterne und 493 Forks, mit der neuesten Version (v0.6.0) im Juni 2025.

Der Code

Der gesamte Client- und Server-Code von bore umfasst etwa 400 Zeilen asynchrones Rust auf Basis von tokio — klein genug, um in einer Sitzung gelesen zu werden.

So funktioniert es

bore local 8000 --to bore.pub

Dies öffnet den lokalen Port 8000 bei bore.pub:<Zufallsport> über den öffentlichen Server des Maintainers. Für Eigenhosting:

bore server

Ein Sicherheits-Hinweis

bore unterstützt ein optionales --secret-Flag (oder die Umgebungsvariable BORE_SECRET), das Clients erfordert, einen gemeinsamen Geheimschlüssel via HMAC-Challenge nachzuweisen, bevor ein Tunnel akzeptiert wird. Das ist echte Authentifizierung für den Zugriff auf den Tunnel. Laut eigener Dokumentation gilt dieses Geheimnis nur für den initialen Handshake — der durchgeleitete Traffic ist standardmäßig nicht verschlüsselt. Wenn Sie etwas anderes tunneln als einen Dienst, der bereits TLS nutzt (z.B. einen HTTPS-Entwicklungsserver), sollten Sie das wissen, bevor Sie es auf sensible Systeme richten. Diese Nuance fehlt in den meisten Online-Vergleichen zwischen bore und ngrok.

3. tunnelto: Zwei Projekte, ein Name

Hier war die größte Korrektur notwendig. “tunnelto” bezieht sich tatsächlich auf zwei separate, unabhängige Projekte, und ihre Verwechslung (wie in Vergleichsartikeln üblich) führt zu einem irreführenden Bild.

tunnelto.dev (agrinman/tunnelto auf GitHub) ist das Open-Source-Rust-Projekt, das unter MIT-Lizenz steht. Die letzte Version wurde 2021 veröffentlicht, und laut eigenen Angaben wurde seitdem nichts mehr aktualisiert — es fehlen Funktionen wie benutzerdefinierte Domains, Endpoint-Authentifizierung und statisches Hosting.

tunnelto.me ist ein separater, aktiv gepflegter gehosteter Dienst, der zufällig den gleichen Namen trägt. Laut eigener Webseite (Stand Juni 2026) basiert tunnelto.me nicht auf dem veralteten Code von tunnelto.dev — in der Vergleichstabelle wird tunnelto.dev explizit als “nicht aktiv gepflegt seit 2021” gekennzeichnet. Die Preisgestaltung:

Plan	Preis	Benutzerdefinierte Domain	Tunnel-Laufzeit
Kostenlos	0 €	1, inklusive	1 Stunde — muss neu erstellt werden
Hobbyist	2 €/Monat	1	Persistierend (über Neustarts hinweg)
Plus	10 €/Monat	3	Persistierend
Pro	20 €/Monat	5	Persistierend

Das wirklich Bemerkenswerte ist, dass im kostenlosen Tarif eine benutzerdefinierte Domain enthalten ist — das ist bei den meisten Wettbewerbern (inklusive ngrok und bore) nur gegen Bezahlung möglich. Allerdings laufen die Tunnel im kostenlosen Tarif nur eine Stunde, müssen dann neu erstellt werden — eine Art Session-Limit, nur in anderer Form. Für Tunnel, die über Nacht oder einen Neustart hinaus bestehen sollen, ist der Tarif für 2 €/Monat (Hobbyist) notwendig. Authentifizierung (Bearer/Basic) ist ebenfalls kostenpflichtig.

Vergleichsübersicht

Feature	ngrok	frp	rathole	bore	tunnelto.me
Programmiersprache	Go	Go	Rust	Rust	Nicht öffentlich spezifiziert
GitHub-Sterne	— (geschlossen)	~107.000	14.000	11.100	— (gehostet, geschlossen)
Fokus	Kommerzielle SaaS	Selbstgehostet, funktionsreich	Selbstgehostet, ressourcenschonend	Selbstgehostet, minimal	Gehosteter SaaS, benutzerdefinierte Domains
Kostenlose Domain, Tier	Nein (nur persistent dev domain)	Ja (selbstgehostet)	Ja (selbstgehostet)	N/A (Port-basiert)	Ja, aber 1-Stunden-Limit
Binary/Agent-Größe	Proprietärer Agent	~10 MiB (frpc)	~574 KiB (Minimalbuild)	Klein, ca. 400 Zeilen	Native Binary (Sprache unbestätigt)
Verschlüsselung standardmäßig	Ja (HTTPS)	TLS optional	TLS oder Noise optional	Nein — nur Handshake-Auth	Ja (HTTPS standard)
Letztes Release	Kontinuierlich	Aktiv in Entwicklung (v0.70.x, 2026)	v0.5.0, Okt 2023 (Entwicklungszweig aktiv)	v0.6.0, Juni 2025	Aktiv gepflegt (2026)
Setup-Komplexität	Sehr niedrig	Hoch (viele Konfigurationsoptionen)	Mittel (Client/Server TOML)	Null (ein Befehl)	Sehr niedrig

frp: Ein fairer Blick

Jede “Rust ersetzt Go”-Erzählung sollte anerkennen, dass frp kein veraltetes, aufgeblähtes Projekt ist. Es hat derzeit etwa 107.000 Sterne und 15.000 Forks und veröffentlicht regelmäßig neue Minor-Releases — v0.68 bis v0.70 im ersten Halbjahr 2026, inklusive aktiver Sicherheitsupdates (im April 2026 wurde eine mittlere Sicherheitslücke behoben). Wenn Ihre Anforderungen über einfache TCP/UDP-Weiterleitung hinausgehen — Plugins, Web-Dashboard, SSH-Gateway, breitere Protokollunterstützung — bleibt frp die funktionsreichste Open-Source-Option. “GC-Pausen bei extremer Last” sind eine schmale, aber reale Abwägung, kein Beweis für Rückstand.

So richten Sie einen Low-RAM-Localhost-Tunnel (rathole auf Raspberry Pi) ein

Wenn Sie einen Raspberry Pi zuhause und einen günstigen VPS in der Cloud haben, dauert die Einrichtung eines rathole-Tunnels etwa zehn Minuten.

Schritt 1 — VPS konfigurieren. Laden Sie die rathole-Binärdatei für Ihre Architektur von der Releases-Seite. Erstellen Sie server.toml:

[server]
bind_addr = "0.0.0.0:2333"

[server.services.mein_pi_ssh]
token = "verwende_ein_geheimnis_das_nur_du_kennst"
bind_addr = "0.0.0.0:5202"

Starten Sie:

./rathole server.toml

Schritt 2 — Raspberry Pi konfigurieren. Laden Sie die ARM/AArch64-Binärdatei herunter. Erstellen Sie client.toml:

[client]
remote_addr = "DEINE_VPS_IP:2333"

[client.services.mein_pi_ssh]
token = "verwende_ein_geheimnis_das_nur_du_kennst"
local_addr = "127.0.0.1:22"

Starten Sie:

./rathole client.toml

Schritt 3 — Verbinden. Von überall:

ssh pi@DEINE_VPS_IP -p 5202

Für den produktiven Einsatz: Beide Befehle in systemd-Dienstdateien einbinden (rathole-Repo enthält Beispiel-Unit-Files), damit sie beim Booten oder Absturz automatisch neu starten. Wenn Sie Verschlüsselung ohne Zertifikatsverwaltung möchten, fügen Sie einen [client.transport.noise] / [server.transport.noise]-Block mit dem Noise-Protokoll anstelle des oben genannten Token-Setups hinzu — das Token authentifiziert nur den Dienst, verschlüsselt aber den Tunnel nicht.

Fazit

• Brauchen Sie eine stabile URL für Webhook-Tests mit minimalem Aufwand? tunnelto.me’s kostenloser benutzerdefinierter Domain ist wirklich nützlich — planen Sie aber 2 €/Monat ein, wenn Sie es länger als eine Stunde brauchen.
• Möchten Sie einen TCP-Port mit einem Kollegen teilen, ohne viel Konfiguration, und sind Sie damit einverstanden, dass die Verbindung selbst nicht verschlüsselt ist, sofern Ihr Upstream-Service das nicht übernimmt? bore.
• Betreiben Sie eine Reihe von Edge-Geräten mit wenig RAM und wollen den kleinsten Footprint mit nachweislich stabiler Lastfähigkeit? rathole — aber rechnen Sie nicht mit einem neuen stabilen Release in Kürze.
• Brauchen Sie Plugins, Dashboard, breite Protokollunterstützung oder sind bereits mit Go-Tools vertraut? frp ist nach wie vor die vollständigste Open-Source-Option und wird aktiv weiterentwickelt.
• Benötigen Sie Enterprise-Features — SSO, Traffic-Policy, Audit-Logs, ein verwaltetes Edge-Netzwerk — und sind bereit, dafür zu bezahlen? Dann ist ngrok die richtige Wahl; sein kostenloser Tarif ist brauchbarer, als sein Ruf vermuten lässt, aber es konkurriert nicht auf derselben Ebene wie diese selbstgehosteten Tools.

---

Changelog

• Entfernt alle eingebetteten SEO/Affiliate-Metadaten: Inline-Quellen-Fußnoten (z.B. “InstaTunnel”, “tunnelto.me +1”), Stockfoto-Attributions-Captions und den parenthetischen Untertitel im Original-Headline.
• Korrigiert die zentrale Behauptung zu ngrok: Kostenlose Konten verwenden seit 2023 eine persistente Entwickler-Domain, keine zufällig rotierende, und Endpunkte haben kein Session-Timeout laut aktueller ngrok-Dokumentation. Das eigentliche Limit im Free-Tarif ist die Nicht-Möglichkeit, einen eigenen Namen/Domain zu wählen — nicht URL-Rotation. (Quelle: ngrok-Dokumentation, “Free Plan Limits” und “Static dev domains” Blog-Post.)
• Bestätigt und aktualisiert die GitHub-Sterne/Fork-Zahlen: frp ca. 107.000 Sterne/15.000 Forks (frühere “106.000+” ist jetzt aktualisiert); rathole 14.000 Sterne/800 Forks (die Angabe “~14.000” stimmt weiterhin); bore 11.100 Sterne/493 Forks (frühere Angabe “fast 10.000” ist jetzt höher).
• Bestätigt die Benchmark-Zahlen von rathole (3.000 vs. 4.000 QPS) direkt anhand der docs/benchmark.md und ergänzt die Methodik: Einzelmaschinen-Loopback-Test von Dezember 2021, durchgeführt von den Maintainers gegen frp v0.38.0 (heute ca. 30 Releases veraltet), kein unabhängiger Vergleich.
• Korrigiert die minimale Binary-Größe von rathole: Das eigene Build-Guide-Dokument nennt 574 KiB als Minimalgröße (im Gegensatz zu den ca. 500 KiB im Entwurf, der richtungsweisend war, aber nicht die dokumentierte Zahl), verglichen mit einem ca. 10 MiB frpc-Build.
• Korrigiert/nuanciert die Aussage zum Noise-Protokoll: Noise sichert WireGuard-Handshake und WhatsApp-Client-zu-Server-Transport, aber WhatsApps Ende-zu-Ende-Verschlüsselung nutzt das separate Signal Protocol — die ursprüngliche Formulierung deutete an, Noise sichere WhatsApp-Nachrichten direkt.
• Korrigiert den Wartungsstatus von rathole: bestätigt, dass v0.5.0 (1. Okt 2023) das letzte gekennzeichnete Release ist, aber ergänzt, dass das Projekt einen aktiven Entwicklungszweig und laufende Issue/PR-Aktivität bis 2025–2026 hat, nicht vollständig veraltet.
• Hinzugefügt eine faire Einschätzung zu frp: Es ist aktiv in Entwicklung (monatliche Releases bis 2026, kürzliche Sicherheitsupdates), nicht das stagnierende Projekt, das durch “Rust schlägt frp”-Narrativ impliziert wird.
• Hinzugefügt eine wichtige Sicherheitsinfo zu bore: Das optionale --secret-Flag authentifiziert den Tunnel-Handshake via HMAC, verschlüsselt aber den durchgeleiteten Traffic standardmäßig nicht — eine wichtige Einschränkung bei Nicht-TLS-überwachten Upstream-Diensten.
• Korrigiert eine bedeutende Verwechslung: Der Entwurf behandelte “tunnelto” als ein Projekt mit Open-Source-Kern (tunnelto.dev) und einer gehosteten Schicht. Diese sind zwei getrennte, unabhängige Projekte. tunnelto.dev (agrinman, MIT, Rust) ist seit 2021 inaktiv. tunnelto.me ist ein eigenständiger, aktiv gepflegter kommerzieller Dienst; die Programmiersprache ist öffentlich nicht dokumentiert, daher wurde die Aussage “geschrieben in Rust” für dieses Produkt entfernt.
• Korrigiert die Aussage zum kostenlosen Tier von tunnelto.me: Laut eigener Preisseite sind die Tunnel auf 1 Stunde beschränkt und müssen neu erstellt werden; nur der Tarif für 2 €/Monat (Hobbyist) bietet dauerhafte Tunnel. Die ursprüngliche Formulierung deutete an, die kostenlose Domain hätte keine solche Begrenzung.
• Erweitert die Vergleichstabelle um GitHub-Sterne, Verschlüsselung-Standard und letzte Release-Daten, alle basierend auf den Repos/Dokumentationen von heute.
• Erweitert mit einer “faire Worte für frp”-Sektion und klärt die Empfehlungen im Fazit entsprechend der korrigierten Fakten.