Reenviar puertos desde un terminal

Un servidor que inicias en la terminal de una conversación se publica solo para ese espacio. El panel de puertos detecta los servicios a la escucha que esta app inició allí, los asigna y te da una dirección para cada lugar desde el que quieras llegar a ellos. Dos espacios pueden escuchar ambos en 5173; sus mapas nunca se mezclan.

Nada de esto abre la máquina: cada ruta la crea el servidor, a petición, y muere con la terminal o el rig.

Ver qué está escuchando

1. Abre la Terminal (VM) de la conversación o un shell del host (en un espacio o en la página de una PR).
2. Inicia tu servidor: pnpm dev, python -m http.server 8000, lo que sea.
3. En unos segundos, el icono de enchufe de la esquina superior derecha de la terminal recibe un punto. Haz clic en él.

El panel lista cada puerto a la escucha con el proceso que lo posee, como 3000 → 3000: a la izquierda, el puerto al que se vinculó el proceso; a la derecha, el puerto en el que responde localmente (el mismo número siempre que estuviera libre en tu máquina). Cada fila también indica si el localhost de escritorio, el Navegador (VM) y Android pueden llegar a él.

La detección está contenida: a una Terminal (VM) se la sondea dentro de ese huésped; a un shell del host se lo sondea desde el árbol de procesos del PTY de esa sesión. Los demás espacios, y los demás procesos de tu Mac, no aparecen en la lista.

Los puertos nuevos de esta terminal se reenvían automáticamente. Desactiva Reenvío automático de puertos en el mismo panel si quieres solo los que agregues tú.

Llegar desde esta computadora

Usa Copiar URL local en la fila: http://localhost:3000. El reenvío escucha solo en loopback, así que nada más en tu red puede verlo.

Si dos espacios exponen ambos el 5173 del huésped y tu máquina ya ocupa 127.0.0.1:5173, el segundo espacio conserva el 5173 del huésped y recibe un puerto local efímero. Copiar URL local usa el número de la derecha.

En un shell del host, el proceso ya está en tu máquina. Asignar el mismo puerto local no hace nada; elegir un puerto local distinto vincula un proxy de loopback al que elegiste.

--host (o vincularse a 0.0.0.0) no hace que un Navegador (VM) con recinto pueda llegar a un servidor en la Mac. El huésped tiene su propio loopback; el servidor planta un túnel dentro de ese huésped cuando la pestaña del Navegador está en el mismo espacio.

Llegar desde el Navegador (VM)

Abre el navegador con recinto en la misma conversación. Escribe localhost:<left-hand port> — el número al que se vinculó el proceso. Una reasignación (5173 → 3000) también responde en el número de la derecha en ese navegador, así que Copiar URL local funciona allí también. El browser_use de un agente puede navegar a cualquiera de los dos. Un servidor del Espacio A nunca aparece como localhost:5173 en el navegador del Espacio B.

Usa localhost, no una IP de LAN ni --host. El huésped tiene su propio loopback; el túnel escucha allí tanto en IPv4 como en IPv6.

Las páginas que abren muchas conexiones a la vez (decenas de recursos, un socket de recarga en vivo) comparten ese mismo túnel. El Navegador (VM) las multiplexa sobre un único exec persistente, así que una ráfaga de peticiones no es un proceso lanzado por conexión y no termina en una página en blanco por tiempo de espera agotado.

Dentro de un mismo espacio, un reenvío de la Terminal (VM) gana sobre uno de un shell del host en el mismo número. Entre espacios no hay precedencia: son mapas separados.

Llegar desde Android

Abre la pestaña Android de ese espacio. El localhost:<port> del emulador se invierte entonces hacia el puerto publicado de este espacio (adb reverse). Un emulador es global para el dispositivo: adjuntar el Espacio B reorienta :5173 hacia B y descarta el de A. Cierra la pestaña y se eliminan los reverses que plantó este rig.

El Simulador de iOS ya es la Mac — sin reverse. Un iPhone físico aún necesita compartirlo en la LAN.

Compartirlo en tu red

⋯ → Compartir en la red local publica el puerto en <server-ip>:<random port> — útil para abrir la página en tu teléfono, o cuando el servidor corre en otra máquina.

• El puerto de LAN siempre lo asigna el sistema operativo, nunca es el número del huésped, así que la exposición es una dirección deliberada y visible, no una adivinable.
• Permanece privado (solo loopback) hasta que lo activas, y ⋯ → Solo local lo saca de nuevo de la red.

Darle un nombre — con HTTPS

⋯ → Establecer un dominio del navegador (.test) asigna al puerto un dominio de desarrollo como myapp.test. Dentro del Navegador (VM), https://myapp.test carga entonces tu servidor con un candado válido — útil para todo lo que se comporta distinto en un origen con nombre o en un contexto seguro (cookies, service workers, callbacks de OAuth).

• Los dominios deben terminar en .test o .localhost — los dos TLD reservados para el desarrollo, así que un nombre de desarrollo nunca puede eclipsar a un sitio real.
• Los nombres de dominio son únicos en el servidor; los números de puerto no. Dos espacios pueden usar ambos 5173, pero no pueden reclamar ambos myapp.test.
• El certificado proviene de una autoridad local acuñada en tu servidor la primera vez que se necesita. Sus claves viven bajo el directorio de datos del servidor y nunca entran en ningún huésped; el navegador con recinto confía exactamente en esa clave, así que el TLS hacia la internet real sigue validándose con normalidad.
• El dominio se resuelve solo dentro del Navegador (VM). Tu propio navegador en el host usa localhost:<port> en su lugar.
• El http://myapp.test sin más también funciona.

Reenviar un puerto a mano

Añadir puerto, al final del panel, asigna un puerto antes de que algo esté escuchando en él (o aunque no haya nada). Un reenvío manual conserva su dirección mientras tu servidor se reinicia —la fila muestra no escucha hasta que vuelve—, mientras que los reenvíos automáticos desaparecen cuando desaparece su puerto. En un shell del host también puedes establecer un puerto local distinto.

Cómo se mantiene contenido

Los puertos se indexan por espacio de trabajo y espacio. El mapa de puertos propio del hipervisor se fija cuando arranca una máquina, así que una Terminal (VM) viaja por dos canales estrechos que controla el servidor: un carril de entrada creado de antemano hacia el huésped que se niega a conectar con cualquier puerto en el que el huésped no esté escuchando realmente, y túneles inversos que el servidor mantiene abiertos para el Navegador (VM) y Android. Un shell del host nunca escanea toda la máquina. Nunca se crea un servicio a la escucha dentro de un huésped que el servidor no haya puesto allí, y todo se desmonta con la terminal o el rig. El diseño se explica en Rigs y recintos; los puertos reservados exactos y las reglas de dominios están en la referencia de rigs.

Relacionado

• Dar a un agente una computadora para probar — abrir, observar y tomar el control de los rigs
• Referencia de rigs — puertos reservados, TLD de desarrollo, valores predeterminados