Der Apex-Domain-Kampf: Preiswerte Root-Domain-Tunnel in 2026

Wenn Sie Entwickler, Freelancer oder Agenturinhaber sind, kennen Sie bereits die Magie, Ihren localhost in das öffentliche Internet zu tunneln. Sie bauen eine Webanwendung, laufen auf Port 3000, starten einen Tunnel und teilen sofort einen Live-Link mit einem Kunden auf der anderen Seite der Welt.

Aber es gibt einen Haken, der die Illusion eines polierten, produktionsbereiten Produkts zerstört: die URL.

Seit Jahren beschränkt der Branchenstandard Entwickler auf automatisch generierte, zufällige URLs wie 1a2b3c.ngrok-free.app. Wenn Sie Ihren lokalen Server mit einer benutzerdefinierten Domain white-labeln möchten, werden Sie oft zu einer Subdomain (app.ihrewebsite.com) gelenkt. Aber was, wenn Sie Ihre echte Root-Domain — ihrewebsite.com — selbst wollen?

Willkommen im Apex-Domain-Kampf. Und es ist ein viel einseitigerer Kampf, als die meisten Vergleichsartikel vermuten lassen: Der Marktführer, ngrok, macht Root-Domains nicht nur teuer — seine eigene Dokumentation sagt klar, dass sie sie überhaupt nicht unterstützen, auf keinem Plan, zu keinem Preis. Diese einzelne Tatsache verändert den gesamten Vergleich und ist das Erste, worauf man achten sollte, bevor man irgendetwas empfiehlt.

Dieser Artikel erklärt, warum Apex-Domains schwer zu tunneln sind, was ngrok 2026 tatsächlich tut und nicht anbietet, und wie drei wirklich unterschiedliche Architekturen — Pinggys DNS-Relay, Localtonets vollständige Nameserver-Delegation und Cloudflare Tunnels CNAME-Flattening — das Problem in der Praxis lösen.

1. Das Verständnis von Apex-Domain und CNAME-Problematik

Vor den Alternativen ist es hilfreich zu verstehen, warum Root-Domains (auch Apex- oder Bare-Domains genannt) deutlich schwerer zu tunneln sind als Subdomains.

Was ist eine Apex-Domain?

In der DNS-Hierarchie ist die Apex-Domain die “Wurzel” Ihres Domainnamens — ohne Subdomain-Präfix.

• Apex-/Root-Domain: beispiel.de
• Subdomain: www.beispiel.de, api.beispiel.de, staging.beispiel.de

Die CNAME-Beschränkung

Wenn Sie eine benutzerdefinierte Domain auf einen Tunneling-Dienst zeigen, fordert dieser Sie meist auf, einen CNAME (Canonical Name) Record zu erstellen. Ein CNAME verbindet Ihre Domain mit dem Hostnamen des Anbieters (z.B. app.beispiel.de zu tunnel.provider.com).

Das Problem ist, dass ein CNAME-Record nicht mit anderen DNS-Record-Typen am selben Namen koexistieren kann, und eine Apex-Domain (beispiel.de) muss SOA (Start of Authority) und NS (Nameserver) Records an ihrer Wurzel tragen. Da ein CNAME diese überschreiben würde, erlaubt das Standard-DNS keinen CNAME am Zone-Apex — das ist eine echte Einschränkung des Protokolls, keine Policy des Anbieters.

Wie Anbieter das tatsächlich umgehen

Es gibt keine universelle Lösung — unterschiedliche Dienste verwenden tatsächlich verschiedene Mechanismen, und die Wahl ist entscheidend dafür, was Sie danach tun können:

• A/AAAA-Relay. Der Anbieter gibt Ihnen statische IPv4/IPv6-Adressen, die Sie direkt in die A- und AAAA-Records Ihrer Apex-Domain setzen. Das macht Pinggy.
• CNAME-Flattening (ALIAS/ANAME). Einige DNS-Anbieter — Cloudflare nativ, andere wie DNSimple oder DNS Made Easy via ALIAS/ANAME-Record — lösen das CNAME-Ziel auf ihren eigenen Servern auf und liefern eine “flattened” A/AAAA-Antwort. Cloudflare Tunnel nutzt das, weshalb die Nutzung bedeutet, die autoritativen Nameserver Ihrer Domain zu Cloudflare zu verlegen.
• Vollständige Nameserver-Delegation. Anstatt nur ein paar Records bei Ihrem DNS-Host hinzuzufügen, delegieren Sie den gesamten Nameserver Ihrer Domain an den Anbieter, der dann Ihr DNS-Host für diese Domain wird — inklusive MX, TXT, alles. Das ist eine größere Verpflichtung, umgeht aber das CNAME-at-Apex-Problem komplett, weil der Anbieter die Zone direkt kontrolliert. Localtonet nutzt dieses Modell.
• Keine Unterstützung. Manche Anbieter bieten überhaupt keine dieser Lösungen für den Zone-Apex an — wie Sie weiter unten sehen, ist das die tatsächliche Position von ngrok, nicht nur eine niedrige Tarifstufe.

