Mon site Web est-il en panne ? Comment trouver ce qui cloche

D'abord, écartez votre propre réseau - trente secondes suffisent

Avant de toucher à quoi que ce soit sur le serveur, déterminez si le problème se situe entre vous et Internet plutôt que du côté du site :

• Ouvrez le site sur votre téléphone, Wi-Fi désactivé, avec les données cellulaires. C'est un tout autre chemin vers le même serveur. Si la page s'affiche, votre site fonctionne et le problème vient de votre réseau, de votre routeur ou du DNS de votre fournisseur Internet.
• Essayez une fenêtre privée ou un autre navigateur. Cela écarte une redirection en cache, une session périmée ou une extension qui fait des siennes.
• Essayez une autre page du même site. Une seule page en erreur, ce n'est pas la même chose qu'un site qui ne répond pas du tout.

Cette étape règle une bonne part des paniques du genre « mon site est en panne », et elle ne coûte rien.

Ensuite, descendez les quatre couches, dans l'ordre

Un site Web est un empilement de choses qui doivent toutes fonctionner, et une panne dans le bas de la pile donne l'impression que tout ce qui se trouve au-dessus est brisé lui aussi. Vérifiez-les dans cet ordre et arrêtez-vous à la première qui échoue : c'est là qu'est votre vrai problème, et le reste n'est que du bruit.

1. Le nom se traduit-il encore en adresse ? (le DNS)

Avant que quoi que ce soit puisse se connecter à votre site, votre domaine doit se traduire en adresse IP. Sinon, rien de ce qui se trouve au-dessus n'a d'importance.

Cette couche lâche de façons banales et fréquentes : un domaine expiré sans que personne s'en aperçoive, un changement de serveurs de noms qui n'a pas fini de se propager, un enregistrement DNS modifié la semaine dernière, ou une mise en attente chez le registraire qui retire carrément le domaine du DNS. C'est aussi la couche qui ressemble le plus à un problème de serveur alors qu'elle n'en est pas un.

Vérifiez-la avec la recherche d'enregistrements DNS. Si votre nom ne se résout pas, arrêtez-vous ici : réparer votre serveur Web n'y changera rien.

2. Quelque chose répond-il à cette adresse ? (le serveur)

Le nom se résout : il faut maintenant que quelque chose accepte une connexion à cette adresse. Si rien ne l'accepte, le serveur - ou ce qui se trouve devant lui - est éteint, n'a pas fini de démarrer, manque de mémoire, ou bloque la requête au pare-feu.

C'est la couche à laquelle les gens pensent quand ils disent « le site est down », et c'est celle où il faut vraiment aller voir la machine.

3. La connexion sécurisée fonctionne-t-elle ? (le certificat)

Si quelque chose répond mais que la connexion échoue avant l'affichage de la moindre page, c'est une bonne nouvelle à sa manière : votre serveur fonctionne. Le problème vient de son certificat ou de sa configuration HTTPS - un certificat expiré, un renouvellement qui a échoué en silence il y a des semaines, un certificat émis pour le mauvais nom, un certificat intermédiaire manquant.

C'est une réparation bien plus légère que celle d'un serveur mort, et mieux vaut savoir à laquelle des deux vous avez affaire avant de commencer. La vérification du cadenas (SSL/TLS) vous dit ce que contient le certificat et quand il expire. Si c'est le renouvellement lui-même qui bloque, la vérification de renouvellement Let's Encrypt examine précisément ce qui empêche l'émission d'un certificat.

4. Le serveur renvoie-t-il vraiment votre site ? (le code de réponse HTTP)

La dernière couche est celle qui sépare « répondre » de « fonctionner ». Un serveur peut accepter votre connexion, établir la connexion chiffrée, puis vous renvoyer une page d'erreur au lieu de votre site.

C'est ce que dit le code de réponse, et le vérificateur d'en-têtes de sécurité vous montre le vrai code - ainsi que la couche qui a lâché, si la requête n'est pas allée jusque-là.

Le piège : « pourtant le ping passe »

Voici la partie à lire deux fois, parce que c'est là que la plupart des gens obtiennent une réponse fausse en pensant avoir la bonne.

