Poorten doorsturen vanaf een terminal

Een server die je in de terminal van een gesprek start, wordt alleen gepubliceerd voor die ruimte. Het poortenpaneel merkt de processen op die deze app daar heeft gestart, brengt ze in kaart en geeft je een adres voor elke plek van waaruit je ze wilt bereiken. Twee ruimtes kunnen allebei op 5173 luisteren; hun poortmappen lopen nooit door elkaar.

Niets hiervan zet de machine open: elk pad wordt door de server aangemaakt, op verzoek, en verdwijnt samen met de terminal of de rig.

Zie wat er luistert

1. Open de Terminal (VM) of hostshell van het gesprek (in een ruimte of op een PR-pagina).
2. Start je server — pnpm dev, python -m http.server 8000, wat dan ook.
3. Binnen een paar seconden krijgt het stekkerpictogram rechtsboven in de terminal een stip. Klik erop.

Het paneel toont elke luisterende poort met het proces dat er eigenaar van is, als 3000 → 3000: links de poort waarop het proces zich heeft gebonden, rechts de poort waarop het lokaal antwoordt (hetzelfde nummer wanneer die vrij was op jouw machine). Elke rij vermeldt ook of desktop-localhost, de Browser (VM) en Android er kunnen komen.

Detectie blijft begrensd: een Terminal (VM) wordt binnen die gast uitgelezen; een hostshell wordt uitgelezen vanuit de PTY-procesboom van die sessie. Andere ruimtes, en andere processen op je Mac, worden niet vermeld.

Nieuwe poorten in deze terminal worden automatisch doorgestuurd. Zet Poorten automatisch doorsturen uit in hetzelfde paneel als je alleen de poorten wilt die je zelf toevoegt.

Bereik het vanaf deze computer

Gebruik Lokale URL kopiëren in de rij — http://localhost:3000. De doorsturing luistert alleen op loopback, dus niets anders op je netwerk kan hem zien.

Als twee ruimtes allebei gastpoort 5173 aanbieden en jouw machine heeft 127.0.0.1:5173 al bezet, dan houdt de tweede ruimte gastpoort 5173 en krijgt die een tijdelijke lokale poort. URL kopiëren gebruikt het rechternummer.

Op een hostshell draait het proces al op jouw machine. Dezelfde lokale poort mappen heeft geen effect; kies je een andere lokale poort, dan bindt er een loopbackproxy aan de poort die je hebt gekozen.

--host (of binden op 0.0.0.0) zorgt er niet voor dat een ingesloten Browser (VM) een server op de Mac kan bereiken. De gast heeft zijn eigen loopback; de server plant een tunnel in die gast zodra het browsertabblad in dezelfde ruimte staat.

Bereik het vanuit de Browser (VM)

Open de ingesloten browser in hetzelfde gesprek. Typ localhost:<left-hand port> — het nummer waarop het proces zich heeft gebonden. Een remap (5173 → 3000) antwoordt in die browser ook op het rechternummer, dus daar werkt URL kopiëren ook. De browser_use van een agent kan naar beide navigeren. Een server in Ruimte A verschijnt nooit als localhost:5173 in de browser van Ruimte B.

Gebruik localhost, geen LAN-IP en niet --host. De gast heeft zijn eigen loopback; de tunnel luistert daar zowel op IPv4 als op IPv6.

Pagina’s die veel verbindingen tegelijk openen (tientallen assets, een live-reloadsocket) delen diezelfde tunnel. De Browser (VM) multiplext ze naar één persistente exec, zodat een uitbarsting van requests niet per verbinding een nieuw proces start en niet uitloopt op een time-out met een witte pagina.

Binnen één ruimte wint een doorsturing van de Terminal (VM) van een hostshell op hetzelfde nummer. Tussen ruimtes is er geen voorrang — het zijn afzonderlijke poortmappen.

Bereik het vanaf Android

Open het tabblad Android van die ruimte. De localhost:<port> van de emulator wordt dan omgekeerd naar de gepubliceerde poort van deze ruimte (adb reverse). Eén emulator is apparaatglobaal: Ruimte B koppelen richt :5173 opnieuw op B en laat die van A vallen. Sluit je het tabblad, dan worden de reverses die deze rig heeft geplant verwijderd.

De iOS Simulator is de Mac zelf — geen reverse nodig. Een fysieke iPhone heeft nog steeds een LAN-deel nodig.

Deel het op je netwerk

⋯ → Delen op lokaal netwerk publiceert de poort op <server-ip>:<random port> — handig om de pagina op je telefoon te openen, of wanneer de server op een andere machine draait.

• De LAN-poort wordt altijd door het besturingssysteem toegewezen, nooit het nummer van de gast, zodat blootstelling een bewust, zichtbaar adres is in plaats van een adres dat te raden valt.
• Hij blijft privé (alleen loopback) totdat je hem aanzet, en ⋯ → Alleen lokaal haalt hem weer van het netwerk.

Geef het een naam — met HTTPS

⋯ → Een browserdomein instellen (.test) kent de poort een dev-domein toe zoals myapp.test. In de Browser (VM) laadt https://myapp.test dan je server met een geldig slotje — handig voor alles wat zich anders gedraagt op een benoemde origin of in een secure context (cookies, service workers, OAuth-callbacks).

• Domeinen moeten eindigen op .test of .localhost — de twee TLD’s die voor ontwikkeling zijn gereserveerd, zodat een dev-naam nooit een echte site kan overschaduwen.
• Domeinnamen zijn uniek op de server; poortnummers niet. Twee ruimtes mogen allebei 5173 gebruiken, maar ze kunnen niet allebei myapp.test opeisen.
• Het certificaat komt van een lokale autoriteit die op je server wordt aangemaakt zodra die voor het eerst nodig is. De sleutels staan onder de datadirectory van de server en komen nooit in een gast terecht; de ingesloten browser vertrouwt precies die ene sleutel, zodat TLS naar het echte internet nog steeds normaal valideert.
• Het domein resolvet alleen binnen de Browser (VM). Je eigen browser op de host gebruikt in plaats daarvan localhost:<port>.
• Gewoon http://myapp.test werkt ook.

Een poort handmatig doorsturen

Poort toevoegen onderaan het paneel mapt een poort voordat (of ongeacht of) er iets op luistert. Een handmatige doorsturing behoudt zijn adres terwijl je server opnieuw opstart — de rij toont luistert niet totdat hij terug is — terwijl automatische doorsturingen verdwijnen zodra hun poort dat doet. Op een hostshell kun je ook een andere lokale poort instellen.

Hoe het ingesloten blijft

Poorten zijn gekoppeld aan werkruimte en ruimte. De eigen poortmap van de hypervisor staat vast zodra een machine opstart, dus een Terminal (VM) rijdt op twee smalle kanalen die de server beheert: één vooraf aangemaakte inkomende baan naar de gast, die weigert verbinding te maken met een poort waarop de gast niet daadwerkelijk luistert, en reverse tunnels die de server openhoudt voor de Browser (VM) en Android. Een hostshell scant nooit de hele machine. Er wordt nooit een listener in een gast aangemaakt die de server er niet heeft neergezet, en alles wordt samen met de terminal of de rig afgebroken. Het ontwerp staat uitgelegd in Rigs en omhullingen; de exacte gereserveerde poorten en domeinregels staan in de rigs-referentie.

Gerelateerd

• Een agent een testmachine geven — rigs openen, bekijken en overnemen
• Rigs-referentie — gereserveerde poorten, dev-TLD’s, standaardwaarden