Gérer la protection anti-bots (JS Challenge)
Activez la vérification à trois modes depuis la page Sécurité, utilisez « Tout le monde » à bon escient, lisez le taux de réussite.
Aide CDN.com.tr
Lire le statut de cache : HIT, MISS, BYPASS, EXPIRED
Utilisez l'en-tête de réponse X-Proxy-Cache-MT pour voir exactement ce que le CDN a fait d'une requête et vérifier que la mise en cache fonctionne comme prévu.
Cache, sécurité, WAF et purge
Lire le statut de cache : HIT, MISS, BYPASS, EXPIRED
Utilisez l'en-tête de réponse X-Proxy-Cache-MT pour voir exactement ce que le CDN a fait d'une requête et vérifier que la mise en cache fonctionne comme prévu.
Cas d'usage
Un client vérifie les en-têtes de réponse dans les DevTools du navigateur et veut savoir si le contenu est servi depuis le cache CDN, récupéré depuis l'origine, ou volontairement ignoré.
Workflow
- Ouvrez l'URL de la page ou de la ressource et inspectez les en-têtes de réponse (onglet Network des DevTools du navigateur ou
curl -I). - Trouver l'en-tête
X-Proxy-Cache-MT. - Faire correspondre la valeur avec le glossaire ci-dessous.
- Répéter la requête : une URL saine et cacheable renvoie MISS à la première requête, puis HIT.
Verifications
- HIT — servi depuis le cache CDN sans contacter votre origine. C'est l'objectif pour le contenu statique et anonyme.
- MISS — pas encore en cache ; récupéré depuis l'origine et stocké. La prochaine requête identique devrait être un HIT.
- EXPIRED — était en cache mais le TTL est dépassé ; récupéré à nouveau depuis l'origine.
- BYPASS — une règle de contournement a correspondu à cette requête, donc le CDN est volontairement allé à l'origine. La raison la plus courante : vous êtes connecté à un panneau ou un CMS, et un cookie de session/connexion désactive la mise en cache pour vous. Les visiteurs sans ce cookie obtiennent toujours HIT.
Questions frequentes
Je vois toujours BYPASS dans mon navigateur mais la mise en cache est censée être activée — pourquoi ?
Vous êtes presque certainement connecté au site ou au panneau. Les cookies de connexion et de session contournent volontairement le cache afin que les pages personnalisées ne soient jamais mises en cache. Testez avec une fenêtre privée ou curl -I https://yourdomain.com/path — vous devriez voir MISS puis HIT.
Le CDN respecte-t-il l'en-tête Cache-Control de mon origine ?
Cela dépend de la règle — les deux options s'excluent. Avec Use browser cache time activé (valeur par défaut des nouveaux comptes), le Cache-Control, s-maxage ou Expires de l'origine fixe le TTL de l'edge et l'en-tête parvient au navigateur sans modification. Si vous renseignez un Cache Expire Time, cette règle ignore les en-têtes de cache de l'origine et réécrit aussi celui que reçoit le navigateur avec votre valeur. Deux pièges : une réponse portant Set-Cookie n'est jamais mise en cache, aussi correct que soit son Cache-Control ; et là où Image Optimization est activée, sur le compte ou sur la règle, les images sont conservées 365 jours quoi que dise l'origine.
Mobile et bureau semblent être mis en cache séparément — est-ce normal ?
Non. La clé de cache ne contient aucun composant d'appareil — mobile et bureau partagent une seule entrée, purger un chemin l'efface donc pour les deux.
Comment forcer du contenu à jour pour tout le monde ?
Purgez le chemin depuis Purge Management. Une actualisation forcée dans votre propre navigateur n'affecte que votre cache navigateur, pas le cache CDN.
Pages associees
La page Sécurité : WAF, blocage d'IP et de pays, hotlink, rate limit
Tous les contrôles de sécurité au niveau du compte sont réunis sur une seule page Sécurité : l'interrupteur WAF pour tout le site, la protection anti-bots JS Challenge, le blocage d'IP et de pays, la protection hotlink, la limitation de débit des requêtes et l'expiration des liens. Chaque enregistrement se déploie automatiquement sur les edges — pas d'étape de publication séparée.
Définir le comportement du cache avec Add Rule
Configurez la clé de cache domaine/chemin, le TTL, les méthodes/statuts, les en-têtes/cookies, l'optimisation et les règles de limitation de débit.
Lire les journaux WAF
Utilisez les journaux WAF pour expliquer un trafic bloqué ou mis au défi sans exposer les systèmes de journalisation internes.
Purger le contenu mis en cache
Purgez un chemin, un chemin enregistré ou l'ensemble du compte, et distinguez le cache CDN du cache navigateur.
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é ».
Activer HSTS pour vos noms d'hôte
Le préréglage de sécurité Hsts fait envoyer par l'edge l'en-tête Strict-Transport-Security: max-age=31536000 sur les réponses HTTPS, afin qu'un navigateur ayant déjà vu votre site refuse de l'ouvrir en HTTP simple pendant un an.
Bloquer le trafic par ASN et par pays
Deux listes noires à l'échelle du compte dans le même panneau : bloquer des pays entiers par code pays, ou bloquer des réseaux entiers par numéro de système autonome. Un visiteur bloqué reçoit la page 403 de marque avec un identifiant de référence.
URLs signées : liens qui expirent
Protégez un fichier pour qu'il ne puisse être récupéré qu'avec une signature que vous générez, valable jusqu'à un moment que vous choisissez. Les requêtes non signées reçoivent 403, celles qui ont expiré reçoivent 410.
Optimisation des images : AVIF et WebP sur l'edge
Activez l'optimisation des images pour le compte ou pour une règle de diffusion et choisissez WebP ou WebP + AVIF : l'edge convertit les images JPEG et PNG et envoie à chaque navigateur un format qu'il accepte, et vos pages gardent les mêmes URL d'images.