Comment résoudre l’erreur Cloudflare 520 : Guide complet de diagnostic et de résolution

L’erreur Cloudflare 520 est un code de statut HTTP renvoyé lorsque le réseau edge de Cloudflare reçoit une réponse vide, inattendue ou autrement ininterprétable de votre serveur d’origine. Contrairement aux erreurs 502 ou 504, qui indiquent un délai d’attente de passerelle ou une mauvaise passerelle, une erreur 520 est le code fourre-tout de Cloudflare pour les réponses qui ne correspondent à aucune spécification HTTP reconnue — ce qui signifie que le serveur d’origine a techniquement répondu, mais ce qu’il a renvoyé était invalide, tronqué ou structurellement malformé.

D’un point de vue pratique, l’erreur 520 signifie que la connexion TCP entre Cloudflare et votre serveur d’origine a été établie, mais que la négociation au niveau HTTP a échoué. L’utilisateur voit une page d’erreur aux couleurs de Cloudflare avec le message "Le serveur web renvoie une erreur inconnue" — et votre site est effectivement hors ligne pour lui.

Ce qui déclenche l’erreur 520 : causes profondes expliquées

Comprendre le mode de défaillance exact est essentiel avant de toucher à toute configuration. L’erreur 520 n’est pas un problème unique — c’est une classe de symptômes. Les causes suivantes sont les plus courantes, classées par fréquence dans les environnements de production.

Le serveur d’origine renvoie un corps de réponse vide sans ligne de statut HTTP. C’est le déclencheur le plus fréquent. Apache ou Nginx peut planter en cours de réponse, laissant Cloudflare avec un socket TCP ouvert sans données entrantes.

Un pare-feu ou un logiciel de sécurité bloque les plages IP de Cloudflare. Des outils comme ModSecurity, Fail2Ban, CSF (ConfigServer Security & Firewall), ou des plugins au niveau applicatif tels que Wordfence peuvent silencieusement abandonner les paquets provenant des IP de sortie de Cloudflare, provoquant une réinitialisation de la connexion sans réponse HTTP appropriée.

Incompatibilité de négociation SSL/TLS entre Cloudflare et l’origine. Si Cloudflare est configuré en mode "Full (Strict)" mais que votre serveur d’origine possède un certificat expiré, auto-signé ou mal configuré, la négociation TLS échoue avant qu’aucune donnée HTTP ne soit échangée.

En-têtes de réponse HTTP malformés ou trop volumineux. Cloudflare impose une limite stricte de 32 Ko sur les en-têtes de réponse. Tout en-tête individuel ou ensemble d’en-têtes combinés dépassant cette limite provoque une erreur 520. C’est un cas limite courant avec des applications PHP mal écrites qui déversent de grandes quantités de données de session ou de sortie de débogage dans les en-têtes.

Crash du processus du serveur d’origine ou kill OOM (Out-of-Memory). Si le processus worker du serveur web (par exemple, un worker Nginx ou un pool PHP-FPM) est tué par le killer OOM de Linux en cours de requête, la connexion est interrompue brusquement.

Exceptions au niveau applicatif avant l’envoi des en-têtes. Une erreur fatale PHP, une exception Python non gérée, ou un crash Node.js qui survient avant l’appel de res.writeHead() résulte en une réponse vide que Cloudflare ne peut pas analyser.

Réinitialisation de connexion par l’origine (TCP RST). Le serveur d’origine réinitialise activement la connexion TCP, ce que Cloudflare interprète comme une réponse inconnue.

Erreur 520 vs. autres erreurs Cloudflare 5xx

Distinguer l’erreur 520 des erreurs Cloudflare similaires évite des efforts de diagnostic inutiles.

Si vous voyez l’erreur 521, votre processus de serveur web ne fonctionne pas. Si vous voyez l’erreur 524, votre application fonctionne mais est trop lente. Si vous voyez l’erreur 520, le serveur fonctionne et répond — mais ce qu’il renvoie est défectueux.

Correction étape par étape de l’erreur 520

