Erreur 524 Cloudflare : A timeout occurred, la comprendre et corriger

Ton site affiche “Error 524: A timeout occurred” ?

Un import de catalogue produit qui tourne depuis une minute et demie, et soudain, à la place de la page attendue : un écran orange Cloudflare avec “524 : A timeout occurred”. Rafraîchir ne change rien. La page reste bloquée, ou finit par tomber exactement au même endroit.

Bonne nouvelle : ce n’est pas une panne générale de ton hébergeur, et ce n’est pas non plus la même chose qu’une erreur 504 ou 502 classiques. Le 524 est une erreur spécifique à Cloudflare, qui a une cause précise et un mécanisme bien identifié. Une fois qu’on comprend ce mécanisme, la correction devient beaucoup plus simple à cibler — et ça se répare, sans forcément tout casser.

524, 502, 504 : ce n’est pas la même erreur

Un 502 Bad Gateway signifie que le serveur en amont (proxy, load balancer) a reçu une réponse invalide de l’origine. Un 504 Gateway Timeout signifie qu’un serveur intermédiaire classique a attendu une réponse et a abandonné. Le 524, lui, est propre à Cloudflare : Cloudflare a bien transmis la requête à ton serveur d’origine, mais celui-ci n’a rien renvoyé dans le délai imparti. Sur les plans Free et Pro, ce délai est fixé à environ 100 secondes, et il n’est pas configurable depuis ton compte Cloudflare. Passé ce délai, Cloudflare coupe la connexion et affiche 524 — même si ton serveur, lui, était encore en train de travailler.

C’est la nuance essentielle : le 524 dit “ton origine met trop de temps à répondre”, pas “ton origine est en panne”. Pour ça, voir plutôt les erreurs 520, 521 ou 523, qui décrivent des situations différentes (origine injoignable, port fermé, réponse vide).

Pourquoi ça arrive : ce qui fait dépasser les 100 secondes

• Un script PHP lent : génération de PDF, traitement d’image lourd, appel à une API tierce qui répond mal, un plugin qui boucle.
• Une requête SQL lourde : table non indexée, base de données surchargée, requête WHERE LIKE %...% sur des milliers de lignes.
• Une tâche longue exécutée en direct dans le navigateur : import ou export de produits WooCommerce, sauvegarde complète, régénération de miniatures en masse, appel à une IA (génération de texte, de résumé, d’image) qui prend plusieurs dizaines de secondes.
• Un serveur d’origine saturé : CPU ou RAM au maximum, trop de processus PHP simultanés, base de données qui rame déjà sur d’autres requêtes.
• Un pare-feu ou une règle de sécurité qui ralentit (sans bloquer franchement) les IP de Cloudflare, ajoutant de la latence à chaque requête.
• Un problème de keep-alive entre Cloudflare et l’origine : la connexion se coupe et se rétablit sans cesse, ce qui allonge artificiellement le temps de réponse perçu.

1. Diagnostiquer : Cloudflare ou serveur ?

Avant de toucher à quoi que ce soit, isole la cause. Désactive temporairement le proxy Cloudflare (passage en “DNS only”, nuage gris au lieu du nuage orange dans le DNS) et recharge la même action. Si l’erreur disparaît et que le serveur répond directement (même lentement), le problème est côté origine, pas côté Cloudflare. Si tu veux revoir comment manipuler ces réglages proprement, notre guide pour configurer ses DNS sur Cloudflare détaille la marche à suivre.

En parallèle, consulte les logs serveur (accès et erreurs PHP) au moment exact du 524 : c’est souvent là que se trouve le vrai coupable — un plugin, une requête, un cron.

2. Optimiser le script ou la requête qui traîne

Dans la majorité des cas, un 524 récurrent pointe vers une action précise : un export CSV, une synchronisation, une recherche sans index. Utilise Query Monitor pour repérer les requêtes lentes et le plugin responsable — notre article sur trouver le plugin qui ralentit WordPress explique la méthode pas à pas. Si la lenteur vient de la base, un nettoyage avec WP-Optimize ou la mise en place d’un cache objet Redis peut suffire à faire tomber le temps de réponse sous la barre critique.

