Transférer des ports depuis un terminal

Un serveur que vous démarrez dans le terminal d’une conversation n’est publié que pour cet espace. Le panneau des ports repère les ports en écoute que cette application a démarrés là, les mappe et vous donne une adresse pour chaque endroit depuis lequel vous pourriez vouloir les joindre. Deux espaces peuvent tous deux écouter sur 5173 ; leurs mappages ne se mélangent jamais.

Rien ici n’ouvre la machine : chaque chemin est créé par le serveur, à la demande, et disparaît avec le terminal ou le rig.

Voir ce qui écoute

1. Ouvrez le Terminal (VM) ou un shell hôte de la conversation (dans un espace ou sur une page de PR).
2. Démarrez votre serveur — pnpm dev, python -m http.server 8000, n’importe quoi.
3. En quelques secondes, l’icône de prise dans le coin supérieur droit du terminal se dote d’un point. Cliquez dessus.

Le panneau liste chaque port en écoute avec le processus qui le détient, sous la forme 3000 → 3000 : à gauche le port sur lequel le processus s’est lié, à droite le port sur lequel il répond localement (le même numéro dès qu’il était libre sur votre machine). Chaque ligne indique aussi si localhost sur l’ordinateur, le Navigateur (VM) et Android peuvent l’atteindre.

La découverte reste confinée : un Terminal (VM) est interrogé depuis l’intérieur de cet invité ; un shell hôte est interrogé depuis l’arbre de processus PTY de cette session. Les autres espaces, et les autres processus de votre Mac, ne sont pas listés.

Les nouveaux ports de ce terminal sont transférés automatiquement. Désactivez Transfert automatique des ports dans le même panneau si vous ne voulez que ceux que vous ajoutez vous-même.

L’atteindre depuis cet ordinateur

Utilisez Copier l’URL locale sur la ligne — http://localhost:3000. Le transfert n’écoute que sur la boucle locale, donc rien d’autre sur votre réseau ne peut le voir.

Si deux espaces exposent tous deux le port invité 5173 et que votre machine occupe déjà 127.0.0.1:5173, le second espace garde le port invité 5173 et reçoit un port local éphémère. Copier l’URL utilise le numéro de droite.

Sur un shell hôte, le processus est déjà sur votre machine. Mapper le même port local ne change rien ; choisir un port local différent lie un proxy de boucle locale à celui que vous avez choisi.

--host (ou une liaison sur 0.0.0.0) ne permet pas à un Navigateur (VM) isolé d’atteindre un serveur sur le Mac. L’invité a sa propre boucle locale ; le serveur implante un tunnel dans cet invité lorsque l’onglet Navigateur est dans le même espace.

L’atteindre depuis le Navigateur (VM)

Ouvrez le navigateur isolé dans la même conversation. Saisissez localhost:<left-hand port> — le numéro sur lequel le processus s’est lié. Un remappage (5173 → 3000) répond aussi au numéro de droite dans ce navigateur, donc Copier l’URL fonctionne là aussi. Le browser_use d’un agent peut naviguer vers l’un ou l’autre. Un serveur de l’espace A n’apparaît jamais comme localhost:5173 dans le navigateur de l’espace B.

Utilisez localhost, pas une IP de réseau local et pas --host. L’invité a sa propre boucle locale ; le tunnel y écoute à la fois en IPv4 et en IPv6.

Les pages qui ouvrent beaucoup de connexions à la fois (des dizaines d’actifs, une socket de rechargement automatique) partagent ce même tunnel. Le Navigateur (VM) les multiplexe sur un seul exec persistant, si bien qu’une rafale de requêtes ne correspond pas à un lancement de processus par connexion et n’expire pas en page blanche.

Au sein d’un même espace, un transfert depuis le Terminal (VM) l’emporte sur un shell hôte sur le même numéro. Entre espaces, il n’y a aucune priorité — ce sont des mappages distincts.

L’atteindre depuis Android

Ouvrez l’onglet Android de cet espace. Le localhost:<port> de l’émulateur est alors inversé vers le port publié de cet espace (adb reverse). Un émulateur est global à l’appareil : rattacher l’espace B réoriente :5173 vers B et abandonne celui de A. Fermez l’onglet et les inversions implantées par ce rig sont supprimées.

Le simulateur iOS est déjà le Mac — aucune inversion. Un iPhone physique a toujours besoin d’un partage sur le réseau local.

Le partager sur votre réseau

⋯ → Partager sur le réseau local publie le port à l’adresse <server-ip>:<random port> — utile pour ouvrir la page sur votre téléphone, ou lorsque le serveur tourne sur une autre machine.

• Le port réseau local est toujours attribué par l’OS, jamais le numéro de l’invité : l’exposition est donc une adresse délibérée et visible plutôt qu’une adresse devinable.
• Il reste privé (boucle locale uniquement) jusqu’à ce que vous l’activiez, et ⋯ → Local uniquement le retire du réseau.

Lui donner un nom — avec HTTPS

⋯ → Définir un domaine navigateur (.test) attribue au port un domaine de développement tel que myapp.test. Dans le Navigateur (VM), https://myapp.test charge alors votre serveur avec un cadenas valide — utile pour tout ce qui se comporte différemment sur une origine nommée ou dans un contexte sécurisé (cookies, service workers, rappels OAuth).

• Les domaines doivent se terminer par .test ou .localhost — les deux TLD réservés au développement, afin qu’un nom de dev ne puisse jamais masquer un vrai site.
• Les noms de domaine sont uniques sur le serveur ; les numéros de port ne le sont pas. Deux espaces peuvent tous deux utiliser 5173, mais ils ne peuvent pas revendiquer tous les deux myapp.test.
• Le certificat provient d’une autorité locale générée sur votre serveur la première fois qu’elle est nécessaire. Ses clés vivent dans le répertoire de données du serveur et n’entrent dans aucun invité ; le navigateur isolé fait confiance à cette seule clé, donc le TLS vers l’internet réel se valide toujours normalement.
• Le domaine ne se résout qu’à l’intérieur du Navigateur (VM). Votre propre navigateur sur l’hôte utilise plutôt localhost:<port>.
• Le simple http://myapp.test fonctionne aussi.

Transférer un port à la main

Ajouter un port, en bas du panneau, mappe un port avant même que quoi que ce soit y écoute (ou sans qu’aucun processus n’y écoute). Un transfert manuel conserve son adresse pendant que votre serveur redémarre — la ligne affiche n’écoute pas jusqu’à son retour — alors que les transferts automatiques disparaissent quand leur port disparaît. Sur un shell hôte, vous pouvez aussi définir un port local différent.

Comment cela reste confiné

Les ports sont indexés par espace de travail et par espace. La table de ports de l’hyperviseur est figée au démarrage d’une machine, si bien qu’un Terminal (VM) emprunte deux canaux étroits contrôlés par le serveur : une voie entrante pré-créée vers l’invité, qui refuse de se connecter à tout port sur lequel l’invité n’écoute pas réellement, et des tunnels inverses que le serveur maintient ouverts pour le Navigateur (VM) et Android. Un shell hôte ne scanne jamais toute la machine. Aucun écouteur n’est jamais créé dans un invité que le serveur n’y a pas mis, et tout est démonté avec le terminal ou le rig. La conception est expliquée dans Rigs et enceintes ; les ports réservés exacts et les règles de domaine se trouvent dans la référence des rigs.

Voir aussi

• Donner une machine de test à un agent — ouvrir, observer et prendre le contrôle des rigs
• Référence des rigs — ports réservés, TLD de développement, valeurs par défaut