Un sous-domaine passe en erreur 500 pendant que le domaine principal répond normalement : le réflexe consiste à chercher un souci Cloudflare global, alors que la cause se loge presque toujours dans la configuration propre au sous-domaine. DNS mal renseigné, proxy activé sur un enregistrement qui pointe vers rien, certificat non couvert : trois pistes à vérifier avant d’appeler qui que ce soit. Pour la définition générale de l’erreur et ses causes côté serveur d’origine, l’article Erreur 500 sur le réseau Cloudflare : causes et solutions pose déjà les bases.
Pourquoi le sous-domaine plante alors que le domaine principal tourne ?
Un sous-domaine n’hérite de rien automatiquement. Il possède son propre enregistrement DNS, parfois son propre serveur ou sa propre application et donc ses propres failles. Le domaine racine pointe parfois vers un hébergement fonctionnel pendant que blog. ou boutique. vise une adresse IP obsolète, une application arrêtée ou un chemin de fichiers qui n’existe plus. Le cache Cloudflare complique parfois le diagnostic : une réponse 500 générée une seule fois par l’origine reste parfois servie aux visiteurs le temps que le cache expire, donnant l’impression d’une panne persistante alors que le serveur d’origine a déjà repris la main. C’est exactement ce qui explique certains cas documentés sur les forums Cloudflare, où le blocage disparaît après un simple vidage de cache une fois les enregistrements DNS corrigés.
DNS, proxy et certificat : les réglages propres à chaque sous-domaine
Un sous-domaine réclame les mêmes briques qu’un domaine classique mais chacune se crée séparément dans l’onglet DNS du tableau de bord Cloudflare.
| Enregistrement | Rôle pour le sous-domaine | Erreur fréquente |
|---|---|---|
| A | Pointe vers l’IP du serveur qui héberge le sous-domaine | IP copiée du domaine principal, invalide pour ce serveur |
| CNAME | Redirige le sous-domaine vers un autre nom d’hôte | Cible qui ne pointe elle-même vers rien |
| TXT (DKIM, SPF) | Authentifie les services liés (mail, API) | Absence totale sur le sous-domaine, sans lien direct avec le 500 mais souvent oubliée en même temps |
Le nuage orange (proxy activé) change aussi la donne. Un sous-domaine laissé en proxy actif alors que le serveur cible n’est pas prêt à répondre correctement renvoie une erreur générée par Cloudflare et non par l’origine. Vérifier le mode SSL/TLS choisi compte tout autant : un mode « Flexible » ou « Full » mal adapté au certificat réellement installé sur le serveur du sous-domaine génère des erreurs de connexion à l’origine, que Cloudflare traduit parfois en 500.
Isoler la panne : passer le sous-domaine en DNS only
Avant de contacter qui que ce soit, quelques manipulations séparent en quelques minutes un problème d’origine d’un problème de configuration Cloudflare.
- Désactiver le proxy (nuage gris) sur l’enregistrement du sous-domaine concerné et recharger la page en direct
- Consulter
sous-domaine.exemple.com/cdn-cgi/tracepour confirmer que la requête atteint bien Cloudflare et repérer l’heure exacte de l’erreur - Vérifier dans les logs de l’hébergeur si le serveur d’origine renvoie lui-même un 500 au même horodatage
- Vider le cache Cloudflare pour ce sous-domaine une fois la correction appliquée côté origine
Si la page fonctionne en direct (nuage gris) mais échoue en proxy (nuage orange), le blocage vient bien de la configuration Cloudflare du sous-domaine et non du serveur. D’autres pannes propres à la couche proxy suivent la même logique de diagnostic : le message 503 backend fetch failed se résout lui aussi en basculant temporairement en DNS only pour vérifier si l’origine répond correctement.
Un certificat expiré peut-il provoquer une erreur 500 sur le sous-domaine ?
Techniquement, un certificat SSL périmé ou absent sur le serveur d’origine du sous-domaine déclenche plutôt une erreur 526 (certificat invalide) qu’une 500 pure. Dans la pratique, les deux se confondent souvent pour un visiteur pressé. Un infogérant qui installe un certificat directement sur le serveur sans passer par l’interface Cloudflare crée un décalage fréquent : le domaine principal reste correctement couvert pendant que le sous-domaine se retrouve laissé de côté. Le mode SSL reste identique pour l’ensemble de la zone dans l’idéal : contrôler que le sous-domaine partage bien le même certificat que le domaine racine (via un certificat wildcard côté Cloudflare, par exemple) évite ce genre de décalage.
Quand le problème vient réellement de Cloudflare ?
Une erreur 500 dont le corps HTML mentionne littéralement « cloudflare » ou « cloudflare-nginx » sort du champ d’un simple réglage DNS. Dans ce cas précis, direction le support Cloudflare avec trois éléments prêts : le nom de domaine complet incluant le sous-domaine, l’heure exacte de l’incident avec le fuseau horaire et le résultat de la page /cdn-cgi/trace. Une modification récente de Page Rules, de Transform Rules ou d’un Worker attaché à ce sous-domaine mérite aussi d’être passée en revue avant d’ouvrir un ticket : ces réglages s’appliquent parfois à un seul hôte sans que l’administrateur s’en souvienne.
