Saltar para o conteúdo

Encaminhar portas a partir de um terminal

Um servidor que inicie no terminal de uma conversa é publicado apenas para esse espaço. O painel de portas deteta os serviços à escuta que esta aplicação iniciou aí, mapeia-os e dá-lhe um endereço para cada local a partir do qual os possa querer alcançar. Dois espaços podem ambos escutar na 5173; os respetivos mapas nunca se misturam.

Nada aqui abre a máquina: todos os caminhos são criados pelo servidor, a pedido, e morrem com o terminal ou o rig.

  1. Abra o Terminal (VM) da conversa ou o shell do anfitrião (num espaço ou numa página de PR).
  2. Inicie o seu servidor — pnpm dev, python -m http.server 8000, o que quiser.
  3. Dentro de alguns segundos, o ícone de ficha no canto superior direito do terminal ganha um ponto. Clique nele.

O painel lista todas as portas à escuta com o processo que lhes pertence, no formato 3000 → 3000: à esquerda, a porta a que o processo se associou; à direita, a porta em que responde localmente (o mesmo número sempre que estiver livre na sua máquina). Cada linha indica também se o localhost do computador, o Navegador (VM) e o Android a conseguem alcançar.

A descoberta é contida: um Terminal (VM) é sondado dentro do próprio convidado; um shell do anfitrião é sondado a partir da árvore de processos da PTY dessa sessão. Outros espaços, e outros processos no seu Mac, não são listados.

As portas novas deste terminal são encaminhadas automaticamente. Desative Encaminhar portas automaticamente no mesmo painel se quiser apenas as que adicionar por si.

Use Copiar URL local na linha — http://localhost:3000. O encaminhamento só escuta em loopback, pelo que mais nada na sua rede o consegue ver.

Se dois espaços expuserem ambos a porta 5173 do convidado e a sua máquina já tiver 127.0.0.1:5173, o segundo espaço mantém a 5173 do convidado e recebe uma porta local efémera. Copiar URL usa o número da direita.

Num shell do anfitrião, o processo já está na sua máquina. Mapear a mesma porta local não faz nada; escolher uma porta local diferente associa um proxy de loopback à que escolher.

--host (ou associar a 0.0.0.0) não faz com que um Navegador (VM) em recinto consiga alcançar um servidor no Mac. O convidado tem o seu próprio loopback; o servidor planta um túnel nesse convidado quando o separador Navegador está no mesmo espaço.

Abra o navegador em recinto na mesma conversa. Escreva localhost:<left-hand port> — o número a que o processo se associou. Um remapeamento (5173 → 3000) também responde no número da direita nesse navegador, pelo que Copiar URL funciona lá igualmente. O browser_use de um agente consegue navegar para qualquer dos dois. Um servidor no Espaço A nunca aparece como localhost:5173 no navegador do Espaço B.

Use localhost, não um IP de LAN nem --host. O convidado tem o seu próprio loopback; o túnel escuta aí tanto em IPv4 como em IPv6.

As páginas que abrem muitas ligações ao mesmo tempo (dezenas de recursos, um socket de live reload) partilham esse mesmo túnel. O Navegador (VM) multiplexa-as num único exec persistente, pelo que uma rajada de pedidos não é um processo criado por ligação nem termina em tempo limite como uma página em branco.

Dentro de um espaço, um encaminhamento do Terminal (VM) prevalece sobre um shell do anfitrião no mesmo número. Entre espaços não há precedência — são mapas separados.

Abra o separador Android desse espaço. O localhost:<port> do emulador é então invertido para a porta publicada deste espaço (adb reverse). Um emulador é global ao dispositivo: associar o Espaço B reencaminha :5173 para B e descarta a de A. Feche o separador e as inversões que este rig plantou são removidas.

O Simulador de iOS já é o Mac — sem inversão. Um iPhone físico continua a precisar de uma partilha na LAN.

⋯ → Partilhar na rede local publica a porta em <server-ip>:<random port> — útil para abrir a página no telemóvel, ou quando o servidor corre noutra máquina.

  • A porta de LAN é sempre atribuída pelo sistema operativo, nunca o número do convidado, pelo que a exposição é um endereço deliberado e visível, em vez de um adivinhável.
  • Permanece privada (apenas loopback) até a ativar, e ⋯ → Apenas local volta a retirá-la da rede.

⋯ → Definir um domínio do navegador (.test) atribui à porta um domínio de desenvolvimento como myapp.test. No Navegador (VM), https://myapp.test passa então a carregar o seu servidor com um cadeado válido — útil para tudo o que se comporte de forma diferente numa origem com nome ou num contexto seguro (cookies, service workers, callbacks OAuth).

  • Os domínios têm de terminar em .test ou .localhost — os dois TLD reservados para desenvolvimento, para que um nome de desenvolvimento nunca possa sobrepor-se a um site real.
  • Os nomes de domínio são únicos no servidor; os números de porta não. Dois espaços podem usar ambos a 5173, mas não podem ambos reclamar myapp.test.
  • O certificado vem de uma autoridade local criada no seu servidor na primeira vez que é necessário. As suas chaves ficam no diretório de dados do servidor e nunca entram em nenhum convidado; o navegador em recinto confia exatamente nessa chave, pelo que o TLS para a internet real continua a validar-se normalmente.
  • O domínio resolve apenas dentro do Navegador (VM). O seu próprio navegador no anfitrião usa localhost:<port> em vez disso.
  • Também funciona com http://myapp.test simples.

Adicionar porta, na parte inferior do painel, mapeia uma porta antes de (ou independentemente de) algo estar à escuta nela. Um encaminhamento manual mantém o seu endereço enquanto o servidor reinicia — a linha mostra não está a escutar até ele voltar — ao passo que os encaminhamentos automáticos desaparecem quando a respetiva porta desaparece. Num shell do anfitrião, também pode definir uma porta local diferente.

As portas têm como chave o espaço de trabalho e o espaço. O próprio mapa de portas do hipervisor é fixado quando a máquina arranca, pelo que um Terminal (VM) viaja em dois canais estreitos controlados pelo servidor: uma faixa de entrada pré-criada para o convidado que se recusa a ligar-se a qualquer porta em que o convidado não esteja realmente à escuta, e túneis inversos que o servidor mantém abertos para o Navegador (VM) e o Android. Um shell do anfitrião nunca analisa a máquina inteira. Nunca é criado um serviço à escuta dentro de um convidado que o servidor não tenha lá colocado, e tudo é desmontado com o terminal ou o rig. O desenho está explicado em Rigs e recintos; as portas reservadas exatas e as regras de domínio estão na referência de rigs.