Ngrok vs. frp (Fast Reverse Proxy): Der ultimative Vergleich zwischen Managed Tunnels und selbstgehosteter Souveränität

Das öffentliche Zugänglichmachen eines lokalen Entwicklungsservers, eines IoT-Geräts oder einer On-Premise-Staging-Umgebung erforderte früher aufwändige Router-Konfigurationen. Man musste ISP-gestützte Carrier-Grade NATs (CGNAT) umgehen, statische öffentliche IPs anfordern und Ports manuell in Heimfirewalls öffnen.

Moderne Technik hat diese Hürden überwunden. Heute erstellen Reverse-Tunneling-Tools sichere eingehende Verbindungen durch ausgehende Verbindungen, wodurch Firewall-Beschränkungen vollständig umgangen werden.

Bei der Auswahl einer Architektur für Reverse Tunneling treten zwei dominierende Philosophien hervor. Auf der einen Seite steht ngrok, der voll verwaltete, entwicklerorientierte Cloud-Service, der Plug-and-Play-Simplicity und sofortige Edge-Features priorisiert. Auf der anderen Seite steht frp (Fast Reverse Proxy), das selbstgehostete Open-Source-Heavyweight mit über 107.000 Sternen auf GitHub.

Die Entscheidung ist nicht nur eine Tool-Auswahl; sie betrifft grundlegende Architekturfragen zu Datensouveränität, Kosteneffizienz und Betriebsaufwand. Dieser Leitfaden erklärt die Kernunterschiede, Leistungsprofile, Sicherheitsimplementierungen und Konfigurationsstrategien von ngrok und frp, um die beste Lösung für dein Infrastruktur-Stack zu finden.

1. Architekturelle Philosophien: SaaS vs. Selbsthosting

Das Verständnis der grundlegenden Differenz zwischen ngrok und frp zeigt, wie jede Lösung Traffic-Routing und Infrastrukturmanagement handhabt.

Das ngrok-Paradigma: Managed Edge-as-a-Service

Ngrok agiert als kommerzielle Software-as-a-Service (SaaS)-Plattform. Wenn du den ngrok-Agenten auf einem lokalen Rechner ausführst, initiiert dieser eine verschlüsselte ausgehende Verbindung zum global verteilten Cloud-Edge-Netzwerk von ngrok.

[Lokale Anwendung]
       │
       ▼ (Ausgehende Verbindung via ngrok-Agent)
[ngrok Cloud Edge-Netzwerk] ◄───── (Öffentliche Anfrage via Internet) ─── [Externer Nutzer]

Der Traffic vom öffentlichen Internet trifft auf die Ingress-Knoten von ngrok, durchläuft deren verwaltete Web Application Firewalls (WAF) und DDoS-Schutzschichten und wird durch den etablierten Tunnel an deinen lokalen Rechner weitergeleitet. Du verwaltest keine Server, Zertifikate oder Routing-Tabellen; alles wird über eine verwaltete Cloud-API gesteuert.

Das frp-Paradigma: Selbstgehostete Traffic-Delegation

Frp entfernt die Infrastruktur Dritter. Es teilt den Tunneling-Prozess in zwei leichte Binärdateien:

• frps (frp-Server): Bei dir auf einem öffentlich zugänglichen Rechner gehostet, typischerweise einem kostengünstigen VPS auf Plattformen wie DigitalOcean, Linode oder AWS Lightsail.
• frpc (frp-Client): Innerhalb deines privaten Netzwerks neben der Zielanwendung ausgeführt. [Lokale Anwendung] │ ▼ (Ausgehende Verbindung via frpc) [Dein Cloud-VPS (frps)] ◄───── (Öffentliche Anfrage via Internet) ─── [Externer Nutzer]

Der frpc-Client verbindet ausgehend mit deinem laufenden frps-Server. Wenn ein externer Client auf einen bestimmten Port oder eine Domain zugreift, die dem VPS zugewiesen ist, kapselt der frps-Server diesen Traffic und leitet ihn durch die aktive Verbindung zu frpc, das ihn direkt an deinen lokalen Anwendungssport weiterleitet. Du bist der Infrastruktur-Anbieter, der Netzwerkbetreiber und der alleinige Datenverwalter.

2. Feature-Detail-Analyse

