L’erreur 524 est un code Cloudflare. La connexion TCP vers l’origine a réussi, Cloudflare a transmis la requête HTTP, et l’origine n’a pas renvoyé de réponse avant le délai de lecture. Ce délai est de 100 secondes par défaut. Le visiteur voit « A timeout occurred ». Dans le journal d’origine, la même requête existe : elle a démarré, et elle se termine parfois après coup par un 200 que plus personne n’attend.
Ce n’est pas un 522. Au 522, la requête HTTP n’est jamais envoyée. Ce n’est pas non plus un 521, où la connexion est refusée.
Causes propres au 524
- Un script PHP ou une requête SQL qui dépasse 100 secondes : export de commandes, génération de PDF, rapport construit dans la requête du navigateur.
- Un verrou de base. La page attend une écriture tenue par une autre commande, et le worker reste occupé jusqu’après le délai Cloudflare.
- Un appel à un service externe (ERP, paiement, transporteur) sans délai propre, effectué au milieu de la page. L’origine garde la connexion Cloudflare ouverte pendant cette attente.
- Une file PHP-FPM saturée : la requête est acceptée au niveau TCP, donc ce n’est pas un 522, puis elle attend un worker libre plus de 100 secondes.
- Un traitement d’image ou d’import lancé quand l’administrateur clique, au lieu d’une tâche de fond.
Le serveur web d’origine fonctionne. Il est simplement trop lent pour la limite du proxy.
Comparer les deux horloges
- Notez l’heure du 524 vue par le visiteur.
- Cherchez la même URL dans le journal d’accès de l’origine. Si la ligne n’existe pas, vous n’êtes pas sur un 524 : revoyez un 521 ou un 522.
- Si la ligne existe et que la durée dépasse 100 secondes, ou que le code 200 est écrit après l’heure du 524, le diagnostic est confirmé.
- Au même moment, listez les requêtes SQL longues et les workers PHP occupés. Le verrou ou l’export y figure.
- Rejouez l’URL courte, celle qui ne fait pas l’export. Elle doit rester rapide. Seule l’URL lourde doit approcher le délai.
- Contrôlez l’URL publique avec un test d’URL. Un 524 intermittent au moment des exports se voit mal dans un navigateur déjà connecté à l’administration.
Une coupure voulue du site ne se fait pas en laissant Cloudflare couper à 100 secondes. Elle s’annonce avec un 503 et un en-tête Retry-After.
Sortir le travail long de la requête
| Travail | Où le placer |
|---|---|
| Export, PDF, rapport | File d’attente. La requête HTTP ne fait qu’enregistrer la demande et répond tout de suite |
| Requête SQL longue | Index ou découpage. Viser une durée très inférieure à 100 secondes |
| Verrou sur les commandes | Raccourcir la transaction. Éviter de tenir un lock le temps d’un appel externe |
| API tierce | Délai de quelques secondes, puis échec contrôlé ou reprise plus tard |
| File de workers | Donner de la place au pool, ou refuser tôt avec un code explicite plutôt que d’attendre 100 secondes |
Relever le délai Cloudflare n’est possible que sur certains contrats, et la page reste inutilisable pendant tout ce temps. Ce n’est pas le correctif d’un export.
Ce qu’il ne faut pas faire
Ne redémarrez pas Cloudflare. Ne traitez pas le 524 comme un 522 en ouvrant le pare-feu : la connexion a déjà lieu. N’allongez pas max_execution_time sans mesurer : PHP continuera après que le visiteur sera parti, et les workers s’empileront. Ne concluez pas que « le site est en ligne » parce qu’une URL légère répond 200.
Après la modification, l’URL qui expirait doit répondre bien avant 100 secondes, y compris depuis l’extérieur. C’est le même critère que pour tester si un site répond vraiment, appliqué à la page qui bloquait le proxy.