Sito web offline: errori del server 500, 502 e 504, cause e soluzioni

I problemi di sito web offline o di blocco improvviso del sito dipendono spesso dal fatto che il server non riesce a elaborare la richiesta, che un livello intermedio non riceve una risposta valida oppure che l’operazione va in timeout. L’errore 500 indica di solito un problema interno generico, legato all’applicazione o alla configurazione del server; l’errore 502 segnala che un proxy o un gateway ha ricevuto una risposta non valida dal backend; l’errore 504, invece, significa che il backend non ha risposto entro il tempo previsto. Per risolvere in modo stabile non basta “riavviare tutto”: bisogna leggere correttamente il codice di errore, analizzare i log del server, misurare l’utilizzo delle risorse, individuare gli errori PHP o applicativi, eliminare i colli di bottiglia del database e dimensionare l’infrastruttura hosting in base al traffico reale.

Per un visitatore, questi errori si traducono semplicemente in una pagina bianca, un messaggio tecnico o un sito irraggiungibile. Per un’azienda, però, significano vendite perse, fiducia ridotta e segnali SEO più deboli. Nei progetti dove la continuità è fondamentale, come e-commerce, siti aziendali, portali di notizie, aree clienti o sistemi di prenotazione, gli errori 5xx possono trasformarsi in perdita di fatturato nel giro di pochi minuti. In questa guida vedremo come distinguere gli errori 500, 502 e 504, come fare una diagnosi rapida e quali misure adottare per evitare che il problema si ripresenti.

Perché i problemi di sito web offline vanno presi sul serio?

Un sito che va giù non è soltanto un inconveniente tecnico. L’impatto riguarda direttamente esperienza utente, tasso di conversione, percezione del brand e visibilità sui motori di ricerca. Google tende a tollerare interruzioni brevi e occasionali; tuttavia, errori 5xx ripetuti possono sprecare crawl budget, far scansionare meno spesso le pagine importanti e generare oscillazioni nel posizionamento.

Nella pratica, gli errori 5xx vanno gestiti su due livelli. Il primo è l’intervento d’urgenza: riportare il sito online e renderlo nuovamente accessibile. Il secondo è l’analisi della causa principale: capire perché lo stesso errore si verifica durante picchi di traffico, esecuzione di cron, aggiornamenti di plugin, importazioni massive o aumento del carico sul database. Riavviare un servizio può dare sollievo temporaneo, ma se la causa resta nascosta l’errore può ripresentarsi dopo poche ore.

Per esempio, in un negozio WooCommerce durante una campagna promozionale l’utilizzo della CPU può salire al 95%, la coda PHP-FPM può saturarsi e il database può bloccarsi su query lente. In uno scenario del genere i visitatori possono vedere errori 500 o 504. Installare soltanto un plugin di cache potrebbe non bastare: servono ottimizzazione delle query, un piano hosting più potente, CDN, object cache e una revisione congiunta dei limiti di risorsa. Quando un progetto cresce e il traffico aumenta, è utile confrontare Pacchetti web hosting Hostragons e, per esigenze superiori di risorse dedicate, Hostragons Soluzioni VPS server.

Differenze principali tra errori 500, 502 e 504

Gli errori 500, 502 e 504 appartengono tutti alla famiglia 5xx, ma non indicano lo stesso problema. Una diagnosi sbagliata porta quasi sempre a interventi sbagliati. La tabella seguente riassume le differenze più comuni.

Questa distinzione è particolarmente importante nelle architetture che usano Nginx, Apache, LiteSpeed, PHP-FPM, Node.js, reverse proxy, CDN e load balancer. Un utente può vedere un 502 nel browser mentre la causa reale è il crash di PHP-FPM. Allo stesso modo, un 504 può non dipendere dal web server, ma da un’API di pagamento esterna che impiega più di 30 secondi a rispondere.

500 Internal Server Error: cause e passaggi per risolvere

Che cosa significa errore 500?

