XtremCache - Cache Varnish

Icône Nom Catégorie Description
XtremCache Experts du web Améliore la vitesse de chargement des sites internet grâce à un mécanisme de cache avancé Varnish

En cours de rédaction

La documentation de cet outil est en cours de rédaction. Cette page est amenée à changer régulièrement.

L'outil XtremCache est un outil qui permet d'améliorer la vitesse de chargement de votre site internet grâce à l'activation d'un mécanisme de cache avancé, configuré directement au niveau du serveur web : Varnish.

Varnish est un mécanisme de cache, qui se gère au niveau serveur et qui permet d'améliorer les performances de votre site internet en gardant les pages et ressources générées en mémoire. Cela permet d'éviter toute la partie de traitement dynamique (PHP par exemple) qui sert à générer la page et qui est consommateur en ressources. Les pages sont générées une première fois puis sont gardées en mémoire pour les futurs visiteurs.

Varnish est très utilisés sur les sites ayant un trafic important, comme les sites de presses par exemple.

Habituellement cet outil n'est pas proposés sur des offres de types mutualisés car la configuration de l'outil dépend fortement du site internet hébergé et du CMS utilisé. Dans une offre mutualisé, les sites hébergés sont très différents et utilisent des technologies hétérogènes. C'est à cela que sert cet outil : il permet d'activer un cache Varnish, avec une configuration optimisée pour le site internet que vous avez.

Pour comprendre le fonctionnement du système de cache Varnish, il faut d'abord voir comment cela fonctionne sans cache.

Fonctionnement sans cache

 Cas du traitement d'une requête sans cache serveur

Traitement d'une requête sans cache serveur

Lorsqu'il n'y a pas de cache serveur, voici les différentes étapes qui sont suivis pour l'affichage d'une page

  1. Le navigateur web du visiteur demande au serveur une page particulière, dans cet exemple, index.php
  2. Le serveur, voyant qu'il s'agit d'une page PHP, va lancer l'exécution de la page PHP pour obtenir une réponse (par exemple, une page HTML)
  3. Le moteur PHP va renvoyer la réponse au serveur
  4. Le serveur va renvoyer la réponse, la page générée, au visiteur

Fonctionnement avec cache

Lorsque le cache Varnish est activé, Varnish se place devant le serveur web pour intercepter les appels des navigateurs web ainsi que les réponses du serveur web. Pour chaque appel, il va regarder si la ressource demandée est en cache ou s'il faut transmettre la demande au serveur web. Pour chaque réponse du serveur web, il va regarder s'il est possible de la placer en cache.

Avec Varnish, l'idée est d'éviter toute la partie de génération de la page au niveau du serveur, par exemple, dans le cas d'un site conçu en PHP, on cherche à éviter tous les traitements PHP car c'est ce qui consomme des ressources et c'est également ce qui est le plus lent (comparativement aux autres traitements effectuées).

 Cas du traitement d'une requête avec un cache varnish actif

Traitement d'une requête lorsque le cache Varnish est activé