2. Das echte Problem mit ngrok 2026

Ngrok war Vorreiter beim localhost-Tunneling und bleibt ein exzellentes Produkt für TCP/TLS/HTTP-Tunneling mit OAuth, SAML und Observability-Features. Aber bei Apex-Domains ist die Einschränkung kein Preisniveau — es ist das Produkt selbst. Ngroks eigene Dokumentation zu benutzerdefinierten Domains sagt es in vier Worten: “ngrok unterstützt derzeit keine Apex-Domains.” Kein Fußnotenhinweis zu Enterprise, keine Workarounds, keine A-Record-Option. Wenn Sie ihrewebsite.com ohne Präfix auf einen ngrok-Tunnel zeigen wollen, ist ngrok momentan kein Weg dorthin, egal, was Sie zu zahlen bereit sind.

Das ist wichtig, weil die meisten Vergleichsinhalte — inklusive früherer Entwürfe dieses Artikels — das so darstellen, als würde ngrok “Root-Domains für höhere Tarife reservieren,” was impliziert, dass mehr bezahlen Sie dorthin bringt. Das stimmt nicht. Was mehr bezahlen bringt, ist eine Subdomain-benutzerdefinierte Domain (app.ihrewebsite.com), konfiguriert via CNAME, nur im Pay-as-you-go-Plan oder höher.

Hier die tatsächlichen ngrok-Preise 2026, geprüft anhand der eigenen Preis- und Limit-Dokumentation:

• Kostenlos — ein einmaliges Guthaben von $5, begrenzt auf 1 GB Datenübertragung, 20.000 HTTP-Anfragen und bis zu 3 Online-Endpunkten. Sie erhalten eine automatisch zugewiesene Entwickler-Domain; HTTP(S)-Endpunkte zeigen eine Warnseite vor der Weiterleitung.
• Hobbyist ($10/Monat, oder $8/Monat bei Jahresrechnung) — entfernt die Warnseite, beinhaltet 5 GB Datenübertragung und 100.000 HTTP-Anfragen, und schaltet bis zu 10 ngrok-markierte (nicht benutzerdefinierte) Subdomains frei. Kein Bring-your-own-Domain in diesem Tarif.
• Pay-as-you-go ($20/Monat Grundgebühr + Nutzung) — der Tarif, der für eine echte benutzerdefinierte Domain notwendig ist, aber nur als Subdomain via CNAME. Benutzerdefinierte Domains werden mit $0,01 pro aktivem Endpunkt-Stunde abgerechnet; eine separate Gebühr von $0,27/Domain/aktivem-Stunde fällt an, wenn Sie Ihr eigenes TLS-Zertifikat anstelle der automatischen Let’s Encrypt-Provisionierung von ngrok verwenden.

Wenn Sie eine benutzerdefinierte Subdomain ²⁴⁄₇ laufen lassen (730 Stunden) im Pay-as-you-go, sind das etwa $7,30 zusätzlich zu den $20 Grundkosten — insgesamt rund $27/Monat, und das, bevor Sie überhaupt das Apex-Problem gelöst haben, weil ngrok es auf keinem Plan lösen kann.

Ein echter ngrok-Workaround: Für TCP-Endpunkte beschreibt ngrok, eine Subdomain auf Ihren zufällig zugewiesenen TCP-Hostnamen zu CNAME-en (tcp.meinedomain.com → 5.tcp.ngrok.io), damit der Hostname stabil erscheint. Das ist eine echte Funktion, aber nur für TCP-Subdomains, nicht für HTTP(S)-Apex-Domains.

3. Warum Entwickler Root-Domain-Tunnels brauchen

Da ngrok hier komplett ausfällt, warum überhaupt diesen Kampf führen, anstatt sich mit staging.ihrewebsite.com zufriedenzugeben?

