Guia prático para compartilhar localhost
Exponha localhost com Cloudflare e GhostlyShare
Quando um cliente precisa de prévia, um provedor de webhook precisa de URL de callback, ou você quer abrir seu servidor dev no celular, precisa de URL pública para algo local. Este guia mostra o caminho Cloudflare via terminal e depois o fluxo GhostlyShare para compartilhamento repetido.
Decisão rápida
Use a ferramenta que corresponde à quantidade de compartilhamento
O erro é tratar toda prévia local como hospedagem. Túnel é melhor para acesso temporário. GhostlyShare é melhor para fluxo regular. Deploy real é melhor quando usuários dependem da URL.
Use cloudflared.exe
Instale o cliente de túnel Cloudflare uma vez, execute um comando, copie a URL temporária e pare com Ctrl+C.
Use GhostlyShare
Deixe o app desktop detectar serviços locais, iniciar compartilhamento, mostrar prontidão, copiar URL e parar acesso sem buscar no terminal.
Faça o deploy do app
Se a URL precisa de uptime, monitoramento, backups, lançamentos estáveis ou suporte, um túnel de laptop não é a solução confiável.
Método 1
Cloudflare EXE: o fluxo mais rápido e limpo via linha de comando
O cliente de túnel da Cloudflare se chama cloudflared. No Windows, instale com winget ou baixe o EXE manualmente. Para prévias rápidas, o Quick Tunnel gera uma URL HTTPS aleatória sem precisar de redirecionamento de porta, zona DNS Cloudflare ou domínio personalizado.
Inicie o app local
Abra a URL local no navegador primeiro. Se o app não funcionar localmente, túnel público não resolve.
npm run devInstale o cloudflared no Windows
Use winget when it is available. If you download the EXE manually, place it in a folder such as C:\Cloudflared\bin and call it cloudflared.exe.
winget install --id Cloudflare.cloudflaredCrie a URL pública
Use the exact local HTTP URL and port. In PowerShell from the EXE folder, use .\cloudflared.exe if the executable is not on PATH.
cloudflared.exe tunnel --url http://localhost:5173Teste antes de compartilhar
Abra a URL gerada trycloudflare.com em janela privada ou outro dispositivo. Verifique login, assets, redirecionamentos e chamadas API antes de enviar.
https://example-random-name.trycloudflare.comPare o túnel deliberadamente
Quando a demo ou teste de webhook acabar, pare o processo no terminal. Se seu computador dormir ou desconectar, o túnel rápido para de funcionar mesmo.
Ctrl+CNomes estáveis para prévias
URL aleatória ou hostname Cloudflare personalizado?
URLs aleatórias são ideais quando o link pode desaparecer após o teste. Domínios personalizados fazem sentido para prévias estáveis, como demo.example.com, quando você já gerencia o domínio na Cloudflare.
| Necessidade | Use | Por que é adequado |
|---|---|---|
| Uma demonstração de cinco minutos ou callback de webhook | URL aleatória | Não precisa de conta ou configuração DNS, e o link é fácil de descartar após o teste. |
| Uma avaliação de cliente que deve parecer personalizada | Domínio personalizado | Um hostname que você controla é mais fácil de reconhecer, mas precisa da sua zona Cloudflare, permissões de token, DNS e roteamento do túnel. |
| Uma prévia que não deve ser aberta casualmente | Link protegido por senha | Adicione uma senha antes de tornar público e compartilhe a URL e a senha separadamente com o grupo restrito que precisa de acesso. |
Outras opções
Outras formas de expor localhost
Você não precisa de uma ferramenta para cada situação. A melhor escolha depende se quer um link descartável, fluxo desktop, prévia com marca, ferramenta de rede privada ou setup auto-hospedado reforçado.
| Ferramenta | Comando ou ação típica | Ideal para | Cuidado |
|---|---|---|---|
| Cloudflare Quick Tunnel | cloudflared tunnel --url http://localhost:5173
|
URLs HTTPS públicas descartáveis rápidas sem alterar o roteador. | Apenas para desenvolvimento e testes; URL aleatória; ciclo de vida no terminal. |
| GhostlyShare | Selecione Ir para Público no app desktop
|
Prévias locais repetidas, testes de webhook, demos protegidas por senha e domínios personalizados Cloudflare opcionais. | Ainda não é hospedagem para produção; seu app local e máquina devem continuar ligados enquanto o link funcionar. |
| ngrok | ngrok http 5173
|
Times que já usam ngrok, domínios reservados, inspeção de tráfego e recursos de roteamento específicos do provedor. | Detalhes da conta e plano importam; mais configuração do provedor que um túnel rápido descartável. |
| Tailscale Funnel | tailscale funnel 3000
|
Pessoas que já usam Tailscale e querem endpoint HTTPS público para dispositivo tailnet. | Requer configuração do Tailscale e Funnel ativado para o tailnet. |
| localtunnel | npx localtunnel --port 3000
|
Compartilhamento rápido de localhost baseado em Node para testes simples. | Útil para prévias simples; pense bem antes de usar para algo sensível. |
| Redirecionamento de porta no roteador | Configure roteador, DNS, TLS e proxy reverso
|
Auto-hospedagem permanente quando você opera a infraestrutura intencionalmente. | Mais superfície de ataque exposta; patching, regras de firewall, logs e TLS ficam sob sua responsabilidade. |
Teste de webhook
Detalhes que economizam tempo com webhooks
Provedores de webhook não podem chamar http://localhost no seu laptop. Podem chamar a URL pública do túnel. Trate essa URL como integração externa real: mantenha assinaturas ativadas, use caminho exato do callback e verifique redirecionamentos e CORS.
Use o caminho completo do callback
Se seu receptor escuta em /api/webhooks/stripe, cole a URL pública com esse caminho, não só o domínio.
Mantenha a validação de assinatura ativada
Um túnel público facilita testar assinaturas reais de webhook. Isso não é motivo para desativar a verificação de assinatura.
Observe URLs base e cabeçalhos encaminhados
Se a URL pública redireciona para localhost, configure URLs base públicas, cabeçalhos encaminhados, proxies confiáveis ou configurações do host do framework.
Teste em sessão limpa do navegador
Use janela privada ou outro dispositivo para evitar que cache de localhost esconda problemas com cookies, CORS, redirecionamentos ou conteúdo misto.
Solução de problemas
Resolva os problemas comuns do túnel primeiro
O túnel inicia, mas a página fica em branco
Abra a URL local diretamente e verifique se assets, URLs de API, WebSocket ou variáveis de ambiente ainda apontam para localhost.
A URL pública redireciona para localhost
Muitos frameworks criam redirecionamentos baseados no host da requisição. Corrija cabeçalhos encaminhados, proxies confiáveis, origem pública ou redirecionamentos forçados de dev.
O link aparece antes de funcionar
O roteamento Cloudflare, DNS, proxy local do GhostlyShare e o app de origem podem precisar de um momento para sincronizar. Aguarde alguns segundos, atualize e teste novamente.
Certificados HTTPS localhost causam erros
Para prévias curtas, faça túnel do endpoint HTTP local quando disponível. Para setups longos, configure TLS de origem intencionalmente, não por tentativa.
Falha no hot reload ou WebSockets
Use ferramenta que suporte WebSockets e garanta que o app construa URLs ws ou wss a partir do host público, não de localhost fixo.
Segurança
Antes de enviar a URL pública
Uma URL pública de prévia ainda é acesso público. A proteção por senha reduz acessos acidentais, mas não torna seguro um serviço local arriscado. Compartilhe a URL mais restrita, use dados de teste e encerre o link após a revisão ou teste de webhook.
Use dados de teste
Não exponha dados reais de clientes, telas administrativas de banco, dashboards internos, segredos ou dados privados da empresa.
Mantenha a autenticação do app ativada
Se um recurso normalmente exige login, deve exigir também na prévia pública.
Use proteção por senha para prévias privadas
Para pequenos grupos de revisão, adicione senha no GhostlyShare antes de tornar público e compartilhe separadamente do link.
Pare e rotacione links
Pare links temporários após uso. Se URL ou senha vazar em ticket ou chat, crie uma prévia nova em vez de reutilizar.
Perguntas frequentes
Perguntas frequentes
Qual é o comando exato no Windows?
Após instalar o cloudflared, execute cloudflared.exe tunnel --url http://localhost:PORT, substituindo PORT pela porta local do seu app, por exemplo 5173, 3000, 5080 ou 8080.
O GhostlyShare é só um wrapper para o cloudflared?
Não. O GhostlyShare usa túneis Cloudflare, mas adiciona um fluxo desktop com detecção de apps, links públicos aleatórios ou personalizados, estado de prontidão, parada de acesso e proteção por senha opcional.
O GhostlyShare pode proteger um link público com senha?
Sim. Ative a proteção por senha antes de tornar público. Visitantes devem digitar a senha antes do GhostlyShare encaminhar ao app local, mas isso não substitui segurança adequada do app.
Preciso redirecionar portas no roteador?
Não para os fluxos de túnel deste guia. cloudflared, GhostlyShare, ngrok, Tailscale Funnel e similares abrem conexões de saída da sua máquina, então geralmente não precisa redirecionar portas no roteador.
Posso testar webhooks por um túnel local?
Sim. Inicie o receptor local de webhook, exponha pelo túnel, cole a URL pública HTTPS com o caminho correto no provedor, envie evento teste e inspecione a requisição localmente.
Devo expor ferramentas administrativas ou bancos de dados?
Geralmente não. Não exponha consoles de banco, dashboards administrativos, painéis de infraestrutura, endpoints de debug ou serviços internos, a menos que estejam reforçados e prontos para acesso externo.
Devo usar túnel de laptop para tráfego de produção?
Não. Use um deploy real ou túnel gerenciado em infraestrutura feita para ficar online, receber atualizações, ser monitorada e se recuperar de falhas.