Lokaler Start, HTTPS‑Tunnel und Erreichbarkeit für ChatGPT

1. localhost ist nur für Sie, nicht für ChatGPT

Beginnen wir mit der wichtigsten kognitiven Dissonanz dieses Moduls. Sie öffnen http://localhost:3000 im Browser, alles funktioniert wunderbar, Next.js lächelt, das Widget wird gerendert. Es klingt logisch: „Ich habe doch eine URL, geben wir sie einfach ChatGPT.“

Das Problem ist, dass localhost keine „magische Domain meines Rechners im Internet“ ist. Es ist ein besonderer Name, der immer auf dieselbe Maschine zeigt, auf der der Browser oder Client läuft. Ihr Laptop spricht mit sich selbst. Die OpenAI‑Server, auf denen ChatGPT läuft, können ebenfalls localhost ansprechen … aber ihren eigenen — im Rechenzentrum. Und Ihr Next.js ist gemütlich hinter Heimrouter, NAT und möglicherweise einem Unternehmens‑VPN versteckt.

In dieser Vorlesung werden wir:

• verstehen, warum localhost für ChatGPT nicht erreichbar ist;
• einen HTTPS‑Tunnel über cloudflared von localhost:3000 zu einer öffentlichen URL einrichten;
• diese URL im ChatGPT Dev Mode verbinden;
• die Kette „Code → Tunnel → ChatGPT“ an einer kleinen Änderung im Widget überprüfen und typische Stolperfallen besprechen.

Daraus folgen zwei einfache Fakten:

1. ChatGPT weiß nicht, wo sich Ihr Laptop befindet.
2. Selbst wenn es das wüsste, kann es nicht direkt anklopfen — eingehende Verbindungen sind geschlossen.

Außerdem arbeitet ChatGPT grundsätzlich nur mit öffentlichen HTTPS‑Endpoints (Einstiegspunkten): Es braucht eine vernünftige Domain und ein TLS‑Zertifikat. Die OpenAI‑Server rufen aus Sicherheitsgründen keine beliebigen unverschlüsselten HTTP‑Adressen auf, daher wird eine HTTPS‑Domain mit gültigem Zertifikat benötigt. Einfach http://moy‑vneshniy‑IP:3000 nach außen freizugeben, ist keine Option mehr.

Wir brauchen daher einen Vermittler — einen Dienst, der:

1. im Internet mit einer normalen HTTPS‑Domain lebt,
2. Anfragen von dieser Domain sicher zu Ihrem localhost:3000 weiterleiten kann.

Das ist genau ein HTTPS‑Tunnel.

2. Was ist ein HTTPS‑Tunnel: eine intuitive Modellvorstellung

Wenn man die großen Worte weglässt, ist ein Tunnel ein Dienst, der Ihnen eine temporäre (oder permanente) öffentliche URL gibt und alle Anfragen von dort an Ihren lokalen Port weiterleitet. In Netzwerkterminologie ist es im Grunde ein Reverse‑Proxy‑Server, der eine ausgehende Verbindung in die Cloud hält.

Intuitive Analogie: Sie sitzen hinter einer geschlossenen Tür (Heimrouter), und der Tunnel ist ein Kurier, der draußen mit einem Schild „alle Briefe hierher“ steht, gelegentlich durch den Hintereingang zu Ihnen in die Wohnung huscht und Ihnen die Briefe in die Hand drückt.

Das Schema des Anfragewegs sieht ungefähr so aus:

sequenceDiagram
    participant ChatGPT as ChatGPT (Cloud)
    participant Tunnel as HTTPS‑Tunnel
(Cloudflare / ngrok)
    participant Dev as Ihr Dev‑Server
(localhost:3000)

    ChatGPT->>Tunnel: HTTPS‑Anfrage an https://xyz.trycloudflare.com
    Tunnel->>Dev: HTTP‑Anfrage an http://localhost:3000
    Dev-->>Tunnel: Antwort von Next.js
    Tunnel-->>ChatGPT: HTTPS‑Antwort

