Le problème : ton site affiche « 523 Origin Is Unreachable »
Un visiteur tape ton nom de domaine et tombe sur une page orange Cloudflare : 523 Origin Is Unreachable. Pas de site, pas d’erreur WordPress classique, juste Cloudflare qui te dit qu’il n’arrive pas à joindre ton serveur d’origine.
Bonne nouvelle : ce n’est presque jamais Cloudflare qui est en panne. C’est un problème de communication entre Cloudflare (qui sert de proxy devant ton site) et le serveur qui héberge réellement tes fichiers. Le DNS pointe vers une IP qui ne répond plus, ou qui n’a jamais été la bonne.
C’est un incident réparable en quelques minutes une fois qu’on sait où regarder. Pas besoin de tout réinstaller, pas besoin de paniquer sur une perte de données : dans l’immense majorité des cas, ton site est intact, c’est juste l’aiguillage réseau qui est cassé.
Pourquoi ça arrive : ce qui casse la liaison Cloudflare → origine
- L’IP du serveur d’origine a changé : migration d’hébergeur, changement de plan, réinstallation d’un VPS — l’ancienne adresse IP dans Cloudflare ne correspond plus à rien.
- L’enregistrement DNS A ou AAAA est faux : une faute de frappe, une IP copiée-collée d’un autre projet, ou un enregistrement resté sur l’ancien hébergeur après une migration.
- Le serveur d’origine est réellement hors service : panne chez l’hébergeur, VPS arrêté, service web (Nginx/Apache) planté.
- Un pare-feu bloque Cloudflare : le serveur d’origine refuse les connexions venant des plages IP Cloudflare (règle firewall trop stricte, fail2ban trop agressif, whitelist mal configurée).
- Le port 80/443 n’est pas ouvert ou n’écoute pas : service web arrêté, certificat SSL cassé côté origine quand le mode Full (strict) est activé.
- Proxy Cloudflare activé sur un enregistrement qui ne devrait pas l’être : par exemple un sous-domaine de test qui pointe vers une IP inactive, mais avec le nuage orange allumé.
1. Vérifie d’abord que ton site répond en direct (sans Cloudflare)
Avant de toucher au DNS, isole la variable Cloudflare. Ouvre un terminal et teste directement l’IP de ton serveur d’origine (celle indiquée dans ton panel d’hébergement) :
ping [IP_ORIGINE]
curl -I http://[IP_ORIGINE]- Si le serveur répond (code 200 ou 301/302), le problème vient bien du DNS ou de la config Cloudflare, pas du serveur lui-même.
- Si rien ne répond, le serveur d’origine est probablement éteint ou injoignable : contacte ton hébergeur en priorité, ou vérifie l’état de ton VPS/instance.
Ce test simple évite de perdre du temps à modifier des enregistrements DNS alors que le vrai souci est un serveur arrêté.
2. Compare l’IP réelle du serveur avec celle enregistrée dans Cloudflare
Direction Cloudflare → ton domaine → DNS → Records. Repère les enregistrements A (IPv4) et AAAA (IPv6) qui pointent vers ton domaine racine (@) et vers www.
Compare cette IP avec l’IP réelle de ton hébergement, disponible dans :
- le panel de ton hébergeur (Hostinger, OVH, IONOS, o2switch…) sous « informations serveur » ou « IP dédiée »,
- ou via SSH si tu as accès au serveur :
curl ifconfig.meexécuté depuis la machine elle-même te donne son IP publique.
Si les deux IP ne correspondent pas, tu as trouvé la cause. C’est le scénario le plus fréquent après une migration d’hébergeur, un changement de plan, ou une reconstruction de VPS : l’ancienne IP reste dans Cloudflare, la nouvelle n’a jamais été renseignée.
Corrige directement dans Cloudflare : clique sur l’enregistrement fautif, remplace la valeur par la bonne IP, sauvegarde. La propagation via Cloudflare est quasi instantanée (contrairement à un changement chez un registrar classique) puisque Cloudflare fait autorité sur ta zone DNS.
3. Vérifie le statut du proxy (nuage orange vs gris)
Chaque enregistrement A/AAAA dans Cloudflare a une icône de nuage :
- Orange (proxy activé) : le trafic passe par Cloudflare, qui doit joindre ton origine pour servir le contenu. C’est ce mode qui déclenche l’erreur 523 en cas de souci.
- Gris (DNS only) : le visiteur va directement sur ton serveur, sans passer par Cloudflare.
Si tu viens de migrer et que tu n’es pas sûr que le serveur d’origine soit stable, passe temporairement l’enregistrement en gris pour confirmer que le site fonctionne en direct. Une fois le DNS confirmé bon et stable, remets le proxy en orange pour profiter du cache et de la protection Cloudflare.
4. Contrôle le mode SSL/TLS (source d’un faux 523)
Dans SSL/TLS → Overview sur Cloudflare, regarde le mode choisi :
- Full (strict) exige un certificat SSL valide sur le serveur d’origine. Si ce certificat est expiré ou absent, Cloudflare peut renvoyer une 523 ou une 526 selon les cas.
- Full (non strict) accepte un certificat auto-signé, plus tolérant en phase de dépannage.
- Flexible ne chiffre que la connexion visiteur → Cloudflare, pas Cloudflare → origine.
Si tu viens de changer de mode SSL sans avoir vérifié que le certificat côté serveur est en place, c’est un point à contrôler. Voir aussi l’article sur le certificat SSL expiré si tu suspectes ce cas précis.
5. Vérifie que le pare-feu du serveur autorise les IP Cloudflare
Certains serveurs (surtout ceux protégés par fail2ban, un WAF maison, ou un firewall Plesk/cPanel strict) bloquent les connexions qui ne viennent pas directement d’un navigateur, et rejettent les plages IP de Cloudflare par erreur.
Demande à ton hébergeur (ou vérifie via SSH, voir se connecter en SSH) que les plages IP officielles de Cloudflare sont autorisées en entrée sur les ports 80 et 443. C’est un point souvent oublié après un durcissement de sécurité suite à un piratage — voir aussi le guide site WordPress piraté si le blocage a été mis en place après un incident de sécurité.
6. Redémarre proprement le service web côté origine
Si le DNS est correct et que le pare-feu laisse passer Cloudflare, mais que le 523 persiste, le service web lui-même (Nginx, Apache, ou le conteneur applicatif) peut être arrêté ou planté.
Connecte-toi en SSH ou via le panel de ton hébergeur (SSH sur Plesk ou SSH sur Gandi selon ton cas) et vérifie l’état du service :
systemctl status nginx
systemctl status apache2Un redémarrage propre du service suffit souvent à rétablir la liaison. Si le service redémarre puis replante immédiatement, le problème est ailleurs (mémoire saturée, configuration cassée) — direction les logs serveur pour identifier la cause exacte.
Tableau récapitulatif : cause → solution
| Cause probable | Comment vérifier | Solution |
|---|---|---|
| IP d’origine changée (migration) | Comparer IP hébergeur vs IP dans Cloudflare DNS | Mettre à jour l’enregistrement A/AAAA |
| Enregistrement DNS faux | Vérifier chaque record A/AAAA du domaine et www | Corriger la valeur dans Cloudflare → DNS |
| Serveur d’origine éteint | ping et curl sur l’IP directe | Redémarrer le serveur/VPS, contacter l’hébergeur |
| Pare-feu bloque Cloudflare | Vérifier les règles firewall côté serveur | Autoriser les plages IP Cloudflare sur 80/443 |
| Certificat SSL cassé en mode Full strict | Vérifier la validité du certificat origine | Renouveler le certificat ou passer en Full (non strict) temporairement |
| Service web planté | systemctl status nginx/apache2 | Redémarrer le service, analyser les logs |
FAQ
La 523 veut-elle dire que mes données sont perdues ?
Non. La 523 est une erreur de communication réseau entre Cloudflare et ton serveur, elle ne touche pas aux fichiers ni à la base de données. Ton site est très probablement intact une fois la liaison DNS rétablie.
Pourquoi le site fonctionne en local mais affiche 523 en ligne ?
Parce que le test en local ne passe pas par Cloudflare. Si ton site répond en direct sur l’IP du serveur mais pas via ton nom de domaine, le problème est presque toujours l’enregistrement DNS dans Cloudflare, pas le serveur lui-même.
Faut-il désactiver le proxy Cloudflare en attendant de résoudre le 523 ?
Oui, temporairement. Passer l’enregistrement en gris (DNS only) permet de confirmer que le serveur répond correctement en direct, le temps de corriger l’IP ou le pare-feu, avant de remettre le proxy orange.
Le 523 peut-il venir d'un problème de DNS pas encore propagé ?
Rarement avec Cloudflare, car Cloudflare fait autorité sur sa propre zone DNS et applique les changements quasi instantanément. Si tu viens de changer de registrar ou de nameservers, vérifie plutôt la propagation avec le guide sur les DNS qui ne propagent pas.
Est-ce lié à un problème sur Hostinger ou IONOS spécifiquement ?
Non, la 523 est une erreur Cloudflare, indépendante de l’hébergeur. Mais si tu configures tes DNS chez Hostinger ou IONOS en parallèle de Cloudflare, vérifie la cohérence des enregistrements avec les guides DNS Hostinger ou DNS IONOS.
Quand passer la main à un pro
Si après avoir vérifié IP, DNS, pare-feu et service web le 523 persiste, ou si tu ne sais pas identifier l’IP réelle de ton serveur, c’est le signal qu’une intervention technique est nécessaire plutôt qu’un nouveau tâtonnement. Un DNS mal configuré peut aussi masquer un souci plus profond (serveur mutualisé saturé, migration incomplète, configuration réseau héritée d’un ancien prestataire). Une maintenance suivie évite justement ce genre d’incident : quelqu’un surveille la cohérence DNS/hébergement avant que le visiteur ne tombe sur la page orange.
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