Lire les en-têtes de statut de cache
HIT, MISS, BYPASS, EXPIRED — la moitié diagnostic de ce workflow.
Ouvrir le sujetAide CDN.com.tr
Clés de cache et purge : pourquoi « j'ai purgé mais c'est toujours l'ancienne version » arrive
Chaque objet mis en cache est stocké sous une clé construite à partir de la requête — schéma, hôte, chemin et chaîne de requête. Une purge n'efface une entrée que lorsqu'elle vise exactement cette clé. Comprendre cette seule idée explique presque tous les cas de « la purge n'a pas fonctionné ».
Cache, sécurité, WAF et purge
Clés de cache et purge : pourquoi « j'ai purgé mais c'est toujours l'ancienne version » arrive
Chaque objet mis en cache est stocké sous une clé construite à partir de la requête — schéma, hôte, chemin et chaîne de requête. Une purge n'efface une entrée que lorsqu'elle vise exactement cette clé. Comprendre cette seule idée explique presque tous les cas de « la purge n'a pas fonctionné ».
Chemin dans le panneau
- Management Panel
- CDN Accounts
- Purge Management
Prerequis
- Le chemin doit appartenir au compte sélectionné.
- Diagnostiquez avec l'URL publique exacte (schéma + hôte + chemin + chaîne de requête), pas un résumé de celle-ci.
Cas d'usage
Vous avez purgé un chemin après un déploiement, mais un visiteur signale encore l'ancienne version. Dans presque tous les cas, la purge a fonctionné — elle a simplement effacé une entrée de cache différente de celle servie au visiteur (une variante avec chaîne de requête, la copie mobile, ou son propre cache navigateur).
Workflow
- Obtenez l'URL exacte que le visiteur voit obsolète — y compris le schéma (https), l'hôte (www ou apex) et toute chaîne de requête. « La page produits » ne suffit pas ; /products et /products?page=2 sont des entrées de cache différentes.
- Vérifiez ce que le CDN a réellement fait : `curl -I` sur cette URL exacte et lisez `X-Proxy-Cache-MT`. HIT signifie que le CDN a servi une copie en cache ; MISS ou BYPASS signifie que ce n'est pas le CDN qui sert l'ancien contenu.
- Purgez avec le périmètre qui correspond au problème dans Purge Management : un chemin exact unique pour une URL, une purge de dossier pour tout ce qui se trouve sous un chemin, ou une purge complète du compte lorsque la structure a changé partout.
- Vérifiez de la même manière que vous avez diagnostiqué : demandez à nouveau l'URL exacte et attendez-vous à MISS (récupéré frais depuis l'origine) puis HIT. Si votre propre navigateur affiche encore l'ancienne page, faites une actualisation forcée — le CDN ne peut pas atteindre les caches navigateur.
Verifications
- Les chaînes de requête créent des entrées séparées : /banner.jpg et /banner.jpg?v=2 sont mis en cache indépendamment. Purger l'un ne touche pas l'autre.
- Le schéma et l'hôte font partie de la clé : http vs https et www vs apex sont des entrées différentes. Purgez la forme canonique que vos visiteurs utilisent réellement.
- Mobile et bureau peuvent être des copies séparées du même chemin — un signalement d'obsolescence uniquement depuis des téléphones est généralement la variante mobile.
- Une purge efface le CDN, jamais le cache navigateur d'un visiteur. Ce qui limite cette dernière fenêtre, c'est le TTL navigateur dans vos règles de cache, pas une purge supplémentaire.
Questions frequentes
La purge a indiqué un succès, mais la page est toujours ancienne — a-t-elle échoué ?
Presque certainement pas. Diagnostiquez avec `curl -I` sur l'URL exacte : si vous voyez MISS à la première requête après la purge, l'entrée CDN a bien été effacée et la copie obsolète se trouve ailleurs — une autre variante de l'URL, ou le cache navigateur du visiteur.
J'ai purgé /products mais /products?page=2 et /products?utm_source=x sont toujours anciens.
Chaque combinaison de chaîne de requête est sa propre entrée de cache. Purgez le dossier/préfixe pour que chaque entrée sous le chemin soit effacée, ou purgez explicitement les variantes les plus fréquentées.
Dois-je purger après chaque déploiement ?
Si votre HTML est mis en cache avec un TTL long, oui — purgez les chemins modifiés comme étape de déploiement. L'API de purge et cdnctl existent exactement pour cela ; un script de déploiement qui se termine par une purge ciblée ne rencontre jamais cette classe de problème.
Quand devrais-je utiliser « purge all » ?
Lorsque la structure des URL a changé sur tout le site (une migration, une refonte) et qu'une purge par chemins serait une longue liste de suppositions. Utilisez-la délibérément : juste après, chaque requête est un MISS jusqu'à ce que le cache se réchauffe, donc votre origine absorbe brièvement tout le trafic.