Cloudflare e WooCommerce: errori 429 e un caso reale
- Web developing
- 28 ottobre 2026
Indice dei contenuti
Un negozio WooCommerce diventa saltuariamente irraggiungibile e restituisce HTTP 429, Too Many Requests. Il comportamento cambia quando il provider attiva o disattiva la propria protezione DDoS. Davanti all’hosting c’è Cloudflare, ma nessuno dell’attuale gestione tecnica può accedere al suo account.
Da dove iniziare? Dal ricostruire le richieste e le regole che attraversano. La presenza di Cloudflare non dimostra che sia la causa dei blocchi. Nel caso descritto, l’indagine ha individuato anomalie e possibili interazioni fra componenti, senza stabilire il meccanismo responsabile di tutti i 429.
Il problema di gestione era invece concreto: un livello importante dell’infrastruttura era fuori dal controllo di chi doveva diagnosticare il guasto.
Errori 429 WordPress: il caso di un e-commerce intermittente
Il caso riguarda un sito WordPress con WooCommerce, circa 5.000 prodotti e hosting presso un provider italiano. Da mesi si verificavano errori intermittenti. Con la protezione DDoS dell’hosting attiva, il sito diventava saltuariamente inaccessibile; disattivandola, tornava generalmente raggiungibile.
Nell’analisi di circa due giorni risultavano oltre 100.000 richieste HTTP e decine di migliaia di risposte 429. Comparivano richieste riconducibili a crawler SEO, bot, browser automatizzati e precaricamento delle pagine. Anche alcune comunicazioni verso endpoint di pagamento ricevevano 429.
Il dominio usava nameserver e proxy Cloudflare, configurati da un precedente fornitore. Nei log prevalevano gli IP del proxy. Il sottodominio FTP risolveva anch’esso verso Cloudflare, mentre le sitemap passavano apparentemente attraverso Workers e archiviazione KV. Un cron giornaliero di aggiornamento registrava ripetuti timeout di 60 secondi. Erano presenti anche eventi cron residui di plugin inattivi.
Nei test effettuati direttamente sull’origine, senza passare dal proxy, il server rispondeva regolarmente, generalmente in meno di un secondo. Questo confronto circoscrive l’indagine, ma non dimostra né una causa Cloudflare né prestazioni adeguate sotto ogni carico: cambia il percorso e possono cambiare cache, protezioni e condizioni del test.
Come funziona il reverse proxy Cloudflare davanti a WooCommerce
I nameserver indicano quali server DNS rispondono per il dominio. Usare nameserver Cloudflare non significa automaticamente far transitare ogni servizio attraverso il proxy: dipende dalla configurazione dei singoli record.
Per un hostname web con proxy attivo, il percorso tipico è:
Browser → Cloudflare → protezioni dell’hosting → server web → WordPress e WooCommerce.
Cloudflare riceve la richiesta come reverse proxy. Può applicare controlli di sicurezza, mitigazione DDoS e cache, secondo piano e configurazione. Se dispone di una risposta utilizzabile in cache, può servirla senza interrogare l’origine; altrimenti inoltra la richiesta all’hosting.
Un negozio richiede attenzione alle risposte personalizzate: carrello, checkout, sessioni e account non devono essere condivisi impropriamente fra utenti. Cache e protezione DDoS svolgono compiti diversi: la prima può ridurre il lavoro dell’origine, la seconda filtra traffico secondo criteri di sicurezza.
L’origine vede come interlocutore di rete Cloudflare. L’IP del visitatore può essere trasmesso tramite header dedicati, come CF-Connecting-IP, e recuperato con una configurazione corretta del server.
Cloudflare e protezione DDoS WordPress: come interpretare i 429
Un 429 indica l’applicazione di una limitazione alle richieste. Può provenire da regole Cloudflare, infrastruttura hosting, plugin o applicazione. Il solo codice HTTP non identifica chi lo abbia generato.
Una possibile interazione riguarda i limiti per IP: numerosi visitatori raggiungono l’origine tramite gli indirizzi del proxy. Se una protezione li considera un’unica sorgente, può sommare richieste indipendenti e bloccare traffico legittimo. La documentazione Cloudflare sugli IP del proxy descrive questo rischio generale.
Vedere IP Cloudflare negli access log non dimostra però che il sistema DDoS del provider usi quegli stessi indirizzi per decidere i blocchi. Registrazione del traffico e applicazione delle protezioni possono avvenire in livelli diversi. Occorre chiedere al provider quale componente intervenga e quali criteri utilizzi.
Anche soglie troppo basse, finestre temporali inadatte e regole firewall poco selettive possono creare falsi positivi. Il ripristino dell’IP originale va concordato con l’hosting: gli header devono essere considerati attendibili soltanto quando provengono da proxy autorizzati. Non basta fidarsi indiscriminatamente di un valore inviato nella richiesta.
Chi cerca informazioni su “Cloudflare Aruba” o su altri abbinamenti fra CDN e hosting deve quindi verificare il servizio specifico e le sue protezioni. Il provider di questo caso resta anonimo: non viene attribuito ad Aruba né ad altri operatori.
Cloudflare FTP: un record DNS può impedire l’accesso
L’anomalia FTP era distinta dai 429: il sottodominio utilizzato dal client puntava agli IP Cloudflare. Il normale proxy HTTP/HTTPS non trasporta il protocollo FTP standard. Esistono servizi specifici per altri protocolli, ma non si attivano semplicemente abilitando il proxy web.
La differenza operativa è questa:
- Proxied: il DNS restituisce indirizzi Cloudflare e il traffico supportato attraversa il proxy.
- DNS only: il DNS restituisce la destinazione configurata e il client la raggiunge direttamente.
Una verifica con dig o nslookup, confrontata con l’hostname fornito dall’hosting, aiuta a individuare la destinazione errata. La correzione ordinaria consiste nel configurare un record FTP dedicato, DNS only, verso il server corretto, oppure usare l’hostname di servizio del provider.
Non serve cambiare il proxy del sito web. Vanno controllati anche eventuali CNAME, le impostazioni FTP passivo e il protocollo richiesto dall’hosting. Senza accesso alla zona DNS, modificare il record richiede prima il recupero del controllo amministrativo. Un record diretto può inoltre rendere pubblico l’IP dell’origine, aspetto da valutare nella configurazione di sicurezza.
Cloudflare Workers e sitemap WordPress: vantaggi e dipendenze
Un Worker associato agli URL delle sitemap può eseguire codice prima dell’origine e restituire XML memorizzato in Workers KV, un archivio chiave-valore distribuito. Questo può ridurre le richieste a WordPress e separare la distribuzione delle sitemap dalla loro generazione.
Nel caso analizzato, l’uso di Workers e KV era una ricostruzione apparente, da confermare accedendo alla configurazione. Il cron di aggiornamento terminava ripetutamente con timeout di 60 secondi: ciò documentava il fallimento delle chiamate, senza identificarne da solo il punto di blocco.
Una personalizzazione di questo tipo richiede controlli su:
- aggiornamento effettivo dell’XML quando cambia il catalogo;
- scadenza, invalidazione e propagazione dei dati in KV;
- gestione degli errori e disponibilità di una risposta alternativa;
- accessibilità delle sitemap ai crawler, senza challenge incompatibili;
- documentazione dello script e responsabilità della manutenzione.
Yoast SEO genera e aggiorna già automaticamente le proprie sitemap. Un ulteriore sistema deve rispondere a un’esigenza concreta e verificata. Altrimenti introduce un’altra copia dei dati, un processo di sincronizzazione e un punto da controllare quando le sitemap sembrano ferme.
Quando il problema dipende da bot, plugin o hosting
L’analisi deve comprendere ciò che genera richieste e ciò che le limita. Bot e crawler SEO aggressivi possono concentrare accessi in pochi minuti. Un plugin di preload può visitare molte pagine per riscaldare la cache; sincronizzazioni marketplace possono aggiungere chiamate API e aggiornamenti frequenti.
WP-Cron esegue attività pianificate; Action Scheduler gestisce code di lavoro usate da WooCommerce e altre estensioni. Questi strumenti non sono anomalie in sé. Vanno cercati duplicazioni, arretrati, errori e processi che ripartono continuamente. Un evento residuo di un plugin disattivato non prova che il codice del plugin stia ancora lavorando: occorre verificare se esista una funzione collegata ed eseguita.
Anche chiamate AJAX frequenti, webhook e tentativi ripetuti dopo un errore possono contribuire al carico. Per i pagamenti bisogna distinguere notifiche in ingresso, richieste in uscita e ritorno del browser: percorrono strade diverse. Un 429 restituito da un servizio esterno richiede verifiche diverse da un 429 ricevuto sul negozio.
Chi riceve un 429 non è necessariamente chi ha generato il traffico elevato. Una notifica di pagamento può essere bloccata da un limite aggregato già raggiunto da altre richieste. L’User-Agent, inoltre, è dichiarato dal client e può essere imitato: aiuta a classificare il traffico, non certifica l’identità del mittente.
Restano da valutare risorse hosting, processi PHP, database e configurazione delle protezioni. Il totale delle richieste in due giorni non descrive da solo picchi, concorrenza e costo delle singole operazioni.
Sintomi WooCommerce, possibili cause e verifiche
Le ipotesi della tabella sono piste diagnostiche, non conclusioni sul caso.
| Sintomo | Possibile causa | Verifica consigliata |
|---|---|---|
| 429 intermittenti | Limiti su hosting, proxy o applicazione | Correlare log e regole attivate |
| IP Cloudflare nei log | IP visitatore non ripristinato nel logging | Controllare header e configurazione server |
| Pagamenti con 429 | Endpoint limitato o servizio remoto | Ricostruire direzione e risposta della chiamata |
| FTP irraggiungibile | Hostname diretto al proxy web | Controllare DNS e destinazione FTP |
| Sitemap non aggiornate | Cache o aggiornamento personalizzato fallito | Confrontare XML pubblico e origine |
| Cron in timeout | Richiesta bloccata, rete o applicazione lenta | Analizzare errori e destinazione del job |
Come diagnosticare WooCommerce con Cloudflare, un passo alla volta
La procedura deve consentire di attribuire gli effetti a modifiche precise.
- Raccogliere i log HTTP. Allineare fusi orari, intervalli, codici e tempi di risposta, evitando di esportare dati personali o segreti.
- Raggruppare endpoint e User-Agent. Separare catalogo, AJAX, sitemap, API e pagamenti; cercare picchi per minuto, non soltanto totali.
- Verificare gli IP originali. Confrontare peer di rete, header attendibili e criteri utilizzati dal provider.
- Controllare Cloudflare. Esaminare eventi di sicurezza, rate limiting, cache e Worker. Senza accesso, registrare esplicitamente questo limite dell’indagine. Un Ray ID può aiutare la correlazione, ma la sua presenza non prova l’origine del 429.
- Analizzare cron e plugin. Controllare hook, frequenza, esiti e azioni fallite o arretrate in WooCommerce → Stato → Azioni programmate.
- Seguire pagamenti e sincronizzazioni. Correlare log del negozio e servizi esterni, verificando notifiche, risposte ed eventuali retry.
- Confrontare proxy e origine con test controllati. Conservare hostname, verifica HTTPS, percorso e metodo; documentare differenze di cache e protezioni. Evitare cambi DNS pubblici per una semplice prova.
- Preparare uno staging indipendente. Proteggerlo dall’indicizzazione e isolare pagamenti, email e sincronizzazioni reali, usando credenziali di test.
- Cambiare un componente alla volta. Annotare modifica, risultato e procedura di ripristino prima del confronto successivo.
Quando conviene mantenere Cloudflare o semplificare l’architettura
Cloudflare può offrire benefici concreti di distribuzione e sicurezza. Non è però indispensabile per ogni sito. Conviene valutare una semplificazione quando mancano gli accessi, il precedente fornitore non è reperibile, le regole sono sconosciute e le personalizzazioni non hanno una manutenzione sostenibile.
Prima di rimuoverlo, occorre misurare se l’origine gestisca il carico previsto e se le protezioni dell’hosting siano sufficienti. Una risposta rapida in un test isolato non basta. Recuperare l’account o ricostruire una configurazione documentata può essere preferibile al distacco.
Disabilitare il proxy e cambiare nameserver sono interventi diversi. Un’uscita completa richiede l’inventario di DNS, record email, DNSSEC, HTTPS, certificati, redirect, cache, sicurezza e integrazioni dipendenti da Workers. Un certificato pensato soltanto per il collegamento Cloudflare-origine potrebbe non essere attendibile dai browser in accesso diretto.
La decisione va presa sui benefici verificati e sulla possibilità di governare il sistema. In questo caso non è stata dimostrata una responsabilità generale di Cloudflare nei 429; è emersa la difficoltà operativa di dover analizzare un’infrastruttura senza controllarne tutti i livelli.
Se il tuo negozio presenta blocchi intermittenti, posso analizzare il percorso delle richieste e valutare gli interventi di assistenza su WooCommerce e altri e-commerce necessari, partendo dai log e dalle configurazioni disponibili.
FAQ su Cloudflare, WooCommerce ed errori 429
Come distinguere un 429 Cloudflare da un 429 dell’hosting?
Correlando risposta, log dell’origine ed eventi di sicurezza. Header e pagina di errore forniscono indizi, ma il passaggio attraverso Cloudflare non identifica da solo il componente che ha applicato il limite.
Un errore 429 dimostra che il negozio è sotto attacco?
No. Può dipendere anche da automazioni legittime, soglie restrittive o richieste aggregate. Servono dati su frequenza, destinazioni e regole applicate.
Devo disattivare la protezione DDoS per sbloccare i pagamenti?
Non come soluzione permanente senza diagnosi. Occorre identificare il flusso interessato e valutare una regola mirata, conservando l’autenticazione delle notifiche e le altre protezioni.
Come verificare che il problema sia risolto?
Ripetendo i test nelle condizioni documentate e monitorando i flussi reali interessati: pagamenti, cron, sitemap e navigazione. Una singola apertura riuscita della home non verifica l’intero negozio.
Quali accessi chiedere quando cambia il fornitore del sito?
Controllo amministrativo di dominio, DNS, hosting e Cloudflare, oltre a inventario di Worker, regole e integrazioni. Il proprietario deve poter autorizzare e revocare gli accessi tecnici.
