rathole vs. frp vs. ngrok: Was die Benchmarks wirklich zeigen

CGNAT und IPv4-Reserven haben das “ein Port am Router öffnen” für die meisten Heimanschlüsse und viele Cloud-Deployments unpraktisch gemacht. Wenn du Webhooks testest, einen Homelab-Dienst betreibst oder Remote-IoT-Geräte verwaltest, brauchst du eine Lösung, die NAT-Traversal übernimmt. Dabei tauchen ständig drei Namen auf: ngrok, frp und der neuere Rust-Vertreter, rathole. Hier erfährst du, was jeder tatsächlich macht, und — da viel Begeisterung online von denselben Quellen kopiert wird — was die Zahlen hinter den Behauptungen wirklich sagen.

ngrok: bequem, zentralisiert und immer noch bandbreitenbegrenzt

Ngrok bleibt bei seinem Versprechen: Ein Befehl, eine öffentliche HTTPS-URL, die auf deinen lokalen Server zeigt, kein eigener Server nötig. Diese Bequemlichkeit entsteht durch Routing deines Traffics über ngroks Edge-Netzwerk, was auch die Grenzen aufzeigt.

Stand 2026 begrenzt ngrok die kostenlose Version auf 1 GB Bandbreite pro Monat mit einem aktiven Endpoint, und es weist bei jedem Neustart eine zufällige .ngrok-free.app-Subdomain zu — problematisch bei Webhooks. Der HTML-Traffic in der Free-Variante zeigt eine Warnseite (übersprungen via API-Header, aber nicht bei browserbasierten Demos). Für eigene Subdomains ist ein kostenpflichtiger Plan nötig, ab Personal ($8/Monat, 5 GB, dann $0.10/GB Überziehung), gefolgt von Pro ($20/Monat, 15 GB) und Enterprise ($39/Monat), mit nutzungsabhängigen Preisen ab $18/Monat für Produktions-Workloads.

Die größere Einschränkung ist die Protokollunterstützung: ngrok unterstützt native UDP-Tunneling bei keinem Tarif. Für Spieleserver, VoIP und IoT-Protokolle wie CoAP oder MQTT-over-UDP ist es daher ungeeignet — nur HTTP, HTTPS, TCP und TLS sind möglich. Was ngrok wirklich stark macht, ist die Tunnelverwaltung: Request-Replay, Traffic-Inspektion, Webhook-Validierung, OAuth/SAML/OIDC-Absicherung und eine ausgefeilte API für die Tunnel-Lifecycle-Management — das versuchen frp oder rathole nicht zu kopieren.

frp: ausgereift, aktiv entwickelt und größer als die Alternativen

frp (Fast Reverse Proxy), geschrieben in Go, ist die etablierte Self-Hosting-Option: frps läuft auf einem VPS mit öffentlicher IP, frpc verbindet sich hinter NAT. Es lohnt sich, den aktuellen Stand von frp genau zu betrachten, denn viele Online-Behauptungen wie “frp ist aufgebläht und unsicher” sind veraltet.

frp wird sehr aktiv weiterentwickelt — Version 0.70.0 wurde am 11. Juli 2026 veröffentlicht, und das Projekt hat über 106.000 GitHub-Sterne sowie etwa 15.000 Forks, deutlich mehr als jede Rust-Alternative in diesem Bereich. TLS-Verschlüsselung ist seit v0.50.0 standardmäßig aktiviert, moderne Konfigurationen nutzen TOML, YAML oder JSON (das alte INI-Format ist veraltet). Authentifizierung unterstützt statische Tokens und OIDC.

Zur Sicherheitsfrage “Clients können beliebige Ports öffnen”: Das stimmt nur, weil frp standardmäßig keine Portbindung einschränkt. Die Server-Konfiguration unterstützt die Direktive allowPorts, die Portbereiche whitelisted, sowie maxPortsPerClient. Das ist aber eine Option, nicht die Standardeinstellung. Ohne allowPorts kann ein Client mit gültigem Token jeden Port auf dem Server anfragen. Das ist ein wichtiger Punkt in Deployment-Guides, aber kein architektonischer Fehler.

Der Kritikpunkt an der Garbage Collection ist architektonisch berechtigt — Go’s GC führt zu unvorhersehbaren Pausen, die eine Sprache ohne GC vermeiden würde —, aber frp hat sich damit in hunderten von Produktions-Deployments bewährt. Ob GC-Pausen relevant sind, hängt stark vom Traffic ab, nicht nur von der Sprache.

rathole: wirklich schnell, aber seit 2023 praktisch nicht mehr gepflegt

