Reenviar puertos desde un terminal

Un servidor que inicies en el terminal de una conversación se publica solo para ese espacio. El panel de puertos detecta los procesos a la escucha que esta app haya iniciado ahí, los asigna y te da una dirección para cada sitio 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 el terminal o el rig.

Qué está escuchando

1. Abre la Terminal (VM) de la conversación o el 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 del terminal recibe un punto. Haz clic en él.

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

El descubrimiento está contenido: a la Terminal (VM) se la sondea dentro de ese huésped, y al shell del host se le sondea desde el árbol de procesos PTY de esa sesión. Otros espacios, y otros procesos de tu Mac, no aparecen en la lista.

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

Llegar desde este ordenador

Usa Copiar URL local en la fila: http://localhost:3000. El reenvío escucha solo en loopback, así que nada más de 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 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 tiene ningún efecto; elegir un puerto local distinto vincula un proxy de loopback al que hayas elegido.

--host (o vincular a 0.0.0.0) no hace que un Navegador (VM) con recinto pueda llegar a un servidor del Mac. El huésped tiene su propio loopback; el servidor implanta un túnel en 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 dentro de ese navegador, así que Copiar URL funciona ahí 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 la LAN ni --host. El huésped tiene su propio loopback; el túnel escucha ahí 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, de modo que una ráfaga de peticiones no supone un proceso por conexión ni termina agotando el tiempo de espera con una página en blanco.

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

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). Cada emulador es global al dispositivo: adjuntar el Espacio B redirige :5173 hacia B y descarta el de A. Cierra la pestaña y se eliminan las inversiones que implantó este rig.

El Simulador de iOS ya es el Mac: sin inversión. Un iPhone físico sigue necesitando que lo compartas en la red local.

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 móvil, o cuando el servidor corre en otra máquina.

• El puerto de la LAN lo asigna siempre 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 que se pueda adivinar.
• Permanece privado (solo loopback) hasta que lo actives, 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 de forma distinta 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 desarrollo, de modo que un nombre de desarrollo nunca puede suplantar 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 procede de una autoridad local emitida en tu servidor la primera vez que se necesita. Sus claves viven en el directorio de datos del servidor y no entran nunca en ningún huésped; el navegador con recinto confía exactamente en esa clave, así que el TLS hacia internet real se sigue validando con normalidad.
• El dominio resuelve solo dentro del Navegador (VM). Tu propio navegador en el host usa en su lugar localhost:<port>.
• El simple http://myapp.test también funciona.

Reenviar un puerto a mano

Añadir puerto, en la parte inferior del panel, asigna un puerto antes de que haya algo escuchando en él (o aunque no lo haya). 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 lo hace 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 propio mapa de puertos del hipervisor queda fijado cuando arranca una máquina, así que la Terminal (VM) viaja por dos canales estrechos que controla el servidor: un carril entrante 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 dentro de un huésped ningún proceso a la escucha que el servidor no haya puesto ahí, y todo se desmonta con el 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 máquina para probar — abrir, observar y tomar el control de rigs
• Referencia de rigs — puertos reservados, TLD de desarrollo, valores predeterminados