Perché nessuno fuori dalla tua rete raggiunge localhost

Un provider di webhook ha bisogno di un URL su cui fare POST, e il tuo server è fermo su localhost:3000. Oppure un collega vuole vedere il branch che stai eseguendo, o il tuo telefono deve raggiungere il server di sviluppo per controllare un layout. Il server è su. Ma niente fuori dalla tua rete riesce a raggiungerlo.

Il port forwarding sul router funzionerebbe, ma espone il tuo IP di casa e richiede accesso da amministratore che spesso non hai. Cloudflare Tunnel prende la strada opposta. cloudflared, un piccolo demone che fai girare accanto al tuo server, apre una connessione in uscita verso l’edge di Cloudflare, e Cloudflare rimanda il traffico indietro attraverso quella connessione. Non apri nessuna porta in entrata e non ti serve un IP pubblico.

Esiste in due forme. Un quick tunnel ti dà un URL HTTPS pubblico con un solo comando, su un hostname casuale che muore quando fermi il processo. È lo strumento giusto per una demo di cinque minuti o un test di webhook. Un tunnel con nome ti dà invece un hostname stabile sul tuo dominio, che sopravvive ai riavvii — abbastanza da diventare un pezzo vero della tua infrastruttura.

Come funziona Cloudflare Tunnel senza aprire una porta

Il trucco è un cambio di direzione. Esporre un servizio normalmente significa aprire una porta in entrata: qualcosa su internet apre una connessione verso la tua macchina, quindi la tua macchina ha bisogno di un indirizzo instradabile e di una regola del firewall che lasci passare quel traffico. Bloccare esattamente questo è il motivo per cui esistono il NAT e la maggior parte dei firewall domestici e aziendali.

cloudflared non resta mai in ascolto di connessioni in entrata. Chiama l’edge di Cloudflare su una normale connessione HTTPS in uscita, lo stesso tipo di connessione che il tuo browser apre in continuazione, e la tiene aperta. Cloudflare spinge poi le richieste giù per quella connessione e legge le risposte, un po’ come un server che invia messaggi su un WebSocket a un browser che si è collegato per primo. Il tuo firewall vede una sola connessione in uscita che già permette. Per lo stesso motivo il tunnel si comporta allo stesso modo dietro un NAT o su un laptop senza IP pubblico: a una connessione in uscita non importa da dove parte.

Il costo è che Cloudflare finisce nel mezzo. L’hostname del tunnel risolve verso Cloudflare, che decifra ogni richiesta al suo edge, la ricifra e la manda giù per il tunnel fino al tuo demone. È la stessa architettura di quando stai dietro a una CDN o a un reverse proxy: rinunci all’accesso diretto in cambio di un intermediario che termina il TLS e può applicare regole di accesso prima che qualcosa raggiunga la tua macchina.

Come creare un quick tunnel con un comando

Prima installa cloudflared: brew install cloudflared su macOS, il pacchetto .deb/.rpm dal repository di Cloudflare su Linux, o l’installer per Windows dalla pagina delle release su GitHub. Poi, con qualcosa già in ascolto su una porta locale:

1

cloudflared tunnel --url http://localhost:3000

Pochi secondi dopo ottieni un output simile a questo:

1
2
3
4
5

2026-09-23T10:14:02Z INF Thank you for trying Cloudflare Tunnel. Doing so...
2026-09-23T10:14:03Z INF +--------------------------------------------------------------------------------------------+
2026-09-23T10:14:03Z INF |  Your quick Tunnel has been created! Visit it at (it may take some time to be reachable):  |
2026-09-23T10:14:03Z INF |  https://wise-juvenile-pink-recovered.trycloudflare.com                                   |
2026-09-23T10:14:03Z INF +--------------------------------------------------------------------------------------------+

Quell’URL serve HTTPS con un certificato gestito da Cloudflare, quindi non tocchi mai la configurazione TLS. Dagli qualche secondo prima che inizi a risolvere. Da quel momento chiunque abbia il link raggiunge il tuo localhost:3000, finché non premi Ctrl-C. L’hostname a quel punto sparisce per sempre, e la prossima esecuzione ne genera uno nuovo. Non fai login, non crei un record DNS, non ti serve un account.

I limiti però sono reali. L’hostname è casuale, quindi non puoi metterlo in una configurazione di webhook che deve sopravvivere a un riavvio. Cloudflare limita i quick tunnel a 200 richieste simultanee e non supporta Server-Sent Events su di essi, quindi uno stream SSE di lunga durata si interrompe. Non c’è nemmeno una garanzia di uptime: i termini di Cloudflare trattano i quick tunnel come una comodità per i test.

Per debuggare un webhook adesso o far raggiungere il server di sviluppo dal tuo telefono, questo basta e avanza. Se deve essere ancora attivo domani, serve un tunnel con nome.

Come configurare un tunnel con nome sul tuo dominio

