Caso di studio: Cloudflare 403 vs downtime reale

Un team di supporto ha segnalato «sito down» dopo aver ricevuto risposte 403 dai controlli di monitoraggio. Gli utenti finali potevano ancora caricare la homepage nei browser. Questo caso spiega come risolvere quella contraddizione.

Sintomi osservati

I controlli automatici restituivano HTTP 403.
Gli utenti browser vedevano occasionalmente pagine challenge, poi il successo.
Nessuna evidenza di crash del server di origine o errori 5xx.

Sequenza diagnostica utilizzata

Esegui l'URL in Verifica siti web e registra testo di stato e note.
Verifica se la risposta include pattern di protezione bot (indizi di challenge Cloudflare).
Prova dal browser e confronta con il comportamento del controllo lato server.
Esamina le soglie delle policy WAF/rate-limit nelle impostazioni edge.

Causa principale

Il sito era online, ma le impostazioni WAF trattavano il traffico non browser come sospetto. I controlli sintetici venivano bloccati all'edge prima di raggiungere il contenuto completo della pagina.

Correzione e validazione

Regole bot/WAF adattate al comportamento di monitoraggio previsto.
Impostazioni rate-limit troppo aggressive ridotte per gli endpoint diagnostici.
Ritest: il checker è passato da stato blocked/limited a risposte online stabili.

Conclusioni

403 non equivale sempre a downtime.
Tipi di richiesta diversi possono ricevere esiti diversi.
Abbina lo stato del checker ai log di sicurezza edge prima di dichiarare un disservizio.

Letture correlate: guida alla risoluzione errori 5xx e metodologia del checker.