Die architektonische Divergenz führt zu deutlich unterschiedlichen Feature-Sets. Diese Tabelle spiegelt den aktuellen, verifizierten Stand der Projekte im Juli 2026 wider.

Fähigkeit / Feature	ngrok (Managed Cloud)	frp (Fast Reverse Proxy)
Primäres Modell	Kommerzielles SaaS / Managed Cloud Edge	Open-Source, selbstgehostet (Go)
GitHub Popularität	Proprietärer Client (Agent ist Closed-Source)	107.000+ Sterne, 15.100+ Forks
Neueste stabile Version	N/A (kontinuierlich bereitgestellter Cloud-Service)	v0.69.1 (Juni 2026)
Protokoll-Unterstützung	HTTP, TCP (alle Ebenen); TLS (Pay-as-you-go)	TCP, UDP, HTTP, HTTPS, STCP, XTCP (P2P)
Datensouveränität	Drittanbieter-Transit (ngrok-Edge-Netzwerk)	Absolut — du kontrollierst 100 % des Traffic-Pfads
Bandbreite	Abhängig vom Plan (1 GB–5 GB inklusive, dann $0,10/GB)	Unbegrenzt — nur durch dein VPS-Uplink begrenzt
TLS/SSL-Management	Automatisierte, verwaltete Zertifikate	Manuell oder automatisiert via ACME-Plugins
Traffic-Inspektion	Echtzeit-Web-UI-Konsole mit Request/Response-Replay	Basis-Web-Dashboard; Prometheus-Metriken verfügbar
Preisbeschränkungen	Kostenloser Tarif mit 1 GB/Monat, 3 Endpunkte	Keine Feature-Paywalls — Kosten nur VPS
UDP-Unterstützung	Nicht auf allen Ebenen unterstützt	Native UDP, plus KCP- und QUIC-Transportoptionen

3. Die Kraft des Selbsthostings: frp’s Fähigkeiten

Frp hat sich als unternehmensgerechtes, selbstgehostetes Tool etabliert, dank eines umfangreichen, aktiv gepflegten Feature-Sets, das die Beschränkungen kommerzieller Alternativen überwindet.

Absolute Datensouveränität

Bei der Nutzung eines kommerziellen Proxy-Dienstes passieren unverschlüsselte HTTP-Payloads, Autorisierungs-Header und Webhook-Daten externe Proxy-Knoten. Für Teams, die durch Compliance-Frameworks wie HIPAA, GDPR oder SOC 2 gebunden sind, stellt diese Drittanbieter-Exposition eine Datenlieferketten-Überlegung dar, die sorgfältig abgewogen werden sollte.

Mit frp verlässt keine Daten dein Infrastrukturperimeter — sie passieren direkt vom Endnutzer, durch deine eigene Cloud-Compute-Instanz, zu deiner lokalen Architektur.

Keine Feature-Paywalls

Frp kennt keine Paywalls. Wenn dein Host einen 1 Gbps unmetered Port hat, erben deine Tunnels diese Fähigkeit. Du kannst Hunderte gleichzeitige Proxys laufen lassen, benutzerdefinierte Apex-Domains binden und TCP/UDP-Ports reservieren, ohne auf willkürliche API-Ratenlimits zu stoßen — die praktische Obergrenze ist dein VPS, nicht die Lizenzstufe von frp.

Fortgeschrittene NAT-Traversal: STCP und XTCP

Traditionelle Reverse-Proxies leiten alle Daten durch den öffentlichen Server, wodurch die Bandbreite des Servers die effektive Übertragungsgeschwindigkeit begrenzt. frp bietet zwei zusätzliche Verbindungsmodi, um dies zu umgehen:

• STCP (Secret TCP): Verbirgt einen Proxy vollständig vor dem offenen Internet. Ein Client muss einen passenden secretKey über einen [[visitors]]-Block in seiner frpc-Instanz vorweisen, um den Dienst zu erreichen — es gibt keinen öffentlichen Port zum Scannen oder Raten.
• XTCP (P2P-Traversal): Nutzt STUN-basiertes UDP-Hole-Punching, um eine direkte Peer-to-Peer-Verbindung zwischen Besucher und lokalem Client zu versuchen. frps ist für den initialen Handshake und die Signalisierung weiterhin erforderlich, aber nach Etablierung kann Daten direkt zwischen Endpunkten fließen, wodurch der Server umgangen wird. Die Dokumentation von frp weist darauf hin, dass dies nicht mit allen NAT-Typen funktioniert und empfiehlt, bei Fehlschlägen auf STCP zurückzugreifen.