Hier muss die Erzählung “Entthronung” korrigiert werden. rathole, ursprünglich von GitHub-Nutzer rapiz1 entwickelt und jetzt unter rathole-org gepflegt, ist ein Rust-Reverse-Proxy, der als schlankere Alternative zu frp konzipiert ist: Nur TCP/UDP-Weiterleitung, kein Webserver, kein Load Balancer, kein Plugin-System.

Der Pflegezustand ist wichtiger als die Benchmarks. Das letzte Release v0.5.0 wurde am 1. Oktober 2023 veröffentlicht. Stand Mitte 2026 sind das knapp drei Jahre ohne neues Release, und die Community hat offen gefragt, ob eine besser gepflegte Alternative aufgetaucht ist. Das Repository hat 13.9k Sterne und 791 Forks — ein respektiertes Projekt, aber nur etwa ein Zehntel der Größe und Community von frp, ohne die Release-Frequenz. Für Hobby-Projekte auf einem Raspberry Pi ist das akzeptabel, für produktive Infrastruktur eher riskant, vor allem bei Sicherheitslücken.

Was rathole tatsächlich bietet:

• Kleine Binärdatei. Laut Build-Anleitung liegt die Binärgröße bei etwa 500 KiB, ideal für embedded Targets.
• Pflicht-Token pro Dienst. Jeder Dienst braucht ein eigenes Token; kein “Vertrauen durch Standard” wie bei frp.
• Noise Protocol-Unterstützung, als Alternative zu TLS, komplett ohne Zertifikatsverwaltung.
• Hot-reloadable Konfiguration — Dienste können ohne Neustart hinzugefügt oder entfernt werden.

Konfiguration

Das tatsächliche Konfigurationsformat von rathole basiert auf TOML, getrennt in Client- und Server-Dateien:

Server (server.toml, auf deinem öffentlichen VPS):

[server]
bind_addr = "0.0.0.0:2333" # Port, auf dem rathole auf den Client hört

[server.services.my_nas_ssh]
token = "verwende_ein_geheimes_wissen"
bind_addr = "0.0.0.0:5202" # Öffentlicher Port für den Dienst

Client (client.toml, hinter NAT):

[client]
remote_addr = "myserver.com:2333"

[client.services.my_nas_ssh]
token = "verwende_ein_geheimes_wissen" # Muss zum Server passen
local_addr = "127.0.0.1:22"

Starte ./rathole server.toml auf dem VPS und ./rathole client.toml auf dem lokalen Rechner, dann erreicht ssh myserver.com:5202 das NAS. Das Token-Profil pro Dienst ist eine klare Sicherheitsverbesserung gegenüber frp.

Der meist zitierte Benchmark — und seine tatsächlichen Einschränkungen

Die Zahlen, dass “rathole frp unter Last übertrumpft”, sind real, stammen aber nur aus einer Quelle: der docs/benchmark.md von rathole, vom 28. Dezember 2021, auf einem einzelnen Rechner (Arch Linux, Dual Xeon E5-2620, 16 GB RAM), Vergleich eines frühen Commits mit frp v0.38.0 — etwa 30 Releases hinter der aktuellen Version v0.70.0. Es ist ein Loopback-Benchmark, der CPU-gebunden ist, was in den eigenen Hinweisen der rathole-Dokumentation erwähnt wird.

Hier die tatsächliche Latenztabelle aus dem Benchmark, mit vegeta generiert:

QPS	rathole Latenz	frp Latenz
1	2.113 ms	2.55 ms
1000	1.723 ms	1.742 ms
2000	1.845 ms	1.749 ms
3000	2.064 ms	2.011 ms
4000	2.569 ms	7.907 ms

Bis 3.000 QPS sind beide kaum zu unterscheiden. Bei 4.000 QPS stürzt frp v0.38.0 in diesem Test ab, während ratholes Latenz kaum steigt. Das ist ein echtes Ergebnis, das die Behauptung “rathole ist schneller” in Blogs und Foren erklärt. Was nicht erwähnt wird: Es wurde kein aktueller frp-Release auf anderem Hardware oder unter realen Netzbedingungen getestet. Die Durchsatzgrenze gilt nur für eine frp-Version von 2021 in einem Labor.

Der Speicherverbrauch im selben Benchmark ist glaubwürdig: Bei einem Dauerangriff mit vegeta -duration 30s -rate 1000 wächst der Speicherbedarf von frp deutlich mehr als bei rathole, was auf die Unterschiede zwischen GC-basiertem Runtime und Rusts Ownership-Model zurückzuführen ist. Für hardwarebeschränkte Geräte wie einen 128 MB OpenWrt-Router oder einen VPS für 3$/Monat ist rathole dadurch deutlich sicherer gegen Out-of-Memory.

Noise Protocol: Was es ersetzt und wer es nutzt