Un tunnel con nome richiede un account Cloudflare gratuito e un dominio il cui DNS è su Cloudflare. La configurazione si fa una volta sola.

1. Autentica cloudflared con il tuo account:

1

cloudflared tunnel login

Questo apre un browser e ti chiede di scegliere il dominio da autorizzare. Poi salva un certificato in ~/.cloudflared/cert.pem, che ogni comando successivo userà.

2. Crea il tunnel e annota il suo ID:

1

cloudflared tunnel create my-app

Questo registra un tunnel chiamato my-app e scrive un file di credenziali, <TUNNEL-ID>.json, in ~/.cloudflared/. Quel file è l’identità del tunnel. Trattalo come un segreto: chiunque lo ottenga può far passare traffico attraverso il tuo tunnel.

3. Scrivi la configurazione. Crea ~/.cloudflared/config.yml:

1
2
3
4
5
6
7
8
9

tunnel: my-app
credentials-file: /home/you/.cloudflared/<TUNNEL-ID>.json

ingress:
  - hostname: app.example.com
    service: http://localhost:3000
  - hostname: api.example.com
    service: http://localhost:8080
  - service: http_status:404

ingress è una lista ordinata di regole hostname-servizio, valutate dall’alto verso il basso. Se hai già configurato nginx come reverse proxy davanti alle tue app, è la stessa logica di routing scritta in YAML invece che con direttive proxy_pass. Un solo tunnel può servire più servizi locali su hostname diversi. L’ultima regola è obbligatoria: è il catch-all che restituisce 404 per qualsiasi hostname non intercettato dalle regole sopra, e cloudflared si rifiuta di partire senza di essa.

4. Punta il DNS verso il tunnel:

1

cloudflared tunnel route dns my-app app.example.com

Questo crea un record CNAME per app.example.com che punta a <TUNNEL-ID>.cfargotunnel.com. È risoluzione DNS ordinaria, solo puntata verso l’infrastruttura tunnel di Cloudflare invece che verso l’IP di un server. Eseguilo una volta per ogni hostname nella tua lista ingress.

5. Avvialo:

1

cloudflared tunnel run my-app

app.example.com ora serve qualunque cosa sia in ascolto su localhost:3000, via HTTPS. Cloudflare termina il TLS all’edge, e la tua origine può restare in HTTP semplice perché la connessione del tunnel è già cifrata.

Un tunnel avviato in un terminale muore con il terminale. Per farlo sopravvivere a un riavvio, installalo come servizio di sistema:

1

sudo cloudflared service install

Su Linux, eseguendolo con sudo, $HOME diventa /root e cloudflared non trova più un config.yml che hai creato come utente normale. Puntalo esplicitamente al file:

1

sudo cloudflared --config /home/you/.cloudflared/config.yml service install

Questo copia la tua configurazione in /etc/cloudflared/config.yml e registra cloudflared con systemd (o launchd, o il service manager di Windows), così parte all’avvio e riparte se va in crash.

Quando Cloudflare Tunnel non è la scelta giusta

Un tunnel ha senso quando il traffico parte da fuori la tua rete e deve raggiungere una macchina senza IP pubblico, o una che non vuoi esporre direttamente: un laptop, un server di casa, una macchina dietro il NAT aziendale. È lo strumento sbagliato in questi casi:

  • Hai già un server con IP pubblico. Il tunnel aggiunge l’edge di Cloudflare come salto in più senza alcun vantaggio. Un record DNS A più il tuo reverse proxy o la tua terminazione TLS è più semplice e ha un componente in meno che può rompersi.
  • Ti serve una latenza bassa garantita o sposti grandi volumi di dati. Ogni byte passa attraverso la rete di Cloudflare. Per la maggior parte del traffico web quel costo è trascurabile; per carichi ad alto throughput o sensibili alla latenza non lo è.
  • Il servizio deve restare su anche se una macchina si spegne. Un solo cloudflared su una sola macchina è un singolo punto di rottura, e service install copre solo il riavvio del processo. Se quell’host muore, l’hostname si spegne. La ridondanza significa far girare lo stesso tunnel da una seconda macchina.
  • Il tuo codice si fida dell’indirizzo TCP sorgente per decisioni di sicurezza. Le richieste arrivano alla tua origine dagli intervalli IP di Cloudflare. L’IP reale del client arriva nell’header CF-Connecting-IP, e qualsiasi cosa legga l’indirizzo del socket vede l’edge di Cloudflare al suo posto.

Quick tunnel o tunnel con nome: da dove iniziare

Se non sei sicuro di quale ti serva, ti serve un quick tunnel. Lancia cloudflared tunnel --url http://localhost:<porta> contro qualsiasi cosa tu stia sviluppando adesso e apri l’URL. Passa a un tunnel con nome quando incontri uno dei suoi due limiti reali: un hostname che deve sopravvivere alla sessione del terminale, o un servizio che deve restare attivo senza supervisione.

Articoli correlati