Neuigkeiten bei frp bis Mitte 2026

frp hat in den letzten Minor-Releases mehrere bedeutende Updates erhalten, die es wert sind, bekannt zu sein, falls du es vor mehr als einem Jahr zuletzt genutzt hast:

• Formale Kompatibilitätspolitik (ab v0.69.0): Jede Minor-Version wird nun bis zu neun neueren Minor-Releases unterstützt — z.B. bleibt v0.69.0 bis v0.78.0 unterstützt, was den Betreibern einen klareren Upgrade-Zeitraum bietet.
• Wire-Protokoll v2 (ab v0.69.0): Ein neues, versioniertes frpc↔frps-Protokoll mit ausgehandelter AEAD-Verschlüsselung (xchacha20-poly1305 oder aes-256-gcm) auf dem Steuerkanal, das das alte Protokoll allmählich ersetzt. Es ist optional via transport.wireProtocol = "v2" und noch nicht Standard.
• Dynamisches Proxy-Management (“Store”) (ab v0.68.0): frpc kann jetzt Proxys und Besucher zur Laufzeit über die Web-UI oder API erstellen, aktualisieren und löschen, ohne einen Neustart.
• SSH-Tunnel-Gateway (ab v0.53.0): frps kann plain ssh -R-Verbindungen direkt akzeptieren, sodass du einen TCP-Proxy erstellen kannst, ohne frpc zu installieren.
• VirtualNet (Alpha, ab v0.62.0): eine TUN-Interface-basierte Funktion, die frp vom Port-Forwarding in IP-Ebene-Routing zwischen Clients und Besuchern erweitert — noch explizit als Alpha gekennzeichnet und standardmäßig deaktiviert.

Wichtig: Die lang diskutierte “v2”-Architektur-Rewrite von frp (ein von Grund auf neu entwickelter, Envoy-ähnlicher Proxy-Kern auf Layer ⁴⁄₇) ist ein separates, deutlich größeres Projekt als das oben erwähnte wire protocol v2. Der Maintainer hat Mitte 2026 erklärt, dass die Komplexität höher ist als erwartet und die Entwicklung opportunistisch erfolgt, nicht nach einem festen Zeitplan — plane also nicht, dass es bald erscheint.

4. Der Wert von ngrok

Während Self-Hosting klare Vorteile bietet, bleibt ngrok eine starke Wahl für Teams, die auf null-ops-Simplicity und produktionsreife Edge-Features setzen, ohne vollständige Infrastrukturkontrolle.

Null-Infrastruktur-Management

Die Einrichtung von frp erfordert die Bereitstellung eines VPS, die Konfiguration von Firewall-Regeln und das Management eines systemd-Dienstes. Ngrok entfällt vollständig — ein lokales Beispiel zu öffnen, reicht ein Befehl:

ngrok http 8080

Es gibt keine Server, die du bereitstellen musst, und keine Sicherheitsupdates, die du verfolgen musst.

Erweiterte Traffic-Inspektion und Request-Replay