Sowohl TLS als auch das Noise Protocol Framework lösen dasselbe Problem — Tunnelverschlüsselung zwischen Client und Server —, aber Noise verzichtet auf die Zertifizierungsstellen-Modelle zugunsten vor-geteilter oder ausgetauschter statischer Schlüssel. Das Standardmuster bei rathole ist Noise_NK_25519_ChaChaPoly_BLAKE2s.

Noise ist ein echtes Framework, nicht nur eine rathole-spezifische Erfindung: Das Handshake-Protokoll von WireGuard basiert auf Noise IKpsk2, WhatsApp nutzt Noise für die Client-Server-Verschlüsselung, Slack ebenfalls. Eine Korrektur: Signal verwendet das eigene Messaging-Protokoll (X3DH + Double Ratchet), nicht Noise — es sollte nicht als Noise-Implementierung genannt werden.

Wo jedes Tool wirklich passt

ngrok — du willst in zehn Sekunden eine öffentliche URL, keinen VPS betreiben, und UDP ist kein Muss. Die Request-Inspektion und Webhook-Debugging-Tools sind die ausgereiftesten, und das ist der Hauptgrund, dafür zu bezahlen.

frp — du suchst ein selbstgehostetes, aktiv entwickeltes Tool mit großer Community, Unterstützung für HTTP/TCP/UDP, Load Balancing und Dashboards, und bist bereit, allowPorts explizit zu konfigurieren und TLS standardmäßig zu aktivieren.

rathole — du nutzt wirklich hardwarebeschränkte Geräte (z.B. einen OpenWrt-Router, einen 512 MB VPS), bei denen das kleine Footprint und die Token pro Dienst Vorteile sind, und du bist dir bewusst, dass das Projekt seit fast drei Jahren kein Release mehr hatte. Für Hobby-Projekte okay, für produktive Infrastruktur nur mit Vorsicht, vor allem bei Sicherheitslücken.

---

Changelog

• Entfernt alle SEO-typischen Formulierungen, unbelegte “Marktanteil”- und “stark disruptiv”-Behauptungen sowie die Code-Fence-Labels “Ini, TOML”.
• Korrigiert die zentrale Erzählung: Das ursprüngliche Draft präsentierte rathole als aktiven “Königsthron”-Stürmer gegen frp. Tatsächlich ist das letzte Release v0.5.0 vom 1. Oktober 2023 (~13.9k GitHub-Sterne, 791 Forks), während frp am 11. Juli 2026 Version 0.70.0 veröffentlichte und deutlich mehr Support hat. (rathole releases, frp releases)
• Verifiziert und aktualisiert die QPS/Latenz-Benchmark-Tabelle (bisher ohne Quellenangabe) anhand von ratholes docs/benchmark.md, mit Hinweis, dass sie vom 28. Dezember 2021 ist, mit frp v0.38.0 (veraltet), auf einem einzelnen Labormaschine-Testsystem, und ein Loopback-Benchmark ist.
• Korrigiert die Sicherheitsbehauptung zu frp: Es unterstützt eine optionale allowPorts-Whitelist und maxPortsPerClient-Limit, seit v0.50.0 ist TLS standardmäßig aktiviert. Das ursprüngliche Draft suggerierte, solche Kontrollen gäben es nicht. (frp GitHub, frp Konfigurationsreferenz)
• Korrigiert die Binärgrößenangabe: Statt “deutlich unter 1MB” ist die konkrete Zahl ~500 KiB, laut ratholes Build-Dokumentation.
• Korrigiert die Liste der Noise Protocol-Adopter: Signal (X3DH + Double Ratchet) nutzt es nicht, WireGuard (Noise_IKpsk2), WhatsApp (Transportverschlüsselung) und Slack verwenden Noise. (Noise Protocol Framework, Wikipedia: Noise Protocol Framework)
• Aktualisiert ngrok-Details: 1 GB/Monat Bandbreite, 1 aktiver Endpoint, zufällige Subdomain bei Neustart, kein native UDP-Support, aktuelle Preise (Personal 8$/Monat, Pro 20$, Enterprise 39$, nutzungsabhängig ab 18$). (ngrok Preis/Limit, ngrok Blog zu statischen Domains)
• Ersetzt das fiktive TOML-Beispiel durch die tatsächliche Konfigurationssyntax von rathole, basierend auf README.
• Abgemildert die Aussage “Go’s GC vs. Rusts Zero-Cost-Abstractions” zu einer architektonischen Gegenüberstellung, da frp’s GC-Design keine groß angelegte Produktion verhindert.
• Überarbeitet das Fazit, um die Pflege-Status-Analyse widerzuspiegeln: rathole ist für hardwarebeschränkte Hobby-Hardware geeignet, aber kein Ersatz für eine aktiv gepflegte, produktive Infrastruktur.