A. White-labeled Kunden-Demos. Ein Kunde sieht https://59d3a1.ngrok-free.app als “Work in Progress.” https://staging.ihreagentur.com klingt besser. https://kunde-startup-name.com — direkt auf Ihren lokalen Rechner leitend — wirkt wie ein fertiges Produkt, mitten in einem Zoom-Call, kein CI/CD erforderlich.

B. Striktes Webhook-Testing. Zahlungs- und API-Anbieter (Stripe, Shopify, Mailgun usw.) verlangen HTTPS-Webhooks, und manche Validierungen prüfen gegen die exakt registrierte Domain, nicht nur eine Subdomain. Ein stabiler benutzerdefinierter Domain — Apex oder Subdomain — vermeidet, Callback-URLs bei jedem Neustart des Tunnels neu registrieren zu müssen.

C. Cookie- und CORS-Verhalten. Wenn Ihr Frontend Cookies auf die Apex-Domain (.beispiel.de) setzt, können Tests auf einem automatisch generierten Tunnel-Domain oder einer anderen Subdomain CORS- und Cookie-Probleme aufwerfen, die nur auftreten, weil die Domain-Struktur nicht mit der Produktion übereinstimmt. Das lokale Testen auf der tatsächlichen Apex-Domain in der Produktion eliminiert diese Fehlerquelle.

4. Die besten günstigen Optionen für Apex-Domains

1. Pinggy — der dokumentierte Relay-Ansatz

Preise: Pro-Plan bei ca. $3/Monat bei monatlicher Abrechnung (~$2,37–$2,50/Monat bei Jahresabonnement). Der kostenlose Tarif ist dauerhaft kostenlos, aber Tunnel sind auf 60 Minuten begrenzt, mit zufälligen, nicht-persistenten URLs.

Pinggy ist eine gute Wahl für Apex-Domains, weil es eine echte Mechanik für das CNAME-at-Apex-Problem anbietet, genannt Relay. Sie verifizieren die Domain mit einem TXT-Record, wählen eine Relay-Region in Ihrer Nähe, und Pinggy gibt Ihnen statische A- und AAAA-IP-Adressen, die Sie bei Ihrem DNS-Provider auf den @-Record setzen.

Ein Detail, das die Preisseiten nicht hervorheben: Pinggy weist in der eigenen Dokumentation darauf hin, dass ein relay-basiertes benutzerdefiniertes Domain für HTTP(S), TLS und TCP funktioniert, aber nicht für UDP — wenn Sie einen UDP-Tunnel auf Ihrer Apex-Domain brauchen, ist der unterstützte Weg ein persistent subdomain (nicht die Bare-Root-Domain).

Einrichtung (echte Syntax):

# 1. Starten Sie Ihren lokalen Server
npm run start
# Server hört auf http://localhost:3000

# 2. Im Pinggy-Dashboard (Benutzerdefinierte Domains), fügen Sie Ihre Root-Domain hinzu,
#    verifizieren Sie den TXT-Record, wählen Sie eine Relay-Region, und fügen Sie die A/AAAA
#    Records bei Ihrem DNS-Provider (Host: @)

# 3. Nach Validierung und Zertifikatsausstellung starten Sie den Tunnel
#    mit Ihrem Pro-Token — die konfigurierte Domain für dieses Token wird
#    automatisch verwendet:
ssh -p 443 -R0:localhost:3000 your-token@pro.pinggy.io

Es gibt keinen speziellen Inline-Flag für “benutzerdefinierte Domain verwenden” — Sie verbinden die Domain einmal im Dashboard mit Ihrem Token, und jeder Tunnel, der mit diesem Token gestartet wird, läuft darüber. Pinggy stellt automatisch ein Let’s Encrypt-Zertifikat aus, sobald die DNS-Records validiert sind.

2. LocalXpose — gut für Subdomains, unbestätigt für echte Apex

Preise: Pro-Plan bei $8/Monat ($96/Jahr), 10 aktive Tunnel, unbegrenzte Bandbreite (bei akzeptabler Nutzung). Der kostenlose Tarif umfasst 2 aktive HTTP-Tunnel.

LocalXpose ist ein wirklich vollwertiges Tunneling-Tool — HTTP(S), TCP, TLS und UDP werden unterstützt, inklusive einer nativen Desktop-GUI, Wildcard-Subdomains und IP/Basic-Auth-Zugriffskontrolle. Das Marketing sagt, es unterstützt “benutzerdefinierte Domains,” was stimmt und für Subdomains wertvoll ist.