Il messaggio 500 Internal Server Error indica che il server non è riuscito a completare la richiesta, ma non può descrivere il problema con un codice più specifico. Per questo l’errore 500 copre un ventaglio molto ampio di possibilità. Può comparire su WordPress, Laravel, applicazioni PHP personalizzate, progetti Python o Node.js, ma con cause diverse. Poiché il messaggio mostrato all’utente è spesso generico, gli indizi più utili si trovano quasi sempre nei file di log.

Cause più comuni dell’errore 500

• Regole .htaccess errate: RewriteRule sbagliate, redirect infiniti o direttive non supportate possono generare un errore 500.
• Fatal error PHP: Funzioni mancanti, versione PHP incompatibile, superamento del limite di memoria o tema/plugin difettosi possono bloccare il sito.
• Permessi di file e cartelle: Permessi non sicuri o non corretti, come file PHP impostati a 777, possono essere rifiutati dal server.
• Dipendenze mancanti: Pacchetti Composer, moduli PHP o file di cache del framework possono essere assenti o corrotti.
• Limiti di risorse del server: CPU, RAM, processi simultanei o I/O saturi possono interrompere la richiesta prima del completamento.

Come risolvere l’errore 500?

Per prima cosa, evitate il panico e ricostruite la cronologia delle modifiche. Se l’errore è iniziato dopo l’aggiornamento di un plugin, una modifica al tema, un cambio di versione PHP, una nuova regola .htaccess o un picco di traffico, il campo di ricerca si restringe molto. Poi procedete con questi controlli:

• 1. Controllate i log: In cPanel, Plesk o nel pannello del server cercate il file error_log. Righe come fatal error, memory exhausted, permission denied o syntax error danno indicazioni molto precise.
• 2. Annullate l’ultima modifica: Disattivate il plugin, il tema o il frammento di codice installato di recente. Su WordPress, rinominare temporaneamente la cartella dei plugin è spesso un test rapido ed efficace.
• 3. Testate il file .htaccess: Salvate temporaneamente il file con un altro nome e rigenerate le regole predefinite. Se il sito torna online, il problema è in una regola di redirect o rewrite.
• 4. Verificate versione e limiti PHP: Un’applicazione non compatibile con PHP 8.2, per esempio, può generare errori 500. Bilanciate memory_limit, max_execution_time e post_max_size in base alle necessità del progetto.
• 5. Correggete i permessi: Come pratica generale, si usano 755 per le cartelle e 644 per i file. Per esigenze specifiche, seguite le indicazioni del vostro provider hosting.
• 6. Pianificate il ripristino da backup: Se il sito in produzione è completamente irraggiungibile, tornare all’ultimo backup funzionante può ripristinare il servizio prima dell’analisi approfondita. Qui i backup regolari diventano fondamentali.

Se l’errore 500 si ripete spesso, non basta guardare solo al codice applicativo. Bisogna analizzare quanti processi PHP sono attivi contemporaneamente, quanta memoria consumano in media, quante connessioni al database vengono aperte e se esistono latenze sul disco o nell’I/O. Negli ambienti di hosting condiviso, i limiti di risorsa possono non stare al passo con la crescita del sito. In casi del genere conviene valutare Hosting WordPress Hostragons o soluzioni con risorse più isolate.

502 Bad Gateway: capire errori di proxy e upstream

Che cosa significa errore 502?

Il 502 Bad Gateway segnala che il livello gateway o proxy, posizionato tra client e servizio backend, non ha ricevuto una risposta valida. Nelle architetture hosting moderne, Nginx lavora spesso come reverse proxy: inoltra richieste PHP a PHP-FPM, richieste Node.js alla porta dell’applicazione oppure traffico verso un altro servizio upstream. Se uno degli elementi di questa catena è fermo, sovraccarico o configurato sulla porta sbagliata, compare un errore 502.

Cause tipiche dell’errore 502

