Le problème : Cloudflare affiche une 520 et personne ne sait pourquoi
L’écran est sobre et un peu inquiétant : un fond orange Cloudflare, “Error 520”, et la mention “Web server is returning an unknown error”. Pas de détail, pas de message d’erreur PHP, rien à copier-coller dans un moteur de recherche pour comprendre ce qui se passe vraiment.
La 520 est une erreur générique : Cloudflare a bien contacté le serveur d’origine (celui qui héberge réellement le site), mais la réponse reçue était vide, mal formée, ou tout simplement incompréhensible. Ce n’est ni un 404, ni un 500 propre : c’est un silence bizarre entre les deux parties.
Bonne nouvelle : dans l’immense majorité des cas, le problème n’est pas côté Cloudflare, il est côté serveur d’origine — et il se diagnostique méthodiquement, sans magie. On distingue ci-dessous les causes possibles, puis les vérifications à faire dans l’ordre, du plus rapide au plus technique.
Pourquoi ça arrive : ce qui casse la communication Cloudflare ↔ origine
- Le serveur d’origine a planté ou redémarré au moment précis de la requête (crash PHP-FPM, Apache/Nginx qui redémarre, OOM killer qui tue un processus).
- Les en-têtes HTTP renvoyés sont trop volumineux : cookies énormes, plugins qui empilent des headers de sécurité ou de cache, certains WAF applicatifs trop bavards.
- Un problème de keep-alive : le serveur d’origine coupe la connexion TCP avant que Cloudflare ait fini de lire la réponse, ou inversement les timeouts ne sont pas alignés entre les deux couches.
- Un dépassement de ressources serveur : mémoire PHP épuisée, temps d’exécution trop court, ce qui coupe la génération de la page en plein milieu.
- Un souci de négociation SSL/TLS entre Cloudflare et l’origine, notamment si le certificat côté serveur est expiré ou mal configuré en mode “Full (strict)”.
- Un pare-feu ou une règle de sécurité (ModSecurity, fail2ban, WAF de l’hébergeur) qui bloque silencieusement les IP de Cloudflare au lieu de renvoyer une vraie erreur.
- Une surcharge ponctuelle du serveur (pic de trafic, crawler agressif, attaque) qui rend l’origine incapable de répondre dans les temps.
1. Vérifier si le problème vient vraiment de Cloudflare
Avant de toucher au serveur, isole la variable Cloudflare. Deux méthodes rapides :
- Passer en mode “Pause Cloudflare” dans le dashboard (DNS → icône du petit nuage orange, basculer en gris pour désactiver le proxy temporairement) et recharger le site en pointant directement sur l’IP d’origine.
- Tester l’IP du serveur directement via un fichier
hostslocal, ou en curl :curl -H "Host: tondomaine.fr" https://IP_DU_SERVEUR/.
Si le site répond correctement en direct mais affiche 520 via Cloudflare, le souci est probablement lié aux en-têtes ou au SSL entre les deux couches (voir étapes 4 et 5). Si le site est aussi cassé en direct, le problème est 100 % côté origine — inutile de perdre du temps sur la configuration Cloudflare.
Pour les erreurs voisines où la distinction origine/proxy se pose aussi, la logique est la même que pour l’erreur 523 Cloudflare ou pour un ERR_CONNECTION_TIMED_OUT : toujours commencer par éliminer une couche à la fois.
2. Consulter les logs du serveur d’origine
C’est l’étape la plus rentable en temps. Connecte-toi en SSH (voir le guide SSH sur OVH ou l’équivalent selon ton hébergeur) et regarde :
error_logd’Apache ou Nginx (souvent dans/var/log/apache2/error.logou via le panel de l’hébergeur mutualisé)- Les logs PHP-FPM, qui révèlent souvent un “segmentation fault” ou un “child killed” au moment exact de la 520
- Les logs applicatifs WordPress si
WP_DEBUG_LOGest activé danswp-config.php
Un crash récurrent au même horaire pointe vers une tâche cron ou un plugin lourd. Une erreur isolée pointe vers un pic de charge ponctuel.
3. Vérifier les ressources serveur et les directives PHP
Une origine qui manque de mémoire ou de temps d’exécution peut couper la réponse en plein milieu — et c’est exactement le genre de réponse tronquée que Cloudflare traduit en 520.
| Directive | Rôle | Symptôme si trop basse | Où la régler | Valeur de départ |
|---|---|---|---|---|
memory_limit | Mémoire max allouée à un script PHP | Réponse coupée, page blanche, “Allowed memory size exhausted” | wp-config.php ou php.ini | 256M |
max_execution_time | Temps max d’exécution d’un script | Timeout en plein rendu de page | php.ini ou panel hébergeur | 60-120s |
max_input_time | Temps max pour traiter les données entrantes | Formulaires ou uploads qui échouent | php.ini | 60s |
max_input_vars | Nombre max de variables reçues (formulaires complexes) | Champs de formulaire tronqués | php.ini | 3000 |
post_max_size | Taille max des données POST | Uploads ou formulaires volumineux refusés | php.ini ou .htaccess | 64M |
upload_max_filesize | Taille max d’un fichier uploadé | Échec d’import média ou plugin | php.ini | 64M |
Ces directives se règlent selon l’hébergeur : certains mutualisés imposent un panel dédié, d’autres acceptent un .user.ini ou un .htaccess. Le détail complet, avec les pièges à éviter, est dans le guide des directives PHP WordPress.
4. Vérifier la taille des en-têtes HTTP renvoyés
Un cookie de session trop lourd, un plugin de sécurité qui empile des headers X- inutiles, ou un cache qui duplique des en-têtes : tout ça peut dépasser la limite acceptée par Cloudflare (généralement autour de 32 Ko cumulés). Résultat : Cloudflare rejette la réponse et affiche 520 plutôt que de transmettre un en-tête corrompu.
Pour vérifier : curl -I en direct sur l’origine et compter le poids des en-têtes. Si un plugin (souvent un plugin de sécurité ou de cache trop agressif) génère des cookies énormes, le désactiver temporairement confirme le diagnostic. C’est un problème qu’on retrouve aussi côté performance générale, traité dans le diagnostic complet d’un site lent.
5. Aligner les timeouts et le keep-alive
Si le serveur d’origine coupe la connexion TCP plus vite que Cloudflare n’attend de réponse (ou l’inverse), la connexion se termine en plein échange — Cloudflare voit une réponse incomplète et renvoie 520. Sur Nginx, vérifier keepalive_timeout ; sur Apache, KeepAliveTimeout. Il faut que ces valeurs soient cohérentes avec les timeouts Cloudflare (100 secondes par défaut côté Cloudflare pour une connexion origine).
6. Contrôler le SSL entre Cloudflare et l’origine
En mode “Full (strict)”, Cloudflare exige un certificat valide côté serveur. Un certificat expiré ou auto-signé mal configuré peut faire échouer la poignée de main SSL et produire une 520 plutôt qu’une erreur SSL explicite. Le sujet est détaillé dans l’article sur le certificat SSL expiré (NET::ERR_CERT_DATE_INVALID) — la logique de vérification est identique côté origine.
7. Écarter un blocage de sécurité qui vise les IP Cloudflare
Certains WAF ou règles fail2ban bloquent les IP Cloudflare par erreur, croyant à une attaque distribuée. Vérifie les plages d’IP officielles Cloudflare dans la configuration du pare-feu serveur et whitelist-les si nécessaire.
Tableau récapitulatif
| Cause | Solution |
|---|---|
| Serveur qui crash / redémarre | Consulter les logs, identifier le processus tué |
| En-têtes HTTP trop gros | Réduire cookies, désactiver plugin en cause |
| Mémoire ou temps d’exécution PHP insuffisants | Ajuster memory_limit, max_execution_time |
| Keep-alive mal aligné | Harmoniser les timeouts Nginx/Apache avec Cloudflare |
| SSL invalide côté origine | Renouveler/corriger le certificat |
| WAF bloque les IP Cloudflare | Whitelister les plages IP Cloudflare |
| Surcharge ponctuelle | Vérifier le trafic, limiter les crawlers agressifs |
Schéma : où se situe la panne
FAQ
La 520 est-elle une erreur de mon côté ou celui de Cloudflare ?
Dans l’écrasante majorité des cas, la cause vient du serveur d’origine (crash, ressources épuisées, en-têtes trop gros). Cloudflare ne fait que rapporter une réponse illisible qu’il a reçue — voir l’étape 1 pour confirmer en bypassant le proxy.
Faut-il désactiver Cloudflare complètement pour résoudre une 520 ?
Non, la pause est un outil de diagnostic temporaire. Une fois la cause identifiée et corrigée côté serveur, il faut réactiver le proxy pour conserver les bénéfices de cache et de protection.
Une 520 peut-elle être liée à un pic de trafic ?
Oui : si l’origine ne peut pas absorber toutes les requêtes simultanées, elle peut renvoyer des réponses partielles ou couper des connexions, ce qui se traduit en 520 côté Cloudflare. Un diagnostic de performance plus large est utile dans ce cas, voir l’arbre de décision pour un site inaccessible.
Quelle différence entre une 520 et une 502/504 ?
La 502 signale une réponse invalide d’un serveur en amont, la 504 un délai dépassé. La 520 est spécifique à Cloudflare : elle regroupe des cas où la réponse de l’origine ne correspond à aucun code HTTP standard. Les diagnostics 502 et 504 partagent une bonne partie de la méthode.
Comment éviter que ça se reproduise ?
Surveiller les logs serveur régulièrement, garder les ressources PHP dimensionnées à la charge réelle du site, et maintenir un certificat SSL valide côté origine. Une maintenance suivie limite fortement la récurrence de ce type d’erreur.
Quand passer la main à un pro
Si le bypass Cloudflare confirme que l’origine répond mal, mais que les logs ne montrent rien d’évident après une heure de recherche, ou si le problème réapparaît de façon aléatoire sans schéma clair (pic de trafic, plugin, certificat), c’est le signal pour faire appel à quelqu’un qui a l’habitude de croiser logs serveur, configuration Cloudflare et directives PHP en une seule session. Une 520 mal diagnostiquée revient — et chaque réapparition coûte plus cher en indisponibilité que l’intervention elle-même.
Ce problème, Peechy s'en occupe
Plutôt que de tout gérer seul, confiez votre site à une agence qui s'occupe de tout — hébergement, sécurité, maintenance et corrections. Encore plus simple en abonnement : on règle les soucis avant même que vous les remarquiez.
Confier mon site à Peechy