LOKALE ENTWICKLUNG · PRAKTISCH TESTEN

Localhost teilen: Website vorführen und Webhooks testen

Deine Website läuft auf deinem Rechner. Mit einem temporären HTTPS-Link können dein Handy, Kunden oder ein Webhook-Dienst darauf zugreifen. Dafür brauchst du kein Deployment.

Vor dem Teilen: Prüfe die lokale Adresse

Schau dir die URL an, die dein Entwicklungsserver ausgibt. Protokoll und Port sind wichtig: http://localhost:5173 und https://localhost:7143 sind unterschiedliche Ziele. Öffne genau diese Adresse auf deinem Rechner und führe einen typischen Vorgang aus, bevor du den Tunnel startest.

Eine App, ein Port

Nutzen Website und API dieselbe lokale Adresse, kann ein Tunnel beide erreichen. Die Pfade bleiben erhalten: Eine öffentliche Anfrage an /kontakt landet auch lokal unter /kontakt. Der Tunnel kopiert oder veröffentlicht keine Dateien auf einem neuen Server.

Frontend und API auf getrennten Ports

Ein Tunnel zum Frontend macht eine API auf einem anderen Port nicht automatisch erreichbar. Ruft der Browser localhost:3000 auf, landet er auf dem Gerät des Besuchers. Nutze den API-Proxy deines Entwicklungsservers oder eine erreichbare Test-URL für die API und passe das Frontend daran an.

Erstelle einen öffentlichen Link

Starte deine Website oder API und prüfe, ob sie lokal erreichbar ist. GhostlyShare erkennt laufende lokale Web-Apps automatisch. Mit Go Public erstellst du einen öffentlichen HTTPS-Link.

  1. Lass deine App und GhostlyShare während des Tests laufen.
  2. Öffne den Link vor dem Teilen in einem privaten Browserfenster.
  3. Nutze Testdaten. Für eine private Kunden-Vorschau kannst du bei Bedarf ein Passwort setzen.

Windows & Linux. Kostenlose temporäre Links ohne Konto, E-Mail oder Abo.

GhostlyShare herunterladen ↗

Alle GhostlyShare-Funktionen ansehen →

GhostlyShare mit öffentlicher Vorschau und Funktionen zum Teilen

Öffne die öffentliche Adresse einmal auf deinem Rechner und einmal auf einem anderen Gerät. Funktioniert die lokale Seite, aber die öffentliche nicht, vergleiche beide URLs. So lässt sich ein Fehler in der App von einem Problem mit dem Tunnel oder den Host-Einstellungen unterscheiden.

Öffne deine Website auf dem Handy

Auf deinem Handy bezeichnet localhost das Handy selbst, nicht deinen Rechner. Öffne stattdessen den öffentlichen Link oder scanne den QR-Code in GhostlyShare.

  1. Wechsle zu mobilen Daten, um den Zugriff von außerhalb deines WLANs zu prüfen.
  2. Teste Menü, Formulare, Bildschirmtastatur und Datei-Uploads am echten Gerät.
  3. Öffne eine Unterseite direkt und lade sie neu. Prüfe auch Bilder und API-Antworten.

Testest du nur im selben WLAN? Dann kann die lokale Netzwerkadresse deines Rechners reichen, wenn Entwicklungsserver und Firewall den Zugriff erlauben. Ein öffentlicher Tunnel hilft bei anderen Netzwerken und externen Diensten.

QR-Code in GhostlyShare zum Öffnen einer Vorschau auf dem Handy

Ein sinnvoller Fünf-Minuten-Test am Handy

Navigation und Layout
Öffne das Menü, drehe das Handy und besuche eine längere Seite. Achte auf seitliches Scrollen, verdeckte Buttons und Inhalte hinter einer festen Kopfzeile. Die Geräteansicht im Desktop-Browser hilft, bildet aber nicht jede Bedienung am echten Gerät ab.
Formulare und Anmeldung
Tippe jedes Eingabefeld an und sende erst einen ungültigen, dann einen gültigen Wert ab. Bleiben Fehlermeldungen trotz Bildschirmtastatur sichtbar? Funktioniert die Anmeldung nur am Rechner, prüfe sie in einer frischen Browsersitzung und kontrolliere Callback-Adresse und Cookie-Einstellungen.
Anfragen und Ladeverhalten
Prüfe eine Seite mit mehreren Bildern und eine Aktion, die Daten lädt. Eine langsame Antwort über deinen Heimanschluss ist kein Leistungstest für den späteren Produktivbetrieb. Notiere die betroffene Seite, das Gerät und den Vorgang, damit du den Fehler lokal nachstellen kannst.

Zeige Kunden deinen Entwurf

Schicke die genaue Seite, zu der du Feedback möchtest. Sag dazu, was getestet werden soll und wie lange die Vorschau erreichbar bleibt.

Vor dem Teilen

Verwende ein Testkonto und Beispieldaten. Prüfe, ob der Link ohne deine eigenen Cookies oder deine angemeldete Sitzung funktioniert.

Bitte um einen konkreten Test

Kontaktformular ausfüllen, mobiles Menü prüfen oder eine Testbestellung durchgehen: Eine konkrete Aufgabe macht das Feedback hilfreicher.

Hier ist die Vorschau für unsere heutige Besprechung. Bitte prüfe das mobile Menü und das Kontaktformular. Nach unserem Gespräch schließe ich den Link.

Mach Rückmeldungen nachvollziehbar

Bitte bei Fehlern um Seiten-URL, Gerät, Browser und die letzte Aktion vor dem Problem. Ein Screenshot mit „Ich habe X erwartet, aber Y ist passiert“ hilft mehr als „Die Seite geht nicht“. Sag Bescheid, wenn du während der Besprechung Änderungen machst: Je nach Einrichtung sehen Besucher diese direkt oder die Seite lädt neu.

