Erreur Cloudflare 520 : ce que ça signifie et comment le corriger

Ce que signifie l'erreur 520

Cloudflare se place entre le visiteur et votre serveur web comme reverse proxy. Pour une requête normale, il ouvre une connexion TCP vers votre origine, envoie la requête, et relaie la réponse HTTP qui revient. L'erreur 520 se déclenche quand cette dernière étape échoue : la connexion TCP réussit, mais les octets qui suivent ne s'analysent pas comme une réponse HTTP valide, ou aucun octet n'arrive du tout avant la fermeture de la connexion.

Cela place le 520 dans une catégorie différente des autres codes 5xx de Cloudflare. L'erreur 521 signifie que l'origine a refusé la connexion d'emblée. L'erreur 522 signifie que la tentative de connexion a expiré. L'erreur 520 signifie que l'origine a dit quelque chose, et que Cloudflare n'a pas pu en faire sens ni le transmettre.

Comment l'erreur 520 apparaît

Dans un navigateur, Cloudflare affiche sa propre page d'erreur, « Error 520: web server returned an unknown error », avec un Ray ID dont vous aurez besoin si vous contactez le support Cloudflare. Une simple requête curl contre le domaine montre le même code de statut :

curl -I https://example.com
HTTP/2 520

Côté Cloudflare, les onglets Security ou Analytics du tableau de bord montrent un pic de réponses 5xx, et les comptes Enterprise avec accès Logpull ou Logpush peuvent extraire le colo de bordure et le Ray ID précis de chaque requête échouée. Rien de tout cela ne vous dit ce que l'origine a réellement envoyé, cependant, donc le prochain endroit où regarder est votre propre serveur.

Sur l'origine, vérifiez les journaux du serveur web et de l'application au même horodatage que les échecs. Cherchez un redémarrage de processus, une erreur de segmentation, une extinction pour manque de mémoire dans le journal système (dmesg ou journalctl -k), ou une erreur applicative qui a fait planter la requête en cours de réponse. Si les journaux applicatifs ne montrent rien d'inhabituel du tout, le problème est plus probablement une réponse techniquement complète mais qui enfreint une règle HTTP, comme un en-tête surdimensionné.

Ce qui provoque l'erreur 520

• Le processus d'origine a planté ou redémarré pendant le traitement de la requête. La connexion se ferme avant qu'une réponse complète ne soit envoyée. C'est la cause la plus courante.
• L'origine a réinitialisé la connexion TCP (RST) au lieu de la fermer proprement. Les serveurs d'application sous pression mémoire ou atteignant un délai d'attente de worker font souvent cela.
• Des en-têtes de réponse au-delà de la limite de 16 Ko de Cloudflare. Un gros en-tête set-cookie, une pile d'en-têtes de débogage, ou des en-têtes CORS verbeux peuvent pousser le total au-delà de ce que Cloudflare acceptera.
• Un cookie ou un en-tête de cookies combinés trop volumineux. Les données de session, les cookies de suivi, ou un pot de cookies mal configuré peuvent grossir au-delà des limites du navigateur et du proxy au fil du temps.
• Une ligne de statut manquante ou mal formée. Certains frameworks renvoient une chaîne d'erreur brute au lieu d'une réponse HTTP correcte quand une exception non gérée atteint la couche serveur web.
• L'origine a renvoyé des données non-HTTP sur le port HTTP(S). Cela arrive après un reverse proxy mal configuré, un mauvais mappage de port, ou un service qui se lie au port avant le vrai serveur web.
• Un équipement de sécurité ou un WAF devant l'origine a coupé la connexion en cours de réponse. Certains WAF et équilibreurs de charge sur site terminent les connexions qui déclenchent une règle, ce qui ressemble en tout point à un plantage vu du côté de Cloudflare.

Comment savoir de qui vient la faute

Puisque Cloudflare a bien reçu une réponse de l'origine, l'erreur 520 est un signal fort que le problème se situe du côté de l'origine plutôt que dans le réseau de Cloudflare, contrairement à l'erreur 521 ou 522 où la connexion elle-même a échoué. La question ouverte est généralement de savoir si cela affecte tous les visiteurs ou seulement certains.

Le moyen le plus rapide de trancher est de lancer une vérification HTTP depuis plusieurs emplacements à la fois. Si une vérification contre le domaine public échoue depuis tous les emplacements en même temps que les utilisateurs signalent l'erreur, l'origine elle-même est en panne ou plante pour tout le monde, pas seulement pour un centre de données de bordure. Si elle échoue seulement par intermittence ou depuis des régions spécifiques, l'origine est peut-être surchargée sous la charge de cette région, ou une couche de mise en cache ou d'équilibrage de charge présente seulement dans une partie de votre installation est en cause. La vérification HTTP de HostTracker s'exécute depuis des points de contrôle dans plusieurs pays et rapporte le résultat de chacun séparément, un détail qu'un simple curl depuis votre bureau ne peut pas vous donner.

Vous pouvez aussi isoler l'origine de Cloudflare entièrement en la contactant directement avec l'en-tête Host du domaine, contournant le réseau de bordure de sorte que toute erreur que vous voyez est indiscutablement celle de l'origine :

curl -v -H "Host: example.com" https://ORIGIN_IP/

Remplacez ORIGIN_IP par l'adresse IP réelle de votre serveur. Si cette requête directe échoue aussi ou renvoie la même réponse cassée, la faute est confirmée au niveau de l'origine.

Comment corriger l'erreur 520

Si vous êtes visiteur