Die Schlüsselpunkte sind folgende.

Erstens sind Sie der Initiator der Verbindung zum Tunneldienst. Das Tool (cloudflared, ngrok usw.) stellt selbst eine ausgehende Verbindung zur Cloud her. Das ist fast immer erlaubt, selbst hinter NAT/Firewall.

Zweitens stellt der Tunneldienst Ihnen eine HTTPS‑Domain mit gültigem Zertifikat zur Verfügung, sodass Sie kein selbstsigniertes TLS manuell aufsetzen müssen.

Drittens erscheint Ihr App für ChatGPT wie ein normaler Webservice mit HTTPS‑Domain. Es merkt nicht, dass der Traffic weiter zu jemandes Laptop geht.

3. Welche Tunnel gibt es und was wählen wir im Kurs

In der Web‑Entwicklungswelt gibt es mehrere beliebte Lösungen für diese Aufgabe:

• ngrok — der Klassiker, lange Zeit de‑facto‑Standard, „wie zeige ich meine lokale Umgebung nach außen“.
• Cloudflare Tunnel (cloudflared) — moderne kostenlose Lösung von Cloudflare, liefert eine Domain der Form *.trycloudflare.com sogar ohne Registrierung; bei Bedarf kann man auch eine eigene Domain anbinden.
• LocalTunnel — minimaler Zauber, einfach ein npm‑Paket, das eine temporäre HTTPS‑URL wie https://something.loca.lt bereitstellt.

Sie lösen alle die gleiche Aufgabe: einem lokalen Server eine öffentliche HTTPS‑Domain zu geben, die für ChatGPT geeignet ist.

Für den Kurs wollen wir den Fokus nicht zerstreuen, daher nehmen wir als „Hauptwerkzeug“ Cloudflare Tunnel mit dem Tool cloudflared. Die Gründe sind einfach: erfordert für schnelle Tunnel keine Registrierung, liefert echtes HTTPS, startet unkompliziert mit einem einzigen Befehl.

Wenn Sie bereits ngrok‑Fan sind — kein Problem. Die Kommandos sind etwas anders, das Konzept ist identisch: ngrok http 3000 statt cloudflared tunnel --url http://localhost:3000.

Zur Orientierung fassen wir die Werkzeuge in einer kleinen Tabelle zusammen.

https://*.trycloudflare.com

https://*.ngrok.app

https://*.loca.lt

In dieser Vorlesung konzentrieren wir uns auf Cloudflare Tunnel im Modus „schneller Einmal‑Tunnel“. Das reicht mehr als aus, um Ihren Next.js mit ChatGPT im Dev Mode „bekannt zu machen“.

4. Prüfen, dass der lokale Next.js läuft

Bevor Sie etwas durch den Tunnel nach außen führen, stellen Sie sicher, dass der lokale Server wirklich läuft. Sonst debuggen Sie den Tunnel, obwohl das Problem schlicht darin liegt, dass Next.js nicht gestartet ist.

Zur Erinnerung die Standardreihenfolge:

# aus dem Projektstamm mit dem Apps‑SDK‑Template
npm install      # falls noch nicht geschehen
npm run dev      # Start des Next.js‑Dev‑Servers

Standardmäßig startet Next.js 16 auf http://localhost:3000 (sofern der Port frei ist). Im Terminal sehen Sie etwas wie:

ready - started server on 0.0.0.0:3000, url: http://localhost:3000

Öffnen Sie im Browser http://localhost:3000 und vergewissern Sie sich, dass die Vorlagenseite erscheint. Das ist Ihr „lokales Labor“. Wenn hier etwas nicht funktioniert (Build‑Fehler, TypeScript meckert, Port belegt), beheben Sie das zuerst und gehen dann an den Tunnel.

5. Cloudflare Tunnel starten: von localhost zum öffentlichen HTTPS

Kommen wir zum Wesentlichen — wir sorgen dafür, dass jede Person im Internet (einschließlich ChatGPT) Ihren Next.js über eine HTTPS‑URL öffnen kann.

