Perché non riesco a raggiungere la mia porta?

Hai configurato un sito, un'app, un database, e dal tuo laptop non riesci a raggiungerli. Il browser resta in attesa. curl va in timeout. Guardi il server e dall'interno sembra tutto a posto: il processo è in esecuzione, i log dicono "listening on port 8080". Ma dall'esterno è come se il server non esistesse.

È uno dei problemi in cui ci si blocca più spesso. Ed è frustrante perché tre problemi completamente diversi appaiono identici dall'esterno. Finché non capisci quale dei tre ti riguarda, non puoi risolverlo.

Questo articolo passa in rassegna i tre livelli, nell'ordine in cui conviene controllarli, e mostra come Server Manager li trova e li risolve.

I tre livelli, in ordine

Tra il tuo browser e il programma in esecuzione sul server, ci sono tre punti in cui il traffico può essere bloccato. Dall'esterno sembrano tutti uguali: "non riesco a raggiungerlo". All'interno, invece, sono problemi molto diversi, con soluzioni molto diverse.

I tre livelli:

1. Firewall del provider cloud — funziona fuori dal tuo server, presso il provider (Hetzner, Oracle, AWS, ecc.). Scarta i pacchetti prima ancora che arrivino al server.
2. Firewall del server — funziona sul tuo server. Scarta i pacchetti quando arrivano, prima che qualunque servizio li veda.
3. Il tuo servizio — il programma vero e proprio (Caddy, la tua app, il tuo database). Potrebbe non essere in esecuzione, oppure ascoltare solo in locale.

Immaginalo come un edificio con tre controlli di sicurezza. Il pacchetto deve superarli tutti e tre per arrivare a destinazione. Se anche uno solo lo blocca, non puoi essere raggiunto; e dall'esterno non puoi sapere quale controllo lo ha fermato.

Livello 3 — Il tuo servizio sta davvero ascoltando?

La causa più economica da controllare e anche la più comune. Prima di preoccuparti dei firewall, verifica che sul server ci sia un programma che ascolta attivamente sulla porta che ti aspetti.

Le due cose che possono andare storte:

• Non c'è nulla in ascolto. Il container è andato in crash. Il servizio systemd non è partito. L'app è uscita all'avvio. Dall'esterno sembra identico a un blocco del firewall: il pacchetto arriva, ma non c'è nessuno a rispondere.
• Il servizio ascolta solo su localhost. Questo è subdolo. Molti programmi usano come impostazione predefinita "solo loopback" (127.0.0.1): il programma è in esecuzione e accetta connessioni senza problemi, ma solo dal server stesso. Le connessioni dall'esterno non possono raggiungerlo anche se tutti i firewall sono completamente aperti. Colpevoli comuni: PostgreSQL appena installato, MySQL/MariaDB, Redis, notebook Jupyter, server di sviluppo, qualunque cosa dica "per sicurezza, per impostazione predefinita ci colleghiamo solo a localhost."

Come ti aiuta Server Manager:

• La scheda Dettagli server → Firewall può rispondere alla domanda "il firewall del mio server lo sta bloccando?", ma per il Livello 3 la chat è più adatta: chiedi a Faro: "C'è qualcosa che ascolta davvero sulla porta 8080?" ed eseguirà ss -tlnp per dirtelo.
• Se fai clic su Diagnostica irraggiungibile nella scheda Firewall, la diagnostica controlla tutti e tre i livelli, incluso questo, e ti dice qual è la causa.

Livello 2 — Il firewall del server (sul server)

Il livello successivo da controllare è il firewall in esecuzione sul server stesso. Su Ubuntu/Debian di solito è ufw; su Fedora/Rocky è firewalld; dietro entrambi c'è iptables grezzo. Qualunque sia il front-end, il compito è lo stesso: scartare i pacchetti in ingresso che non sono esplicitamente consentiti.

Tre cose da sapere su questo livello:

• La maggior parte dei server nuovi è "default-allow": ogni porta è raggiungibile attraverso il firewall del server, perché il firewall non è installato oppure non sta applicando alcuna regola. Server Manager lo mostra chiaramente: in questo caso, la scheda Firewall mostra un banner giallo "Consenti per impostazione predefinita".
• Un server "irrigidito" è "default-deny": il traffico in ingresso è bloccato per impostazione predefinita; passano solo le porte esplicitamente consentite. SSH (porta 22) viene sempre mantenuta aperta, insieme a ciò che hai confermato durante la configurazione.
• La maggior parte dei provider di hosting non abilita un firewall del server per te. O ricevi un server con tutto consentito per impostazione predefinita (ogni porta aperta a questo livello), oppure lo configuri tu.

Come ti aiuta Server Manager:

• Dettagli server → scheda Firewall ti mostra lo stato attuale a colpo d'occhio: backend (ufw / iptables / firewalld / none), attivo o con tutto consentito per impostazione predefinita, e l'elenco delle porte esplicitamente consentite con etichette in linguaggio semplice.
• Apri una porta ti permette di consentire una singola porta attraverso il firewall del server con un clic (il campo Porta + il selettore del protocollo in alto nella scheda). La chat ti guida nel modo sicuro e persistente per farlo.
• Rendi più restrittivo il firewall di questo server trasforma in sicurezza un server con tutto consentito per impostazione predefinita in uno che blocca per impostazione predefinita. Una finestra modale elenca ogni servizio attualmente in ascolto e ti permette di scegliere quali devono restare pubblici. SSH viene sempre mantenuto (la protezione si rifiuta di chiuderti fuori). Docker viene rilevato automaticamente e viene usata una modalità compatibile con Docker, così i container continuano a funzionare.
• Diagnostica irraggiungibile controlla questo livello (e gli altri) e indica quale sta bloccando la tua porta.

Importante: abilitare un firewall del server con Docker è delicato. Un semplice ufw enable su un host Docker può rompere la rete dei container: Docker gestisce le proprie regole firewall tramite una catena separata (DOCKER-USER) e ufw non ne è consapevole. Se lasci che Server Manager gestisca l'irrigidimento, rileva Docker e usa automaticamente un percorso sicuro per Docker. Farlo a mano senza quell'integrazione è un modo comune per perdere connettività verso i container.

Livello 1 — Il firewall del provider cloud (fuori dal server)

Il livello più insidioso. Il tuo provider di hosting esegue un firewall davanti al tuo server: i pacchetti vengono filtrati prima ancora di raggiungere la tua VM. Server Manager non può vedere direttamente dentro questo firewall perché non si trova sul tuo server; solo la console web del provider può modificarlo.

Nomi e comportamenti variano moltissimo:

La cosa da tenere a mente è questa: il firewall del server e il firewall cloud sono due firewall separati. Entrambi possono bloccare. Entrambi possono far passare. Puoi aprire una porta lato server e restare comunque bloccato lato cloud (molto comune). Puoi non avere nulla lato server ma essere bloccato lato cloud (anche questo comune).

Come ti aiuta Server Manager:

• Server Manager non può modificare direttamente le regole del firewall cloud (servirebbero chiavi API per ogni provider), ma Faro conosce i passaggi clic per clic per tutti i principali provider e ti guida. Dopo aver aperto una porta lato server, Faro ti chiede "vuoi che ti guidi anche nell'apertura lato cloud?" e ti dà istruzioni esatte per la console web del tuo provider.
• Quando esegui Diagnostica irraggiungibile nella scheda Firewall, la diagnostica identifica se il firewall cloud è il blocco e produce automaticamente la procedura guidata specifica per il provider.
• Quando rendi più restrittivo il firewall di questo server, Faro ti ricorda di restringere anche il firewall lato cloud in modo che corrisponda (altrimenti hai una configurazione asimmetrica: stretta sul server, larga nel cloud).

Come Server Manager controlla per te tutti e tre i livelli

Percorso tramite chat: apri Faro e scrivi "perché non riesco a raggiungere la porta 8080?" L'agente verifica i tre livelli in ordine: servizio in ascolto, firewall del server, firewall cloud, e ti dice qual è la causa. Poi ti propone di risolverla.

Percorso tramite interfaccia: Dettagli server → scheda Firewall → Diagnostica irraggiungibile. Inserisci la porta, fai clic sul pulsante. Stessa verifica sui tre livelli, stessa diagnosi, stessa proposta di correzione.

Il risultato è sempre un livello specifico indicato come causa, più una singola soluzione proposta come domanda sì/no. Niente checklist generiche di più pagine.

Scenari comuni

"Ho distribuito un database e non riesco a connettermi dal laptop"

Quasi certamente Livello 3: il database sta **ascoltando solo su 127.0.0.1**. PostgreSQL, MySQL, MariaDB e Redis usano tutti localhost come impostazione predefinita. Funzionano correttamente, semplicemente non puoi raggiungerli dall'esterno.

La soluzione dipende da ciò che vuoi fare:

• Per app→database sullo stesso server (il caso normale): è così che dovrebbe essere. Collega la tua app a localhost:5432 (o a qualunque sia la porta) e hai finito. Non serve cambiare firewall. In Server Manager: non devi fare nulla: Faro distribuisce i database in questo modo per impostazione predefinita.
• Per amministrazione remota "il mio laptop → database": apri un tunnel: ssh -L 5432:localhost:5432 user@server dal tuo laptop, poi collega il client DB a localhost:5432 in locale. È più sicuro che esporre il DB a internet. In Server Manager: chiedi a Faro il comando esatto per il tunnel: conosce l'utente e l'host del tuo server.
• Per "voglio davvero che questo database sia raggiungibile pubblicamente": cambia l'indirizzo di bind nella configurazione del DB in 0.0.0.0, riavvia il DB, poi apri la porta sia nel firewall del server SIA nel firewall cloud. Prima assicurati assolutamente di aver impostato una password forte: esporre un DB a internet senza autenticazione robusta è un modo comune per farsi compromettere. In Server Manager: chiedi a Faro di fare tutti e tre i passaggi (ricollegare il DB al nuovo bind, aprire la porta del firewall del server tramite la scheda Firewall, guidarti nella regola del provider cloud). Se non ne hai ancora impostata una, fai prima generare a Faro una password forte.