1. Rechargez la page après une minute ou deux. Beaucoup d'erreurs 520 viennent d'un bref plantage ou redémarrage dont le superviseur de processus du site se remet automatiquement.
2. Essayez une fenêtre privée ou incognito, ou un autre réseau. Cela écarte un cache local obsolète ou une extension de navigateur qui se comporte mal, même si un 520 est rarement causé par quelque chose de votre côté.
3. Vérifiez si le site publie sa propre page de statut, s'il en a une, pour une panne connue.
4. Il n'y a rien à configurer de votre côté pour corriger un 520. Il est généré par le serveur du site lui-même, pas par votre navigateur, votre FAI ni votre résolveur DNS.

Si vous gérez le site

1. Vérifiez les journaux du serveur web et de l'application d'origine à l'horodatage exact des échecs, en cherchant un plantage, une exception non gérée, ou un redémarrage de worker.
2. Contournez Cloudflare et interrogez l'origine directement avec l'en-tête Host (montré ci-dessus), ou utilisez l'option « Pause Cloudflare on Site » de Cloudflare, pour confirmer que la réponse est cassée indépendamment du proxy.
3. Mesurez la taille de vos en-têtes de réponse et de vos cookies. Un seul gros en-tête set-cookie ou un tas d'en-têtes de débogage laissés actifs en production peuvent pousser le total au-delà de 16 Ko ; élaguez ce dont vous n'avez pas besoin et déplacez les données de session volumineuses côté serveur.
4. Cherchez des réponses mal formées : un reverse proxy ou un équilibreur de charge pointant vers le mauvais upstream, une application renvoyant du texte brut sur un port HTTP, ou une ligne de statut manquante venant du gestionnaire d'erreur par défaut d'un framework.
5. Cherchez un épuisement des ressources sur l'origine : limites de mémoire, limites de pool de connexions, ou un gestionnaire de processus (systemd, pm2, un pool de workers Gunicorn ou uWSGI) bloqué dans une boucle de redémarrage.
6. Si un WAF, un proxy antivirus, ou un équilibreur de charge se trouve entre internet et votre serveur d'application, vérifiez ses propres journaux pour des connexions qu'il a coupées ou réinitialisées au même moment.

Comment le prévenir

L'erreur 520 apparaît généralement d'abord comme un ticket de support, pas comme une alerte, car rien du côté de l'origine ne journalise nécessairement un handshake échoué avec la bordure de Cloudflare de la même façon qu'il journalise une exception applicative. Une vérification de disponibilité externe qui s'exécute depuis l'extérieur de votre propre réseau détecte le même échec que voit un visiteur, depuis le même point de vue, avant que quelqu'un n'ait à le signaler. Exécuter la vérification depuis plusieurs pays montre aussi immédiatement si un 520 est global ou limité à une région, ce qui est le détail qui décide par où commencer le débogage.

Erreurs associées

• Erreur Cloudflare 521 : le serveur web est en panne - l'origine a refusé la connexion au lieu de répondre.
• Erreur Cloudflare 522 : délai de connexion dépassé - le handshake TCP vers l'origine n'a jamais abouti.
• Erreurs serveur 5xx - la famille générale de codes de statut.
• 502 Bad Gateway - la version non spécifique à Cloudflare d'une réponse upstream invalide.

Questions fréquentes

L'erreur 520 est-elle la faute de Cloudflare ou la mienne ?

Presque toujours celle de l'origine. Cloudflare a reçu une réponse et n'a pas pu en faire sens ni la transmettre, ce qui signifie que c'est le serveur d'origine, pas le réseau de Cloudflare, qui a produit la réponse cassée.

L'erreur 520 signifie-t-elle que tout mon site est en panne ?

Pas nécessairement. Elle signifie que la requête spécifique qui l'a déclenchée a échoué. Si l'origine plante sous la charge, elle peut servir 520 à certaines requêtes et des réponses normales à d'autres jusqu'à ce que le problème sous-jacent soit corrigé.

Puis-je corriger l'erreur 520 depuis le tableau de bord Cloudflare seul ?

Rarement. Puisque la cause se trouve presque toujours du côté de l'origine, les réglages du tableau de bord ne corrigeront pas une application qui plante ou un en-tête de réponse surdimensionné. L'exception est de vérifier que votre mode SSL/TLS et vos réglages d'origine correspondent à ce que votre serveur fait réellement, ce qui écarte au moins une mauvaise configuration côté Cloudflare.

Quelle est la différence entre l'erreur 520 et un simple 502 Bad Gateway ?

502 est le statut HTTP général pour une réponse invalide d'un serveur upstream, utilisé par n'importe quel reverse proxy. Cloudflare utilise 520 spécifiquement comme son propre fourre-tout pour une réponse tellement cassée qu'elle ne correspond à aucun des autres codes 5xx nommés de Cloudflare, ce qui explique pourquoi la page d'erreur Cloudflare et le Ray ID apparaissent au lieu d'une page 502 générique.

Un gros cookie peut-il vraiment causer un 520 ?

Oui. Cloudflare impose une limite sur la taille totale des en-têtes de réponse, actuellement autour de 16 Ko, et les cookies comptent dans ce total. Une application qui n'arrête pas d'ajouter au cookie de session, ou qui fixe plusieurs gros cookies à la fois, peut franchir cette limite et déclencher un 520 même quand l'application elle-même n'a aucun bug.

Réessayer la requête va-t-il corriger le problème ?

Parfois, si la cause était un plantage ou un redémarrage transitoire de l'origine qui s'en est déjà remise. Si l'origine envoie systématiquement des réponses cassées, par exemple à cause d'un en-tête surdimensionné sur chaque requête, réessayer n'aidera pas tant que l'origine n'est pas corrigée.