Inoltra porte da un terminale

Un server che avvii nel terminale di una conversazione viene pubblicato solo per quello spazio. Il pannello delle porte rileva i processi in ascolto che questa app ha avviato lì, li mappa e ti fornisce un indirizzo per ogni luogo da cui potresti volerli raggiungere. Due spazi possono ascoltare entrambi su 5173; le loro mappe non si mescolano mai.

Nulla di tutto questo apre la macchina: ogni percorso viene creato dal server, su richiesta, e muore con il terminale o il rig.

Vedi cosa è in ascolto

1. Apri il Terminale (VM) o una shell sull’host della conversazione (in uno spazio o in una pagina di PR).
2. Avvia il tuo server — pnpm dev, python -m http.server 8000, qualsiasi cosa.
3. In pochi secondi l’icona della spina nell’angolo in alto a destra del terminale riceve un puntino. Cliccala.

Il pannello elenca ogni porta in ascolto con il processo che la possiede, nella forma 3000 → 3000: a sinistra la porta su cui il processo si è associato, a destra la porta su cui risponde localmente (lo stesso numero ogniqualvolta fosse libera sulla tua macchina). Ogni riga indica anche se localhost sul desktop, il Browser (VM) e Android possono raggiungerla.

Il rilevamento è circoscritto: un Terminale (VM) viene interrogato all’interno di quel guest; una shell sull’host viene interrogata dall’albero dei processi PTY di quella sessione. Gli altri spazi, e gli altri processi sul tuo Mac, non vengono elencati.

Le nuove porte in questo terminale vengono inoltrate automaticamente. Disattiva Inoltro automatico delle porte nello stesso pannello se vuoi solo quelle che aggiungi tu.

Raggiungilo da questo computer

Usa Copia URL locale sulla riga — http://localhost:3000. L’inoltro ascolta solo su loopback, quindi nient’altro sulla tua rete può vederlo.

Se due spazi espongono entrambi la porta guest 5173 e la tua macchina occupa già 127.0.0.1:5173, il secondo spazio mantiene la porta guest 5173 e riceve una porta locale effimera. Copia URL usa il numero a destra.

Su una shell sull’host, il processo è già sulla tua macchina. Mappare la stessa porta locale non ha alcun effetto; scegliere una porta locale diversa associa un proxy loopback a quella che hai scelto.

--host (o l’associazione su 0.0.0.0) non rende un Browser (VM) isolato in grado di raggiungere un server sul Mac. Il guest ha il suo loopback; il server impianta un tunnel in quel guest quando la scheda Browser è nello stesso spazio.

Raggiungilo dal Browser (VM)

Apri il browser isolato nella stessa conversazione. Digita localhost:<left-hand port> — il numero su cui il processo si è associato. Anche un remap (5173 → 3000) risponde al numero a destra in quel browser, quindi Copia URL funziona anche lì. Il browser_use di un agente può navigare verso l’uno o l’altro. Un server nello Spazio A non appare mai come localhost:5173 nel browser dello Spazio B.

Usa localhost, non un IP della LAN e non --host. Il guest ha il suo loopback; il tunnel ascolta lì sia su IPv4 sia su IPv6.

Le pagine che aprono molte connessioni in una volta (decine di asset, un socket di live reload) condividono quello stesso tunnel. Il Browser (VM) le multiplexa su un unico exec persistente, quindi una raffica di richieste non è un processo avviato per ogni connessione e non va in timeout come una pagina bianca.

All’interno di uno spazio, un inoltro di Terminale (VM) prevale su una shell sull’host sullo stesso numero. Tra spazi diversi non c’è precedenza: sono mappe separate.

Raggiungilo da Android

Apri la scheda Android di quello spazio. Il localhost:<port> dell’emulatore viene quindi invertito verso la porta pubblicata di questo spazio (adb reverse). Un emulatore è globale per il dispositivo: collegare lo Spazio B reindirizza :5173 verso B e abbandona quello di A. Chiudi la scheda e i reverse che questo rig ha impiantato vengono rimossi.

Il Simulatore iOS è già il Mac: nessun reverse. Un iPhone fisico ha comunque bisogno di una condivisione sulla LAN.

Condividilo sulla tua rete

⋯ → Condividi sulla rete locale pubblica la porta su <server-ip>:<random port> — utile per aprire la pagina sul telefono, o quando il server gira su un’altra macchina.

• La porta LAN è sempre assegnata dal sistema operativo, mai il numero del guest, quindi l’esposizione è un indirizzo deliberato e visibile, non uno indovinabile.
• Resta privata (solo loopback) finché non la attivi, e ⋯ → Solo locale la toglie di nuovo dalla rete.

Dagli un nome — con HTTPS

⋯ → Imposta un dominio browser (.test) assegna alla porta un dominio di sviluppo come myapp.test. All’interno del Browser (VM), https://myapp.test carica poi il tuo server con un lucchetto valido — utile per tutto ciò che si comporta diversamente su un’origine con nome o in un contesto sicuro (cookie, service worker, callback OAuth).

• I domini devono terminare in .test o .localhost — i due TLD riservati allo sviluppo, così un nome di sviluppo non può mai oscurare un sito reale.
• I nomi dei domini sono univoci sul server; i numeri delle porte no. Due spazi possono usare entrambi 5173, ma non possono rivendicare entrambi myapp.test.
• Il certificato proviene da un’autorità locale generata sul tuo server la prima volta che serve. Le sue chiavi risiedono nella directory dei dati del server e non entrano mai in alcun guest; il browser isolato si fida esattamente di quella chiave, quindi il TLS verso il vero internet viene comunque convalidato normalmente.
• Il dominio si risolve solo all’interno del Browser (VM). Il tuo browser sull’host usa invece localhost:<port>.
• Anche http://myapp.test semplice funziona.

Inoltra una porta manualmente

Aggiungi porta in fondo al pannello mappa una porta prima (o a prescindere dal fatto) che qualcosa sia in ascolto su di essa. Un inoltro manuale mantiene il suo indirizzo mentre il tuo server si riavvia — la riga mostra non in ascolto finché non torna — mentre gli inoltri automatici scompaiono quando scompare la loro porta. Su una shell sull’host puoi anche impostare una porta locale diversa.

Come resta circoscritto

Le porte sono indicizzate per spazio di lavoro e per spazio. La mappa delle porte dell’hypervisor è fissata all’avvio di una macchina, quindi un Terminale (VM) viaggia su due canali stretti controllati dal server: una corsia in entrata pre-creata verso il guest che rifiuta di connettersi a qualsiasi porta su cui il guest non sia effettivamente in ascolto, e tunnel inversi che il server tiene aperti per il Browser (VM) e Android. Una shell sull’host non scansiona mai l’intera macchina. Nessun listener viene mai creato dentro un guest se non è il server a metterlo lì, e tutto viene smantellato con il terminale o il rig. Il design è spiegato in Rig e recinti; le porte riservate esatte e le regole sui domini sono nel riferimento sui rig.

Correlati

• Assegna a un agente una macchina su cui testare — aprire, osservare e prendere il controllo dei rig
• Riferimento sui rig — porte riservate, TLD di sviluppo, valori predefiniti