Si votre site se trouve derrière Cloudflare, Shopify, Squarespace, Wix ou un service semblable - et c'est maintenant le cas de la plupart des sites de PME - alors ce n'est pas votre site que le ping atteint. Ce sont leurs serveurs de bordure, les machines que ces services placent devant le vôtre un peu partout dans le monde : immenses, réparties sur la planète et pour ainsi dire jamais en panne. Ils répondront allègrement pendant que votre véritable serveur, derrière eux, est mort.

C'est exactement le sens d'une page Error 521 de Cloudflare : la bordure va bien, votre serveur d'origine, non. Un ping ne voit pas cette différence. Aucun outil qui se contente de demander « est-ce que cette machine répond ? » ne la voit non plus. Seule une vraie requête, qui revient avec un vrai code de réponse, en est capable.

L'erreur joue aussi dans l'autre sens : bien des serveurs en parfaite santé sont configurés pour ignorer le ping, si bien qu'une absence de réponse ne prouve rien non plus. Les deux erreurs existent, et la rassurante - « votre site fonctionne » alors qu'il est en panne - est la plus dangereuse des deux.

Ce que veulent dire les codes d'erreur courants

• 521, 522, 523 (Cloudflare). La bordure fonctionne et votre serveur d'origine ne lui répond pas. Votre problème est à la couche 2 ci-dessus, sur votre propre machine.
• 502 Bad Gateway. Le serveur placé devant votre application l'a jointe et a reçu n'importe quoi en retour - très souvent, l'application a planté et le serveur Web devant elle tourne toujours.
• 503 Service Unavailable. Le serveur dit délibérément « pas maintenant » : surcharge, redémarrage ou mode maintenance.
• 500 Internal Server Error. Votre application s'est exécutée et a levé une erreur. Le serveur va bien; votre code ou sa base de données, non.
• 403 Forbidden. Quelque chose refuse volontairement : des droits d'accès, une règle de pare-feu ou une extension de sécurité qui a décidé que vous étiez une menace.
• 404 Not Found. Le serveur fonctionne parfaitement et cette page n'existe pas. Ce n'est pas une panne de site.

Remarquez que dans tous ces cas, votre serveur a répondu. C'est une bien meilleure position que le silence, et c'est le signe d'une réparation bien plus légère.

Pourquoi deux sites de vérification de panne se contredisent

Parce qu'ils ne sont pas au même endroit. Un site vérifié depuis Toronto, depuis Francfort et depuis Singapour peut réellement fonctionner à un endroit et pas à l'autre : un changement DNS qui n'a pas fini de se propager, une panne de réseau régionale, ou un serveur de bordure qui a des ratés.

La même limite vaut pour nous, et nous préférons le dire : nos vérifications partent d'un seul endroit, au Canada. Si tout semble en bonne santé ici mais que le site refuse quand même de se charger chez vous, c'est justement cet écart qui est votre réponse - essayez avec les données cellulaires, et demandez à quelqu'un d'une autre ville d'essayer aussi.

Si ce n'est pas votre site

Si vous voulez simplement acheter quelque chose et que la boutique ne se charge pas, le premier réflexe reste le même : essayez avec les données cellulaires. Ensuite, attention à la suite. « Ce site est en panne, prenez plutôt ce lien-ci » est un montage courant pour vous amener sur une boutique sosie, et chercher le nom d'un commerçant dont le site est en panne est un bon moyen d'aboutir là où vous ne vouliez pas aller. Si un lien vous arrive alors que vous êtes déjà à bout de patience, vérifiez-le avant de cliquer.

La version courte

Essayez d'abord votre téléphone avec les données cellulaires. Vérifiez ensuite, dans l'ordre : le nom se résout-il, quelque chose répond-il, le certificat fonctionne-t-il, et que renvoie réellement le serveur. Arrêtez-vous à la première panne. Et ne vous fiez pas au ping : derrière un réseau de diffusion de contenu (CDN), il vous dira que tout va bien pendant que votre site est en panne. Voyez ce que votre serveur renvoie vraiment.