• Il servizio PHP-FPM è fermo o il file socket non è raggiungibile.
• L’applicazione Node.js, Python o Java non è in ascolto sulla porta prevista.
• Nella configurazione upstream di Nginx sono indicati IP, porta o percorso socket errati.
• La CDN o il firewall non riesce a ricevere la risposta attesa dal server origin.
• La RAM del server è piena e i processi terminati forzatamente fanno cadere i servizi backend.

Piano pratico per risolvere l’errore 502

Nel caso di un 502, l’obiettivo iniziale è capire quale anello della catena non sta rispondendo. La sequenza seguente è una delle più efficaci nei processi reali di assistenza tecnica:

• Controllate lo stato dei servizi: Verificate che PHP-FPM, web server, database e servizi applicativi siano attivi. Su VPS o server dedicati potete usare comandi come systemctl status.
• Confrontate i log upstream: Analizzate il log errori di Nginx insieme ai log di PHP-FPM o dell’applicazione, sulla stessa fascia oraria. Messaggi come connection refused, upstream prematurely closed connection o no live upstreams sono indizi chiave.
• Controllate l’uso delle risorse: Se la RAM supera il 90% e lo swap è molto utilizzato, i servizi possono smettere di rispondere. Anche un load CPU molto superiore al numero di core crea code e ritardi.
• Verificate socket e porte: Se Nginx punta a 127.0.0.1:9000 mentre PHP-FPM ascolta su un socket differente, il 502 è praticamente inevitabile.
• Testate il livello CDN: Bypassate temporaneamente la CDN e raggiungete direttamente il server origin. Se il problema appare solo tramite CDN, controllate DNS, SSL e impostazioni di connessione all’origin.

A volte l’errore 502 è legato anche alla configurazione SSL. Se tra CDN e origin viene usato HTTPS, ma il certificato del server origin è scaduto o associato al dominio sbagliato, possono comparire errori gateway. Per configurare correttamente il livello SSL, potete consultare le opzioni in Certificati SSL Hostragons e la guida guida all'installazione del certificato SSL.

504 Gateway Timeout: risolvere definitivamente i problemi di timeout

Che cosa significa errore 504?

Il 504 Gateway Timeout indica che il proxy o gateway non ha ricevuto una risposta dal servizio backend entro il tempo configurato. Il servizio non deve per forza essere spento: può semplicemente rispondere troppo lentamente. Per questo il 504 è spesso collegato a problemi di performance, database, API esterne o processi che richiedono troppo tempo.

Cause frequenti dell’errore 504

• Query database lente: Mancanza di indici, scansioni di tabelle molto grandi o lock aumentano i tempi di risposta.
• Ritardi di API esterne: Pagamenti, spedizioni, CRM o servizi di magazzino lenti possono lasciare la richiesta web in attesa.
• Latenza di rete: Se applicazione e database si trovano in località diverse, la latenza può diventare critica.
• Cron o importazioni molto pesanti: Import CSV, invio massivo di email o generazione report possono rallentare le richieste degli utenti.
• Timeout non coerenti: I valori di timeout di Nginx, Apache, PHP-FPM e applicazione possono essere disallineati.

Come eliminare l’errore 504?

Aumentare semplicemente i valori di timeout spesso nasconde il sintomo, ma non risolve il problema. Per esempio, concedere 120 secondi a una query che non termina in 30 secondi può ridurre il numero di errori, ma non migliora l’esperienza utente. L’approccio corretto è misurare il punto lento e velocizzarlo.

• 1. Scomponete il tempo di risposta: Misurate separatamente tempo applicativo, tempo database, tempo API esterna e attesa del server.
• 2. Attivate lo slow query log: In MySQL o MariaDB registrate le query superiori a 1 secondo. Aggiungete indici o riscrivete le query lente che si ripetono spesso.
• 3. Spostate i lavori pesanti in background: Generazione report, elaborazione immagini, invio email e sincronizzazione stock dovrebbero essere eseguiti tramite code.
• 4. Usate la cache: Cache di pagina, object cache e OPcache riducono in modo significativo il carico delle applicazioni dinamiche.
• 5. Allineate i timeout: proxy_read_timeout, fastcgi_read_timeout, max_execution_time e timeout applicativi non devono contraddirsi tra loro.
• 6. Impostate limiti sulle API esterne: Se l’API non risponde, la richiesta dell’utente non deve restare sospesa all’infinito. Usate retry, fallback e timeout brevi.

