Guida pratica alla condivisione di localhost
Esponi localhost con Cloudflare e GhostlyShare
Quando un cliente necessita un'anteprima, un provider webhook un URL callback, o vuoi aprire il dev server su un telefono, serve un URL pubblico per qualcosa che gira ancora localmente. Questa guida mostra prima il percorso Cloudflare da terminale, poi il flusso GhostlyShare per condivisioni ripetute.
Decisione rapida
Usa lo strumento adatto alla quantità di condivisione
L'errore è trattare ogni anteprima locale come hosting. Un tunnel è ideale per accesso temporaneo. GhostlyShare è migliore per flussi regolari. Un deployment reale serve se gli utenti dipendono dall'URL.
Usa cloudflared.exe
Installa una volta il client tunnel di Cloudflare, esegui un comando, copia l'URL temporaneo e poi interrompilo con Ctrl+C.
Usa GhostlyShare
Lascia che l'app desktop rilevi i servizi locali, inizi la condivisione, mostri lo stato, copi l'URL e fermi l'accesso senza cercare nel terminale.
Distribuisci l'app
Se l'URL necessita uptime, monitoraggio, backup, rilasci stabili o supporto, un tunnel da laptop non è un confine di affidabilità adeguato.
Metodo 1
Cloudflare EXE: il flusso da riga di comando più rapido e pulito
Il client tunnel di Cloudflare si chiama cloudflared. Su Windows puoi installarlo con winget o scaricare l'EXE manualmente. Per anteprime di sviluppo brevi, Quick Tunnel fornisce un URL HTTPS casuale senza port forwarding, zona DNS Cloudflare o dominio personalizzato.
Avvia l'app locale
Apri prima l'URL locale nel browser. Se l'app non funziona localmente, un tunnel pubblico non lo risolverà.
npm run devInstalla cloudflared su 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.cloudflaredCrea l'URL pubblico
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:5173Testa prima di condividere
Apri l'URL trycloudflare.com generato in una finestra privata o su un altro dispositivo. Controlla login, risorse, redirect e chiamate API prima di condividerlo.
https://example-random-name.trycloudflare.comInterrompi il tunnel volontariamente
Quando demo o test webhook finiscono, interrompi il processo terminale. Se il computer va in sospensione o si disconnette, il tunnel rapido smetterà comunque di funzionare.
Ctrl+CNomi anteprima stabili
URL casuale o hostname Cloudflare personalizzato?
URL casuali sono perfetti quando il link può sparire dopo un test. I domini personalizzati hanno senso per anteprime stabili, ad esempio demo.example.com, se gestisci già il dominio su Cloudflare.
| Necessità | Usa | Perché è adatto |
|---|---|---|
| Una demo di cinque minuti o callback webhook | URL casuale | Non serve account o configurazione DNS, e il link è facile da scartare dopo il test. |
| Una recensione cliente che deve apparire brandizzata | Dominio personalizzato | Un hostname che controlli è più facile da riconoscere, ma richiede la tua zona Cloudflare, permessi token, DNS e instradamento del tunnel. |
| Una anteprima che non dovrebbe essere aperta casualmente | Link protetto da password | Aggiungi una password prima di rendere pubblico, poi condividi URL e password separatamente con il gruppo ristretto che necessita accesso. |
Altre opzioni
Altri modi per esporre localhost
Non serve uno strumento per ogni situazione. La scelta migliore dipende se vuoi un link usa e getta, un flusso desktop, un'anteprima brandizzata, uno strumento per rete privata o un setup self-hosted intenzionalmente protetto.
| Strumento | Comando o azione tipica | Ideale per | Attenzione |
|---|---|---|---|
| Cloudflare Quick Tunnel | cloudflared tunnel --url http://localhost:5173
|
URL HTTPS pubblici usa e getta veloci senza modifiche al router. | Solo sviluppo e test; URL casuale; ciclo di vita terminale. |
| GhostlyShare | Seleziona Vai Pubblico nell'app desktop
|
Anteprime locali ripetute, test webhook, demo protette da password e domini personalizzati Cloudflare opzionali. | Non è hosting di produzione; l'app locale e la macchina devono restare attive mentre il link funziona. |
| ngrok | ngrok http 5173
|
Team che usano già ngrok, domini riservati, ispezione traffico e instradamento specifico provider. | Dettagli di account e piano sono importanti; più configurazione provider rispetto a un tunnel rapido usa e getta. |
| Tailscale Funnel | tailscale funnel 3000
|
Persone che usano già Tailscale e vogliono un endpoint HTTPS pubblico per un dispositivo tailnet. | Richiede configurazione Tailscale e Funnel abilitato per il tailnet. |
| localtunnel | npx localtunnel --port 3000
|
Condivisione localhost rapida basata su Node per test semplici. | Utile per anteprime semplici; valuta bene prima di usarlo per dati sensibili. |
| Port forwarding del router | Configura router, DNS, TLS e reverse proxy
|
Self-hosting permanente quando gestisci intenzionalmente l'infrastruttura. | Superficie di attacco più ampia; patch, regole firewall, log e TLS diventano responsabilità tua. |
Test webhook
Dettagli che fanno risparmiare tempo con i webhook
I provider webhook non possono chiamare http://localhost sul tuo laptop. Possono chiamare l'URL pubblico del tunnel. Tratta quell'URL come una vera integrazione esterna: mantieni firme attive, usa il percorso callback esatto e verifica redirect e CORS.
Usa il percorso callback completo
Se il ricevitore ascolta su /api/webhooks/stripe, incolla l'URL pubblico con lo stesso percorso, non solo il dominio.
Mantieni attiva la validazione delle firme
Un tunnel pubblico facilita il test delle firme webhook reali. Non è motivo per disabilitare la verifica delle firme.
Controlla URL base e header inoltrati
Se l'URL pubblico reindirizza a localhost, configura URL base pubblici, header inoltrati, proxy attendibili o impostazioni host del framework.
Testa da una sessione browser pulita
Usa una finestra privata o un secondo dispositivo per evitare che la cache localhost nasconda problemi con cookie, CORS, redirect o contenuti misti.
Risoluzione problemi
Risolvi prima i problemi comuni del tunnel
Il tunnel parte, ma la pagina è vuota
Apri direttamente l'URL locale, poi verifica se risorse, URL API, WebSocket o variabili ambiente puntano ancora a localhost.
L'URL pubblico reindirizza a localhost
Molti framework creano redirect basati sull'host della richiesta. Correggi header inoltrati, proxy attendibili, origine pubblica o redirect forzati in sviluppo.
Il link appare prima di funzionare
Instradamento Cloudflare, DNS, proxy locale di GhostlyShare e app origin potrebbero necessitare di qualche secondo per sincronizzarsi. Attendi, aggiorna e riprova.
Certificati HTTPS localhost causano errori
Per anteprime brevi, tunnelizza l'endpoint HTTP locale se disponibile. Per configurazioni più lunghe, configura intenzionalmente TLS origin invece di indovinare.
Ricarica a caldo o WebSocket falliscono
Usa uno strumento che supporta WebSocket e assicurati che l'app costruisca URL ws o wss dall'host pubblico, non da un valore localhost hardcoded.
Sicurezza
Prima di inviare l'URL pubblico
Un URL di anteprima pubblico è comunque accesso pubblico. La protezione con password riduce accessi accidentali, ma non rende sicuro un servizio locale rischioso. Condividi l'URL più limitato, usa dati di test e interrompi il link dopo la revisione o il test webhook.
Usa dati di test
Non esporre dati reali di clienti, pannelli admin database, dashboard interne, segreti o dati aziendali riservati.
Mantieni attiva l'autenticazione dell'app
Se una funzione richiede login, deve richiederlo anche durante l'anteprima pubblica.
Usa la protezione con password per anteprime private
Per piccoli gruppi di revisione, aggiungi una password GhostlyShare prima di rendere pubblico e condividila separatamente dal link.
Interrompi e ruota i link
Interrompi i link temporanei dopo l'uso. Se URL o password trapelano in ticket o chat, crea una nuova anteprima invece di riutilizzarla.
Domande frequenti
Domande frequenti
Qual è il comando esatto per Windows?
Dopo aver installato cloudflared, esegui cloudflared.exe tunnel --url http://localhost:PORT, sostituendo PORT con la porta locale della tua app, ad esempio 5173, 3000, 5080 o 8080.
GhostlyShare è solo un'interfaccia per cloudflared?
No. GhostlyShare usa tunnel Cloudflare, ma aggiunge un flusso desktop per rilevamento app, link pubblici casuali o personalizzati, stato di prontezza, interruzione accesso e protezione opzionale con password.
GhostlyShare può proteggere un link pubblico con password?
Sì. Attiva la protezione con password prima di rendere pubblico. I visitatori devono inserirla prima che GhostlyShare inoltri il traffico all'app locale selezionata, ma non sostituisce una corretta sicurezza dell'app.
Serve il port forwarding del router?
No per i flussi tunnel in questa guida. cloudflared, GhostlyShare, ngrok, Tailscale Funnel e simili aprono connessioni in uscita, quindi di solito non serve port forwarding in ingresso.
Posso testare i webhook tramite un tunnel locale?
Sì. Avvia il ricevitore webhook locale, esponilo tramite tunnel, incolla l'URL HTTPS pubblico con il percorso callback corretto nel provider, invia un evento di test e ispeziona la richiesta localmente.
Devo esporre strumenti admin o database?
Di solito no. Non esporre console database, dashboard admin, pannelli infrastruttura, endpoint debug o servizi interni a meno che non siano intenzionalmente protetti e pensati per essere raggiungibili da internet.
Posso usare un tunnel da laptop per traffico di produzione?
No. Usa un deployment reale o un tunnel gestito su infrastruttura pensata per restare online, ricevere aggiornamenti, essere monitorata e recuperare da errori.