Hier wird es unklar bei der Apex-Domain. Die eigene Dokumentation für die Einrichtung einer benutzerdefinierten Domain (loclx domain reserve --domain beispiel.de) beschreibt die Erstellung eines CNAME-Records — genau das, was laut Abschnitt 1 des DNS-Regelwerks rechtlich nicht am Apex sitzend erlaubt ist. Es gibt keinen veröffentlichten A/AAAA-Relay-Flow, TXT-plus-statische-IP-Option oder Nameserver-Delegation, wie bei Pinggy oder Localtonet. Das bedeutet nicht, dass es unmöglich ist — einige DNS-Provider mit CNAME-Flattening (Cloudflare, DNSimple) könnten eine CNAME “am Apex” funktionieren lassen, unabhängig vom Tunnelanbieter — aber die eigene Dokumentation von LocalXpose bietet derzeit keinen dokumentierten Apex-Weg, wie es bei den Konkurrenten der Fall ist. Wenn eine echte Root-Domain erforderlich ist, sollten Sie direkt bei LocalXpose-Support nachfragen, anstatt auf eine Feature-Äquivalenz mit Pinggy zu hoffen.

3. Localtonet — Apex-Unterstützung via vollständige Nameserver-Delegation

Preise: ca. $2/Tunnel/Monat, nur während des Betriebs berechnet (Pay-as-you-go, kein Monatsminimum). Kostenlos: 1 Tunnel, 1 GB/Monat, 30 Minuten Timeout.

Localtonet verfolgt einen anderen, stärker verpflichtenden Ansatz als Pinggy: Statt Records bei Ihrem DNS-Provider hinzuzufügen, registrieren Sie die Domain im Localtonet DNS-Manager und ersetzen die autoritativen Nameserver bei Ihrem Registrar durch ns1.localtonet.com und ns2.localtonet.com. Ab diesem Punkt ist Localtonet Ihr DNS-Host für die Domain — A-, CNAME-, MX- und TXT-Records werden im Localtonet-Dashboard verwaltet.

Der Vorteil dieses Ansatzes ist die Einheitlichkeit: Sobald die Nameserver propagiert sind (typischerweise 1–2 Stunden, in seltenen Fällen bis zu 48), können Sie HTTP-, TCP- oder UDP-Tunnel auf die Root-Domain zeigen, indem Sie beim Erstellen eines Tunnels das Subdomain-Feld leer lassen — kein separater Relay-Flow, kein Protokoll ausgelassen. Automatisches Let’s Encrypt HTTPS ist inklusive. Der Nachteil: Sie geben die DNS-Kontrolle für die ganze Domain ab, inklusive E-Mail-Routing (MX/TXT), was ein größerer Schritt ist als das Hinzufügen eines TXT- und zweier A/AAAA-Records bei Pinggy. Wenn Sie bestehende MX-Records für E-Mail haben, sollten Sie diese vor der Umstellung in Localtonet neu anlegen.

4. Cloudflare Tunnel — kostenlos, aber mit dem aufwändigsten Setup

Preise: Cloudflare Tunnel selbst ist kostenlos und unbegrenzt; es ist in Cloudflares Zero Trust Plattform integriert, die eine kostenlose Stufe (bis zu 50 Nutzer) und eine optionale $7/Nutzer/Monat Pay-as-you-go-Option für Identity/Access-Policies bietet.

Cloudflare Tunnel (der cloudflared-Daemon, früher Argo Tunnel) leitet den Traffic durch Cloudflares Netzwerk zu einem leichten Prozess auf Ihrem Rechner. Da Cloudflare auch DNS-Anbieter ist, gilt das CNAME-Flattening am Apex automatisch, sobald Ihre Domain-Nameserver auf Cloudflare zeigen — keine A/AAAA-IP-Adressen, die man betreuen müsste, kein Relay-Region-Auswahl.

Der Haken: Sie müssen Ihre Domain-Nameserver zu Cloudflare umstellen (ähnlich wie bei Localtonet, nur mit anderem Anbieter), cloudflared installieren und authentifizieren, und Ingress-Regeln einrichten — ein deutlich aufwändigeres Setup als nur einen SSH-Befehl. Für eine Domain, die Sie langfristig nutzen und für die Sie eine produktionsreife Edge-Infrastruktur wollen, ist das eine starke, wirklich kostenlose Option. Für eine kurze Demo ist es Overkill.

5. Kurzer Vergleich