In uno scenario reale, una pagina categoria che filtra 60 mila prodotti senza un indice sul campo categoria può generare molti 504 durante una campagna. Aggiungere l’indice, mettere in cache i risultati dei filtri e ottimizzare le query può risolvere il problema anche senza aumentare le risorse. Se però la crescita del traffico è stabile, sarà necessario pianificare anche uno scaling dell’infrastruttura.

Checklist in 10 passaggi per una diagnosi rapida

Quando un sito va improvvisamente offline, intervenire in modo disordinato fa perdere tempo. La checklist seguente aiuta a procedere con metodo negli errori 500, 502 e 504:

• 1. Verificate se l’errore riguarda tutti o solo voi: Testate da un’altra rete, da connessione mobile e con strumenti esterni di uptime.
• 2. Confermate il codice di stato HTTP: Usate gli strumenti sviluppatore del browser o un controllo tipo curl -I https://iltuodominio.com per leggere il codice reale.
• 3. Elencate le ultime modifiche: Ci sono stati deploy di codice, aggiornamenti plugin, cambi DNS, rinnovi SSL, modifiche PHP o configurazioni server?
• 4. Guardate i log del web server: I log errori di Apache, Nginx o LiteSpeed sono la prima fonte da consultare.
• 5. Analizzate i log applicativi: WordPress debug log, Laravel storage logs o log di processo Node.js indicano spesso l’origine del problema.
• 6. Misurate le risorse server: CPU, RAM, spazio disco, inode, I/O disco e numero di connessioni vanno valutati nello stesso momento.
• 7. Controllate il database: Il limite connessioni è saturo? Ci sono query bloccate? Le query lente sono aumentate?
• 8. Testate firewall e CDN: Regole WAF, filtri bot o connessione CDN-origin possono funzionare in modo errato.
• 9. Tenete pronto il backup: Se un file critico è corrotto o un aggiornamento è fallito, serve un piano di rollback rapido.
• 10. Create un report della causa principale: Dopo la risoluzione, documentate ora, impatto, causa, soluzione e azioni preventive.

Questa lista è molto utile anche per dividere le responsabilità all’interno del team. Quando contattate il provider hosting, condividere ora dell’errore, URL di esempio, codice visualizzato, ultime modifiche e, se possibile, screenshot riduce il tempo di risoluzione. Per problemi di accesso legati a dominio, DNS o redirect, anche risorse come Verifica dominio e registrazione Hostragons e Guida alla gestione DNS possono aiutare la diagnosi.

Leggere correttamente le risorse del server

Una parte significativa degli errori 5xx è legata a colli di bottiglia nelle risorse. Tuttavia, una CPU alta non significa sempre codice scritto male: a volte il sistema viene messo sotto pressione da traffico organico superiore alle attese, attacchi bot, cron configurati male o procedure di backup. Per questo le metriche non vanno lette da sole, ma collegate alla cronologia degli eventi.

Metriche fondamentali da monitorare

• Utilizzo CPU: Un uso costante sopra l’80% aumenta il rischio di code e ritardi.
• RAM e swap: Se lo swap cresce, i processi rallentano e possono comparire errori 502 e 504.
• Disk I/O: Scrittura intensiva di log, backup grandi o operazioni database possono causare attese I/O.
• Entry process e connessioni concorrenti: Negli hosting condivisi, i limiti di processi simultanei possono trasformarsi in errori 500.
• Connessioni database: Avvicinarsi al limite max_connections aumenta gli errori applicativi.
• TTFB: Un aumento costante del tempo al primo byte è un segnale precoce prima dei 504.