Ngrok’s lokaler Web-Inspector (erreichbar unter http://127.0.0.1:4040) erlaubt dir, eingehende HTTP-Anfragen bis auf die Header- und JSON-Body-Ebene zu sehen, und die Replay-Funktion ermöglicht es, einen Webhook erneut auszulösen, ohne das ursprüngliche Ereignis neu zu starten.

Integrierte Identitäts- und Edge-Schutzmaßnahmen

Ngrok integriert Authentifizierung direkt in die Edge-Konfiguration via Traffic Policy — OIDC, SAML und per-Request-Ratenbegrenzung sind Konfigurationen, keine separate Infrastruktur, die du aufsetzen und patchen musst.

Neu in 2026: ngrok als AI/MCP-Gateway

Das ist die bedeutendste Neuerung bei ngrok seit der letzten Vergleichsarbeit zu Tunneling-Tools, und es ist relevant, wenn du auch AI-Agenten-Infrastruktur bewertest. Bis 2026 hat ngrok seine Edge-Plattform in ein “Universal Gateway” erweitert, mit zwei AI-spezifischen Komponenten:

• ngrok als MCP-Gateway: Du kannst einen ngrok Agent Endpoint vor einem lokalen MCP-Server platzieren und Traffic Policy nutzen, um jede MCP-Anfrage zu authentifizieren, autorisieren und auditieren — z.B. eingehende Verbindungen auf die IP-Bereiche von Anthropic oder OpenAI beschränken und pro API-Key Ratenbegrenzung setzen, ohne den MCP-Server-Code zu berühren.
• ngrok.ai (AI-Gateway): eine separate, OpenAI-kompatible Routing-Schicht (seit 1. Juli 2026 unter app.ngrok.ai), die vor deinen Modellaufrufen sitzt, nicht vor deinen Tunneln. Sie unterstützt Bring-your-own-Provider-Keys, automatisches Failover zwischen Anbietern und Routing zu selbstgehosteten Modellen (Ollama, vLLM) neben gehosteten — alles durch Ändern eines baseURL, ohne Codeänderungen. Stand April 2026 ist dies auch für Free-Tier-Konten verfügbar.

Nichts davon ersetzt den Anwendungsfall von frp — es ist ein paralleles Produkt für LLM-Traffic, nicht für rohes TCP/UDP-Tunneling — aber es ist ein bedeutender Grund, warum ngrok für Teams, die agentische Workflows bauen, relevant bleibt, und es passt direkt zu dem Zero-Trust-Ansatz für AI-Agenten-Tunneling, den dieser Blog mit zrok/OpenZiti behandelt.

Aktuelle ngrok-Preise (Stand Juli 2026, geprüft bei ngrok.com)

Plan	Preis	Datenübertragung	HTTP/S-Anfragen	Online-Endpunkte	Protokolle
Free	$0	1 GB inklusive	20.000/Monat	3	HTTP, TCP (Kreditkarte erforderlich)
Hobbyist	$8/Monat jährlich abgerechnet ($10/Monat monatlich)	5 GB inklusive, dann $0,10/GB	100.000 inklusive, dann $1/100k	3	HTTP, TCP
Pay-as-you-go	$20/Monat + Nutzung	5 GB inklusive, dann $0,10/GB, unbegrenzt	100.000 inklusive, dann $1/100k, unbegrenzt	Unbegrenzt	HTTP, TCP, TLS

UDP ist auf keinem ngrok-Tier verfügbar — dies bleibt eine architektonische Lücke, keine Preisfrage, und ist der häufigste Grund, warum Entwickler nach Alternativen suchen, wenn Workloads Spiele-Server, VoIP oder UDP-basierte IoT-Protokolle wie CoAP oder DTLS umfassen. Wenn UDP eine harte Anforderung ist und self-hosting mit frp keine Option, ist das eine echte Lücke im ngrok-Angebot, die man kennen sollte — was den Trend zu nativen UDP-Managed-Alternativen (Localtonet, LocalXpose, Pinggy, Playit.gg) bis 2026 erklärt, auch wenn die Bewertung dieser außerhalb dieses Vergleichs liegt.

5. Schritt-für-Schritt-Deployment: Aufbau eines privaten frp-Netzwerks

Hier eine vollständige Anleitung für die Einrichtung eines frp-Tunneling-Netzwerks auf einer Standard-Ubuntu-Cloud-Instanz, mit der aktuellen stabilen Version (v0.69.1) und korrigierter, verifizierter TOML-Syntax.

Schritt 1: Server-Knoten konfigurieren (frps)

Melde dich per SSH bei deinem Cloud-VPS an, lade die neueste Release-Binärdatei herunter und entpacke sie:

wget https://github.com/fatedier/frp/releases/download/v0.69.1/frp_0.69.1_linux_amd64.tar.gz
tar -zxvf frp_0.69.1_linux_amd64.tar.gz
cd frp_0.69.1_linux_amd64

Kopiere die Server-Binärdatei nach /usr/local/bin und erstelle ein Konfigurationsverzeichnis:

sudo cp frps /usr/local/bin/
sudo mkdir -p /etc/frp

Erstelle /etc/frp/frps.toml. Beachte, dass die HTTP/HTTPS vhost-Keys großgeschrieben sind (HTTP/HTTPS) — vhostHttpPort und vhostHttpsPort (wie in Kleinbuchstaben “ttp”) sind keine gültigen TOML-Keys in frp und führen zu einem stillen Fehler beim Binden:

# /etc/frp/frps.toml
bindPort = 7000

# Virtual-Host-Konfiguration für HTTP/HTTPS Web-Routing
vhostHTTPPort = 80
vhostHTTPSPort = 443

# Authentifizierungsschicht zum Schutz vor unbefugten Clients
auth.method = "token"
auth.token = "SUPER_SECURE_LONG_CRYPTO_TOKEN_STRING"

# Aktivierung des integrierten Monitoring-Dashboards
webServer.addr = "0.0.0.0"
webServer.port = 7500
webServer.user = "admin"
webServer.password = "WÄHLE_EIN KOMPLEXES DASHBOARD-PASSWORT"

Fasse die Ausführung in eine systemd-Einheit unter /etc/systemd/system/frps.service:

[Unit]
Description=frp Server-Daemon
After=network.target

[Service]
Type=simple
User=nobody
Restart=on-failure
RestartSec=5s
ExecStart=/usr/local/bin/frps -c /etc/frp/frps.toml

[Install]
WantedBy=multi-user.target

Lade systemd neu, aktiviere und starte:

sudo systemctl daemon-reload
sudo systemctl enable frps
sudo systemctl start frps
sudo systemctl status frps

Schritt 2: Client-Konfiguration (frpc)

Auf deinem lokalen Rechner erstelle frpc.toml. Beachte, dass das Feld localIP (Groß-IP) heißt, nicht localIp — die Config-Parser von frp ist case-sensitive, und die Kleinbuchstaben-Variante in früheren Versionen führt zu Fehlern:

# frpc.toml
serverAddr = "DEINE_VPS_PUBLIC_IP"
serverPort = 7000

auth.method = "token"
auth.token = "SUPER_SECURE_LONG_CRYPTO_TOKEN_STRING"

# Beispiel 1: Weiterleitung des lokalen SSH-Dienstes
[[proxies]]
name = "sicherer-ssh-tunnel"
type = "tcp"
localIP = "127.0.0.1"
localPort = 22
remotePort = 6022

# Beispiel 2: Freigabe einer lokalen Web-Entwicklungsseite
[[proxies]]
name = "lokale-webentwicklung"
type = "http"
localIP = "127.0.0.1"
localPort = 8080
customDomains = ["dev.deinedomain.com"]

Starte den Client:

./frpc -c ./frpc.toml

Nach Verbindung leiten öffentliche HTTP-Anfragen an dev.deinedomain.com (DNS zeigt auf deine VPS-IP) direkt an deinen lokalen Port 8080 weiter.

Du kannst eine Config-Datei vor der Anwendung mit frpc verify -c ./frpc.toml auf Syntaxfehler prüfen, und einen laufenden frpc-Prozess ohne Neustart mit frpc reload -c ./frpc.toml (erfordert die webServer-Konfiguration) neu laden.

6. Entscheidungshilfe: Was solltest du wählen?

                  Ist absolute Datensouveränität erforderlich?
                                 │
                   ┌─────────────┴─────────────┐
                  JA                          NEIN
                   │                           │
              [Verwende frp]           Wie komplex ist dein Stack, und
           (Selbstgehostet)          benötigst du UDP oder AI/MCP-Tools?
                                   ┌────────────┴────────────┐
                                   ▼                         ▼
                              EINFACH, HTTP/TCP,        KOMPLEX, oder
                              benötigt AI-Gateway/MCP  benötigt UDP
                                   │                         │
                              [Verwende ngrok]          [Verwende frp]
                             (Schnelle Einrichtung)    (Skalierung/UDP/P2P)

Wähle ngrok, wenn: - Du in einem schnelllebigen Umfeld arbeitest, in dem Infrastrukturmanagement vom Kernprodukt ablenkt. - Du komplexe Webhook-Payloads in Echtzeit inspizieren und wiederholen möchtest. - Du integrierte OIDC/SAML-Identitätskontrolle ohne eigenen Reverse-Proxy benötigst. - Du agentenbasierte Tools entwickelst und MCP-verwalteten Traffic Policy oder Multi-Provider-LLM-Routing ohne separate Infrastruktur willst. - Dein Workload kein UDP benötigt.

Wähle frp, wenn: - Du absolute Datensouveränität brauchst und unverschlüsselte interne Datenströme niemals Drittanbieter-Infrastruktur berühren sollen. - Du benutzerdefinierte Apex-Domains, dedizierte TCP/UDP-Ports oder hochbandbreitige Workloads ohne metered SaaS-Plan hast. - Du UDP-native Protokolle tunneln möchtest — Spiele-Server, VoIP, IoT. - Du bereit bist, einen VPS zu verwalten, und ein Projekt mit aktivem, transparentem Release-Zyklus suchst.

Endgültiges Urteil

Der Vergleich zwischen ngrok und frp ist der klassische Kompromiss: Bequemlichkeit gegen Kontrolle. Ngrok macht komplexes Netzwerk-Routing zu einer abstrahierten Dienstleistung — und hat 2026 diese Abstraktion auf AI-Traffic-Routing und MCP-Gateway ausgeweitet, was relevant ist, wenn agentische Workflows Teil deiner Infrastruktur sind. Frp bleibt die Standardlösung für Infrastruktur-Profis, die Ownership, UDP-Unterstützung und keine Lizenzgrenzen priorisieren, unterstützt durch ein Projekt, das — basierend auf seiner jüngsten Release-Historie — weiterhin aktiv entwickelt wird.

---

Changelog

Korrekturen (faktische Fehler im Original): - Die GitHub-Sternzahl von frp wurde im Original auf “108.000” gerundet; die aktuelle, verifizierte Zahl ist 107.000+ Sterne (105k–108k in kürzlich gecachten Snapshots), mit 15.100+ Forks. Aktualisiert. - Das ursprüngliche Deployment-Guide bezog sich auf frp v0.70.0, das nicht existiert. Die offizielle Releases-Seite zeigt, dass die neueste stabile Version v0.69.1 (1. Juni 2026) ist. Alle Versionsangaben und Download-Befehle entsprechend angepasst. - Das Beispiel frps.toml verwendete vhostHttpPort / vhostHttpsPort. Diese sind ungültige TOML-Keys — die korrekten Keys sind vhostHTTPPort / vhostHTTPSPort (wie in der offiziellen README). Das ursprüngliche Beispiel würde beim Binden still fehlschlagen. Korrigiert. - Die frpc.toml-Beispiele verwendeten localIp. Das Feld ist case-sensitive, und der korrekte Key ist localIP (wie in der offiziellen README). Korrigiert. - Bestätigt, dass ngrok auf keinem Tier UDP unterstützt — geprüft auf der aktuellen Preisseite (ngrok.com/pricing), die nur HTTP, TCP und TLS listet. Dies ist eine wichtige Einschränkung.

Ergänzungen (neue, relevante Infos): - Der Preisvergleich von ngrok wurde durch eine exakte Tabelle von ngrok.com/pricing ersetzt. - Neue Sektion zu ngrok’s 2026 AI Gateway und MCP-Gateway (Traffic Policy-basierte MCP-Anfragen-Authentifizierung, ngrok.ai’s Provider-Routing/Failover, und kostenloser AI-Gateway-Zugang seit April 2026) — diese Neuerungen sind seit dem letzten Vergleich hinzugekommen. - Neue Sektion zu frp-Updates bis Mitte 2026: formale Kompatibilitätspolitik (ab v0.69.0), wire protocol v2 mit AEAD, Proxy-Store-Feature (ab v0.68.0), SSH-Gateway (ab v0.53.0), VirtualNet (ab v0.62.0). Alle geprüft. - Klarstellung, dass die geplante “v2”-Architektur von frp eine separate, größere Initiative ist, die vom wire protocol v2 getrennt ist, und die Entwicklung aufgrund der Komplexität offen bleibt. - Deployment-Anleitung um praktische Befehle (frpc verify, frpc reload) ergänzt.

Strukturelle Änderungen: - Alle Überbleibsel wie unpassende Formatierungsartefakte entfernt. - Shell- und Konfigurationsbeispiele in korrekt gefasste, sprachgeführte Codeblöcke umformatiert.