Kinsta ou o2switch pour détecter une panne WordPress masquée par le cache

Une page WordPress peut répondre 200 pendant une panne d’origine

Votre page d’accueil s’ouvre et le contrôle externe indique HTTP 200. En parallèle, une requête qui atteint l’application WordPress reçoit HTTP 503. Les deux observations peuvent être exactes. Une page déjà stockée dans un cache intermédiaire reste parfois lisible pendant que le serveur qui doit générer de nouvelles réponses est indisponible. Le suivi de la page publique décrit alors ce que voit une partie des visiteurs. Il faut une deuxième mesure pour connaître l’état du traitement d’origine.

Le premier cas est celui d’une copie encore fraîche. Un cache peut la renvoyer sans appeler l’origine. Le deuxième cas intervient après la fin de la fraîcheur. La directive HTTP `stale-if-error` permet, lorsqu’elle est prise en charge et autorisée par la politique effective du cache, de servir une ancienne réponse après certaines erreurs d’origine. Dans les deux cas, le visiteur peut recevoir HTTP 200 et exactement les mêmes octets. Le mécanisme qui produit ce résultat est différent, ce que l’on peut vérifier en comparant les traces des requêtes et l’âge de la réponse.

Le comparatif examine les moyens documentés de retrouver ces traces chez Kinsta et o2switch. L’exercice local utilise un serveur d’origine et un cache simplifié qui communiquent par HTTP. Il permet d’observer le résultat public, la réponse de l’origine et la fin de la fenêtre de secours dans une chronologie reproductible. Les politiques réelles des deux hébergeurs doivent être vérifiées pour le site concerné.

Prélever la réponse publique avant de toucher au cache

Choisissez une page publique représentative, sans session utilisateur. Notez le domaine, l’adresse complète, l’heure avec son fuseau et la zone depuis laquelle le contrôle part. Lancez une requête GET et relevez le statut, `Age` s’il est présent, `Cache-Control` et les en-têtes propres à la couche de cache. Gardez aussi un petit témoin de version ou une empreinte du corps si cette page permet une comparaison stable. Sur PowerShell, une requête peut être conservée avec `curl.exe -sS -D entetes.txt -o page-recue.html "$url"`, après avoir placé dans `$url` l’adresse de recette.

Un en-tête d’âge aide à dater la copie. Il ne permet pas à lui seul d’affirmer que l’origine vient d’être interrogée, ni que la politique de secours est active. Les valeurs de diagnostic du fournisseur et les journaux complètent la mesure. Une première réponse qui paraît ancienne peut provenir du cache de page, d’un réseau de diffusion ou d’une couche ajoutée au site. Relevez les indices de chaque couche avant de purger, car la purge peut faire disparaître le témoin de la panne.

Si la page redirige, identifiez la réponse finale et vérifiez que le contrôle public et la mesure de recette ciblent bien la même application. Pour une page qui varie selon une session ou une langue, documentez la variante testée. Un navigateur en fenêtre privée écarte certains effets locaux, tout en pouvant encore recevoir une copie partagée. Le test doit donc conserver ce que la réponse et les journaux permettent d’observer sur l’ensemble du trajet.

• Relever l’URL, l’heure, le statut HTTP et les en-têtes du cache avant toute purge.
• Comparer l’empreinte ou le témoin de version de la réponse publique avec celui de la version attendue.

Ajouter une mesure qui exécute réellement l’application

Choisissez un contrôle de lecture léger qui passe dans WordPress ou dans le composant que vous voulez surveiller. Une image statique ou un fichier texte peut répondre alors que PHP est arrêté. Sur une recette autorisée, utilisez un chemin de diagnostic prévu à cet effet ou un contrôle applicatif déjà en place. Vérifiez qu’il suit la même application, qu’il ne crée ni commande ni contenu, et qu’il peut renvoyer une erreur lorsqu’un service dont il dépend devient indisponible.

Configurez ce chemin pour que la réponse ne soit pas stockée, puis vérifiez son traitement dans chaque cache actif. `Cache-Control: no-store` est un signal standard de la réponse. Une règle qui met quand même cette adresse en cache, ou une copie enregistrée avant la modification, peut rendre la mesure trompeuse. Confirmez le passage à l’origine avec les journaux et contrôlez plusieurs lectures. L’ajout d’un paramètre aléatoire ne suffit pas si le cache ignore ce paramètre ou si le traitement prend un autre chemin.

Conservez les deux mesures pendant l’incident. La page publique renseigne sur la continuité de l’affichage. Le contrôle applicatif renseigne sur ce qu’exécute le serveur. Si la page répond 200 et le contrôle 503, rapprochez l’heure du journal PHP ou serveur. Si seul le contrôle échoue, vérifiez aussi ses propres dépendances avant d’attribuer la panne à tout WordPress. Un témoin de bon fonctionnement doit rester limité et interprétable.

