risoluzione-problemi
“Impossibile raggiungere il sito” dopo il deploy — come diagnosticare
Un percorso in parole semplici per capire dove si blocca un sito appena pubblicato: dominio, server, firewall, server web, app o HTTPS.
Hai completato il deployment dell’applicazione, aperto il nome a dominio nel browser e ti sei trovato di fronte al messaggio meno esplicativo possibile: “Impossibile raggiungere il sito”[cite: 1]. La schermata non specifica se l'anomalia sia nel codice applicativo, nella risoluzione del dominio o nella configurazione del server[cite: 1].
In breve: La comparsa dell'errore “Impossibile raggiungere il sito” a seguito del deploy indica che il browser non è riuscito a completare l'instradamento di rete dal computer client al server[cite: 2]. Per effettuare la diagnosi occorre verificare la catena in sequenza: accertarsi che il dominio punti all'IP corretto del server, che il server accetti il traffico in ingresso, che un web server sia in ascolto, che l'applicazione sia in esecuzione e che il certificato HTTPS sia valido[cite: 2].
Cosa significa “Impossibile raggiungere il sito” dopo il deploy?
L'errore “Impossibile raggiungere il sito” restituito dai browser come Chrome costituisce un errore di consegna della richiesta di rete[cite: 3]. Può essere paragonato a un pacco non recapitato a destinazione: l'indirizzo potrebbe essere errato, il percorso bloccato, il destinatario assente o il servizio di portineria non istruito su quale appartamento raggiungere[cite: 3].
Una richiesta web attraversa una sequenza definita di passaggi:
- Il nome a dominio deve essere risolto in un indirizzo IP.
- L'indirizzo IP deve corrispondere al server su cui è stato effettuato il deploy.
- Il server deve consentire il traffico sulle porte di rete dedicate, tipicamente la 80 (HTTP) e la 443 (HTTPS).
- Un web server (come Nginx o Caddy) deve prendere in carico ed evadere la richiesta.
- L'applicazione sottostante deve risultare in esecuzione dietro al web server.
- Se si impiega HTTPS, il certificato SSL/TLS deve risultare valido e associato al dominio.
Anziché procedere per tentativi casuali, è sufficiente analizzare l'instradamento in ordine sequenziale per individuare il punto preciso di interruzione.
Da dove iniziare la diagnosi: dominio, server o app?
L'analisi diagnostica deve partire dal nome a dominio, che costituisce l'indirizzo di destinazione della richiesta. Se il dominio è indirizzato a una destinazione errata, la pagina non si caricherà anche in presenza di una configurazione di backend corretta.
Occorre verificare che i record DNS puntino all'indirizzo IP pubblico del server. Per una configurazione standard, questo comporta l'impostazione di un record A per il dominio apex (es. example.com) e di un record dedicato per il sottodominio www.example.com. Se i DNS sono stati modificati di recente, è necessario considerare i tempi di propagazione delle modifiche sulla rete.
Per approfondire i concetti fondamentali legati alla gestione dei domini, consulta la nostra guida su come collegare un dominio al tuo server.
Una verifica utile consiste nel digitare l'indirizzo IP pubblico del server direttamente nel browser. Se l'IP risponde correttamente ma il dominio no, la causa è riconducibile alla risoluzione DNS o alle regole di routing del web server. Se l'IP risulta irraggiungibile, l'analisi si sposta sui livelli interni: firewall, web server e processo applicativo.
Perché il server non risponde alla richiesta?
Se il record DNS è configurato correttamente ma il browser restituisce comunque l'errore “Impossibile raggiungere il sito”, il server potrebbe rifiutare la connessione o non essere in ascolto sulle porte previste.
Il firewall funge da filtro di sicurezza e stabilisce quali porte di rete possano accettare traffico. Per i servizi web, le porte standard di comunicazione sono la 80 per HTTP e la 443 per HTTPS. Se tali porte risultano bloccate a livello di firewall, il browser non potrà stabilire la connessione, indipendentemente dallo stato dell'applicazione.
A livello successivo si colloca il web server. Servizi come Nginx, Apache o Caddy ricevono le richieste dei client per instradarle verso le rispettive applicazioni di backend. Se il web server non è in esecuzione, ascolta su porte differenti o non riconosce l'hostname richiesto, il percorso di rete si interrompe.
In ambienti multi-tenant possono verificarsi sovrapposizioni: un progetto potrebbe non funzionare poiché entra in conflitto di porta con un altro o perché il web server indirizza la richiesta a una directory non corretta. Quando si gestiscono più applicazioni sulla stessa macchina, è indispensabile mantenere separati domini, porte e certificati. Questo tema è trattato nel dettaglio nella guida su come ospitare più siti web su un solo server.
Perché l’app funziona in locale ma non dopo il deploy?
La corretta esecuzione in ambiente locale conferma la validità del codice applicativo, ma non garantisce che la configurazione o il packaging sul server siano adeguati.
L'applicazione potrebbe essere in ascolto solo su un'interfaccia di rete interna (es. localhost), risultando inaccessibile al web server. In alternativa, il processo potrebbe essersi arrestato in avvio a causa di variabili d'ambiente mancanti, mancata connessione al database o una porta di rete non corrispondente a quella attesa dal reverse proxy.
L'adozione di container Docker introduce un ulteriore livello di astrazione. Docker isola l'applicazione all'interno di un container con le sue dipendenze, ma richiede una corretta mappatura verso l'esterno: il server deve sapere a quale container e a quale porta inoltrare il traffico pubblico. Per approfondire la gestione della rete con i container, fa' riferimento alla nostra guida [Docker su un server per principianti](/blog/docker-su-vps-per-principianti-cos-e-quando-ti-serve-e-collegare un dominio al tuo server e Docker su un server per principianti.
Infine, anche la configurazione HTTPS può impedire la corretta fruizione di un'applicazione funzionante. Un certificato SSL assente, scaduto o non corrispondente all'hostname genera avvisi di blocco da parte del browser o il fallimento dell'handshake sicuro. Se la connessione in HTTP ha esito positivo ma HTTPS fallisce, l'anomalia è circoscritta ai certificati o al loro binding e non riguarda il codice sorgente.
FAQ
L'errore “Impossibile raggiungere il sito” indica che il deploy è fallito? Non necessariamente. Conferma solo che il browser non è riuscito a raggiungere la destinazione. L'applicazione potrebbe essere attiva, mentre la catena di risoluzione si interrompe a livello di DNS, firewall, reverse proxy o certificati SSL.
È necessario attendere la propagazione DNS prima di eseguire altri controlli? Se i DNS sono stati modificati di recente, occorre attendere i tempi di aggiornamento. È tuttavia opportuno verificare preventivamente che l'IP associato nei record A sia corretto, poiché l'attesa non corregge eventuali errori di inserimento.
Perché l'indirizzo IP del server funziona ma il dominio no? Questo scenario indica che l'infrastruttura è raggiungibile e punta tipicamente a un problema di risoluzione DNS o a una mancata associazione del dominio (virtual host) nella configurazione del web server.
Perché la connessione HTTP funziona mentre HTTPS restituisce errore? In questo caso l'applicazione e il routing sono operativi, ma la configurazione SSL/TLS è incompleta o errata. Le cause più comuni includono la mancanza del certificato, la sua avvenuta scadenza o l'emissione per un hostname differente.
La soluzione intermedia
Server Manager semplifica l'analisi dell'infrastruttura rendendo visibile l'intera catena di puntamento, dal dominio fino all'applicazione attiva, eliminando la necessità di ricostruire le configurazioni a memoria o tramite cronologia dei comandi. Quando un servizio non è raggiungibile dopo il deploy, è possibile identificare immediatamente se il problema risieda nei DNS, nell'associazione dei certificati HTTPS o nei conflitti di routing tra più progetti.
Il vantaggio risiede nella conservazione della tracciabilità dell'architettura nel tempo: la mappa dei collegamenti permette di verificare in ogni momento l'associazione tra domini, applicazioni e certificati attivi.
Questo approccio offre un quadro di controllo chiaro e leggibile, consentendo di isolare e risolvere le anomalie con un metodo diagnostico sistematico e riproducibile.
La diagnosi si considera conclusa con successo quando il nome a dominio risponde in modo costante da qualsiasi rete esterna tramite protocollo HTTPS, mostrando la corretta interfaccia applicativa e presentando un certificato SSL valido.