"Ho aperto la porta in ufw e ancora non riesco a raggiungerla"

Livello 1: il firewall del provider cloud non è stato aggiornato. Lato server, ufw allow 8080/tcp apre il Livello 2; il pacchetto deve comunque superare il Livello 1 prima di raggiungere il tuo server. Apri la regola corrispondente nella console del tuo provider cloud.

In Server Manager: chiedi a Faro di guidarti nella regola lato cloud per il tuo provider: ti darà passaggi clic per clic per Hetzner / AWS / Oracle / ecc. senza che tu debba cercare com'è fatto il pannello.

"Ieri funzionava, oggi no"

Alcune cause comuni:

• Il tuo IP è cambiato: se il firewall cloud è ristretto a "solo il mio IP" e durante la notte la tua connessione di casa ha ricevuto un nuovo IP (molto comune con la maggior parte degli ISP consumer), il nuovo IP ora è bloccato. Allarga temporaneamente a 0.0.0.0/0, entra, poi restringi di nuovo.
• Il servizio è andato in crash: un problema di Livello 3 mascherato. Controlla systemctl status <service> o docker ps.
• Il server è stato irrigidito di recente: se qualcuno ha abilitato il firewall del server senza includere la porta che ti interessa, ora quella porta è bloccata al Livello 2. Apri la scheda Firewall per vedere il set di regole attuale.

In Server Manager: inserisci la porta interessata nella scheda Firewall e fai clic su Diagnostica irraggiungibile: Faro verifica tutti e tre i livelli e ti dice quale è regredito. Più veloce che andare a tentativi.

"Riesco a fare curl dal server, ma non dall'esterno"

Questo è il confine diagnostico: ti dice che il servizio va bene e che il Livello 3 non è il problema. A questo punto è il Livello 2 (firewall del server) oppure il Livello 1 (firewall cloud). Usa Diagnostica irraggiungibile per restringere ulteriormente il campo.

In Server Manager: il pulsante Diagnostica irraggiungibile nella scheda Firewall è lo strumento giusto proprio per questo caso: salta il Livello 3 (perché hai già dimostrato che funziona) e ti dice quale dei due livelli firewall sta scartando il pacchetto.

Domande comuni

Mi serve un firewall del server se il mio provider cloud ne ha già uno?

Sì e no, dipende dal tuo modello di rischio. Un firewall cloud copre il caso comune. Un firewall del server è utile quando:

• Usi Docker: in alcune configurazioni, i container possono aprire varchi propri che aggirano il firewall cloud. Un firewall del server intercetta l'egress dei container.
• Ti dimentichi di rimuovere regole temporanee dal firewall cloud: il firewall del server è la rete di sicurezza.
• Vuoi filtrare il traffico in uscita: i firewall cloud di solito si concentrano sull'ingresso; i firewall del server possono fare entrambe le cose.

Se nessuna di queste situazioni si applica, per la maggior parte delle configurazioni basta un singolo firewall cloud configurato bene.

Server Manager funziona senza un firewall del server?

Sì. Server Manager non richiede alcuna configurazione firewall per funzionare. La scheda Firewall serve alla tua sicurezza, non a collegarsi a Server Manager stesso (a Server Manager serve solo SSH, porta 22).

Perché la scheda Firewall mi dice "Consenti per impostazione predefinita" se non ho mai configurato nulla?

Perché quello è lo stato reale. La maggior parte dei server nuovi non ha un firewall del server configurato: ogni porta è raggiungibile a quel livello. Che qualcosa arrivi davvero al tuo servizio dipende dal Livello 1 (firewall cloud) e dal Livello 3 (se il servizio sta ascoltando). Il banner giallo è un avviso: potresti voler renderlo più restrittivo.

"Apri porta 22 / SSH" è qualcosa che dovrei mai chiudere?

No. Server Manager parla con il tuo server solo tramite SSH. Chiudere la porta 22 disconnette Server Manager e avresti bisogno del ripristino dalla console del provider (vedi Ripristinare quando SSH smette di funzionare). Per questo motivo, la scheda Firewall si rifiuta di offrire un pulsante Chiudi sulla riga SSH, e la finestra di irrigidimento blocca la riga SSH su "mantieni sempre aperta."

Cosa NON rientra qui

• Problemi di traffico in uscita (il tuo server non riesce a raggiungere internet): è una configurazione diversa, di solito NAT, DNS o rete in uscita del provider. Chiedi a Faro di diagnosticarla.
• Errori HTTPS / TLS: in quel caso la raggiungibilità funziona, ma l'handshake di cifratura fallisce. È un'area diversa; controlla la sezione domini, HTTPS ed email.
• Problemi DNS ("il mio dominio non punta al server"): trattati in Punta un dominio qui. Il pacchetto non è ancora arrivato alla questione dei firewall: non sa nemmeno dove si trova il server.
• Configurazione specifica dell'app (quale variabile d'ambiente impostare perché la tua app ascolti su 0.0.0.0 invece che su 127.0.0.1): varia da app ad app. Chiedi a Faro: conosce le più comuni.