Potete usare un approccio a soglie semplici: se in condizioni normali il TTFB è tra 300 e 600 ms, ma durante una promozione sale a 5-10 secondi, bisogna pianificare la capacità prima che gli errori diventino visibili. Monitoraggio uptime, analisi dei log e misurazioni di performance, usati insieme, permettono di intercettare il problema prima che cresca.

Misure preventive su applicazione, database e hosting

Cosa fare lato applicazione

Qualità del codice e aggiornamenti controllati sono una delle difese più forti contro i problemi di sito web offline. Rimuovete plugin inutilizzati, scegliete temi e componenti da fonti affidabili, testate la compatibilità con la versione PHP in un ambiente separato. Usare uno staging invece di modificare direttamente il sito live consente di intercettare molti errori 500 prima che raggiungano gli utenti.

• Non mostrate il debug agli utenti sul sito live: scrivetelo nei file di log.
• Prima di ogni aggiornamento, eseguite backup completi di file e database.
• Separate i processi lunghi dalle richieste degli utenti.
• Ottimizzate le immagini e riducete script non necessari.
• Analizzate il traffico bot e limitate bot malevoli o eccessivi tramite WAF.

Cosa fare lato database

Le prestazioni del database sono decisive soprattutto per WordPress, WooCommerce, forum, portali e sistemi con area membri. Siti con migliaia di prodotti, ordini, commenti o record di log possono soffrire per tabelle gonfie e query lente. Manutenzione regolare, controllo degli indici e pulizia dei dati inutili riducono il rischio di 504.

• Usate lo slow query log per individuare le query più costose.
• Aggiungete indici corretti alle colonne filtrate più spesso.
• Pulite opzioni autoloaded inutili.
• Archiviate periodicamente vecchie revisioni, transient e tabelle di log.
• Eseguite i backup del database nelle fasce orarie con meno traffico.

Cosa fare lato hosting

Se l’infrastruttura hosting non è adatta, anche un sito ben ottimizzato può andare in difficoltà durante i picchi. Un semplice sito vetrina aziendale e un e-commerce ad alto traffico non hanno lo stesso fabbisogno. Traffico, numero di operazioni, percentuale di pagine dinamiche, uso email, dimensione del database e requisiti di sicurezza vanno valutati insieme.

• Per siti piccoli e medi possono bastare piani hosting facili da gestire.
• Per siti con molte operazioni dinamiche, un VPS con CPU/RAM isolate è spesso più stabile.
• Nei progetti aziendali, backup regolari, SSL, WAF e monitoraggio uptime dovrebbero essere standard.
• I record DNS vanno mantenuti semplici e le catene di redirect inutili eliminate.
• Se usate una CDN, server origin, SSL e regole cache devono essere configurati correttamente.

In questa valutazione guardare solo allo spazio disco può essere fuorviante. Un sito che usa 2 GB di spazio può consumare più CPU di un altro che occupa 20 GB, se ha molti utenti simultanei e tante richieste dinamiche. La scelta del piano deve quindi basarsi su traffico reale e carico operativo, non soltanto sui gigabyte disponibili.

Cosa fare per la SEO in caso di errori 5xx?

I motori di ricerca non penalizzano immediatamente errori 5xx temporanei, ma interruzioni ripetute possono influenzare scansione e indicizzazione. Se Googlebot riceve spesso risposte 500, 502 o 504 su pagine importanti, può ridurre la frequenza di crawl. Inoltre, quando gli utenti cliccano un risultato organico e trovano un errore, la fiducia e le conversioni ne risentono.

Per ridurre il rischio SEO, attivate monitoraggio uptime sulle pagine critiche, controllate le statistiche di scansione in Search Console e analizzate nei log del server i codici di stato ricevuti da Googlebot. In caso di manutenzione programmata, una risposta 503 Service Unavailable breve e correttamente configurata è preferibile a un 500 non gestito. Inserire l’header Retry-After nella pagina di manutenzione indica ai motori quando riprovare.

Durante migrazioni, cambi dominio o passaggi a HTTPS, redirect sbagliati e certificati non corretti possono causare problemi di accesso simili a errori 5xx. Prima della migrazione è buona norma abbassare il TTL DNS, creare backup, testare su un dominio o ambiente temporaneo e monitorare i log subito dopo il passaggio.

