Causes courantes de panne d’un site web

Quand un site web tombe, le premier réflexe est de deviner la cause. Redémarrer le serveur. Annuler la mise en production. Appeler l’hébergeur. Parfois, cela marche. Le plus souvent, on perd les vingt premières minutes.

Mieux vaut commencer par dire précisément ce que vous voyez. Le symptôme réduit la cause à une ou deux couches, et chaque couche a sa propre première vérification. Ce guide repose sur cette idée. Pour la définition d’une panne et de ses effets, consultez temps d’arrêt d’un site web.

Est-il en panne pour tout le monde ?

Avant de modifier quoi que ce soit, déterminez qui est touché.

• Ouvrez le site depuis un téléphone en données mobiles, pas depuis le réseau de votre bureau.
• Regardez ce que votre surveillance a enregistré : quand le premier échec s’est produit et quel en était le motif.
• Demandez à un collègue situé ailleurs d’essayer.
• Vérifiez si une seule page, un seul pays ou un seul type d’appareil échoue.

Si vous êtes le seul à voir le problème, la cause est probablement locale : votre réseau, une réponse DNS en cache, un VPN ou une extension de navigateur. Si tout le monde le voit, poursuivez ci-dessous.

Du symptôme à la première vérification

La RFC 9110 définit les trois codes de passerelle. Un 502 signifie qu’une passerelle ou un proxy a reçu une réponse invalide du serveur situé derrière lui. Un 503 signifie que le serveur ne peut pas traiter la requête pour le moment, généralement à cause d’une surcharge ou d’une maintenance, et peut inclure un en-tête Retry-After. Un 504 signifie que la passerelle n’a pas reçu de réponse à temps. Dans les trois cas, la porte d’entrée est ouverte et le problème se situe plus loin.

Commandes pour un premier coup d’œil

Depuis n’importe quelle machine dotée d’un terminal :

curl -I https://example.com/

Cette commande affiche la ligne d’état et les en-têtes, sans le corps de la réponse. Pour plus de détails, y compris la résolution DNS, la connexion et l’étape du certificat, ajoutez -v :

curl -v https://example.com/ -o /dev/null

L’endroit où la sortie s’arrête vous indique où ça échoue. Si elle s’arrête avant « Connected », le problème vient du nom ou du réseau. Si elle s’arrête à l’étape du certificat, examinez le certificat. Si vous obtenez une ligne d’état, le serveur a répondu, et l’état vous indique la suite.

Serveur et hébergement

La machine peut être éteinte, à court de mémoire, à court d’espace disque ou surchargée. Un disque plein est discret : les bases de données arrêtent d’écrire, les journaux se remplissent et l’application se met à échouer de façon étrange.

Consultez d’abord la page de statut de l’hébergeur, puis la machine elle-même : processus en cours, mémoire, disque et charge. Un incident chez votre fournisseur cloud peut ressembler exactement à une défaillance de votre côté ; regardez donc sa page de statut avant de passer une heure sur votre configuration.

Application et déploiements

Une mise en production ratée est l’une des causes les plus courantes d’une panne qui démarre à une minute précise. Si l’échec a commencé juste après un déploiement, revenez d’abord en arrière et enquêtez ensuite.

Les signes typiques sont des erreurs 500, une page blanche ou une application qui démarre puis s’arrête. Le journal de l’application au moment du premier échec nomme généralement l’exception. Une nouvelle dépendance non installée, une valeur d’environnement manquante et une modification de base de données que le code n’attend pas sont des causes fréquentes.

Proxys, répartiteurs de charge et CDN

De nombreux sites se trouvent derrière un proxy inverse, un répartiteur de charge ou un réseau de diffusion de contenu. Quand le proxy fonctionne et que le serveur derrière lui ne fonctionne pas, les visiteurs voient un 502 ou un 504, souvent sur une page aux couleurs du proxy. Cet habillage vous indique que la couche avant est vivante et qu’il faut regarder derrière.

Consultez le journal du proxy pour y trouver l’erreur en amont. Un délai d’attente du proxy plus court que la requête la plus lente de l’application produira des erreurs 504 même si l’application est saine.

DNS et domaine

Si le nom cesse de se résoudre, le site est inaccessible, quel que soit l’état du serveur. Les causes comprennent un enregistrement supprimé, un serveur de noms modifié, une panne du fournisseur et un domaine expiré.

Suivez Comment dépanner les erreurs de résolution DNS pour trouver la couche concernée, et vérifiez l’enregistrement avec Comment vérifier la date d’expiration d’un domaine.

Certificats

Un certificat expiré, ou émis pour un autre nom, fait afficher aux navigateurs un avertissement en pleine page. Le serveur fonctionne, mais les visiteurs ne passeront pas. Vérifiez les dates et les noms figurant sur le certificat. La cause et la prévention sont expliquées dans Comment éviter l’expiration d’un certificat SSL.

Surcharge

Un pic de trafic, une lourde tâche de fond ou un moteur de recherche qui explore le site trop vite peuvent épuiser toute la capacité. Les signes sont d’abord des pages lentes, puis des erreurs 503 ou 504, puis des délais dépassés. Cela se rétablit souvent sans intervention et revient au pic suivant.

Regardez le graphique de charge dans les minutes précédant le premier échec. Si les temps de réponse ont augmenté régulièrement avant la panne, la surcharge est probable.

Services tiers

Une page peut se charger alors qu’une fonction échoue : paiement, connexion, recherche ou carte. Le service qui se trouve derrière est en panne ou lent. De l’extérieur, le site paraît en ligne. Lisez l’erreur que l’application consigne pour l’appel défaillant et consultez la page de statut du fournisseur.

Ce qu’un moniteur peut vous apprendre

Une vérification depuis l’extérieur, comme celle d’UptimeWire, interroge l’adresse et lit la réponse. Pour une vérification échouée, elle enregistre un motif. Les motifs qu’elle distingue comprennent :

• le nom de domaine n’a pas pu être résolu,
• la connexion a échoué,
• aucune réponse dans les 15 secondes,
• le certificat TLS ou la connexion n’est pas valide,
• le serveur a répondu avec un code d’état donné,
• le texte attendu n’a pas été trouvé sur la page.

Ce motif vous oriente vers la bonne ligne du tableau ci-dessus avant même d’ouvrir un serveur. UptimeWire ouvre un incident après trois vérifications échouées d’affilée, espacées d’environ 20 secondes, et conserve le motif avec lui. Consultez Comment surveiller la disponibilité d’un site web pour la mise en place.

Une vérification qui lit un code d’état ne peut pas voir une connexion qui rejette tous les mots de passe. Voir aussi pourquoi les moniteurs envoient de fausses alertes pour le problème inverse.

Après le rétablissement

Une fois que le site répond de nouveau, notez :

• l’heure du premier échec et l’heure du rétablissement,
• le symptôme et la cause,
• ce qui a réglé le problème,
• ce qui vous aurait permis de le remarquer plus tôt.

Ces quatre lignes suffisent pour transformer une panne en quelque chose d’utile à la personne suivante.

Liste de contrôle

• Énoncez le symptôme en une phrase.
• Vérifiez si tout le monde est touché.
• Lisez le motif d’échec enregistré.
• Lancez curl -v et voyez où ça s’arrête.
• Vérifiez le dernier déploiement ou la dernière modification.
• Vérifiez le DNS, le domaine et le certificat, qui échouent sans aucun changement de votre côté.
• Notez la cause et la correction.