Étape 1 : Vérifier la santé et la connectivité du serveur d’origine

Avant de toucher à Cloudflare, confirmez que le serveur d’origine est actif et que le démon du serveur web fonctionne.

Vérifiez si le processus du serveur web est actif :

# For Nginx
sudo systemctl status nginx

# For Apache
sudo systemctl status apache2

# For LiteSpeed
sudo systemctl status lsws

Testez la connectivité directe à l’IP d’origine, en contournant le proxy de Cloudflare. Récupérez votre IP d’origine depuis le tableau de bord DNS de Cloudflare, puis testez-la directement :

curl -I --resolve yourdomain.com:80:YOUR_ORIGIN_IP http://yourdomain.com/
curl -I --resolve yourdomain.com:443:YOUR_ORIGIN_IP https://yourdomain.com/

Si curl renvoie un statut HTTP valide (200, 301, etc.), le serveur d’origine est fonctionnel et le problème se situe dans la couche de communication entre Cloudflare et l’origine. Si curl renvoie une réponse vide ou une réinitialisation de connexion, le problème est du côté de l’origine.

Vérifiez la pression sur les ressources système :

# Memory usage
free -h

# CPU load
uptime

# Check for OOM kills in the last boot
dmesg | grep -i "oom|killed process"

# Check for PHP-FPM pool exhaustion
sudo systemctl status php8.1-fpm

Étape 2 : Inspecter les journaux d’erreurs du serveur d’origine

Les journaux du serveur d’origine sont la source de diagnostic la plus précieuse. Ne sautez pas cette étape.

Pour Nginx :

sudo tail -n 100 /var/log/nginx/error.log
sudo tail -n 100 /var/log/nginx/access.log

Pour Apache :

sudo tail -n 100 /var/log/apache2/error.log
sudo tail -n 100 /var/log/apache2/access.log

Recherchez spécifiquement :

• Les entrées de niveau [crit] ou [emerg]

upstream prematurely closed connection (Nginx + PHP-FPM)
Premature end of script headers (Apache + CGI/PHP)
worker_connections are not enough (limite de workers Nginx atteinte)
Les erreurs fatales PHP enregistrées dans le journal d’erreurs du serveur web

