Zum Inhalt springen

Ports von einem Terminal weiterleiten

Ein Server, den du im Terminal einer Unterhaltung startest, wird nur für diesen Bereich veröffentlicht. Das Ports-Panel bemerkt die Listener, die diese App dort gestartet hat, ordnet sie zu und nennt dir eine Adresse für jeden Ort, von dem aus du sie erreichen willst. Zwei Bereiche können beide auf 5173 lauschen; ihre Zuordnungen vermischen sich nie.

Nichts davon öffnet die Maschine: Jeden Zugang legt der Server auf Anfrage an, und er endet mit dem Terminal oder dem Rig.

  1. Öffne das Terminal (VM) oder die Host-Shell der Unterhaltung (in einem Bereich oder auf einer PR-Seite).
  2. Starte deinen Server — pnpm dev, python -m http.server 8000, irgendetwas.
  3. Nach wenigen Sekunden bekommt das Steckersymbol oben rechts im Terminal einen Punkt. Klicke darauf.

Das Panel listet jeden lauschenden Port mit dem Prozess, dem er gehört, als 3000 → 3000: links der Port, an den der Prozess gebunden hat, rechts der Port, auf dem er lokal antwortet (dieselbe Zahl, wann immer sie auf deinem Rechner frei war). Jede Zeile sagt außerdem, ob localhost auf dem Desktop, der Browser (VM) und Android ihn erreichen.

Die Erkennung bleibt eingegrenzt: Ein Terminal (VM) wird in diesem Gast abgefragt, eine Host-Shell über den PTY-Prozessbaum dieser Sitzung. Andere Bereiche und andere Prozesse auf deinem Mac erscheinen nicht.

Neue Ports in diesem Terminal werden automatisch weitergeleitet. Schalte Ports automatisch weiterleiten im selben Panel aus, wenn du nur die Ports willst, die du selbst hinzufügst.

Nutze in der Zeile Lokale URL kopieren — http://localhost:3000. Die Weiterleitung lauscht nur auf Loopback, deshalb sieht sie sonst niemand in deinem Netzwerk.

Wenn zwei Bereiche beide den Gast-Port 5173 freigeben und dein Rechner 127.0.0.1:5173 schon belegt, behält der zweite Bereich den Gast-Port 5173 und bekommt einen ephemeren lokalen Port. Lokale URL kopieren verwendet die rechte Zahl.

Auf einer Host-Shell läuft der Prozess schon auf deinem Rechner. Dieselbe lokale Portnummer zuzuordnen bewirkt nichts; ein anderer lokaler Port bindet einen Loopback-Proxy an den Port, den du gewählt hast.

--host (oder das Binden von 0.0.0.0) macht einen gekapselten Browser (VM) nicht fähig, einen Server auf dem Mac zu erreichen. Der Gast hat sein eigenes Loopback; der Server legt einen Tunnel in diesen Gast, wenn der Browser-Tab im selben Bereich ist.

Öffne den gekapselten Browser in derselben Unterhaltung. Tippe localhost:<left-hand port> — die Zahl, an die der Prozess gebunden hat. Eine Umleitung (5173 → 3000) antwortet in diesem Browser auch auf der rechten Zahl, deshalb funktioniert Lokale URL kopieren auch dort. browser_use eines Agenten kann beide Ziele ansteuern. Ein Server in Bereich A erscheint nie als localhost:5173 im Browser von Bereich B.

Nimm localhost, keine LAN-IP und nicht --host. Der Gast hat sein eigenes Loopback; der Tunnel lauscht dort auf IPv4 und auf IPv6.

Seiten, die viele Verbindungen auf einmal öffnen (Dutzende Assets, ein Live-Reload-Socket), teilen sich denselben Tunnel. Der Browser (VM) multiplexiert sie auf einen persistenten Exec, sodass ein Schub von Fetches nicht je Verbindung einen Prozess startet und nicht als weiße Seite ins Timeout läuft.

