Quali sono le cause dei tempi di inattività dei VPS? 9 problemi da verificare
Pubblicato l'11 novembre 2026
Un VPS può sembrare non disponibile per diversi motivi molto differenti tra loro, e il primo compito consiste nel distinguere un vero guasto del server da un problema dell'applicazione, della rete o del DNS. Di rado i tempi di inattività di un VPS sono causati da un singolo evento eclatante. Più spesso è stato ignorato un piccolo segnale d'allarme: lo spazio su disco si è esaurito durante la notte, un database ha utilizzato tutta la memoria disponibile, una regola del firewall ha bloccato il traffico oppure una route a monte ha smesso di rispondere.
La risposta più sensata consiste nel verificare il servizio dall'esterno, controllare lo stato del server dall'interno e confrontare entrambi con la cronologia del monitoraggio. Così si raccolgono dati concreti prima che qualcuno prema il pulsante di riavvio. I riavvii sono utili in certi casi, ma possono anche cancellare le prove.
Quali sono le cause dei tempi di inattività dei VPS nella pratica?
Per tempo di inattività si intende che un servizio necessario agli utenti non è disponibile o è così lento da risultare inutilizzabile. Il VPS stesso potrebbe essere ancora in funzione, mentre un sito web, un'API, un servizio di posta o un database non lo è. Allo stesso modo, un server potrebbe essere integro ma irraggiungibile a causa di un problema del percorso di rete o del DNS.
Questa distinzione è importante durante un incidente. Se il nodo host è integro e la macchina virtuale risponde dalla console ma non da Internet pubblico, l'indagine deve concentrarsi sulla rete e sulle regole del firewall. Se la macchina non riesce a pianificare i processi perché la memoria è esaurita, la rete pubblica non è la causa. Anche i log raccontano la stessa storia, se si pone loro la domanda giusta.
1. Esaurimento delle risorse all'interno della macchina virtuale
CPU, RAM, spazio su disco, capacità degli inode e I/O del disco sono risorse limitate. Un picco di traffico, una query inefficiente, un processo in background fuori controllo o una cache dimensionata male possono consumarne una più rapidamente del previsto.
La pressione sulla memoria è particolarmente comune. Linux potrebbe attivare il killer OOM e terminare un processo del database o dell'applicazione per mantenere in funzione il sistema. Dal punto di vista del cliente, questo equivale a un tempo di inattività. Su un server senza swap o con un piano sottodimensionato, un breve picco può trasformarsi in un'interruzione completa del servizio.
Anche un disco pieno causa comportamenti altrettanto sconcertanti. Non è possibile scrivere i log, i database potrebbero smettere di accettare modifiche e i servizi potrebbero non riuscire a riavviarsi. È opportuno controllare anche gli inode: milioni di piccoli file di cache o di sessione possono impedire la creazione di nuovi file anche quando `df -h` indica che c'è spazio libero su disco.
La soluzione non è sempre «acquistare più risorse». Aggiungere RAM potrebbe essere la scelta giusta, ma prima occorre identificare il carico di lavoro che è aumentato e capirne il motivo. La capacità dovrebbe essere calcolata sulla base dell'utilizzo normale, dei picchi e di un margine per il ripristino, non soltanto considerando un tranquillo martedì mattina.
2. Guasti delle applicazioni e dei database
Un VPS funzionante non garantisce che anche l'applicazione funzioni. I server web possono esaurire i processi worker, i pool PHP possono bloccarsi, i container possono entrare in un ciclo di arresti anomali e le connessioni al database possono esaurirsi. Una distribuzione può inoltre introdurre un errore di sintassi, una dipendenza incompatibile o una migrazione che blocca una tabella molto utilizzata.
Spesso questi incidenti riguardano un solo servizio. SSH potrebbe funzionare e l'agente di monitoraggio potrebbe segnalare un carico di sistema normale, ma il sito restituisce errori 502, 503 o 500. Prima di riavviare tutto in una volta, controlla i log dell'applicazione, lo stato dei servizi, le distribuzioni recenti, i log degli errori del database e i tempi di risposta.
Una buona pianificazione del ripristino prevede procedure di rollback verificate. Un rollback rapido può ripristinare i ricavi più velocemente di quanto si riesca a eseguire il debug del nuovo codice in produzione sotto pressione. Per i team di e-commerce e SaaS, includi le migrazioni del database nello stesso piano di modifica della release dell'applicazione. Il codice si può ripristinare facilmente; i dati modificati sono meno accomodanti.
3. Problemi di rete, routing e firewall
La raggiungibilità pubblica dipende da molto più del solo VPS. Un problema di routing a monte, un guasto in un punto di interscambio Internet, la perdita di pacchetti, un gruppo di sicurezza configurato in modo errato o una modifica del firewall possono interrompere l'accesso mentre la VM continua a funzionare normalmente.
All'interno del server, tra le cause più comuni figurano un gateway predefinito errato, modifiche accidentali alla configurazione dell'interfaccia, una regola del firewall che blocca le porte 80 o 443 oppure regole di fail2ban che bloccano traffico legittimo. La limitazione della frequenza e la mitigazione degli attacchi DDoS possono inoltre influire sul comportamento in caso di traffico insolitamente elevato.
Gli incidenti di rete richiedono verifiche a più livelli. Esegui test da più aree geografiche, verifica se l'indirizzo IP risponde all'ICMP solo se tale protocollo è stato autorizzato intenzionalmente e testa la porta del servizio effettivamente utilizzata. Un ping riuscito non dimostra che un sito web sia disponibile, così come un ping non riuscito non dimostra che il server sia fuori servizio.
4. Problemi di DNS e certificati che sembrano tempi di inattività
Il DNS non viene eseguito all'interno del VPS, ma un record DNS errato può far sembrare non disponibile un servizio funzionante. Tra gli esempi più comuni figurano un record A che punta a un vecchio indirizzo IP, un dominio scaduto, un record mancante dopo una migrazione o nameserver diversi da quelli previsti per il provider DNS.
I guasti dei certificati TLS creano un'esperienza simile per i clienti. Il server potrebbe fornire il sito, ma i browser avvisano gli utenti e li invitano a non proseguire perché il certificato è scaduto, il nome host non corrisponde oppure il rinnovo non è andato a buon fine. Tecnicamente, non si tratta di un tempo di inattività del VPS. Dal punto di vista operativo, però, i visitatori non possono comunque utilizzare il sito: il problema merita quindi la stessa urgenza.
Monitora le date di rinnovo dei domini, le modifiche al DNS e le scadenze dei certificati insieme agli avvisi dell'infrastruttura. Sono verifiche che richiedono poco sforzo e offrono un grande vantaggio quando un'attività dipende dal traffico web.
5. Guasti del nodo host o della piattaforma di storage
Un VPS funziona su un'infrastruttura fisica. Guasti hardware, problemi del sistema operativo host, problemi dell'hypervisor o il degrado dello storage possono interessare una o più VM sullo stesso nodo. Le piattaforme professionali utilizzano ridondanza, monitoraggio e procedure di manutenzione per ridurre questo rischio, ma nessun provider serio può promettere che i componenti fisici non si guasteranno mai.
Gli incidenti di storage possono essere particolarmente destabilizzanti perché le applicazioni restano in attesa delle operazioni di lettura e scrittura. Potresti notare un'attesa I/O elevata, timeout del database, pagine lente o una VM che sembra bloccata. L'intervento appropriato dipende dalla piattaforma: i tecnici potrebbero migrare la VM, riparare il nodo sottostante o ripristinare i servizi da uno stato noto e funzionante.
Chiedi al provider se sono inclusi gli avvisi di manutenzione, il monitoraggio a livello di host e l'escalation al supporto. Per i carichi di lavoro che non possono tollerare il guasto di un singolo server, la soluzione è architetturale: repliche, bilanciamento del carico, backup esterni al server e una procedura di ripristino verificata. Un VPS può essere affidabile, ma resta pur sempre un solo VPS.
6. Manutenzione e modifiche alla configurazione
La manutenzione pianificata è più sicura di una riparazione d'emergenza, ma le modifiche restano una delle principali cause di interruzione. Gli aggiornamenti del kernel potrebbero richiedere un riavvio. L'aggiornamento di un pannello di controllo può modificare la configurazione del server web. Cambiare le versioni di PHP, le impostazioni del database, le regole del firewall o le interfacce di rete può smentire un presupposto mai documentato.
La soluzione è una gestione controllata delle modifiche, anche per i team più piccoli. Se opportuno, crea un backup o uno snapshot, registra la configurazione attuale, pianifica le modifiche al di fuori del periodo di maggiore attività e verifica in seguito il percorso effettivo dell'utente. «Il servizio è avviato» non significa che «i clienti possano accedere e completare il checkout».
Per i clienti con VPS gestiti, una verifica pratica prima e dopo una modifica rischiosa può eliminare molti dubbi. Su kodu.cloud, il monitoraggio e il supporto operativo sono pensati per intercettare i guasti più banali prima che trasformino il pomeriggio in un'avventura.
7. Incidenti di sicurezza e gestione degli abusi
Credenziali compromesse, plugin vulnerabili, malware, attacchi brute force e abuso delle risorse possono causare tempi di inattività. Un aggressore potrebbe consumare CPU per il cryptomining, inondare un servizio di richieste, eliminare file o modificare le impostazioni DNS e dell'applicazione. A volte un provider deve limitare temporaneamente un VPS che attacca altri sistemi o genera traffico dannoso.
La prevenzione è una questione pratica, non un mistero: installa gli aggiornamenti di sicurezza, usa chiavi SSH e l'autenticazione a più fattori quando disponibili, limita l'accesso amministrativo, rimuovi i software inutilizzati e conserva i backup al di fuori del VPS. Controlla i log di autenticazione e il traffico in uscita anomalo. Se il server inizia improvvisamente a inviare più email di quanti siano i clienti dell'attività, non si tratta di una svolta nel marketing.
8. Lacune nel monitoraggio e rilevamento tardivo
L'interruzione potrebbe iniziare con un piccolo guasto, ma l'impatto sull'attività aumenta se nessuno se ne accorge. Un controllo di disponibilità di base può indicare se una porta risponde. Un monitoraggio più completo tiene traccia anche della CPU, della memoria, dell'utilizzo del disco, dell'attesa I/O, dei processi dei servizi, della scadenza dei certificati SSL, dell'esito dei backup e delle transazioni chiave dell'applicazione.
Gli avvisi dovrebbero raggiungere una persona in grado di intervenire. Troppi avvisi superflui abituano i team a ignorarli del tutto; troppo pochi ti lasciano senza visibilità. Imposta soglie significative, usa l'escalation per i guasti prolungati e rivedi gli avvisi dopo gli incidenti. Il monitoraggio in stile FASTCARE è utile perché rileva i primi segnali di peggioramento, non soltanto l'arresto definitivo.
Come ridurre i tempi di inattività dei VPS prima che si verifichino
Inizia dalle basi del ripristino. Conserva backup verificati, prova regolarmente il ripristino e archivia almeno un backup al di fuori del VPS stesso. Un backup mai ripristinato è solo un file promettente, non ancora un piano di ripristino.
Poi definisci i valori di riferimento della capacità. Monitora il comportamento normale e di picco di CPU, memoria, storage e database. Imposta gli avvisi prima che l'utilizzo del disco raggiunga il livello in cui i log e i servizi smettono di funzionare. Per i servizi critici, separa il database dal livello web o introduci la ridondanza quando il costo dei tempi di inattività lo giustifica.
Infine, fai in modo che le modifiche siano tracciabili. Registra le distribuzioni, le modifiche all'infrastruttura, le modifiche al DNS e le finestre di manutenzione. Durante un incidente, un registro delle modifiche con data e ora spesso riduce la diagnosi da ore a minuti.
Una procedura di gestione degli incidenti ben ponderata è meglio delle supposizioni: determina l'ambito del problema, proteggi i dati, ripristina il servizio rivolto ai clienti e poi indaga sulla causa principale mentre le prove sono ancora disponibili. Il servizio può tornare alla normalità e la prossima interruzione può essere meno grave della precedente.
Andres Saar, ingegnere dell'assistenza clienti