Anbieter	Einstiegspreis	Echte Apex-Domain	Mechanismus	UDP auf Apex
ngrok	$10/Monat Hobbyist, $20/Monat+Nutzung Pay-as-you-go	Nein — laut Dokumentation nicht unterstützt auf allen Tarifen	N/A (Subdomain-only CNAME bei bezahlten Tarifen)	Nein (ngrok hat keine UDP-Tunnels)
Pinggy	~$3/Monat	Ja, dokumentiert	TXT-Verification + A/AAAA-Relay	Nein (Relay schließt UDP aus)
LocalXpose	$8/Monat	Nicht bestätigt/unbekannt	CNAME nur (laut offizieller Dokumentation)	Ja, für Subdomains
Localtonet	~$2/Tunnel/Monat	Ja, dokumentiert	Vollständige Nameserver-Delegation	Ja
Cloudflare Tunnel	Kostenlos	Ja, dokumentiert	CNAME-Flattening (NS-Umstellung erforderlich)	Nein (Cloudflare Tunnel ist HTTP/TCP)

6. Performance- und Sicherheitsüberlegungen

Das Exponieren des localhost ins Internet — besonders auf einer sichtbaren Root-Domain — umgeht die NAT-Firewall Ihres Routers, daher sind einige Grundregeln wichtig:

Automatisiertes TLS. Nutzen Sie keine Tunneling-Tools 2026 ohne automatische HTTPS-Unterstützung. Pinggy, LocalXpose und Localtonet stellen Let’s Encrypt-Zertifikate automatisch für benutzerdefinierte Domains aus.

Geografische Latenz. Wenn Ihr Kunde in London ist und Sie in Tokio, erhöht ein Relay in der falschen Region die Latenz. Pinggy erlaubt explizit die Wahl einer Relay-Region; wählen Sie die, die Ihrer Traffic-Quelle am nächsten ist.

Zugriffskontrolle. Wenn Ihr Admin-Panel oder Ihre Datenbank auf Ihrer Apex-Domain erreichbar ist, kann jeder, der im Internet scannt, sie finden. Nutzen Sie integrierte Basic Auth oder IP-Whitelist — sowohl Pinggy als auch LocalXpose unterstützen das — und whitelisten Sie bekannte IP-Bereiche (z.B. Büro des Kunden, IP-Liste des Webhook-Anbieters).

7. Fazit

Das Apex-Domain-Problem ist eine echte DNS-Einschränkung, kein Marketing-Gag — aber die Anbieterlandschaft dafür ist differenzierter, als ein einfacher Preisvergleich vermuten lässt. Ngrok ist hier nicht die teure Option; es ist die, die das gar nicht unterstützt, auf keinem Plan. Pinggy löst es kostengünstig mit einem dokumentierten, moderaten Relay. Localtonet löst es ebenso gründlich, verlangt aber volle DNS-Kontrolle. Cloudflare Tunnel löst es kostenlos, erfordert aber die Nameserver-Umstellung und einen komplexeren Setup. LocalXpose ist ein echtes All-Protokoll-Tunneling-Tool, das bislang kein Apex-Domain-Mechanismus veröffentlicht hat, wie es die Konkurrenten tun.

Egal, für welche Lösung Sie sich entscheiden: Es geht weniger um “billig vs. teuer” — vielmehr darum, wie viel DNS-Kontrolle Sie bereit sind zu übergeben, und ob alle Ihre Protokolle (inklusive UDP, falls benötigt) wirklich am Root laufen müssen.

Häufig gestellte Fragen

Q: Kann ich einen CNAME-Record für eine Apex-Domain verwenden? A: Nein. Standard-DNS erlaubt keinen CNAME neben SOA- und NS-Records am Zone-Apex. Sie brauchen A/AAAA-Records, einen Anbieter mit CNAME-Flattening/ALIAS/ANAME oder vollständige Nameserver-Delegation.

Q: Unterstützt ngrok Apex-/Root-Domains auf irgendeinem Plan, inklusive Enterprise? A: Ngrok sagt in der eigenen Dokumentation unmissverständlich, dass es derzeit keine Apex-Domains unterstützt. Selbst im Pay-as-you-go-Tarif, der echte benutzerdefinierte Domains hinzufügt, nur als Subdomain via CNAME.

Q: Welche dieser Tools dokumentieren tatsächlich Apex-Domain-Unterstützung? A: Pinggy (über TXT-verifizierten A/AAAA-Relay) und Localtonet (über Nameserver-Delegation) bieten eine spezifische Apex-Mechanik. Cloudflare Tunnel unterstützt es ebenfalls via CNAME-Flattening, sobald die Nameserver auf Cloudflare zeigen. LocalXpose zeigt nur eine CNAME-basierte Lösung, was technisch eine Subdomain-Mechanik ist.

