DESENVOLVIMENTO LOCAL · TESTES REAIS
Compartilhe localhost: testes no celular e de webhooks
Seu site roda no seu computador. Um link HTTPS temporário permite o acesso pelo celular, por clientes ou por um serviço de webhooks, sem fazer deploy.
Antes de compartilhar: confira o endereço local
Veja a URL exibida pelo servidor de desenvolvimento. Protocolo e porta importam: http://localhost:5173 e https://localhost:7143 são destinos diferentes. Abra o endereço exato e realize uma ação comum antes de criar o túnel.
Um aplicativo, uma porta
Se página e API usam o mesmo endereço local, um túnel alcança ambas. Os caminhos são preservados: uma requisição pública a /contact chega a /contact no aplicativo local. O túnel não copia nem faz deploy dos arquivos.
Frontend e API em portas diferentes
Um túnel para o frontend não publica automaticamente uma API em outra porta. Um navegador que chama localhost:3000 acessa o dispositivo do visitante. Use o proxy de API do servidor de desenvolvimento ou uma URL de teste acessível para a API e ajuste o frontend.
Obtenha um link público
Inicie o site ou a API e confira o acesso local. O GhostlyShare detecta automaticamente os aplicativos web locais em execução. Clique em Go Public para criar um link HTTPS público.
- Mantenha o aplicativo e o GhostlyShare em execução durante o teste.
- Abra o link em uma janela privativa antes de compartilhar.
- Use dados de teste. Se necessário, adicione uma senha para uma prévia privada do cliente.
Windows e Linux. Links temporários gratuitos, sem conta, e-mail ou assinatura.
Baixar GhostlyShare ↗
Abra o endereço público no computador e em outro dispositivo. Se a página local funciona, mas a pública não, mantenha ambas as URLs à mão para distinguir problemas do aplicativo de problemas no túnel ou na configuração do host.
Abra localhost no celular
No celular, localhost aponta para o próprio celular, não para seu computador. Abra o link público ou escaneie o código QR no GhostlyShare.
- Use os dados móveis para testar o acesso fora do Wi-Fi.
- Teste menu, formulários, teclado e envio de arquivos no dispositivo real.
- Abra uma página interna diretamente e recarregue-a. Confira também imagens e respostas da API.
Vai testar apenas no mesmo Wi-Fi? O endereço de rede local do computador pode bastar se o servidor de desenvolvimento e o firewall permitirem. Um túnel público ajuda no acesso por outras redes e serviços externos.
Um teste útil de cinco minutos no celular
- Navegação e layout
- Abra o menu, gire o celular e visite uma página longa. Procure rolagem horizontal, botões cobertos e conteúdo escondido pelo cabeçalho fixo. A emulação do navegador ajuda, mas não reproduz todas as interações reais.
- Formulários e sessão
- Toque em cada campo e envie um valor inválido, depois um válido. Confira se os erros ficam visíveis acima do teclado. Se o login funciona só no computador, teste uma sessão nova e confira callback e cookies.
- Requisições e carregamento
- Teste uma página com muitas imagens e uma ação que carregue dados. Uma resposta lenta pela conexão doméstica não mede o desempenho em produção. Anote página, dispositivo e ação para reproduzir o problema localmente.
Mostre seu trabalho a um cliente
Envie a página exata que deseja revisar. Explique o que testar e quando a prévia será encerrada.
Antes de enviar
Use uma conta de teste e conteúdo de exemplo. Confira se o link funciona sem seus cookies ou sua sessão autenticada.
Peça uma verificação específica
Preencher o formulário, revisar o menu móvel ou finalizar uma compra com pagamento de teste: uma tarefa clara gera feedback mais útil.
Aqui está a prévia para a revisão de hoje. Confira o menu móvel e o formulário de contato. O link será encerrado depois da nossa chamada.
Torne o feedback reproduzível
Peça URL, dispositivo, navegador e última ação antes do problema. Uma captura com “esperava X, mas aconteceu Y” ajuda mais que “a página não funciona”. Avise se editar o aplicativo durante a revisão: conforme a configuração, os visitantes podem ver mudanças ou recargas imediatamente.
Receba um webhook localmente
Um serviço de webhooks não alcança localhost no seu computador. Informe o endereço público do túnel com o caminho de callback. O exemplo pressupõe que seu aplicativo já processe requisições POST em /api/webhooks/demo.
http://localhost:5173/api/webhooks/demohttps://YOUR-TUNNEL.trycloudflare.com/api/webhooks/demo- Substitua YOUR-TUNNEL pelo hostname real e informe a URL completa de callback nas configurações de teste do provedor.
- Mantenha a verificação de assinaturas ativada. Armazene o segredo do webhook localmente e envie um evento de teste pelo provedor.
- Confira o status da entrega e os logs locais. Retorne a resposta de sucesso esperada e trate novas tentativas sem repetir a ação.
Uma solicitação de senha no navegador pode bloquear o remetente do webhook. Use um endpoint acessível ao provedor e verifique suas requisições assinadas. CORS se aplica a requisições do navegador, não a webhooks entre servidores.
Confira a resposta do webhook, não só o navegador
Abrir o callback no navegador normalmente envia GET. Muitos endpoints de webhook esperam POST, então um erro no navegador não prova falha na entrega. Envie o evento de teste e compare horário e ID de entrega com o log local.
- 404 / 405
- Confira caminho e método HTTP. Use a porta da API, não necessariamente a do frontend. Uma página inicial acessível não significa que o endpoint de callback exista.
- 401 / 403
- Identifique quem rejeitou a requisição: senha da prévia, autenticação do aplicativo ou verificação da assinatura. Para dados assinados, siga as regras sobre o corpo original da requisição; analisá-lo e reescrevê-lo antes da verificação pode invalidar a assinatura.
- 5xx / Timeout
- Confira se o aplicativo está ativo e recebeu a requisição. Em processamentos demorados, respeite o prazo do provedor e use tarefas em segundo plano quando adequado. Teste uma entrega repetida para evitar pedidos ou mensagens duplicados.
Use o modo de teste do provedor e evite registrar segredos ou dados pessoais completos. Um teste bem-sucedido verifica entrega e processamento, mas não substitui os requisitos de integração do provedor.
O link abre, mas algo não funciona?
O link público não alcança o aplicativo
Abra primeiro a URL local. Confira a porta, HTTP ou HTTPS e se aplicativo e túnel continuam em execução.
Imagens ou chamadas de API falham
Procure URLs localhost fixadas no código. Use caminhos relativos quando possível. Uma API em outra porta precisa de uma rota acessível própria.
O aplicativo redireciona para localhost
Confira a URL base pública, os proxies confiáveis e os callbacks de login. Autorize o host real da prévia sem desativar globalmente a validação de hosts.
A recarga em tempo real ou os WebSockets falham
Confira se os WebSockets usam o host público e wss em páginas HTTPS. Alguns servidores de desenvolvimento exigem configurar um host HMR separado.
O webhook não recebe uma resposta de sucesso
Confira o caminho de callback, o método HTTP, o segredo da assinatura e o log de entrega. Atualize a URL de callback ao iniciar outro túnel temporário.
Conclua o teste e pare de compartilhar
Encerre o compartilhamento no GhostlyShare ou o túnel no terminal com Ctrl+C. Uma expiração pode encerrar automaticamente uma prévia agendada. Remova também as URLs temporárias de callback no provedor ao terminar.
Precisa de um endereço fixo para uso contínuo?
Uma prévia temporária não é um deploy. Nosso guia de hospedagem em casa explica túneis nomeados, domínios, serviços do Windows e custos de operação.
Configurar um Cloudflare Tunnel permanente →Dúvidas sobre prévias locais
Perguntas frequentes
Por que localhost não funciona no meu celular?
Localhost aponta para o dispositivo que abre o endereço. Use o link público no celular para acessar o aplicativo no computador.
Meu computador precisa ficar ligado?
Sim. Computador, aplicativo local e túnel precisam continuar ativos. A suspensão ou a interrupção do túnel torna a prévia indisponível.
Preciso de um domínio para a prévia?
Não. Um túnel temporário fornece um endereço HTTPS público. Atualize os links compartilhados e as configurações de webhooks se ele mudar.