Aller au contenu

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 à l’écoute que cette application y a démarrés, les mappe et vous donne une adresse pour chaque endroit d’où vous pourriez vouloir les joindre. Deux espaces peuvent écouter tous les deux 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 meurt avec le terminal ou le rig.

  1. Ouvrez le Terminal (VM) ou le shell de l’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 affiche un point. Cliquez dessus.

Le panneau liste chaque port à l’é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 chaque fois qu’il était libre sur votre machine). Chaque ligne indique aussi si le localhost du bureau, le Navigateur (VM) et Android peuvent l’atteindre.

La découverte est contenue : un Terminal (VM) est interrogé à l’intérieur de cet invité; un shell de l’hôte est interrogé à partir de 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 le Transfert automatique des ports dans le même panneau si vous ne voulez que ceux que vous ajoutez vous-même.

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

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

Dans un shell de l’hôte, le processus est déjà sur votre machine. Mapper le même port local ne fait 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) en enceinte 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 se trouve dans le même espace.

Ouvrez le navigateur en enceinte dans la même conversation. Tapez localhost:<port de gauche> — 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 y fonctionne également. 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, et non une IP de réseau local ni --host. L’invité a sa propre boucle locale; le tunnel y écoute en IPv4 et en IPv6.

Les pages qui ouvrent plusieurs connexions à la fois (des dizaines de ressources, une socket de rechargement en direct) partagent ce même tunnel. Le Navigateur (VM) les multiplexe sur un seul exécutant persistant, de sorte qu’une rafale de requêtes n’entraîne pas un lancement de processus par connexion et n’expire pas en page blanche.

Dans un même espace, un transfert du Terminal (VM) l’emporte sur un shell de l’hôte pour le même numéro. Entre les espaces, il n’y a aucune préséance — ce sont des mappages distincts.

Ouvrez l’onglet Android de cet espace. Le localhost:<port> de l’émulateur est alors redirigé en sens inverse vers le port publié de cet espace (adb reverse). Un émulateur est global à l’appareil : y rattacher l’espace B recible :5173 vers B et abandonne celui de A. Fermez l’onglet et les redirections inverses implantées par ce rig sont retirées.

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

⋯ → Partager sur le réseau local publie le port à <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 du réseau local est toujours attribué par le système d’exploitation, jamais le numéro de l’invité, de sorte que l’exposition est une adresse délibérée et visible plutôt qu’une adresse devinable.
  • Il reste privé (boucle locale seulement) tant que vous ne l’activez pas, et ⋯ → Local uniquement le retire du réseau.

⋯ → Définir un domaine navigateur (.test) attribue au port un domaine de développement comme 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, de sorte qu’un nom de développement ne peut 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 les deux utiliser 5173, mais ils ne peuvent pas tous les deux revendiquer myapp.test.
  • Le certificat provient d’une autorité locale créée sur votre serveur la première fois qu’elle est nécessaire. Ses clés résident dans le répertoire de données du serveur et n’entrent jamais dans un invité; le navigateur en enceinte approuve exactement cette clé, de sorte que le TLS vers le vrai Internet se valide toujours normalement.
  • Le domaine se résout dans le Navigateur (VM) uniquement. Votre propre navigateur sur l’hôte utilise plutôt localhost:<port>.
  • Le simple http://myapp.test fonctionne aussi.

Ajouter un port au bas du panneau mappe un port avant que quoi que ce soit y écoute, ou indépendamment de cela. Un transfert manuel conserve son adresse pendant le redémarrage de votre serveur — la ligne affiche n’écoute pas jusqu’à ce qu’il revienne — alors que les transferts automatiques disparaissent en même temps que leur port. Dans un shell de l’hôte, vous pouvez aussi définir un autre port local.

Les ports sont indexés par espace de travail et par espace. Le mappage de ports de l’hyperviseur est fixé au démarrage d’une machine, de sorte 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 de l’hôte ne balaie jamais la machine entière. Aucun écouteur n’est jamais créé dans un invité que le serveur n’y a pas mis, et tout est démantelé 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.