504 Gateway Timeout derrière Cloudflare

Ce que signifie cette erreur et comment la reconnaître

• La page d’erreur affiche la marque Cloudflare et inclut généralement un Cloudflare Ray ID au lieu de la mise en page d’erreur habituelle de votre site.
• Un rapport, un export, un téléversement, un appel API ou une action groupée spécifique échoue alors que les pages ordinaires continuent de se charger.
• La même requête peut répondre lentement, dépasser le délai d’attente ou échouer lorsqu’elle est testée directement sur l’origine.
• Le problème peut être intermittent lorsque l’origine est surchargée, ou constant lorsque Cloudflare ne peut pas atteindre l’origine configurée.
• Les journaux de l’application ou du serveur web peuvent indiquer que la requête a commencé mais ne s’est pas terminée avant le délai d’attente côté client.

Causes principales, classées par probabilité

1. L’origine met trop de temps à répondre. Une requête de base de données, un rapport, un export, un téléversement ou une autre opération synchrone peut dépasser le délai pendant lequel Cloudflare attendra une réponse.
2. La requête atteint une limite de délai d’attente Cloudflare. La limite applicable dépend de la requête, de la configuration du compte et du plan. Augmenter le délai d’attente du serveur web d’origine ne prolonge pas la limite du edge Cloudflare.
3. Cloudflare ne peut pas atteindre l’origine de manière fiable. Des règles de pare-feu, des défaillances réseau, une cible DNS incorrecte, un service indisponible ou la saturation des connexions peuvent empêcher une réponse à temps.
4. Le endpoint ne convient pas au proxy. Une API interne ou spécialisée peut nécessiter une configuration DNS-only soigneusement contrôlée plutôt que de passer par le proxy Cloudflare.
5. Les paramètres SSL/TLS ne correspondent pas à l’origine. Vérifiez le certificat de l’origine, le hostname et la validité du certificat lors de l’utilisation de Full (strict). Les problèmes de certificat peuvent produire d’autres erreurs Cloudflare liées à l’origine ; confirmez donc la réponse exacte au lieu de supposer que tout problème SSL est un 504.

Comment corriger le problème

1. Confirmez que Cloudflare a produit la réponse

Vérifiez la présence de la marque Cloudflare et d’un Ray ID sur la page d’erreur, puis comparez-la à la page d’erreur habituelle de votre application. Si Cloudflare a généré la page, modifier uniquement la gestion des erreurs de l’application ne résoudra pas le problème entre le edge et l’origine.

2. Déterminez la portée et le moment du problème

Notez le hostname et le chemin exacts, la méthode HTTP, l’action de l’utilisateur, l’heure approximative de début et indiquez si le problème touche tous les visiteurs ou une seule opération. Vérifiez si les pages ordinaires fonctionnent alors qu’une requête de rapport, d’export ou d’API échoue.

Un échec limité à une opération coûteuse pointe davantage vers une durée d’exécution excessive du backend. Des échecs touchant les requêtes ordinaires et rapides indiquent davantage un problème d’accessibilité de l’origine, de capacité ou de configuration.

3. Testez l’origine indépendamment

Utilisez un test direct autorisé de l’origine qui conserve le hostname, l’en-tête Host, le comportement TLS, l’authentification et le routage requis. Un hostname de test temporaire en DNS-only peut être utile s’il est configuré de manière sûre et si l’accès à l’origine reste correctement restreint.

• L’origine est également lente ou échoue : examinez les journaux de l’application, les requêtes de base de données, la capacité des workers, les dépendances en amont, la charge du serveur et la saturation des connexions.
• L’origine est rapide mais le hostname public renvoie un 504 : recherchez les règles d’accès du pare-feu entre Cloudflare et l’origine, le DNS, les paramètres SSL/TLS, le statut du proxy et le endpoint concerné.
• Le test direct n’est pas représentatif : répétez-le avec la même authentification, le routage basé sur le hostname, les en-têtes et les autres exigences que ceux de la requête défaillante.