Lorsque le cache Varnish est activé, voici ce qu'il se passe (de manière simplifiée) :

  • Le navigateur web du visiteur demande une page particulière. Cette demande arrive sur le cache Varnish dans un premier temps, plutôt que d'arriver sur le serveur web.
  • Varnish regarde si la ressource est en cache
    • Si oui, alors Varnish renvoi la réponse qu'il a en cache au navigateur web (sur l'image étape 3 en vert et 4)
    • Si non, alors Varnish transmet la demande au serveur web pour avoir la page à renvoyer (sur l'image, étape 3 en rouge)
      • Le serveur web constate qu'il s'agit d'une page PHP donc lance le traitement PHP (étape 4)
      • Le moteur PHP retourne la page générée au serveur web (étape 5)
      • Le serveur web retourne la page générée à Varnish, Varnish regarde si cette page peut être mise en cache ou non (étape 6)
        • Si oui, Varnish place la page en cache puis retourne la réponse au visiteur (étape 7)
        • Si non, Varnish retourne la réponse sans la mettre en cache (étape 7)

On constate donc que lorsqu'une page est en cache, plusieurs étapes sont évitées :

  • L'appel vers le serveur web
  • Toute la partie de traitement PHP, pour générer la page. Dans cet exemple, c'est PHP qui est utilisé comme langage de programmation pour la création du site mais le principe est identique pour d'autres langages (Python, Ruby, etc…)

Le cache Varnish étant directement en mémoire RAM, ce qu'il y a de plus rapide, la page est servi très rapidement.

Cachable ou pas ?

Afin d'avoir un bon ratio de HIT/MISS, c'est-à-dire le ratio des pages servies depuis le cache (HIT) par rapport aux pages qui ne sont pas servies depuis le cache (MISS), il est important de comprendre comment Varnish s'y prend pour déterminer si une page peut être garder en mémoire (cache) ou non.

Toutes les pages ne peuvent pas être conservées en mémoire cache. Certaines pages sont générées de manière totalement dynamiques et il n'est pas pertinent de garder cela en cache. Par exemple, des pages qui sont générées en fonction d'un utilisateur connectée sur le site internet. Le contenu étant dépendant de l'utilisateur connecté, il n'est pas possible de garder cette page en mémoire pour la transmettre à d'autres visiteurs.

Voici les cas ou Varnish ne peut pas garder en mémoire une page donnée :

  • Toutes les requêtes différentes des requêtes HEAD/GET ne sont pas mise en cache. Dans le cas d'une requête POST, la page générée car très probablement varier en fonction du contenu du POST.
  • Si un cookie, qui n'est pas dans la liste des cookies à exclure, est présent. La page générée peut varier en fonction de la valeur de certains cookies, un cookie peut contenir la langue de préférence du site par exemple.
  • Certaines parties ou fichiers des sites spécifiques, par exemple, dans le cas de WordPress, le dossier wp-admin va être exclu du cache
  • Toutes les requêtes AJAX, que cela soit GET ou POST
  • Les pages ayant des headers “Authorization” ou “Authenticate”, ce sont des pages privées et protégées par des authentifications (authentication basic avec .htacess par exemple)

C'est en partie pour cette raison là, l'algorithme qui sert à déterminer si une page peut être en cache ou non, que la configuration de Varnish dépend fortement du type de CMS utilisé. C'est pour cette raison qu'il y a différents templates de cache proposées, ce sont des configurations adaptées au CMS utilisé par votre site internet.

Par exemple, dans le cas de WordPress, il y aura des règles pour exclure le dossier wp-admin, dans le cas de Joomla, ça sera administrator etc…

L'outil XtremCache est découpée en plusieurs parties / sous outils. Il y a également un vocabulaire, spécifique à l'outil et au mécanisme de cache Varnish qu'il faut connaitre pour comprendre l'outil.

Page d'accueil

Lorsqu'on se rend sur l'outil, la page d'acceuil va lister tous les domaines configurés sur l'hébergement. Pour le moment, seul les domaines supplémentaires et le domaine principal sont listés. A terme, les sous-domaines seront également listées dans une mise à jour de l'outil.

Page d’accueil de l'outil d'ajout de cache varnish o2switch

Page d’accueil de l'outil XtremCache permettant d'ajouter un cache Varnish

Différentes actions sont possibles pour chaque nom de domaines listés :

  • Le cache n'est pas actif sur le domaine
    • Le bouton Activer le cache lance l'outil permettant de configurer un cache sur le nom de domaine concernée
  • Le cache est actif sur le domaine
    • Le bouton Info permet d'avoir un résumé de la configuration effectuée sur le domaine. La clé de purge du cache est notée à cet endroit
    • Le bouton Vérifier affiche un outil qui permet de vérifier si le cache est bien actif sur le site ou une page en particulier. C'est un outil de debug
    • Le bouton Vider le cache permet de vider l'intégralité du cache associé au domaine
    • Le bouton Désactiver temporairement permet de désactiver temporairement le cache, le temps de faire un test par exemple. Le cache peut être réactivé très rapidement, sans coupure.
    • Le bouton Désactiver totalement enlève toutes les personnalisations effectuées sur le domaine, comme le cache mais également ipxtender (les deux outils étant compatibles l'un avec l'autre)
  • Le cache est désactivé temporairement sur le domaine
    • Les boutons Info, Vérifier et Désactiver totalement font la même chose que lorsque le cache est actif (cf. ci-dessus)
    • Le bouton Réactiver le cache permet de réactiver le cache pour le domaine concerné. La réactivation est assez rapide

L'outil xtremCache est compatible avec l'outil ipXtender (cf. documentation de l'outil ipXtender). La colonne Informations permet de voir cela, cette colonne affiche les personnalisations effectuées sur le nom de domaine, il y a plusieurs cas possibles :

  • Cache (actif) : indique que le cache xtremCache est actif pour le domaine mais pas ipXtender
  • Cache (inactif) : le cache xtremCache a été désactivé temporairement pour le nom de domaine. L'outil ipXtender n'est pas actif pour le domaine
  • Cache (actif) + ipXtender : le domaine pointe sur l'adresse IP sélectionnée dans ipXtender et le cache xtremCache est actif
  • Cache (inactif) + ipXtender : le domaine pointe vers l'adresse IP sélectionnée dans ipXtender mais le cache xtremCache est désactivé (temporairement)
  • ipXtender : ipXtender est actif donc le domaine pointe vers une adresse ip personnalisée, il n'y a pas de cache xtremCache actif
  • non personnalisé : c'est la configuration par défaut d'un domaine configuré sur l'hébergement, il n'y a pas de personnalisation ipXtender ou xtremCache

Activer un cache

La page d'activation de cache permet d'activer un cache sur un nom de domaine particulier et de choisir puis personnaliser la configuration en fonction du site internet.

Page d'activation du cache Varnish de l'outil XtremCache o2switch

Page d'activation du cache Varnish o2switch

Dans la page d'activation du cache Varnish, à cet instant, il est possible de choisir deux choses :

  • Le Template : sert à définir quel est la configuration Varnish à activer pour le nom de domaine. Plusieurs templates sont proposées, la plupart correspondent à un CMS ou Framwork particulier. Le bouton de détection automatique permet de choisir le template automatiquement, l'outil va essayer de détecter le CMS utilisé puis remplir le champs en fonction du résultat trouvé.
  • Nom du cookie : sert à définir une liste de cookie à ignorer, pour améliorer la mise en cache et le ratio HIT/MISS comme vu dans la partie cachable ou pas ?

Changement d'adresse IP

L'activation du cache sur le domaine implique un changement d'adresse IP pour ce domaine. Cela implique plusieurs choses :
  • Le domaine doit utiliser nos serveurs DNS. Si ce n'est pas le cas, pensez à changer l'adresse IP du site manuellement dans vos DNS sinon cela générera une erreur 502
  • Il y aura un délai de propagation DNS, durant cette période, le site risque d'être inaccessible (erreur 502). Faites cela dans une période creuse ou dés le début, lors de la création/configuration du domaine

L'outil est compatible avec ipXtender, en fonction de la configuration détectée, l'adresse IP d'ipXtender est conservé :

  • Le domaine n'est pas sur ipXtender : l'adresse IP associé au domaine sera 109.234.164.18
  • Le domaine est sur ipXtender : l'adresse IP sélectionnée dans ipXtender est conservée

Lorsque la configuration est terminée, un résumé des opérations effectuées s'affiche. Il est conseillé de lire cela rapidement pour voir s'il y a des erreurs. La configuration modifiant l'adresse IP associée au domaine, nous vous recommandons de tester le bon fonctionnement de vos comptes emails également (l'outil prend cela en compte, mais c'est toujours mieux de le vérifier vous même également).

Résumé des opérations effectuées pour l'activation du cache

Un exemple de résumé des actions effectuées pour l'activation du cache Varnish

Détection du SSL

Soyez vigilent sur la détection du SSL sur le nom de domaine. Lisez bien le rapport des actions effectuées et si vous voyez que le SSL n'est pas détecté, alors que vous savez que le site utilise un certificat SSL et est accessible en HTTPS, suivez les étapes de la partie SSL non détecté puis relancez l'activation.

Info

La partie info permet d'afficher un résumé de la configuration, dans cet outil là, la partie la plus importante est la clé de purge.

Information sur la configuration du cache pour un domaine

Détail de la configuration du cache pour un domaine spécifique

Voici le détail des différents champs affichés par l'outil d'information :

  • Nom de domaine : affiche sur quel domaine est activé le cache
  • SSL : affiche si le domaine dispose de SSL ou non, pour le HTTPS
  • Adresse IP d'origine : l'adresse IP sur lequel est hébergé le domaine à l'origine, c'est-à-dire lorsqu'il n'y a pas de personnalisations comme ipXtender ou xtremCache
  • Type de personnalisation : affiche un texte qui décrit la configuration en place sur le domaine. C'est le même affichage que la colonne personnalisation visible sur la page d'accueil de l'outil
  • Clé de purge du cache : clé secrète à utiliser pour purger le cache du site.
  • Configuration personnalisée : Affiche la configuration personnalisée effectuée sur le cache du site. Par exemple, la liste des cookies à ignorer.

Vérifier

L'outil Vérifier permet de faire des requêtes sur la page d'accueil du site internet ou une page spécifique afin de vérifier si la page en question est dans le cache.

Pour cela, l'outil va faire deux requêtes :

  • une première requête HEAD pour s'assurer que la page a été visité au moins une fois (afin de lui laisser une chance d'être dans le cache)
  • une deuxième requête, de type GET pour vérifier si la page servie vient du cache ou non

L'outil liste aussi les cookies détectés, cela peut être utile pour ajuster les règles de cache.

Outil de vérification du cache sur une page particulière du site

Outil de vérification du cache sur le site internet

L'outil va afficher un rapport similaire au rapport suivant :

Rapport de la vérification du cache

Rapport généré par l'outil de vérification du cache

Le rapport contient plusieurs éléments :

  • La première phrase du rapport indique si la page a été servie depuis le cache ou non
  • La deuxième phrase du rapport indique si la page a définie des cookies, si c'est le cas, ces derniers sont affichées (nom : valeur)
  • Ensuite, s'affiche les entêtes (headers) renvoyés par la réponse du serveur, certains headers sont plus intéressants que d'autres
    • X-Storage : affiche la stratégie de cache utilisée pour la ressource. Les pages et certains fichiers statiques sont stockées en mémoire RAM (memory), d'autres types de ressources peuvent être stockées sur un cache SSD NVMe local (les images)
    • X-Cache : peut contenir les valeurs HIT, qui signifie que la page a été servi depuis le cache, ou MISS qui signifie que la page n'a pas été servie depuis le cache
    • X-Cache-Hits : affiche le nombre de fois que la ressource a été chargé depuis le cache

Vider le cache

Cet outil permet de vider le cache associé au domaine. Cette option vide l'intégralité du cache associé au domaine.

Un message s'affiche lorsque le cache est vidé :

Message indiquant que le cache serveur est bien vidé

Message indiquant que le cache a été vidé correctement

Désactiver temporairement

Cet outil permet de désactiver temporairement le cache associé au site internet. La désactivation temporaire du cache est assez rapide à être pris en compte et n'engendre pas de coupure du site internet.

Contrairement à la désactivation totale, la désactivation temporaire ne change pas l'adresse IP liée au domaine donc il n'y a pas de coupure/délai de propagation DNS à prévoir.

Cette option est adaptée pour faire des tests, par exemple, si vous soupçonnez que le cache peut être à l'origine d'un comportement anormal sur votre site.

Un rapport s'affiche lorsque le cache est désactivé temporairement sur le site internet :

Désactivation temporaire du cache

Rapport qui s'affiche suite à la désactivation temporaire du cache

Désactivation temporaire du cache

La désactivation temporaire du cache est la méthode de désactivation recommandé car cela est pris en compte rapidement et n'engendre pas de coupure. La désactivation totale du cache peut engendrer une coupure des services car l'adresse IP associée au site est changé pour remettre l'adresse IP d'origine.

Désactiver totalement

La désactivation totale remet à zéro l'ensemble des configurations effectuées sur le nom de domaine, c'est-à-dire les configurations de cache mais également les configurations ipXtender.

En résumé, cela permet de remettre le domaine a son état d'origine.

Désactivation totale

La désactivation totale change l'adresse IP du domaine pour remettre l'adresse IP d'origine. Cela peut causer des perturbations sur le site internet (erreur 502) le temps que la modification DNS soit prise en compte (délai de propagation DNS). Cet outil est a utilisé en dernier recours, si vous souhaitez juste désactiver le cache, utilisez l'outil de désactivation temporaire.

La désactivation totale est similaire à une remise à zéro (reset) de la configuration du domaine.

Un message s'affiche suite à la désactivation totale :

Rapport de désactivation totale et remise à zéro

Rapport de la remise à zéro de la configuration du domaine

Réactiver le cache

Cette option permet de réactiver un cache, qui a été précédemment désactivé temporairement. La réactivation du cache est assez rapide a être prise en compte. Il n'y a pas de perturbation à prévoir, l'adresse IP liée au domaine n'est pas changée.

Un message s'affiche suite à la réactivation du cache :

Réactivation du cache Varnish

Message informant de la réactivation du cache sur le nom de domaine

Les Templates correspondent aux configurations de cache disponibles, ces configurations là sont gérées au niveau du serveur et sont maintenus par o2switch.

Les Templates définissent les règles de caches. Le rôle d'un template est d'optimiser la ratio HIT/MISS (autrement dit, avoir le plus de choses possibles en cache) pour une technologies de création de site donnée, tout en évitant les effets de bord.

Par exemple, un template va :

  • définir des listes d'URL exclues comme les pages d'administrations, pour éviter les effets de bord
  • une liste de cookies à ignorer, pour améliorer la mise en cache
  • faire des exceptions sur des extensions et thèmes qui peuvent être utilisés et à l'origine de problèmes

Plusieurs templates sont proposées, pour le moment, il y a quelques templates qui correspondent aux CMS les plus utilisés ainsi que des templates plus génériques qui peuvent être utilisés pour des sites “fait main”.

Les pages suivants donnent plus d'indications sur ce que font ces templates :

A venir dans un futur proche : Magento, WordPress + WooCommerce, Joomla + Hikashop

Votre application n'est pas proposée ?

Si votre application n'est pas proposée dans la liste des templates supportés ou si vous avez des suggestions d'amélioration, rapport de bug, vous pouvez nous contacter sur support@o2switch.fr. Nous regarderons s'il est possible de proposer un template spécifique à l'application/Framework/CMS que vous utilisez.

Il existe différentes pour purger le cache :

  • depuis l'outil pour vider le cache dans cPanel
  • manuellement ou avec un script PHP en effectuant des requêtes de purges
  • (à venir) depuis une extension WordPress

Dans cet partie, nous allons voir toutes les méthodes de purges de cache proposée à l'exception de l'outil proposée dans cPanel qui est expliquée dans la partie ci-dessus.

Purge manuelle ou via un script

Pour vider le cache, il faut envoyer une requête de type PURGE sur la page à purger (c'est-à-dire la page pour laquelle nous souhaitons vider le cache).

Cette requête la doit impérativement contenir une entête (header) supplémentaire nommée X-VC-Purge-Key, la valeur de cette entête doit correspondre à la clé de purge du cache qui peut être retrouvé dans la partie Info de l'outil.

Donc par exemple, en utilisant curl cela donne la requête suivante :

curl -X 'PURGE' -H 'X-VC-Purge-Key:af6beb7c-36ff-4b68-8f2e-241d67211c1b' mon-dev.xyz

La requête ci-dessus ne purge que la page d'accueil du site internet, c'est la forme la plus simple de purge proposée. Il est également possible de purger une page spécifique, par exemple :

curl -X 'PURGE' -H 'X-VC-Purge-Key:af6beb7c-36ff-4b68-8f2e-241d67211c1b' mon-dev.xyz/ma-page

Si le domaine se trouve derrière une solution comme Cloudflare (ce n'est pas recommandé de mixer les deux) ou si le domaine ne pointe pas directement vers l'adresse IP du cache (pour une raison ou pour une autre) alors il faut générer l'entête host manuellement et indiquer l'adresse IP du serveur de cache. Ce cas est très rare et c'est un usage avancé, par exemple :

# pour connaitre l'adresse IP du serveur de cache
dig +short @ns1.o2switch.net mon-dev.xyz
# requête de purge en précisant l'host manuellement
curl -X 'PURGE' -H 'X-VC-Purge-Key:af6beb7c-36ff-4b68-8f2e-241d67211c1b' -H 'Host:mon-dev.xyz' http://109.234.164.18/ma-page

Le mécanisme de cache supporte un autre type de purge, les purges en utilisant une regex. Cette méthode de purge est très pratique car permet de vider le cache de manière rapide et précise :

  • il est possible de vider tout le cache lié au domaine en une seule requête
  • ou de vider le cache que pour certains types de fichiers ou d'adresse, par exemple, tous les fichiers png

Pour utiliser cette méthode, il faut faire une requête de purge comme vu dans les exemples précédents puis ajouter une entête X-Purge-Regex qui contient l'expression régulière (regex) à utiliser pour vider le cache.

Par exemple, pour vider tout le cache associé au domaine :

curl -X 'PURGE' -H 'X-VC-Purge-Key:af6beb7c-36ff-4b68-8f2e-241d67211c1b' -H 'X-Purge-Regex:.*' mon-dev.xyz

Pour ne vider que le cache du répertoire wp-content/uploads (donc les images pour WordPress) :

curl -X 'PURGE' -H 'X-VC-Purge-Key:af6beb7c-36ff-4b68-8f2e-241d67211c1b' -H 'X-Purge-Regex:wp-content/uploads/.*' mon-dev.xyz

Pour ne vider que les images se terminant par .jpg:

curl -X 'PURGE' -H 'X-VC-Purge-Key:af6beb7c-36ff-4b68-8f2e-241d67211c1b' -H 'X-Purge-Regex:.*\.jpg$' mon-dev.xyz

Retours

L'outil retourne un code HTTP 200 si la purge s'est bien passée et un code HTTP 405 si la clé de purge n'est pas passée ou est invalide.

L'outil affiche également un retour HTML simple, le message varie légèrement si la méthode par regex est utilisée :

<!-- Retour lorsque c'est une purge simple -->
<!DOCTYPE html>
<html>
  <head>
    <title>200 Purged.</title>
  </head>
  <body>
    <h1>Error 200 Purged.</h1>
    <p>Purged.</p>
    <h3>Guru Meditation:</h3>
    <p>XID: 62717987</p>
    <hr>
    <p>Varnish cache server</p>
  </body>
</html>
 
<!-- Retour lorsque la méthode REGEX est utilisée -->
<!DOCTYPE html>
<html>
  <head>
    <title>200 Purged using the Purge Regex Method</title>
  </head>
  <body>
    <h1>Error 200 Purged using the Purge Regex Method</h1>
    <p>Purged using the Purge Regex Method</p>
    <h3>Guru Meditation:</h3>
    <p>XID: 62849276</p>
    <hr>
    <p>Varnish cache server</p>
  </body>
</html>
 
<!-- Retour lorsque c'est invalide (mauvaise clé ou clé de purge absente) -->
<!DOCTYPE html>
<html>
  <head>
    <title>405 Not allowed, purge authentification failed</title>
  </head>
  <body>
    <h1>Error 405 Not allowed, purge authentification failed</h1>
    <p>Not allowed, purge authentification failed</p>
    <h3>Guru Meditation:</h3>
    <p>XID: 63144036</p>
    <hr>
    <p>Varnish cache server</p>
  </body>
</html>

Erreur 502

L'erreur 502 peut venir de plusieurs choses mais si l'erreur s'affiche suite à l'activation du cache, la désactivation totale du cache ou l'activation d'ipXtender, cela signifie l'une des trois choses suivantes :

  • C'est lié au délai de propagation DNS. Toutes les opérations listées ci-dessus change l'adresse IP associée au domaine. Ce changement d'IP peut prendre du temps, tant que la bonne adresse IP n'est pas prise en compte, vous risquez d'avoir une erreur de type HTTP 502, cela est normal (temporairement du moins)
  • Le nom de domaine ne pointe pas vers la bonne adresse IP. Cela peut arriver si vous utilisez des serveurs DNS tiers, la mise à jour de l'IP associée au domaine n'est pas automatique. Dans ce cas, il faut configurer l'adresse la bonne adresse IP (listée dans la page d'accueil de l'outil) dans votre zone DNS
  • Peu probable, même erreur que précédemment, l'adresse IP ne pointe pas au bon endroit mais la cause est différente. Cela peut être lié à votre environnement locale, par exemple, si vous avez fait des tests en modifiant votre ficher hosts

Pour le délai de propagation DNS, vous ne pouvez pas faire grand chose, sauf vider votre cache DNS local. Cela peut vous faire gagner quelques heures mais ce n'est pas forcément suffisant ! Pour vider votre cache DNS local, vous pouvez suivre la procédure expliquée sur la page de l'outil ipXtender.

Pour vérifier si le domaine pointe vers la bonne adresse IP, si vous disposez de la ligne de commande et de la commande dig, vous pouvez lancer les deux commandes suivantes :

# l'ip côté o2switch, celle du cache donc 
dig +short @ns1.o2switch.net mon-domaine.fr
# l'ip depuis un DNS tiers, celui de Google dans ce cas
dig +short @8.8.8.8 mon-domaine.fr
# les deux IPs doivent être identique, si c'est différents, il y a un problème

Ou vous pouvez utiliser un outil en ligne comme Dig sur Kloth.net :

Vérification de la configuration DNS sur Kloth

Vérification de la configuration DNS sur l'outil DIG en ligne de Kloth.net

Sur l'outil en ligne de Kloth.net, il faut faire deux requêtes :

  • la première avec locahost ou 8.8.8.8 comme adresse de serveur, pour trouver l'adresse IP associé au domaine
  • la deuxième avec ns1.o2switch.net comme adresse de serveur DNS pour comparer cela avec l'adresse IP que devrait avoir le site internet

Les deux IPs devraient être identiques, sinon cela signifie qu'il y a probablement un problème.

HTTPS / Redirections

Certaines configurations de .htaccess, qui fonctionneraient dans d'autres cas, peuvent générer des boucles de redirections à l'infini et empêcher le chargement du site internet.

Généralement, cela arrive lorsque les règles du .htaccess vérifie si la requête est en HTTPS ou non en se basant sur le port d'écoute du serveur web. Voici un exemple de règle :

RewriteEngine On 
RewriteCond %{SERVER_PORT} ^80$
RewriteRule ^(.*)$ https://%{SERVER_NAME}%{REQUEST_URI} [L,R]

Exemple de règles de redirections permettant de forcer le HTTPS qui ne fonctionneront pas correctement

Le code ci-dessus ne fonctionne pas à tous les coups car suppose que le serveur web écoute sur le port 80 pour le traitement d'une requête HTTP, c'est souvent vrai mais il y a certains cas ou ce n'est pas le cas.

Cette méthode de détection du https ne fonctionnera pas car le port 80 n'est jamais utilisé par le serveur web apache sur nos hébergements, c'est lié à la manière dont sont configurés les serveurs.

Ce code peut être remplacé par l'équivalent suivant qui fonctionne correctement :

RewriteEngine On 
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteCond %{HTTPS} !on
RewriteRule ^(.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Exemple de redirection qui fonctionne pour forcer le HTTPS

SSL non détecté

Dans certains cas, l'outil xtremCache ou même ipXtender ne détecte pas correctement le certificat SSL lié au nom de domaine à personnaliser.

Cela arrive lorsque le certificat SSL n'est pas installé correctement sur l'hébergement.

Cela s'affiche dans le rapport des actions effectuées pour faire la configuration, il y a une ligne indiquant qu'aucun SSL n'est détecté. Si vous savez que c'est une erreur et qu'un certificat SSL est bien actif, vous pouvez corriger cela en forçant la réinstallation du certificat SSL puis en relançant l'outil d'activation du cache ou de changement d'ip.

Cela peut être fait de deux manières différentes :

  • Depuis l'outil Let's Encrypt qui se trouve dans la catégorie sécurité de cPanel : il suffit de cliquer sur réinstaller
  • Depuis l'outil SSL/TLS de cPanel, toujours dans la catégorie sécurité : il faut cliquer sur Gérer les sites SSL puis sélectionner le domaine, cliquer sur remplir automatiquement puis valider.

13/11/2018

  • Grosse mise à jour de l'outil qui corrige plusieurs bug et apporte des nouvelles fonctionnalités
  • Amélioration de la détection du SSL lors de l'activation de l'outil
  • Ajout d'une option pour choisir les www ou non dans l'outil de test de cache
  • Simplification de l'ensemble des messages renvoyés par l'outil
  • L'outil permettant de vider le cache vide le cache pour les 4 versions du domaine, c'est-à-dire : http, http + www, https, https + www
  • Rectification d'un bug concernant l'exclusion des cookies, c'est bien pris en compte également. Les cookies avec un _ sont autorisés à présent.
  • Un bug affichait les sous-domaines comme configurables avec l'outil de cache alors que cela n'est pas encore possible à cause d'une limitation de cPanel
  • Ajout d'une option permettant d'ignorer certains headers renvoyés (à tort) par des sites internet, comme cache-control:max-age=0. Permet de forcer le cache.
  • Modification de l'infrastructure pour éviter le problème des redirections infinies et des règles de redirections dans les .htaccess invalides.
  • Code permettant de gérer les hooks cPanel pour la mise à jour de certificat SSL plus robuste
  • Changement de méthode de gestion au niveau de Varnish : permet une prise en compte beaucoup plus rapide. Le temps de chargement est fortement diminué, pour passer de plusieurs minutes à 20-30 secondes à présent. L'activation / désactivation / réactivation est beaucoup plus rapide et flexible à présent.
  • Mise à jour de l'UX (breadcrumb)
  • Correction de bug en rapport avec ipxtender dans des cas très spécifiques de désactivation/réactivation du cache

05/09/2018

  • Mise à jour qui corrige quelques bugs en rapport avec les erreurs E010, E012
  • Amélioration de l'ux du loader de chargement
  • Mise à jour des templates de cache
  • Correction d'un bug concernant l'adresse IP du visiteur qui est remontée dans les logs de connexion

06/06/2018

  • Mise en place de la version 1 de l'outil de cache