In einem Bereich gewinnt eine Weiterleitung aus dem Terminal (VM) gegen eine Host-Shell auf derselben Zahl. Über Bereiche hinweg gibt es keinen Vorrang — es sind getrennte Zuordnungen.

Öffne den Tab Android dieses Bereichs. localhost:<port> des Emulators wird dann auf den veröffentlichten Port dieses Bereichs umgekehrt (adb reverse). Ein Emulator gilt geräteweit: Hängst du Bereich B an, zeigt :5173 auf B, und die Zuordnung von A fällt weg. Schließe den Tab, dann werden die Reverse-Weiterleitungen entfernt, die dieses Rig angelegt hat.

Der iOS Simulator ist bereits der Mac — kein Reverse. Ein physisches iPhone braucht weiterhin eine Freigabe im LAN.

⋯ → Im lokalen Netzwerk teilen veröffentlicht den Port unter <server-ip>:<random port> — nützlich, um die Seite auf dem Telefon zu öffnen oder wenn der Server auf einer anderen Maschine läuft.

  • Der LAN-Port wird immer vom Betriebssystem vergeben, nie mit der Zahl des Gastes. Die Freigabe ist deshalb eine bewusste, sichtbare Adresse und keine, die sich erraten lässt.
  • Er bleibt privat (nur Loopback), bis du ihn umschaltest, und ⋯ → Nur lokal nimmt ihn wieder vom Netzwerk.

⋯ → Browser-Domain festlegen (.test) weist dem Port eine Dev-Domain zu, etwa myapp.test. Im Browser (VM) lädt https://myapp.test dann deinen Server mit einem gültigen Schloss — nützlich für alles, das sich auf einem benannten Origin oder in einem sicheren Kontext anders verhält (Cookies, Service Worker, OAuth-Callbacks).

  • Domains müssen auf .test oder .localhost enden — die beiden TLDs, die für die Entwicklung reserviert sind, damit ein Dev-Name nie eine echte Website verdecken kann.
  • Domain-Namen sind auf dem Server eindeutig; Port-Zahlen nicht. Zwei Bereiche dürfen beide 5173 nutzen, aber nicht beide myapp.test beanspruchen.
  • Das Zertifikat stammt von einer lokalen Zertifizierungsstelle, die dein Server beim ersten Bedarf erzeugt. Ihre Schlüssel liegen im Datenverzeichnis des Servers und gelangen in keinen Gast; der gekapselte Browser vertraut genau diesem einen Schlüssel, sodass TLS ins echte Internet weiterhin normal geprüft wird.
  • Die Domain löst sich nur im Browser (VM) auf. Dein eigener Browser auf dem Host nutzt stattdessen localhost:<port>.
  • Auch reines http://myapp.test funktioniert.

Port hinzufügen unten im Panel ordnet einen Port zu, bevor etwas darauf lauscht — oder unabhängig davon, ob überhaupt etwas lauscht. Eine manuelle Weiterleitung behält ihre Adresse, während dein Server neu startet — die Zeile zeigt lauscht nicht, bis er zurück ist —, wohingegen automatische Weiterleitungen verschwinden, sobald ihr Port verschwindet. Auf einer Host-Shell kannst du außerdem einen anderen lokalen Port setzen.

Ports haben Arbeitsbereich und Bereich als Schlüssel. Die eigene Portzuordnung des Hypervisors steht fest, wenn eine Maschine startet, deshalb nutzt ein Terminal (VM) zwei schmale Kanäle, die der Server steuert: eine vorab angelegte eingehende Bahn in den Gast, die keine Verbindung zu einem Port aufbaut, auf dem der Gast nicht tatsächlich lauscht, und Reverse-Tunnel, die der Server für den Browser (VM) und für Android offen hält. Eine Host-Shell scannt nie die ganze Maschine. Im Gast entsteht nie ein Listener, den der Server nicht selbst dort angelegt hat, und alles wird mit dem Terminal oder dem Rig abgebaut. Das Design steht unter Rigs und Kapseln; die genauen reservierten Ports und Domain-Regeln in der Rigs-Referenz.