Kinsta Launch, confronter les en-têtes aux journaux MyKinsta

Dans MyKinsta, ouvrez Sites et sélectionnez le site. La documentation distingue le cache de page du site et le cache en périphérie. Pour identifier la couche qui a servi une page, Kinsta documente `X-Kinsta-Cache` pour le cache du site et `Ki-CF-Cache-Status` avec `ki-cache-type` pour le cache en périphérie. Relevez les valeurs de la réponse effectivement reçue. Un indicateur de cache indique la couche et son état. Pour comprendre pourquoi l’origine est inaccessible, rapprochez-le du journal qui correspond à l’heure du test.

Dans l’onglet Journaux du site, recherchez la requête de la sonde et les erreurs de la même période. Les journaux documentés incluent `access.log`, `error.log` et `kinsta-cache-perf.log`. Une ligne qui montre une réponse du cache et une autre qui montre une erreur de l’application donnent deux éléments complémentaires. Le cache en périphérie repose sur la réponse déjà mise en cache au niveau du site. Lors d’une recette, vérifiez donc l’exclusion de la sonde sur les couches qui s’appliquent au domaine, avec les réglages pris en charge.

Kinsta indique que le cache en périphérie n’est pas disponible dans l’environnement de préproduction standard et qu’il est incompatible avec la protection par mot de passe. La copie privée peut servir à tester le comportement applicatif de la sonde. Pour vérifier les en-têtes en périphérie, utilisez les accès et le périmètre approuvés pour l’environnement concerné. Sur le site public, observez les réponses et les journaux existants. Provoquez la panne uniquement dans la recette locale.

o2switch Grow, retrouver le cache réellement actif sur le domaine

Dans cPanel, confirmez le domaine concerné et l’outil de cache qui s’y applique. o2switch documente l’activation de LiteSpeed LSCache par domaine, avec l’extension correspondante côté WordPress lorsque ce parcours est retenu. La documentation LiteSpeed cite `X-LiteSpeed-Cache` parmi les en-têtes de diagnostic. Relevez-le s’il est disponible sur votre réponse et vérifiez si une autre couche a répondu. Commencez avec les réglages existants pour que la mesure corresponde à l’incident observé.

Depuis les outils de mesure de cPanel, récupérez le journal d’accès du domaine et cherchez le contrôle de recette à l’heure notée. Si vous avez configuré l’exclusion d’une URI de diagnostic dans le système de cache, vérifiez qu’elle est réellement prise en compte. Faites deux lectures consécutives et cherchez les deux requêtes dans le journal qui prouve leur passage à l’application. Une trace du cache ou du serveur web peut nécessiter d’être complétée par un journal applicatif privé.

La procédure d’activation LSCache décrite par o2switch comporte des restrictions pour les sous-domaines. Un sous-domaine de recette peut donc avoir un trajet différent de celui du domaine principal. Utilisez cette copie pour vérifier la sonde et ses dépendances, puis relevez le comportement du domaine de production sans changer sa configuration pendant la collecte. Si la recette a introduit une exclusion temporaire, retirez-la après validation et vérifiez l’état du chemin concerné.

Offres et conditions vérifiées le 11 novembre 2026

Le tarif mensuel Kinsta Launch relevé sur la page française est de 0 USD le premier mois, puis 17,50 USD HT par mois pendant trois mois, puis 35 USD HT par mois. La campagne affichée est réservée aux nouveaux clients et prend fin le 1er décembre 2026. Douze mois à cette séquence représentent 332,50 USD HT, si le tarif et le périmètre restent les mêmes. Confirmez au récapitulatif les taxes, la date du premier débit et le montant applicable. L’offre décrit une installation WordPress et 15 Go de stockage.

o2switch Grow est affiché à 7 € HT par mois en équivalent, soit 84 € HT payés pour douze mois. La fiche d’aide indique 84 € HT au tarif relevé pour un renouvellement annuel. Le domaine est annoncé gratuit la première année. Relevez son prix pour l’échéance suivante et le total TTC du dossier. La fiche présente huit threads vCPU et 16 Go de RAM. Ces ressources servent à situer le forfait, tandis que les journaux et le comportement de la sonde permettent de vérifier la panne d’origine.

Les prix gardent leur devise et leur calendrier d’origine. La période payée d’avance chez o2switch et la suite de débits mensuels chez Kinsta doivent être reportées séparément pour comparer un budget. Pour ce scénario, identifiez aussi qui possède les droits de lecture des journaux, qui peut vérifier une exclusion de cache et comment le rétablissement sera confirmé. Ces éléments déterminent si l’équipe peut diagnostiquer la différence entre un 200 public et un 503 d’origine.

Mesurer la durée du secours avant de conclure au rétablissement

