Directory articoli
Gestisco diversi siti web WordPress e una volta ho perso più di 800 visite in un solo giorno a causa di un errore 502. Dopo tre giorni di indagini, ho scoperto che il colpevole si trovava in una posizione poco visibile nel backend.
Chiunque gestisca un sito web WordPress sa che la cosa più frustrante non è la mancanza di traffico, ma quando il sito diventa improvvisamente inaccessibile, con errori incomprensibili come 500, 502, 503 e 504 che compaiono sullo schermo.
Pensavi che il server fosse andato in crash e ti sei precipitato a discutere con il fornitore di hosting, solo per scoprire, dopo che questi hanno verificato, che il server era perfettamente funzionante.
Potresti pensare che si tratti di un conflitto tra plugin, quindi li disattivi e li controlli uno per uno, dedicandoci gran parte della giornata, ma l'errore continua a ripresentarsi.
In realtà, non deve essere così complicato. Dopo essere caduto in innumerevoli trappole, ho scoperto che l'80% degli errori 5xx dei siti web WordPress non può sfuggire a questi 4 colpevoli. Ognuno di essi è ben nascosto, ma può facilmente rovinare il tuo sito web.
Ora, userò la mia esperienza pratica per illustrare chiaramente queste insidie, in modo che anche i principianti possano seguire e risolvere i problemi, e non dovrete mai più essere sopraffatti dagli errori.
Primo colpevole: WP-CRON non era stato disabilitato, installando di fatto un "consumo di energia nascosto" sul sito web.
Molti non sanno che WordPress include una funzionalità di pianificazione delle attività chiamata WP-CRON, abilitata per impostazione predefinita.
Le sue funzioni sembrano molto pratiche, come la programmazione della pubblicazione degli articoli, il backup automatico, il controllo degli aggiornamenti dei plugin e persino l'invio di promemoria ai membri.
Ma sapevate che questa funzionalità apparentemente utile è in realtà la principale causa di crash dei server e di errori 5xx?
WP-CRON è diverso dal Cron nativo del server. Non viene eseguito in modo proattivo, ma viene attivato dalle visite degli utenti. Ogni volta che un utente visita il tuo sito web, eseguirà segretamente il file /wp-cron.php per verificare se ci sono attività pianificate da svolgere.
Ciò significa che ogni visitatore del tuo sito web aggiunge un "onere extra", e maggiore è il numero di visitatori, più pesante diventa questo onere.
Avevo un sito web che riceveva oltre mille visitatori al giorno. Quando WP-CRON non era disabilitato, l'utilizzo della CPU del server spesso raggiungeva picchi superiori all'80% e si verificavano almeno due errori 503 al giorno, con i visitatori reindirizzati a una pagina di errore non appena cliccavano sul link.
La cosa peggiore è che, anche se non si impostano attività pianificate, WP-CRON si avvia automaticamente, richiedendo ripetutamente risorse del server. Col tempo, il server non sarà in grado di gestire il carico e segnalerà un errore.
La documentazione di GitHub afferma chiaramente: "Codice di risposta HTTP imprevisto: 500 o superiore, questo significa che si è verificato un errore sul server che impedisce l'esecuzione dello spawner cron". Ciò significa che quando WP-CRON non funziona correttamente, causerà un errore del server di tipo 500 o superiore.
L'approccio corretto consiste nel disabilitare il WP-CRON predefinito e utilizzare invece le attività pianificate native del server. In questo modo, le attività pianificate verranno eseguite normalmente, riducendo al contempo il carico sul server.
Se il tuo server supporta il comando curl, puoi aggiungere direttamente un'attività pianificata in questo modo (modifica in base al dominio del tuo sito web):
*/15 * * * * curl https://www. 你的域名/wp-cron.php?doing_wp_cron > /dev/null 2>&1Questo comando esegue un'attività WP-CRON ogni 15 minuti, adatta alla maggior parte dei siti web di piccole e medie dimensioni; se il tuo sito web ha attività programmate frequenti, puoi utilizzare anche questo:
*/5 * * * * curl https://www. 你的域名/wp-cron.php?doing_wp_cron > /dev/null 2>&1Dopo aver disattivato WP-CRON e impostato attività pianificate sul server, l'utilizzo della CPU è sceso al di sotto del 30% e non si sono verificati errori 503 per un intero mese. Anche il tasso di fidelizzazione dei visitatori è aumentato del 18%.
Secondo colpevole: le attività CRON ripetute e i file residui dopo la disinstallazione del plugin lasciano essenzialmente "spazzatura" sul sito web.
Risolvere il problema di WP-CRON non significa poter stare tranquilli; c'è una trappola nascosta che molti proprietari di siti web trascurano.
Ciò significa che le attività pianificate da CRON vengono eseguite ripetutamente, oppure che le attività pianificate residue continuano a essere eseguite segretamente anche dopo la disinstallazione del plugin.
Vi è mai capitato di disinstallare un plugin di backup, ma di scoprire che il server continua a eseguire automaticamente il backup ogni giorno, o addirittura visualizza un messaggio di errore relativo al backup, che alla fine si traduce in un errore 500?
Ciò è causato dalle attività pianificate residue del plugin.
Ad esempio, se un plugin genera un'attività pianificata giornaliera, WordPress continuerà a eseguirla anche dopo la disinstallazione del plugin. Tali attività pianificate sono inutili. Queste attività residue e superflue consumeranno continuamente risorse del server e finiranno per causare errori.
Peggio ancora, alcuni plugin generano automaticamente più attività pianificate ripetitive. Ad esempio, un'attività di "controllo giornaliero degli aggiornamenti" potrebbe essere creata cinque volte e ognuna verrebbe eseguita secondo una pianificazione, il che significa che il server dovrebbe elaborare cinque attività identiche contemporaneamente.
Avevo installato in precedenza un plugin SEO e, dopo averlo disinstallato, non ci ho fatto caso. Dopo circa due settimane, il mio sito web ha iniziato a presentare frequenti errori di timeout 504. Controllando i log del server, ho scoperto che il plugin aveva lasciato tre attività pianificate giornaliere, ciascuna con un tempo di esecuzione di 12 secondi. L'esecuzione simultanea di queste tre attività causava direttamente il timeout della risposta del server.
La cosa ancora più spaventosa è che queste attività residue e ricorrenti programmate sono invisibili nel backend di WordPress e non hai idea che siano in esecuzione di nascosto.
Tuttavia, esiste una soluzione: il plugin WP-Crontrol può gestirlo perfettamente. Si tratta dello strumento ufficiale di gestione delle attività Cron raccomandato da WordPress, che consente di visualizzare, modificare ed eliminare tutte le attività pianificate direttamente nel backend.
Secondo la descrizione del plugin WordPress, WP-Crontrol permette di "visualizzare tutti gli eventi cron pianificati, modificarli, eliminarli, metterli in pausa, riprenderli ed eseguirli immediatamente". In altre parole, consente di visualizzare tutte le attività pianificate ed eliminare quelle duplicate o non valide. È molto facile da usare e non richiede la scrittura di una sola riga di codice.
Dopo aver utilizzato questo plugin per la risoluzione dei problemi, ho eliminato 8 attività duplicate e 5 attività residue del plugin, e la velocità di risposta del sito web è migliorata immediatamente del 40%. L'errore 504 non si è più verificato.
Un avvertimento: quando eliminate delle attività, assicuratevi di controllare attentamente ed evitate di eliminare accidentalmente attività pianificate fondamentali di WordPress, come "wp_version_check" (controllo della versione). L'eliminazione accidentale potrebbe impedire il corretto aggiornamento del sito web.
Sebbene il plugin WP-Crontrol consenta di eliminare manualmente le attività duplicate o non valide, ciò richiede un intervento manuale, il che non è l'ideale...
Tuttavia, possiamo automatizzare questo processo utilizzando il codice WordPress. Per maggiori dettagli, consulta il tutorial qui sotto. ▼
Colpevole n. 3: Database ridondanti in WordPress
In WordPress, una delle cause dell'errore 500 è la ridondanza del database, in particolare la presenza di tabelle di dati di grandi dimensioni generate da alcuni plugin.
Utilizzando il plugin di ottimizzazione di WordPress, ho riscontrato che alcune tabelle di dati erano insolitamente grandi, in particolare la tabella di configurazione di Wordfence (wfconfig) .
Analisi del problema
- wfconfig presenta una grave ridondanza nelle tabelle dati.Era già stata ripulita in precedenza, ma è ricomparsa molto rapidamente.
- Problemi del motore di archiviazione predefinitoLa tabella di configurazione di Wordfence utilizza il motore InnoDB predefinito, che nel tempo accumulerà centinaia di MB di dati ridondanti.
- Impatto sulle prestazioniLe tabelle di dati possono facilmente raggiungere dimensioni di centinaia di MB, causando un calo della velocità di caricamento del sito web e persino generando errori 500.
Soluzione
Questo accade perché le tabelle dati configurate da Wordfence utilizzano il motore Inno predefinito. Col tempo, questo accumulerà rapidamente centinaia di megabyte di dati ridondanti, influenzando la velocità di caricamento del sito web.
Per istruzioni su come cambiare il motore di archiviazione predefinito di MariaDB in MyISAM utilizzando HestiaCP , fare riferimento al seguente tutorial:
Quarto colpevole: gli errori successivi agli aggiornamenti di plugin/temi sono come eseguire un "intervento chirurgico non ortodosso" sul sito web.
Molti proprietari di siti web hanno l'abitudine di cliccare immediatamente su "aggiorna" quando vedono le richieste di aggiornamento per plugin o temi, credendo che gli aggiornamenti risolveranno le vulnerabilità e miglioreranno le prestazioni.
Ma la verità è esattamente l'opposto: molti errori 5xx sono causati dall'aggiornamento di plugin o temi.
Ho già riscontrato questo problema in passato. Il mese scorso ho aggiornato il mio sito web con un popolare plugin per la creazione di pagine. Dopo aver cliccato su "aggiorna", la pagina è diventata vuota e, dopo averla ricaricata, è comparso un errore 500 Internal Server Error, rendendo impossibile l'accesso al backend.
In seguito ho scoperto che la nuova versione del plugin era incompatibile con la versione PHP del mio sito web. Dopo l'aggiornamento del plugin, il codice non funzionava correttamente, causando direttamente un errore sul server.
Gli errori successivi all'aggiornamento di plugin o temi sono una causa comune di errori 500 in WordPress, soprattutto quando la nuova versione del plugin presenta vulnerabilità del codice o conflitti con altri plugin o temi presenti sul sito web.
Un altro scenario possibile è che, dopo l'aggiornamento del tema, il codice personalizzato precedente venga sovrascritto, causando un disordine nel layout del sito web e il malfunzionamento di alcune funzionalità, con conseguenti errori 502 e 503.
Un mio amico, che gestisce un'attività di e-commerce, ha riscontrato un errore 502 sul suo sito web dopo aver aggiornato il plugin WooCommerce, il che gli ha impedito di effettuare ordini. Ha perso oltre 2000 yuan di vendite in sole 3 ore e gli ci è voluto un intero pomeriggio per risolvere il problema.
In realtà, la soluzione più diretta ed efficace a questa situazione è ripristinare una versione precedente che funzionava correttamente.
Molte persone non sanno come ripristinare una versione precedente del sito, ma non è necessario scaricare o caricare manualmente i file; il plugin WP Rollback semplifica il processo.
Secondo la descrizione di WordPress, il plugin WP Rollback permette di "ripristinare rapidamente e facilmente qualsiasi tema o plugin da wordpress.org a una versione precedente (o più recente) senza alcuna procedura manuale". In altre parole, consente di ripristinare plugin o temi a una versione precedente con un solo clic, senza operazioni complicate, rendendolo facile da usare anche per i principianti.
Dopo che l'ultimo aggiornamento del mio plugin non è andato a buon fine, ho utilizzato WP Rollback per ripristinare la versione precedente con un solo clic. Il sito web è tornato alla normalità in soli 30 secondi e non ho perso alcun dato.
Ecco un suggerimento: prima di aggiornare plugin o temi, esegui sempre un backup del tuo sito web. È consigliabile testarlo prima in un ambiente di prova per assicurarsi che non ci siano problemi, prima di aggiornarlo sul sito ufficiale, in modo da evitare errori.
In conclusione: padroneggia questi 3 punti per dire addio definitivamente agli errori 5xx del tuo sito web WordPress.
Quando si gestisce un sito web WordPress, gli errori 500, 502, 503 e 504 sono come degli "ostacoli", apparentemente problematici, ma la causa principale è in realtà piuttosto chiara: non si tratta di un malfunzionamento del server, né di un grave problema con il programma del sito web, bensì di tre dettagli trascurati: WP-CRON, le attività pianificate residue e gli aggiornamenti di plugin/temi.
Come proprietario di un sito web WordPress, dopo essere stato inizialmente sommerso dagli errori e ora essere in grado di individuare e risolvere rapidamente tutti gli errori 5xx, la lezione più importante che ho imparato è che la stabilità di un sito web non si basa sul "chiudere la stalla dopo che i buoi sono scappati", ma piuttosto sul principio che "prevenire è meglio che curare".
Molti proprietari di siti web pensano che questi piccoli dettagli siano irrilevanti e si pentono di non averli controllati in anticipo solo quando il sito non funziona correttamente, perde traffico e subisce una perdita di fatturato.
È fondamentale comprendere che per un sito web la "stabilità" rappresenta il principale vantaggio competitivo. Un singolo errore 5xx può causare la perdita del 10% dei visitatori, e la presenza di errori multipli può addirittura portare a un calo del posizionamento nei motori di ricerca, vanificando tutti gli sforzi SEO precedentemente compiuti.
Come dice il proverbio, "Un argine di mille miglia può essere sfondato da un formicaio". Gli errori 5xx dei siti web WordPress non compaiono mai all'improvviso, ma sono il risultato dell'accumulo di piccoli problemi: WP-CRON non disabilitato, attività pianificate residue e aggiornamenti eseguiti frettolosamente. Questi "formicai" apparentemente insignificanti finiranno per distruggere l'intero "argine" del sito web.
Un funzionamento veramente efficiente significa stroncare i problemi sul nascere.
- Disabilita il WP-CRON predefinito e sostituiscilo con un'attività pianificata basata sul server;
- Utilizza regolarmente WP-Crontrol per eliminare le attività programmate ripetitive e residue;
- Assicurati di eseguire un backup dei tuoi dati prima di aggiornare plugin o temi e ripristina immediatamente la versione precedente in caso di errori.
Queste tre operazioni non richiedono tecnologie complesse o sviluppatori costosi, e persino i principianti possono apprenderle facilmente, eppure possono proteggere il tuo sito web dagli errori 5xx e garantirne un funzionamento stabile.
Ogni caricamento stabile del tuo sito web e ogni visita che vi transita rappresentano una risorsa preziosa che accumuli nel tempo.
D'ora in poi, individua questi tre fattori critici ed esegui una manutenzione quotidiana per garantire che il tuo sito web WordPress non solo possa reggere il tuo duro lavoro, ma anche aumentare costantemente il traffico e i ricavi.
Se al momento riscontri errori 5xx, prova a seguire i passaggi descritti in questo articolo per la risoluzione dei problemi. Sono convinto che in breve tempo riuscirai a liberarti di questi inconvenienti, a rendere il tuo sito web stabile e a raggiungere una crescita a lungo termine.
Speriamo che l'articolo "I 4 principali responsabili degli errori 500, 502, 503 e 504 sui siti web WordPress", condiviso sul blog di Chen Weiliang ( https://www.chenweiliang.com/ ), possa esservi utile.
Sentitevi liberi di condividere il link di questo articolo: https://www.chenweiliang.com/cwl-33968.html