3. Sortir les tâches longues du parcours HTTP

C’est le levier le plus efficace, et souvent le plus durable : ne fais jamais dépendre une tâche longue (import massif, sauvegarde, génération d’un gros rapport, appel IA) d’une seule requête HTTP synchrone. Découpe-la en tâches plus petites traitées en arrière-plan via WP-Cron déclenché côté serveur (et non par visite), une file d’attente (queue) ou un traitement asynchrone qui renvoie immédiatement “en cours” à l’utilisateur puis notifie la fin du traitement. Le navigateur (et Cloudflare) n’attend alors plus une réponse unique de 3 minutes, mais plusieurs réponses courtes.

4. Ajuster les timeouts serveur — sans se tromper sur ce qui est réglable

Ici, il faut être honnête sur ce qui dépend de toi et ce qui ne dépend pas de toi.

Ce qui dépend de ton serveur :

• max_execution_time (PHP) : durée maximale d’exécution d’un script PHP. Trop bas, un script légitime est coupé en plein calcul. Se règle dans wp-config.php, le php.ini ou via le panel de ton hébergeur. Valeur de départ raisonnable : 60 à 90 secondes pour un site classique.
• memory_limit (PHP) : mémoire allouée à PHP. Insuffisante, elle produit une “erreur critique” ou un écran blanc plutôt qu’un vrai timeout, mais elle aggrave souvent la lenteur générale. 256 Mo est un bon point de départ pour WordPress.
• Timeout Nginx/Apache (proxy_read_timeout, fastcgi_read_timeout, Timeout) : délai que le serveur web accorde avant de couper la connexion avec PHP-FPM. Doit être cohérent avec max_execution_time.

Ce qui ne dépend pas de toi : la limite d’environ 100 secondes entre Cloudflare et ton origine, sur les plans Free et Pro, est fixe. Il n’existe pas de réglage dans le dashboard Cloudflare pour l’augmenter à ce niveau d’abonnement. Corriger le script ou déplacer la tâche en arrière-plan est donc la vraie solution — pas espérer un paramètre caché. Pour aller plus loin sur ces réglages, notre guide sur les directives PHP WordPress détaille chaque limite et où la modifier.

5. Sortir l’endpoint lent du proxy Cloudflare

Pour un endpoint précis et connu pour être long (un webhook d’import, une API interne), une option pragmatique : le faire passer en “DNS only” (nuage gris) via un sous-domaine dédié non proxifié. La requête va alors directement à ton serveur sans passer par la limite de 100 secondes de Cloudflare. Attention : cela retire aussi la protection DDoS et le cache Cloudflare sur ce sous-domaine précis — à réserver aux endpoints techniques, pas au site public.

6. Vérifier le pare-feu et whitelister les IP Cloudflare

Un pare-feu applicatif (WAF) ou une règle fail2ban trop agressive peut ralentir — sans totalement bloquer — les requêtes provenant des plages d’IP Cloudflare, ajoutant une latence qui pousse la réponse au-delà des 100 secondes. Vérifie que les plages IP officielles de Cloudflare sont bien autorisées sans limitation de débit sur ton serveur.

7. Contrôler la santé générale de l’origine

Un serveur au bord de la saturation répond lentement à tout, pas seulement au script fautif. Vérifie la charge CPU, la RAM disponible, le nombre de processus PHP-FPM actifs. Si le disque est presque plein, ça peut aussi ralentir les écritures — voir notre article sur l’erreur 507, disque plein. Pour un audit plus large de la lenteur du site, notre diagnostic complet, tous CMS confondus reste un bon point de départ.

Tableau récap

FAQ

Quand passer la main à un pro

Si le 524 revient régulièrement malgré l’optimisation du script identifié, ou si tu ne parviens pas à isoler la cause exacte entre serveur, base de données et pare-feu, c’est le signe qu’il faut un œil technique qui audite l’infrastructure dans son ensemble — pas juste rajouter un paramètre au hasard. Une maintenance régulière évite justement ce genre de blocage : surveiller les temps de réponse avant qu’ils ne franchissent la limite, c’est bien plus simple que de courir après un timeout une fois le client bloqué devant un écran orange.