Installation von cloudflared

Die Installationsmethode hängt vom OS ab. Der einfachste Weg für macOS ist Homebrew:

brew install cloudflare/cloudflare/cloudflared

Unter Windows und Linux können Sie ein Binary herunterladen oder einen Paketmanager verwenden, wie in der Cloudflare‑Dokumentation empfohlen (Links finden Sie in den Zusatzmaterialien des Moduls).

Die Installation prüfen Sie mit:

cloudflared --version

Wenn das Tool nicht gefunden wird, prüfen Sie PATH oder starten Sie das Terminal neu.

Schneller Einmal‑Tunnel

Unser Ziel ist jetzt ein minimal funktionsfähiger Tunnel, ohne Account, Domain und komplexe Konfiguration. Dafür hat cloudflared den Quick‑Tunnel‑Modus, der eine URL auf der Domain trycloudflare.com bereitstellt.

Bei laufendem npm run dev führen Sie in einem zweiten Terminal aus:

cloudflared tunnel --url http://localhost:3000

Merken Sie sich die einfache Regel: HTTPS außen, HTTP innen. cloudflared gibt Ihnen außen eine HTTPS‑Domain, greift aber auf Ihr localhost:3000 per normalem HTTP zu.

Nach kurzer Ausgabe sehen Sie eine Zeile wie:

INF +-------------------------------------------------------------+
INF |  Your quick Tunnel has been created!                        |
INF |  https://giftgenius-1234.trycloudflare.com                  |
INF +-------------------------------------------------------------+

Dieses https://giftgenius-1234.trycloudflare.com ist die neue öffentliche Adresse Ihrer lokalen Anwendung. Der Tunnel nimmt HTTPS‑Anfragen an diese Domain entgegen und leitet sie an http://localhost:3000 weiter.

Ein paar wichtige Punkte.

Erstens muss das Terminal mit cloudflared geöffnet bleiben, solange Sie den Tunnel brauchen. Sobald Sie es schließen (oder Strg+C drücken), fällt der Tunnel, die URL funktioniert nicht mehr.

Zweitens kann die Quick‑Tunnel‑URL bei jedem Start neu sein. Für unsere Übungsentwicklung ist das okay: Ziel des aktuellen Moduls ist nur, ChatGPT über irgendeine funktionierende HTTPS‑Adresse Zugriff auf Ihren lokalen Next.js zu geben. Das bedeutet aber, dass Sie die URL im ChatGPT Dev Mode gelegentlich aktualisieren müssen. Im Modul 7 kommen wir auf das Thema Tunnel zurück und richten dann eine stabile Dev‑Domain ein, damit Sie nicht den Adressen hinterherlaufen.

Den Tunnel wie eine normale Website prüfen

Bevor wir das in ChatGPT einbinden, prüfen wir, dass der Tunnel einfach aus dem Internet erreichbar ist.

1. Öffnen Sie die erhaltene https://...trycloudflare.com im Browser.
2. Sie sollten dieselbe UI sehen wie auf http://localhost:3000.
3. In der Konsole, in der npm run dev läuft, sehen Sie neue Anfragen — Next.js bedient also tatsächlich den externen Zugriff.

Wenn die Seite nicht öffnet oder einen Fehler zeigt, prüfen Sie zuerst:

