166 27/03/2026 07/04/2026 5 min

Diagnosi probabile

Quando un servizio server non risponde da rete, le cause più frequenti sono abbastanza ripetitive: il processo non è in ascolto, la porta è chiusa dal firewall, il DNS punta all’IP sbagliato, oppure c’è un problema di routing o di reverse proxy davanti al servizio. In ambienti hosting e VPS, spesso il guasto è esterno al software applicativo e riguarda solo uno degli strati della catena: rete, filtro, web server, backend PHP, database o applicazione.

La diagnosi corretta parte sempre da una distinzione semplice: il servizio è vivo localmente? Se risponde in locale ma non dall’esterno, il problema è quasi sempre nella rete o nel firewall. Se non risponde nemmeno in locale, il problema è nel servizio stesso, nelle dipendenze o nel sistema operativo.

Un’altra ipotesi comune è il sovraccarico: il servizio resta tecnicamente attivo ma non accetta nuove connessioni perché ha esaurito worker, file descriptor, RAM o slot del backend. In quel caso la porta può sembrare “aperta”, ma il test applicativo fallisce o va in timeout.

Verifiche immediate

  1. Verifica la raggiungibilità dall’esterno. Prova ad aprire il servizio dal browser o con un test rete. Se il sito o la porta non rispondono, annota l’errore preciso: timeout, connessione rifiutata, DNS fallito, pagina vuota o errore HTTP. L’esito atteso è capire se il problema è totale o parziale.
  2. Controlla se il processo è in ascolto sul server. Da SSH, usa un comando come ss -tulpn o ss -ltnp per verificare che la porta sia effettivamente aperta localmente. L’esito atteso è vedere il servizio associato alla porta corretta.
  3. Verifica lo stato del servizio. Con systemctl status nome-servizio controlla se il demone è attivo, in errore o in restart loop. L’esito atteso è uno stato active (running) o comunque un indizio chiaro sull’errore.
  4. Controlla il firewall. Su sistemi Linux, verifica se la porta è consentita da ufw, firewalld o regole iptables. L’esito atteso è che la porta del servizio sia permessa in ingresso.
  5. Testa il servizio in locale. Usa curl http://127.0.0.1:PORTA o, per HTTPS, curl -k https://127.0.0.1:PORTA. Se la risposta arriva in locale ma non fuori, il problema è quasi certamente nella rete esterna o nel firewall.

Soluzione consigliata passo-passo

  1. Ripristina prima il punto più sicuro e reversibile. Se il servizio è fermo, riavvialo in modo controllato con systemctl restart nome-servizio. Questa è la correzione meno invasiva quando non ci sono evidenze di un errore di configurazione. Subito dopo verifica con systemctl status nome-servizio e con un test di connessione locale.
  2. Se il servizio parte ma non risponde, controlla i log essenziali. Esamina i log del servizio con journalctl -u nome-servizio -n 100 --no-pager e, se si tratta di web server, anche i log di errore dell’applicazione o del virtual host. Cerca segnali come porta già occupata, permessi mancanti, file di configurazione errato, crash di dipendenze o esaurimento risorse. L’obiettivo è individuare il blocco reale prima di cambiare altro.
  3. Se il problema è di rete, verifica DNS e IP. Controlla che il dominio punti all’IP corretto con un test come dig dominio.tld +short oppure nslookup dominio.tld. Se l’IP è sbagliato, correggi il record DNS nel pannello del provider o del registrar. Dopo la modifica, considera la propagazione e verifica di nuovo da una rete esterna.
  4. Se il problema è il firewall, apri solo la porta necessaria. In ufw, ad esempio, consenti la porta del servizio invece di disattivare il firewall. Esempio: ufw allow 443/tcp. Con firewalld, usa la regola equivalente per il servizio o la porta. Dopo ogni modifica, controlla che la regola sia presente e rifai il test di connessione dall’esterno.
  5. Se il servizio è dietro un reverse proxy, verifica il backend. In configurazioni con Nginx, Apache, Plesk, cPanel o proxy dedicati, il front-end può essere online mentre il backend è morto. Controlla il backend locale, ad esempio PHP-FPM, Node.js, Tomcat, Redis o il database. Se uno di questi è in errore, il proxy può restituire 502, 503 o timeout anche se la porta frontale risponde.
  6. Se il problema è dovuto a risorse esaurite, libera il collo di bottiglia minimo. Controlla CPU, RAM e I/O con strumenti come top, free -m, iostat o il monitor del pannello hosting. Se il server è saturo, la soluzione più sicura è ridurre il carico temporaneamente, riavviare solo il servizio in crisi e pianificare poi l’ottimizzazione. Evita interventi aggressivi finché non hai confermato la causa.
  7. Se il servizio continua a non rispondere, prova un rollback della modifica recente. Se il guasto è iniziato dopo un cambio di configurazione, un aggiornamento o un deploy, ripristina l’ultima configurazione funzionante o la copia di backup del file coinvolto. Prima di sovrascrivere, conserva una copia del file attuale con un nome diverso, così da poter tornare indietro rapidamente.

Controlli finali / rollback

  1. Controllo finale del servizio. Verifica che il processo sia attivo, che la porta sia in ascolto e che una richiesta locale risponda con successo. L’esito atteso è active (running) e una risposta valida al test HTTP o TCP.
  2. Controllo finale dall’esterno. Ripeti il test da una rete diversa o da uno strumento esterno. L’esito atteso è la raggiungibilità reale del servizio, non solo la risposta locale.
  3. Rollback se il fix peggiora la situazione. Se dopo il riavvio o la modifica il servizio non torna stabile, ripristina il backup della configurazione, annulla la regola firewall appena aggiunta o riporta il DNS precedente se era stato cambiato di recente. Dopo il rollback, ripeti i test iniziali per confermare il ritorno allo stato precedente.
  4. Verifica post-intervento. Monitora per alcuni minuti log ed errori applicativi per assicurarti che il servizio non entri di nuovo in crash loop o saturazione. Se il problema si ripresenta, la causa probabile è una dipendenza a valle o una soglia di risorse ancora insufficiente.

Checklist rapida

  • Conferma se il problema è locale o solo esterno.
  • Verifica stato servizio, porta in ascolto e log.
  • Controlla firewall, DNS e reverse proxy.
  • Ripristina prima il fix più sicuro e reversibile.
  • Valida con un test finale da fuori server.

Assunzione: il contesto è un servizio esposto su Linux o su pannello hosting comune, con accesso SSH o accesso al pannello per i controlli base.