Dans l’exercice, la réponse d’origine annonce une fraîcheur de 10 secondes et 20 secondes de secours après l’expiration. À 5 secondes, le cache a cinq secondes et aucune nouvelle requête n’est adressée à l’origine. À 15 secondes, la copie a dépassé sa fraîcheur de cinq secondes. Le cache de recette interroge alors l’origine, reçoit 503, puis sert la copie ancienne. À 31 secondes, la copie a dépassé de 21 secondes sa période de fraîcheur. Elle sort de la fenêtre simulée de secours et le résultat public devient 503.

Pour un site réel, relevez la durée et les règles de la couche qui a servi la réponse. Une valeur `Age` plus grande que la fraîcheur observée peut être compatible avec une réponse ancienne, mais le calcul dépend de la politique effective, des en-têtes et des couches intermédiaires. Cherchez la trace de l’erreur d’origine avant d’attribuer le 200 au secours. Si la copie était encore fraîche, le cache peut avoir répondu sans constater la panne. Si la politique de secours n’est pas documentée dans votre offre, traitez le motif du 200 comme une hypothèse à confirmer.

Conservez une mesure séparée pour les chemins personnalisés ou transactionnels. Une page publique servie en cache peut rester lisible alors qu’un formulaire, un panier ou une connexion ne fonctionne plus. Validez le trajet de la sonde sans déclencher d’action réelle. Si la mesure confirme une panne, utilisez le journal qui correspond à l’application et à l’heure du test. Après la correction, vérifiez la sonde et relisez la page publique avant d’annoncer le rétablissement.

Vérifier le retour de l’origine et la page effectivement servie

Lorsque l’application répond de nouveau, vérifiez que la sonde reçoit le statut attendu et un témoin de réponse généré par l’application. Contrôlez aussi le retour au fonctionnement du chemin utilisateur concerné dans votre recette. La page publique peut encore afficher la version qui était en cache avant la panne. Relevez son âge ou son témoin de version et comparez-le à la réponse que l’origine doit maintenant produire. Ce rapprochement permet de distinguer un rétablissement réel d’une simple continuité d’affichage.

Si une purge ciblée est nécessaire après la reprise, utilisez celle qui correspond au domaine, à l’URL et à la couche identifiée. Rejouez la requête publique et attendez de constater le nouveau contenu, en tenant compte du délai d’application indiqué pour le cache. Pendant un incident actif, une purge globale peut retirer la copie encore lisible pour certains visiteurs. Préservez le relevé initial et choisissez le moment de l’invalidation après avoir mesuré l’origine.

Si vous aviez ajouté une sonde temporaire ou modifié une règle pour la recette, conservez les relevés puis restaurez la configuration de départ sur la copie. Relisez les chemins concernés après le retour. Une sonde permanente doit rester minimale, protégée si nécessaire et vérifiée à chaque changement de couche de cache. Le résultat attendu est une preuve récente de l’état applicatif à côté du contrôle de la page publique.

• Confirmer le retour de la sonde applicative au statut attendu.
• Relire la page publique et vérifier sa version après l’actualisation du cache.

Huit contrôles locaux pour comparer les deux lectures

Le ZIP lance deux serveurs sur la boucle locale et avance une horloge de test. Au départ, le cache enregistre une page HTTP 200. Pendant la panne, la page reçoit deux fois les mêmes octets, d’abord sans appel à l’origine, puis après un 503. Le contrôle hors cache reçoit 503. Quand la fenêtre de secours prend fin, la page publique reçoit également 503. Après le retour de l’application, le cache reçoit une version différente et la sonde revient à 200.

Les huit contrôles passent depuis le ZIP extrait avec Python 3.14.4. Les requêtes HTTP ont réellement lieu entre les deux serveurs. Le cache et son horloge sont ceux de l’exercice. Les durées et l’en-tête `X-Recette-Cache` servent à rendre visibles les cas de test. La réponse d’origine est simulée sur un serveur local. Les réglages des offres sont documentaires. Le relevé propre à votre site reste nécessaire pour qualifier un incident. Si la sonde confirme une erreur 503, le guide associé aide à isoler sa cause dans WordPress ou sur le serveur.

Kinsta Launch convient si votre équipe utilise MyKinsta pour rapprocher les traces du cache de page, du cache en périphérie et de l’application. o2switch Grow convient si elle suit déjà les domaines, leur cache et les journaux depuis cPanel. Pour les deux offres, validez les mêmes éléments : une page publique lisible, une mesure qui atteint le traitement surveillé et un relevé de la reprise. Ces résultats permettent de garder le 200 public dans le suivi sans lui faire porter à lui seul l’état de WordPress.

• Extraire le ZIP et lancer `python recette.py`.
• Comparer les lectures du cache, de l’origine, de la sonde et de la page rétablie.

Pour aller plus loin

• Lire la fiche Kinsta
• Lire la fiche o2switch
• Diagnostiquer et corriger une erreur 503 WordPress
• Télécharger la recette du cache et de l’origine (ZIP)