• Läuft npm run dev?
• Haben Sie sich nicht in der lokalen URL beim Starten des Tunnels vertan (http://localhost:3000, nicht https:// und nicht Port 3001)?
• Blockiert etwas ausgehende Verbindungen (selten, aber möglich in sehr strengen Firmennetzen)?

6. Diesen URL in den ChatGPT Dev Mode eintragen

Jetzt haben wir alles, um die Kette zu verbinden:

ChatGPT (Cloud) → Ihr HTTPS‑Tunnel → lokales Next.js.

Den Teil zur Dev‑Mode‑Oberfläche haben Sie bereits in der vorherigen Vorlesung gesehen; wir wiederholen das jetzt mit einer echten HTTPS‑URL statt einer theoretischen.

Die allgemeine Abfolge in ChatGPT ist wie folgt.

Öffnen Sie zuerst ChatGPT im Browser und gehen Sie zum Entwicklerbereich (typischerweise etwas wie „Developer“, „Apps“, „My apps“ — die konkreten Bezeichnungen können sich mit UI‑Updates ändern).

Erstellen Sie eine neue App oder bearbeiten Sie Ihre bestehende Dev‑App, falls Sie schon eine angelegt haben.

Geben Sie in das Feld, in das die URL Ihrer App einzutragen ist, die Wurzeladresse des Tunnels an, zum Beispiel:

https://giftgenius-1234.trycloudflare.com/mcp

Der Einstiegspunkt ist unser /route/mcp.ts. Beim Verbinden beginnt ChatGPT damit und lädt anschließend alle notwendigen Informationen. Im README des Templates kann ein anderer Pfad angegeben sein, wenn es mehrere Apps gibt; vorerst nehmen wir an, dass Tunnel‑Root + /mcp das ist, was Sie brauchen.

Speichern Sie die App‑Konfiguration. In diesem Moment macht ChatGPT mehrere Anfragen an Ihre Anwendung über den Tunnel:

• Liest das App‑Manifest (Metadaten, Tools usw.).
• Prüft die Erreichbarkeit des MCP‑Endpoints.
• Ruft die Liste aller Tools und Ressourcen ab.
• Cacht den HTML‑Code aller Widgets(!)

Wenn alles gut läuft, sehen Sie Ihre App in der Liste der Dev‑Apps. Falls etwas kaputt ist (ungültiges Manifest, Server antwortet nicht, Tunnel ist gefallen), zeigt ChatGPT einen Fehler wie „App unavailable“ oder etwas Ähnliches.

Wichtig: Dieselbe HTTPS‑URL des Tunnels verwendet ChatGPT sowohl für Tool‑Aufrufe (MCP) als auch für das Laden des Widgets und der statischen Dateien. Im nächsten Abschnitt betrachten wir diese beiden Rollen getrennt.

7. Wie die Anfragen jetzt laufen: zwei Rollen Ihres Tunnels

Es ist wichtig, genau zu verstehen, was ChatGPT mit dieser URL macht. In der Apps‑SDK‑Architektur gibt es zwei Haupteinstiegspunkte: den MCP‑Endpoint und das UI‑Widget.

Vereinfacht sieht die Kette so aus:

flowchart LR
    ChatGPT["ChatGPT (Modell)"] 
    subgraph Internet
        Tunnel[HTTPS‑Tunnel
giftgenius-1234.trycloudflare.com]
    end
    Local["Next.js‑Dev‑Server http://localhost:3000"]

    ChatGPT -- HTTP(S)‑Anfragen an /mcp --> Tunnel
    ChatGPT -- Laden des iframe /widget --> Tunnel
    Tunnel --> Local

Der Tunnel hat faktisch zwei Hauptrollen:

• Rolle 1: MCP‑Endpoint (Tools). Wenn das Modell ein Tool aufrufen will, macht es einen HTTP‑POST an den MCP‑Endpoint (im Template ist das die Route app/mcp/route.ts in Next.js) unter derselben Tunnel‑Domain.
• Rolle 2: UI‑Widget und statische Dateien. Wenn das Modell ein Widget anzeigen möchte, bettet es ein iframe mit Ihrer URL ein (gewöhnlich /widget oder was im Manifest angegeben ist), und das Laden läuft ebenfalls über den Tunnel.

Der Tunnel ist also nicht „für nur eine Sache“, er ist die einheitliche Tür zu Ihrer lokalen App: UI, MCP, statische Inhalte — alles geht über dieselbe öffentliche HTTPS‑Domain.

8. Praxis: die Kette „Code → Tunnel → ChatGPT“ prüfen

Damit wir sicher sind, dass das wirklich funktioniert und nicht nur auf den Schaubildern schön aussieht, machen Sie ein minimales Praxisszenario.

Erstens starten Sie npm run dev und stellen Sie sicher, dass http://localhost:3000 im Browser öffnet.

Zweitens starten Sie cloudflared tunnel --url http://localhost:3000 und erhalten eine öffentliche HTTPS‑URL. Prüfen Sie diese in einem anderen Browser oder sogar auf einem anderen Gerät (zum Beispiel auf dem Handy über mobiles Internet) — so stellen Sie sicher, dass die Anfragen wirklich über das Internet gehen und nicht nur auf Ihrer Maschine kreisen.

Drittens öffnen Sie ChatGPT, wechseln in den Dev Mode und stellen sicher, dass Ihre App mit dieser URL verbunden ist. Wählen Sie in einem Chat im Composer Ihre App, beginnen Sie einen Dialog und schauen Sie, ob ChatGPT das Widget einbettet und Ihr UI lädt.

Um sichtbar zu machen, dass das genau Ihr Code ist, können Sie etwas sehr Einfaches im Widget ändern, zum Beispiel die Überschrift:

// app/widget/page.tsx (Beispiel)
'use client';

export default function GiftGeniusWidget() {
  return <h1>GiftGenius über den Tunnel 🚇</h1>;
}

Nach dem Speichern der Datei:

1. Warten Sie, bis Next.js den Fast Refresh durchgeführt hat,
2. gehen Sie in den Bereich von ChatGPT, in dem Sie Ihre App hinzugefügt haben, und aktualisieren (refresh) Sie sie,
3. öffnen/aktualisieren Sie die Sitzung mit der App in ChatGPT,
4. schreiben Sie eine neue Anfrage an ChatGPT und bitten Sie, Ihr Widget anzuzeigen,
5. vergewissern Sie sich, dass der neue Überschriftstext bereits innerhalb von ChatGPT sichtbar ist.

Das ist der kleine Moment der Wahrheit: Sie haben gerade Code auf Ihrer Maschine geändert, und diese Änderung hat sich über den Tunnel in der Cloud‑Oberfläche von ChatGPT niedergeschlagen.

9. Ein wenig über Sicherheit und „was Sie genau nach außen gestellt haben“

Jeder Tunnel ist kein Spielzeug, sondern ein echter öffentlicher Eingang zu Ihrer Maschine. In unserem Übungsszenario leiten wir nur localhost:3000 weiter, wo die Next.js‑Anwendung läuft. Das ist relativ sicher, wenn:

• dieser Port für nichts anderes verwendet wird;
• Sie keine „Monster‑App“ betreiben, in die aus irgendeinem Grund ein DB‑Adminpanel, phpMyAdmin und noch vier Demo‑Services eingebaut sind.

Ein paar wichtige Praxisregeln.

Ein Tunnel ist ein Entwicklungswerkzeug, kein produktives System. Wir verwenden ihn bewusst im Dev Mode, nicht für echte Nutzer und schon gar nicht für Zahlungsabwicklung.

Vermeiden Sie es, auf demselben Port (3000) irgendwelche Admin‑Panels, Datenbanken ohne Passwörter und Ähnliches zu starten. Alles, was auf diesem Port antwortet, ist aus dem Internet sichtbar, solange der Tunnel aktiv ist.

Verteilen Sie Ihre trycloudflare.com‑URL nicht überall. Ja, die Wahrscheinlichkeit, dass jemand sie aktiv scannt, während Sie ein Übungsprojekt bauen, ist gering. Aber die Gewohnheit „Link zum Dev‑Server überall herumreichen“ kann Ihnen in Produktion auf die Füße fallen.

Später, wenn wir zu Themen wie Vercel und Production‑Umgebung kommen, werden wir normales Hosting mit stabilen Domains und Produktionssicherheit verwenden, und der Tunnel bleibt ein reines Dev‑Werkzeug.

10. Typische Fehler beim lokalen Start und mit dem Tunnel

Wir haben nun einen laufenden lokalen Next.js, einen funktionierenden HTTPS‑Tunnel und den verbundenen Dev Mode in ChatGPT. Zum Schluss — einige typische Fehler, die fast alle in den ersten Iterationen sehen, und wie man sie schnell diagnostiziert.

Fehler Nr. 1: Versuch, http://localhost:3000 direkt in ChatGPT zu verwenden.
Manche Einsteiger kopieren diese URL in die Dev‑Mode‑Konfiguration und wundern sich, warum ChatGPT meldet, es könne die App nicht erreichen. Zur Erinnerung: localhost bedeutet „ich selbst“ für den, der die Anfrage stellt. Für ChatGPT sind das die OpenAI‑Server, nicht Ihr Laptop. Besondere Logs werden Sie dabei nicht sehen, weil die Anfragen Ihre Maschine überhaupt nicht erreichen.

Fehler Nr. 2: Den Tunnel zu einem nicht existierenden oder falschen Port starten.
Häufiges Szenario: Sie haben früher einmal npm run dev auf Port 3000 laufen lassen, der Server ist längst beendet, aber im zweiten Terminal starten Sie aus Gewohnheit cloudflared tunnel --url http://localhost:3000. Cloudflare gibt Ihnen eine hübsche HTTPS‑Domain, aber beim Öffnen gibt es einen Fehler. Die Diagnose ist einfach: Der lokale Server läuft nicht. Prüfen Sie immer zuerst http://localhost:3000 im Browser und schalten Sie erst dann den Tunnel ein.

Fehler Nr. 3: Verwechslung zwischen http:// und https:// beim Start des Tunnels.
Der Tunnel liefert Ihnen außen HTTPS, intern muss er aber per HTTP an den lokalen Server gehen, zum Beispiel http://localhost:3000. Der Versuch, https://localhost:3000 anzugeben, führt oft zu seltsamen TLS‑Fehlern im Inneren oder einfach zur Unerreichbarkeit. Merken Sie sich die Regel: HTTPS außen, HTTP innen.

Fehler Nr. 4: Terminal mit Tunnel geschlossen bei aktivem Testen in ChatGPT.
Noch ein Klassiker: Alles ist eingerichtet, die App funktioniert in ChatGPT, dann schließen Sie aus Versehen das Terminalfenster mit cloudflared. Zehn Minuten später kommen Sie zu ChatGPT zurück — „App unavailable“. Der Grund ist simpel: Die URL steht noch in den App‑Einstellungen, aber der Tunnel selbst ist aus. Merken Sie sich: Solange Sie die App im Dev Mode testen, muss ein Terminal mit laufendem Tunnel daneben offen sein.

Fehler Nr. 5: Unbewusste Verwendung einer neuen URL nach dem Neustart des Tunnels.
Im Quick‑Tunnel‑Modus vergibt Cloudflare bei jedem Start eine neue *.trycloudflare.com. Wenn Sie cloudflared stoppen und neu starten, in ChatGPT aber weiterhin die alte URL steht, wird ChatGPT brav dorthin gehen und Timeouts oder einen fremden Service bekommen. Aktualisieren Sie bei geänderter Tunnel‑URL immer die Einstellung im Dev Mode. Später sprechen wir darüber, wie man eine stabile Dev‑Domain einrichtet, damit Sie nicht hinter URLs herlaufen.

Fehler Nr. 6: Überflüssige oder riskante Services auf denselben Port legen.
Manche Entwickler starten auf Port 3000 der Bequemlichkeit halber nicht nur Next.js, sondern auch allerlei „Hilfszeug“: Debug‑Panel, experimentelles API ohne Authentifizierung und so weiter. Sobald Sie diesen Port durch den Tunnel weiterleiten, sind all diese Dinge von außen erreichbar. Beim Übungsprojekt passiert wahrscheinlich nichts Schlimmes, aber diese Gewohnheit erhöht in realen Projekten das Risiko von Leaks und Hacks deutlich. Behalten Sie immer im Kopf: Alles, was auf dem im Tunnel angegebenen Port antwortet, schaut ins Internet.