Comparez les horodatages des journaux avec les moments où les erreurs 520 se sont produites. Le tableau de bord de Cloudflare sous Analytics > Traffic affiche les horodatages des pics d’erreurs 520 que vous pouvez utiliser pour la corrélation.
Étape 3 : Mettre en liste blanche les plages IP de Cloudflare dans votre pare-feu
Si un pare-feu bloque les IP de sortie de Cloudflare, la connexion sera réinitialisée silencieusement. Cloudflare publie ses plages IP actuelles sur https://www.cloudflare.com/ips/.
Pour UFW (Ubuntu/Debian) :
# Download Cloudflare IPv4 ranges and whitelist them
for ip in $(curl -s https://www.cloudflare.com/ips-v4); do
  sudo ufw allow from $ip to any port 80,443 proto tcp
done

# Repeat for IPv6
for ip in $(curl -s https://www.cloudflare.com/ips-v6); do
  sudo ufw allow from $ip to any port 80,443 proto tcp
done

sudo ufw reload
Pour CSF (ConfigServer Firewall) :
Ajoutez les plages IP de Cloudflare à /etc/csf/csf.allow, puis redémarrez CSF :
sudo csf -r
Pour ModSecurity : Si vous suspectez ModSecurity d’être la cause, vérifiez son journal d’audit :
sudo tail -n 200 /var/log/modsec_audit.log
Recherchez les correspondances de règles contre les adresses IP de Cloudflare. Vous pouvez mettre en liste blanche les IP de Cloudflare dans votre configuration ModSecurity ou utiliser la directive SecRemoteRules pour les exclure.
Note critique : Ne désactivez jamais définitivement votre pare-feu ou ModSecurity. Mettez en liste blanche uniquement les plages IP publiées par Cloudflare, et réactivez tous les contrôles de sécurité immédiatement après les tests.
Étape 4 : Auditer et corriger les en-têtes de réponse HTTP
Les en-têtes malformés ou trop volumineux sont une cause fréquemment négligée des erreurs 520. Utilisez curl avec une sortie détaillée pour inspecter exactement ce que votre origine envoie :
curl -v --resolve yourdomain.com:443:YOUR_ORIGIN_IP https://yourdomain.com/ 2>&1 | head -80
Surveillez :

Les en-têtes contenant des caractères non-ASCII ou des caractères de contrôle
Les en-têtes Set-Cookie avec des valeurs extrêmement longues (courant dans les mauvaises configurations de session PHP)
Les en-têtes Content-Type manquants ou malformés
Les en-têtes Content-Length dupliqués avec des valeurs contradictoires

Si vous exécutez une application PHP, vérifiez php.ini pour les paramètres output_buffering. Un tampon de sortie désactivé combiné à une erreur fatale en cours de réponse peut provoquer une transmission partielle des en-têtes.
Pour les sites WordPress en particulier : Les plugins qui injectent de grandes quantités de données dans les en-têtes HTTP (certains plugins de sécurité ou de mise en cache le font) peuvent faire dépasser la limite de 32 Ko de Cloudflare. Auditez les plugins actifs et testez en mode sans échec.
Étape 5 : Valider la configuration SSL/TLS de Cloudflare
Une incompatibilité SSL entre Cloudflare et l’origine est une source courante d’échecs de classe 520 qui se déguise en erreur inconnue générique.
Accédez à Tableau de bord Cloudflare > SSL/TLS > Vue d’ensemble et vérifiez le mode de chiffrement :



Mode SSL Cloudflare
Exigence d’origine
Recommandé pour








—
—
—








Off
Pas de SSL sur l’origine
Jamais recommandé








Flexible
Pas de SSL requis sur l’origine
Configurations héritées uniquement ; risque de sécurité








Full
N’importe quel certificat SSL sur l’origine (y compris auto-signé)
Environnements de développement








Full (Strict)
Certificat SSL valide et approuvé sur l’origine
Tous les sites en production





Si votre origine utilise un certificat auto-signé et que Cloudflare est configuré en mode Full (Strict), la négociation TLS échouera. Installez soit un certificat valide sur l’origine (un certificat Let’s Encrypt gratuit fonctionne), soit passez temporairement en mode Full pendant que vous corrigez le certificat.
Si vous avez besoin d’un certificat correctement approuvé pour votre serveur d’origine, les Certificats SSL d’une autorité de certification approuvée éliminent entièrement le problème des certificats auto-signés et sont compatibles avec le mode Full (Strict) de Cloudflare.
Étape 6 : Mettre en pause le proxy Cloudflare pour un diagnostic ciblé
Retirer temporairement Cloudflare du chemin de requête permet d’isoler si le problème se trouve dans la configuration de Cloudflare ou sur le serveur d’origine.
Méthode 1 : Désactiver le proxy sur un enregistrement DNS spécifique
Dans le tableau de bord DNS de Cloudflare, cliquez sur l’icône de nuage orange à côté de votre enregistrement A ou CNAME pour le rendre gris. Cela contourne le proxy de Cloudflare tout en conservant la résolution DNS via Cloudflare. La propagation DNS prend jusqu’à 5 minutes.
Méthode 2 : Mettre Cloudflare en pause globalement pour le domaine
Accédez à Tableau de bord Cloudflare > Vue d’ensemble > Actions avancées > Mettre Cloudflare en pause sur le site. Cela achemine tout le trafic directement vers votre origine.
Après la mise en pause, testez votre site. S’il se charge correctement, le problème se trouve dans la configuration de Cloudflare. S’il échoue toujours, le problème est sur le serveur d’origine indépendamment de Cloudflare.
Réactivez Cloudflare immédiatement après les tests — un Cloudflare en pause signifie que votre site perd la protection DDoS, la mise en cache CDN et la couverture WAF.
Étape 7 : Vérifier l’exactitude des enregistrements DNS
Un enregistrement DNS A mal configuré pointant vers une adresse IP incorrecte ou obsolète amène Cloudflare à acheminer le trafic vers le mauvais serveur, qui renverra une réponse inattendue.
Dans le tableau de bord DNS de Cloudflare :

Vérifiez que l’enregistrement A pour votre domaine racine (@) pointe vers l’IP actuelle de votre serveur d’origine
Vérifiez que le CNAME pour www se résout correctement
Si vous avez récemment migré des serveurs, confirmez que l’ancienne IP n’est plus référencée nulle part

Confirmez l’IP vers laquelle Cloudflare envoie réellement le trafic :
dig +short yourdomain.com @1.1.1.1
Comparez cela avec l’IP réelle de votre serveur d’origine. Si elles diffèrent, mettez à jour l’enregistrement DNS dans Cloudflare.
Étape 8 : Augmenter les ressources du serveur d’origine
Si votre serveur d’origine est constamment sous forte charge, des erreurs 520 se produiront de manière intermittente lors des pics de trafic lorsque les processus workers s’épuisent et que les connexions sont abandonnées.
Diagnostiquer l’épuisement des ressources :
# Check Nginx worker connections
sudo nginx -T | grep worker_connections

# Check PHP-FPM pool limits
cat /etc/php/8.1/fpm/pool.d/www.conf | grep -E "pm.|max_children"

# Monitor real-time connections
ss -s
Options de réglage sans mise à niveau matérielle :

Augmenter worker_connections dans /etc/nginx/nginx.conf

• Augmenter pm.max_children dans la configuration du pool PHP-FPM
• Activer la directive keepalive de Nginx pour les connexions en amont
• Implémenter la mise en cache d’objets (Redis ou Memcached) pour réduire la pression sur la base de données
• Activer la règle de page Cache Everything de Cloudflare pour décharger la livraison des ressources statiques

Pour les applications qui ont dépassé les capacités d’une infrastructure partagée, la migration vers un environnement VPS Hosting vous donne un contrôle total sur les limites des processus workers, l’allocation mémoire et le réglage TCP au niveau du noyau — rien de tout cela n’est disponible sur les plans partagés.

Si votre application gère des charges de travail intensives en calcul (inférence ML, traitement vidéo, opérations sur de grands ensembles de données) qui provoquent des crashes intermittents de workers, le GPU Hosting décharge ces tâches de vos processus de serveur web, éliminant une source courante de crashes en cours de réponse.

Étape 9 : Examiner les règles de pare-feu et de sécurité de Cloudflare

Les propres fonctionnalités de sécurité de Cloudflare peuvent parfois interférer avec la communication légitime vers l’origine, en particulier si des règles de pare-feu personnalisées ou des règles WAF sont mal configurées.

Vérifiez Tableau de bord Cloudflare > Sécurité > WAF > Règles personnalisées pour toute règle susceptible d’intercepter les requêtes avant qu’elles n’atteignent l’origine. Examinez également Sécurité > Paramètres > Vérification d’intégrité du navigateur — dans de rares cas, cela peut provoquer un comportement inattendu avec certains agents utilisateurs ou requêtes automatisées.

Consultez le journal Sécurité > Événements pour voir si Cloudflare bloque ou challenge des requêtes qui devraient atteindre votre origine.

Étape 10 : Escalader vers votre hébergeur ou le support Cloudflare

Si toutes les étapes ci-dessus ont été épuisées sans résolution, escaladez avec des informations précises.

Lorsque vous contactez votre hébergeur, fournissez :

• Les horodatages exacts des occurrences d’erreurs 520 (depuis Cloudflare Analytics)
• Les extraits pertinents de votre journal d’erreurs du serveur web
• La sortie de curl -v contre votre IP d’origine
• Les métriques d’utilisation des ressources actuelles (CPU, RAM, nombre de connexions)

Les fournisseurs exploitant une infrastructure gérée sur des Serveurs Dédiés peuvent effectuer des diagnostics au niveau du noyau, des captures de paquets (tcpdump) et une inspection au niveau des sockets qui ne sont pas disponibles dans les environnements partagés.

Lorsque vous contactez le support Cloudflare, incluez :

• Votre Ray ID depuis la page d’erreur 520 (visible dans le HTML d’erreur de Cloudflare)
• Un fichier HAR capturé depuis Chrome DevTools pendant l’erreur
• Votre mode SSL/TLS actuel et toutes les règles de pare-feu personnalisées

Le Ray ID est essentiel — il permet aux ingénieurs de Cloudflare de récupérer l’entrée exacte du journal du nœud edge pour votre requête échouée.

Diagnostic avancé : capturer l’échec exact avec tcpdump

Pour les erreurs 520 persistantes ou intermittentes qui résistent au dépannage standard, une capture de paquets sur le serveur d’origine révèle exactement ce qui se passe au niveau TCP/HTTP lorsque Cloudflare se connecte.

# Capture traffic from Cloudflare IPs on port 443
sudo tcpdump -i eth0 -w /tmp/cloudflare_capture.pcap 'src net 103.21.244.0/22 or src net 103.22.200.0/22 or src net 103.31.4.0/22 or src net 104.16.0.0/13 or src net 104.24.0.0/14' and port 443

Ouvrez le fichier .pcap résultant dans Wireshark et filtrez par tcp.flags.reset == 1 pour identifier les paquets TCP RST, qui indiquent que l’origine réinitialise activement les connexions. Filtrez par http pour inspecter les réponses HTTP partielles envoyées.

Ce niveau d’analyse identifie de manière définitive si l’erreur 520 est causée par un RST de pare-feu, un crash d’application en cours de réponse, ou un échec TLS.

Prévenir l’erreur 520 : mesures proactives

Le dépannage réactif est coûteux. Ces mesures réduisent significativement la probabilité d’occurrence des erreurs 520.

Implémentez les vérifications de santé Cloudflare. Sous Traffic > Health Checks, configurez une vérification de santé contre votre origine. Cloudflare vous alertera avant que les utilisateurs ne commencent à voir des erreurs 520.

Activez la fonctionnalité Always Online de Cloudflare (sous Caching > Configuration). Bien qu’elle ne corrige pas le problème sous-jacent, elle sert des versions mises en cache de vos pages aux utilisateurs lors des pannes d’origine, évitant une interruption complète du service.

Configurez la surveillance du serveur d’origine avec des outils comme UptimeRobot, Pingdom, ou une solution auto-hébergée comme Uptime Kuma. Surveillez l’IP d’origine directement (pas le domaine proxifié par Cloudflare) pour détecter les défaillances d’origine indépendamment de Cloudflare.

Automatisez la mise en liste blanche des IP Cloudflare. Les plages IP de Cloudflare changent occasionnellement. Utilisez une tâche cron pour actualiser votre liste blanche de pare-feu :

# /etc/cron.weekly/update-cloudflare-ips
#!/bin/bash
CF_IPS=$(curl -s https://www.cloudflare.com/ips-v4)
# Add logic to update UFW/CSF/iptables rules

Utilisez les Authenticated Origin Pulls de Cloudflare. Cette fonctionnalité configure votre origine pour n’accepter que les connexions HTTPS présentant le certificat client de Cloudflare, bloquant toutes les requêtes directes vers l’origine qui contournent le proxy. Cela élimine également une classe d’erreurs 520 causées par du trafic non-Cloudflare atteignant votre origine et déclenchant des réponses de logiciels de sécurité.

Pour les équipes gérant plusieurs domaines et applications web, un VPS avec cPanel fournit un accès centralisé aux journaux, la gestion du pare-feu et la gestion des certificats SSL pour tous les domaines hébergés — réduisant considérablement le temps de diagnostic pour les événements d’erreur 520.

Matrice de décision : diagnostiquer votre scénario spécifique d’erreur 520

Liste de contrôle des points clés techniques

Avant d’escalader vers le support, confirmez que vous avez complété chacun des points suivants :

• Vérifié que le processus du serveur web d’origine fonctionne (systemctl status)
• Testé la connectivité directe à l’origine avec curl -v --resolve en contournant Cloudflare
• Examiné les journaux d’erreurs d’origine pour les horodatages exacts des événements d’erreur 520
• Confirmé que les plages IP de Cloudflare sont en liste blanche dans tous les pare-feux actifs (UFW, CSF, iptables, ModSecurity)
• Validé que les en-têtes de réponse sont inférieurs à 32 Ko et ne contiennent pas de valeurs malformées
• Confirmé que le mode SSL/TLS de Cloudflare correspond au type de certificat de l’origine
• Vérifié que les enregistrements DNS A pointent vers l’IP d’origine correcte et actuelle
• Vérifié la mémoire système et le CPU pour les kills OOM ou l’épuisement des ressources
• Capturé le Ray ID depuis la page d’erreur 520 pour l’escalade vers le support Cloudflare
• Examiné le journal des événements de sécurité Cloudflare pour les interférences des règles WAF

Foire aux questions

Quelle est la différence entre l’erreur Cloudflare 520 et l’erreur 521 ?

L’erreur 521 signifie que Cloudflare a réussi à atteindre l’IP de votre serveur d’origine mais que le processus du serveur web a refusé la connexion TCP — généralement parce que Nginx ou Apache ne fonctionne pas. L’erreur 520 signifie que la connexion TCP a été établie mais que la réponse HTTP était vide, tronquée ou malformée. Si vous voyez l’erreur 521, démarrez votre serveur web. Si vous voyez l’erreur 520, le serveur fonctionne mais envoie des réponses défectueuses.

L’erreur 520 peut-elle être causée par Cloudflare lui-même, et non par le serveur d’origine ?

Rarement, mais oui. Des problèmes sur les nœuds edge de Cloudflare peuvent provoquer des erreurs 520 qui ne sont pas reproductibles lors d’un accès direct à l’origine. Vérifiez cloudflarestatus.com pour les incidents actifs. Si l’origine répond correctement via curl direct et que la page de statut de Cloudflare affiche un incident actif, attendez que Cloudflare le résolve plutôt que d’apporter des modifications à votre serveur.

Pourquoi l’erreur 520 se produit-elle uniquement de manière intermittente et non de façon constante ?

Les erreurs 520 intermittentes indiquent presque toujours un épuisement des ressources — les pools de workers PHP-FPM manquant d’enfants disponibles, Nginx atteignant les limites worker_connections, ou le killer OOM de Linux terminant des processus sous pression mémoire. Ces conditions surviennent lors de pics de trafic et se résolvent lorsque le trafic diminue, créant le schéma intermittent. Les erreurs 520 constantes pointent vers un problème de configuration.

La mise en pause de Cloudflare corrige-t-elle l’erreur 520 ?

Mettre Cloudflare en pause le retire du chemin de requête, donc si votre site fonctionne après la mise en pause, le problème se trouve dans la configuration de Cloudflare (mode SSL, règles WAF, enregistrements DNS). Si votre site échoue toujours après la mise en pause, le problème est sur le serveur d’origine. Mettre Cloudflare en pause est une étape de diagnostic, pas un correctif — cela supprime la protection DDoS et la mise en cache CDN pendant qu’il est actif.

Comment trouver le Ray ID pour signaler une erreur 520 à Cloudflare ?

Le Ray ID est affiché en bas de la page d’erreur 520 de Cloudflare montrée aux utilisateurs. Il ressemble à une chaîne hexadécimale de 16 caractères (par exemple, 7a3f2b9c1d4e8f0a). Vous pouvez également le trouver dans l’en-tête de réponse CF-Ray, visible dans Chrome DevTools sous l’onglet Réseau. Incluez toujours cet ID lors de l’ouverture d’un ticket de support Cloudflare — il permet aux ingénieurs de Cloudflare de récupérer l’entrée exacte du journal edge pour votre requête échouée.