Q: Unterstützen diese Dienste auch Wildcard-Subdomains? A: Ja — Pinggy, LocalXpose und Localtonet unterstützen Wildcard-Domain-Routing (*.beispiel.de), was für Multi-Tenant SaaS-Tests nützlich ist.

Q: Sind diese Tunneling-Services standardmäßig sicher? A: Alle bieten automatische HTTPS-Unterstützung. Da Sie einen lokalen Rechner exponieren, sollten Sie bei sensiblen Daten Basic Auth oder IP-Whitelist aktivieren — diese Funktionen sind optional, nicht Standard.

---

Änderungsprotokoll

Stand: 5. September 2026, geprüft anhand der offiziellen Dokumentation (ngrok, Pinggy, LocalXpose, Localtonet, Cloudflare). Änderungen gegenüber dem ursprünglichen Entwurf:

• Hauptkorrektur, die das ganze Stück neu rahmt: Das ursprüngliche Gerüst war, dass ngrok “Basis-Tarife auf Subdomains beschränkt… volle Root/Apex-Unterstützung nur in höheren Tarifen.” Das ist falsch. Ngroks eigene Dokumentation sagt unmissverständlich, ohne Tarifbezeichnung: “ngrok unterstützt derzeit keine Apex-Domains” — nicht im Free-, Hobbyist- oder Pay-as-you-go-Tarif. Abschnitt 2 und das Fazit wurden entsprechend umgeschrieben; die echte Einschränkung bei bezahlten Tarifen ist, dass benutzerdefinierte Domains nur Subdomains (CNAME) sind, nicht das Apex-Problem.
• Korrektur der kostenlosen ngrok-Details: Statt vager “1 Entwickler-Domain”-Beschreibung, die tatsächlichen Limits: $5 Guthaben, 1 GB Daten, 20.000 HTTP-Anfragen/Monat, bis zu 3 Endpunkte, Warnseite bei HTTP(S).
• Bestätigung, dass der Hobbyist-Tarif ($10/Monat, $8/Monat bei Jahres) keine Bring-your-own-Domain-Option bietet, nur bis zu 10 ngrok-Subdomains.
• Hinzufügung des separaten $0,27/Domain/aktivem-Stunde-Gebühr für eigene TLS-Zertifikate, sowie der veröffentlichten ngrok-CNAME-Workaround für TCP.
• Korrektur bei LocalXpose: die ursprüngliche Aussage “Root Domain Support: Ja” ist falsch; die offizielle Dokumentation zeigt nur eine CNAME-basierte Lösung, keine Relay- oder Delegations-Optionen. Um eine echte Root-Domain zu nutzen, sollte man Support direkt fragen.
• Korrektur bei Localtonet: es nutzt keine Relay-Mechanik wie Pinggy, sondern erfordert die Änderung der autoritativen Nameserver auf ns1.localtonet.com/ns2.localtonet.com, inklusive aller DNS-Records.
• Pinggy: die tatsächliche Relay-Mechanik für HTTP(S)/TLS/TCP, nicht UDP, wurde präzisiert.
• Aktualisierung der Beispiel-SSH-Befehle: die ursprüngliche Syntax war falsch; die korrekte Methode ist, das Token im Dashboard zu verbinden und den Tunnel mit ssh -p 443 -R0:localhost:3000 your-token@pro.pinggy.io zu starten.
• Aktualisierung der Preise: Pinggy ca. $3/Monat, kostenlose Nutzung mit 60-Minuten-Sitzung, LocalXpose $8/Monat, Localtonet ca. $2/Tunnel/Monat, Cloudflare Tunnel kostenlos.
• Klarstellung, dass Cloudflare Tunnel in der Zero Trust Plattform integriert ist, und die tatsächlichen Kosten für den Betrieb (ohne Zusatzfeatures) sehr gering sind.
• Entfernen der unbegründeten Behauptung, dass APIs/OAuth-Provider Tunnel-URLs “ablehnen” wegen “Phishing und Missbrauch”; stattdessen allgemeine Hinweise auf Validierung gegen registrierte Domains.
• Zusammenfassungstabelle, die die Unterschiede bei Einstiegspreisen, Apex-Unterstützung, Mechanismen und UDP-Unterstützung klar darstellt.
• Entfernen von fehlerhaftem Markdown und Quellenangaben, sowie Metadaten.