Empfange einen Webhook lokal

Ein Webhook-Dienst erreicht localhost auf deinem Rechner nicht. Gib ihm die öffentliche Tunnel-Adresse mit deinem Callback-Pfad. Das Beispiel setzt voraus, dass deine App bereits POST-Anfragen unter /api/webhooks/demo verarbeitet.

http://localhost:5173/api/webhooks/demohttps://YOUR-TUNNEL.trycloudflare.com/api/webhooks/demo
  1. Ersetze YOUR-TUNNEL durch deinen echten Hostnamen und trage die vollständige Callback-URL in den Testeinstellungen des Anbieters ein.
  2. Lass die Signaturprüfung eingeschaltet. Hinterlege das Webhook-Secret lokal und sende beim Anbieter ein Testereignis.
  3. Prüfe Zustellstatus und lokale Protokolle. Gib die vom Anbieter erwartete Erfolgsantwort zurück und verarbeite erneute Zustellungen ohne doppelte Aktionen.

Eine Passwortabfrage im Browser kann den Webhook-Absender blockieren. Nutze einen für den Anbieter erreichbaren Endpunkt und prüfe dessen signierte Anfragen. CORS betrifft Browseranfragen, nicht die Webhook-Zustellung zwischen Servern.

Beispiel: GitHub-Webhook-Signaturen prüfen ↗

Prüfe die Webhook-Antwort, nicht nur die Browserseite

Beim Öffnen der Callback-URL sendet der Browser normalerweise eine GET-Anfrage. Viele Webhook-Endpunkte erwarten stattdessen POST. Ein Fehler im Browser beweist deshalb noch nicht, dass die Zustellung scheitert. Sende das Testereignis des Anbieters und vergleiche Zeitstempel und Zustell-ID mit deinem lokalen Protokoll.

404 / 405
Prüfe Pfad und HTTP-Methode. Verwende den Port der API, nicht automatisch den des Frontends. Eine erreichbare Startseite bedeutet nicht, dass der Callback-Endpunkt existiert.
401 / 403
Prüfe, wo die Anfrage abgewiesen wurde: am Vorschau-Passwort, an der Anmeldung deiner App oder an der Signaturprüfung. Beachte bei signierten Daten die Vorgaben des Anbieters zum ursprünglichen Anfrageinhalt. Wird er vor der Prüfung eingelesen und verändert, kann die Signatur ungültig werden.
5xx / Timeout
Prüfe, ob die App noch läuft und die Anfrage erhalten hat. Beachte bei längerer Verarbeitung die Antwortfrist des Anbieters und verlagere Arbeit bei Bedarf in den Hintergrund. Teste eine erneute Zustellung, damit nicht doppelte Bestellungen oder Nachrichten entstehen.

Nutze den Testmodus des Anbieters und protokolliere keine Secrets oder vollständigen personenbezogenen Nutzdaten. Ein erfolgreicher Test prüft die Zustellung und Verarbeitung in deiner App. Die Integrationsvorgaben des Anbieters gelten trotzdem.

Der Link öffnet sich, aber etwas funktioniert nicht?

Der Link erreicht die App nicht

Öffne zuerst die lokale URL. Prüfe Port, HTTP oder HTTPS und ob App und Tunnel noch laufen.

Bilder oder API-Aufrufe fehlen

Suche nach fest eingetragenen localhost-URLs. Nutze möglichst relative Pfade. Ein eigener API-Port braucht einen ebenfalls erreichbaren Zugangsweg.

Die App leitet zu localhost zurück

Prüfe öffentliche Basis-URL, Einstellungen für vertrauenswürdige Proxys und Login-Callbacks. Erlaube den konkreten Vorschau-Host, statt Host-Prüfungen generell abzuschalten.

Live-Reload oder WebSockets funktionieren nicht

Prüfe, ob WebSockets den öffentlichen Host und auf einer HTTPS-Seite wss verwenden. Manche Entwicklungsserver brauchen eine eigene Host-Einstellung für HMR.

Der Webhook bekommt keine Erfolgsantwort

Prüfe Callback-Pfad, HTTP-Methode, Signatur-Secret und Zustellprotokoll. Aktualisiere die Callback-URL nach dem Start eines neuen temporären Tunnels.

Beende den Test und die Freigabe

Beende die Freigabe in GhostlyShare oder stoppe den Tunnel im Terminal mit Strg+C. Eine Ablaufzeit kann eine geplante Vorschau automatisch beenden. Entferne nach dem Test auch temporäre Callback-URLs beim Webhook-Anbieter.

Brauchst du eine feste Adresse für den Dauerbetrieb?

Eine temporäre Vorschau ersetzt kein Deployment. Unser Home-Hosting-Ratgeber erklärt benannte Tunnel, Domains, Windows-Dienste und laufende Kosten.

Einen dauerhaften Cloudflare Tunnel einrichten →

Fragen zu lokalen Vorschauen

FAQ

Warum funktioniert localhost auf meinem Handy nicht?

Localhost bezeichnet das Gerät, auf dem du die Adresse öffnest. Nutze auf deinem Handy den öffentlichen Vorschau-Link, um die App auf deinem Rechner zu erreichen.

Muss mein Rechner eingeschaltet bleiben?

Ja. Dein Rechner, die lokale App und der Tunnel müssen weiterlaufen. Im Energiesparmodus oder nach dem Stoppen des Tunnels ist die Vorschau nicht erreichbar.

Brauche ich für eine Vorschau eine Domain?

Nein. Ein temporärer Tunnel stellt eine öffentliche HTTPS-Adresse bereit. Ändert sich die Adresse, aktualisiere geteilte Links und Webhook-Einstellungen.