Quando contattare il supporto hosting?

Alcuni problemi possono essere risolti dal gestore del sito; altri richiedono accesso al server e competenze specifiche. Nei casi seguenti è consigliabile contattare rapidamente il supporto hosting:

• L’errore riguarda tutto il sito e non riuscite ad accedere nemmeno al pannello di amministrazione.
• Nei log compaiono righe come permission denied, upstream failed o resource limit exceeded.
• PHP-FPM, web server o database vanno continuamente in crash.
• Con la CDN disattivata il sito si apre, mentre con la CDN attiva restituisce 502 o 504.
• I limiti di risorsa si saturano spesso e non è chiaro quale piano sia più adatto.
• L’accesso si è interrotto dopo modifiche a SSL, DNS o firewall.

Quando aprite una richiesta di supporto, aggiungere queste informazioni riduce notevolmente i tempi: ora di inizio dell’errore, URL interessati, codice visualizzato, ultime modifiche effettuate, screenshot, eventuali righe di log e indicazione se il problema è continuo o intermittente. Questi dati aiutano il team tecnico a riprodurre il problema e a controllare il livello corretto dell’infrastruttura.

Domande frequenti

L’errore 500 significa che il mio sito è stato hackerato?

No, un errore 500 da solo non è una prova di compromissione. Nella maggior parte dei casi dipende da un errore PHP, un conflitto tra plugin, una regola .htaccess sbagliata, permessi file non corretti o limiti di risorsa. Tuttavia, se l’errore compare insieme a modifiche inattese nei file, redirect sospetti o account utente sconosciuti, è opportuno eseguire una scansione di sicurezza.

L’errore 502 Bad Gateway può dipendere dall’utente?

Di solito no. Il 502 indica quasi sempre un problema di comunicazione tra server, proxy, CDN o servizio backend. L’utente può provare a svuotare la cache del browser e testare da un’altra rete, ma se l’errore è visibile a tutti la soluzione va cercata lato server.

Per un 504 Gateway Timeout basta aumentare il timeout?

A volte aiuta temporaneamente, ma non è una soluzione definitiva. In caso di 504 l’obiettivo è trovare la causa principale: query lente, ritardi di API esterne, CPU satura o processi troppo lunghi. L’aumento dei timeout va applicato con cautela e insieme a interventi di ottimizzazione.

Gli errori 5xx fanno calare subito il ranking SEO?

Interruzioni brevi e rare di solito non causano perdite permanenti di posizionamento. Se però gli errori 5xx si ripetono spesso, pagine importanti restano irraggiungibili a lungo o Googlebot riceve regolarmente errori server, crawl e performance organica possono peggiorare.

Qual è l’abitudine più importante per prevenire un sito web offline?

L’abitudine più importante è combinare monitoraggio regolare e gestione controllata delle modifiche. Uptime monitoring, backup, controllo dei log, test in staging, software aggiornato e monitoraggio delle risorse permettono di prevenire la maggior parte degli errori 500, 502 e 504 prima che diventino critici.

Riepilogo rapido e prossimo passo

Gli errori 500, 502 e 504 appartengono alla stessa famiglia, ma indicano livelli diversi: il 500 è spesso un problema applicativo o di configurazione, il 502 segnala un errore di comunicazione tra proxy e upstream, il 504 riguarda timeout e colli di bottiglia di performance. La soluzione corretta passa da conferma del codice, lettura dei log, misurazione delle risorse, analisi delle ultime modifiche e ottimizzazione stabile.

Se il vostro sito soffre spesso di problemi di sito web offline, conviene valutare insieme risorse hosting, configurazione SSL e DNS, prestazioni applicative e database. Per scegliere un’infrastruttura più adatta o confrontare le opzioni con un team tecnico, potete esaminare le soluzioni Hostragons: l’obiettivo è costruire un’esperienza web più veloce, sicura e resistente alle interruzioni.