4. Corrigez une opération réellement lente

Pour un rapport, un export, une action groupée ou une autre tâche longue, évitez de maintenir une seule requête du navigateur ouverte jusqu’à la fin du traitement. Déplacez l’opération vers un job en arrière-plan, affichez un état de traitement et permettez à l’utilisateur de récupérer le résultat par polling ou via une notification de fin.

Mesurez également les requêtes de base de données, les traces de l’application, les appels en amont, la profondeur de la file d’attente et l’utilisation des ressources. N’augmentez pas le délai d’attente de l’origine comme solution principale sans mesurer l’opération : si Cloudflare atteint sa limite en premier, le visiteur recevra toujours une erreur tandis que l’origine pourra continuer à effectuer un travail inutile.

5. Vérifiez le délai d’attente Cloudflare applicable

Consultez le compte Cloudflare et la documentation pertinente pour connaître le délai d’attente applicable à la requête et au plan concernés. Si le traitement est valide mais ne peut pas se terminer dans une limite fixe, les options pratiques consistent à le repenser comme un traitement asynchrone ou à utiliser, lorsqu’elle est disponible, une configuration de compte et un plan prenant en charge le délai requis.

6. Vérifiez l’accessibilité lorsque les échecs persistent

Si les requêtes ordinaires et rapides échouent également, vérifiez les points suivants :

• L’enregistrement DNS pointe vers l’adresse actuelle de l’origine.
• Le pare-feu de l’origine autorise le trafic Cloudflare comme requis, sans exposer de services inutiles.
• Le serveur web écoute sur le port attendu et accepte le hostname demandé.
• L’origine dispose d’une capacité suffisante et ne rejette pas ou ne met pas en file d’attente les connexions.
• Le mode SSL/TLS correspond au certificat de l’origine, au hostname et à la validité du certificat, en particulier avec Full (strict).
• L’enregistrement concerné est destiné à être proxifié plutôt qu’à être servi via une configuration DNS-only contrôlée.

N’effectuez des modifications DNS, de pare-feu, SSL/TLS ou de proxy qu’avec les autorisations appropriées et un plan de retour arrière. Testez à nouveau le endpoint défaillant exact après chaque modification importante afin de conserver une relation claire entre la cause et l’effet.

7. Escaladez avec des éléments utiles

Si l’origine est saine et répond rapidement lors d’un test direct équivalent, recueillez le Ray ID, l’horodatage et le fuseau horaire, le hostname, le chemin, la méthode de requête, la zone Cloudflare concernée et les résultats du test direct. Transmettez ces informations à l’administrateur du compte Cloudflare ou au contact du support afin que le comportement entre le edge et l’origine puisse être examiné.

Prévention et vérification du correctif

• Mesurez séparément le temps de réponse de l’origine, la durée totale de la requête et la disponibilité côté Cloudflare.
• Exécutez les rapports, exports, téléversements et opérations groupées prévisiblement longs via des jobs en arrière-plan avec une progression ou un état de fin visible.
• Déclenchez des alertes sur l’augmentation de la latence de l’origine, les échecs de connexion, la saturation des ressources et la profondeur de la file d’attente avant que les utilisateurs ne rencontrent des délais d’attente.
• Soumettez les enregistrements DNS, les règles de pare-feu de l’origine et les allowlists de trafic Cloudflare à une gestion des changements.
• Surveillez la validité du certificat de l’origine et la couverture des hostnames avec Full (strict), et examinez les changements SSL/TLS avant leur déploiement.
• Documentez les endpoints destinés à utiliser le proxy Cloudflare et ceux qui nécessitent une configuration DNS-only contrôlée.
• Retestez la connectivité représentative avec l’origine après toute modification de l’infrastructure, du DNS, du pare-feu, du certificat ou du proxy.

Questions fréquentes