Sito WordPress che si blocca ogni 5-6 ore: la causa nascosta è php-fpm su OpenLiteSpeed

WordPress si blocca con OpenLiteSpeed, Redis, php-fpm e Cloudflare, funziona perfettamente per alcune ore, poi si blocca mostrando l’errore Cloudflare 524 (A timeout occurred). Riavvii il server e tutto torna a funzionare — salvo bloccarsi di nuovo qualche ora dopo.

I sintomi tipici sono:

• Errore 524 di Cloudflare (Host Error)
• Log di LiteSpeed con No request delivery notification has been received from LSAPI application, possible dead lock
• CPU bassa, RAM apparentemente normale
• pkill -f lsphp risolve temporaneamente ma il problema si ripresenta
• Solo il riavvio completo del server risolve davvero

La causa: php-fpm che si accumula silenziosamente

Se usi aaPanel + OpenLiteSpeed, quando installi PHP dal pannello, aaPanel avvia automaticamente php-fpm oltre al modulo lsphp nativo di OpenLiteSpeed.

Il problema è che OpenLiteSpeed non usa php-fpm — usa lsphp (LSAPI). Quindi php-fpm gira inutilmente in background accumulando processi sleeping nel corso delle ore fino a esaurire le risorse di sistema.

Per verificarlo:

ps aux | grep php-fpm | wc -l

Se il numero è alto (centinaia o quasi 1000), hai trovato il problema.

La diagnosi completa

1. Controlla i processi php-fpm

ps aux | grep php-fpm | wc -l

2. Verifica quali servizi php-fpm sono attivi

systemctl list-units | grep php-fpm

3. Controlla la RAM usata

free -h

4. Verifica i processi lsphp (questi sono normali su OpenLiteSpeed)

ps aux | grep lsphp | wc -l

5. Controlla i log di OpenLiteSpeed

tail -20 /usr/local/lsws/logs/error.log

La soluzione definitiva

Ferma tutti i processi php-fpm

pkill -9 -f php-fpm

Disabilita i servizi php-fpm all’avvio

systemctl disable php-fpm-81.service 2>/dev/null
systemctl disable php-fpm-82.service 2>/dev/null
systemctl disable php-fpm-83.service 2>/dev/null
systemctl disable php-fpm-84.service 2>/dev/null

Verifica che siano fermi

ps aux | grep php-fpm | wc -l
# Deve restituire 1 (solo il processo grep stesso)

Controlla che il sito funzioni

curl -I https://tuodominio.com 2>/dev/null | head -2
# Deve restituire HTTP/2 200

Altre ottimizzazioni consigliate

Correggi max_allowed_packet in MariaDB

Un valore errato può causare crash periodici del database:

grep "max_allowed_packet" /etc/my.cnf

Se trovi valori assurdi come 100G, correggili:

sed -i 's/max_allowed_packet = 100G/max_allowed_packet = 64M/' /etc/my.cnf
systemctl restart mysql

Imposta un limite di memoria per Redis

redis-cli -a 'tuapassword' config set maxmemory 512mb
redis-cli -a 'tuapassword' config set maxmemory-policy allkeys-lru

Riduci max_execution_time di PHP

In aaPanel → PHP → Configurazione, imposta:

• max_execution_time = 30 (invece di 600)
• default_socket_timeout = 15

Questo evita che richieste bloccate tengano occupato PHP per 10 minuti.

Disabilita WP-Cron interno e usa il cron di sistema

In wp-config.php:

define('DISABLE_WP_CRON', true);

Poi aggiungi un cron di sistema:

crontab -e
# Aggiungi:
*/5 * * * * wget -q -O - https://tuodominio.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1

Attiva TCP SYN cookies contro flood

echo "net.ipv4.tcp_syncookies=1" >> /etc/sysctl.conf
sysctl -p

Script di monitoraggio

Per tenere sotto controllo la situazione, lancia questo script in background:

nohup bash -c '
while true; do
  COUNT=$(ps aux | grep lsphp | wc -l)
  FPM=$(ps aux | grep php-fpm | wc -l)
  MEM=$(free -m | awk "NR==2{print \$3}")
  echo "$(date) - PHP:$COUNT FPM:$FPM MEM:${MEM}MB"
  sleep 30
done
' > /tmp/monitor.log 2>&1 &

Controlla il log con:

cat /tmp/monitor.log | tail -10

Se FPM inizia a salire, esegui subito pkill -9 -f php-fpm.

Perché succede questo?

aaPanel è progettato per supportare più web server (Nginx, Apache, OpenLiteSpeed). Quando installi PHP, avvia php-fpm per compatibilità con tutti i server. Ma OpenLiteSpeed usa un sistema diverso (LSAPI/lsphp) e non ha bisogno di php-fpm.

Il risultato è che php-fpm gira inutilmente, accumulando centinaia di processi sleeping nel corso delle ore fino a esaurire i file descriptor e la memoria disponibile, causando il blocco di OpenLiteSpeed e di conseguenza del sito.

Regole Cloudflare consigliate

Se usi Cloudflare con WooCommerce e WOOF (filtri prodotti), aggiungi questa regola di sicurezza:

((http.request.uri.query contains "filter_") or 
(http.request.uri.query contains "query_type_")) and 
not (cf.client.bot)

Action: Managed Challenge

Questo blocca i bot malevoli che martellano i filtri WooCommerce, escludendo automaticamente crawler legittimi come Google, Facebook ecc.

Blocca anche xmlrpc.php se non lo usi:

(http.request.uri.path eq "/xmlrpc.php")

Action: Block

Articolo basato su un caso reale di troubleshooting su fashionstyledesigner.com — un sito WooCommerce su aaPanel + OpenLiteSpeed + Cloudflare.

• Plugin o Codice: Disattivare API REST in WordPress
• Reindirizzamento Post e Pagine con Yoast SEO
• Pulizia Database WordPress: Una Guida Completa con Advanced Database Cleaner
• Tornare alla Vecchia Versione di WordPress: Guida Completa al Downgrade WordPress
• Cloudflare Internal Server Error: tutte le soluzioni per risolvere il problema
• Backup Sito Web WordPress: La Guida Completa con UpdraftPlus Plugin WordPress