Comprendre les en-têtes Cloudflare : cf-cache-status, cf-ray et compagnie

Vous avez placé votre site WordPress derrière Cloudflare et vous voulez savoir si le CDN fait vraiment son travail. Dans les réponses de votre serveur apparaissent soudain des lignes comme cf-cache-status: DYNAMIC ou cf-ray: 8f2a1c3d4e5f6a7b-FRA. Ces en-têtes sont un peu la notice que Cloudflare glisse dans chaque réponse : ils vous indiquent si un fichier provient du cache, quel centre de données a répondu et si une règle de sécurité est intervenue. Vous découvrirez ici ce que signifient les différentes valeurs et ce que vous pouvez en tirer pour votre site.

Que sont les en-têtes Cloudflare et comment les lire ?

Cloudflare s’intercale comme proxy entre vos visiteurs et votre serveur. Chaque requête passe par le réseau de Cloudflare, qui y ajoute des en-têtes au passage. Certains sont visibles par le navigateur de vos visiteurs, d’autres n’arrivent que sur votre serveur. Pour comprendre comment fonctionne un tel réseau, lisez notre article Qu’est-ce qu’un CDN ?.

Le plus simple pour voir les en-têtes, ce sont les outils de développement de votre navigateur. Ouvrez l’onglet « Réseau », rechargez la page et cliquez sur la première ligne. Dans le terminal, c’est encore plus rapide :

curl -sI https://example.com/

La réponse ressemble alors à peu près à ceci :

HTTP/2 200
content-type: text/html; charset=UTF-8
cache-control: max-age=0
cf-cache-status: DYNAMIC
server: cloudflare
cf-ray: 8f2a1c3d4e5f6a7b-FRA

S’il n’y a aucune ligne commençant par cf-, la requête ne passe pas du tout par Cloudflare. Dans la plupart des cas, l’enregistrement DNS est alors réglé sur « DNS only » (nuage gris) au lieu de « Proxied » (nuage orange).

Que signifie cf-cache-status ? Toutes les valeurs en un coup d’œil

L’en-tête cf-cache-status est le plus important de tous. Il vous dit comment Cloudflare a traité précisément cette réponse. La documentation officielle recense neuf valeurs :

• HIT : le fichier se trouvait dans le cache et vient directement de Cloudflare. Votre serveur ne s’est rendu compte de rien. C’est la valeur que vous voulez voir.
• MISS : le fichier peut être mis en cache, mais il n’était pas encore présent dans ce centre de données. Cloudflare l’a récupéré sur votre serveur. À la requête suivante, vous devriez voir HIT.
• EXPIRED : le fichier était dans le cache, mais il avait expiré. Cloudflare en a récupéré une version fraîche sur votre serveur.
• REVALIDATED : la copie en cache avait expiré. Cloudflare a demandé à votre serveur si quelque chose avait changé, et la réponse était non. Le fichier provenait donc du cache, mais le visiteur a dû attendre cette vérification.
• UPDATING : la copie avait expiré, mais elle a quand même été livrée immédiatement, pendant que Cloudflare la renouvelle en tâche de fond. Cela se produit lorsque votre serveur envoie stale-while-revalidate.
• STALE : Cloudflare a livré une copie expirée parce que votre serveur était injoignable. C’est un signal d’alerte à prendre au sérieux.
• BYPASS : le fichier aurait pu en principe être mis en cache, mais la réponse de votre serveur l’en a empêché, par exemple à cause d’un cookie.
• DYNAMIC : Cloudflare n’a même pas regardé dans le cache, car d’après les règles en vigueur, ce contenu n’est pas mis en cache.
• NONE/UNKNOWN : c’est Cloudflare qui a généré la réponse, par exemple lors d’une redirection vers HTTPS, d’un blocage par le firewall ou d’un Worker.

Bon à savoir : depuis le 26 mai 2026, Cloudflare distingue plus nettement deux de ces valeurs. Auparavant, certaines réponses impossibles à mettre en cache recevaient un MISS à chaque requête. Depuis ce changement, elles affichent toujours BYPASS. MISS ne veut donc plus dire qu’une chose : le fichier peut être mis en cache, mais il n’est pas disponible pour le moment. Beaucoup d’anciens tutoriels en ligne décrivent encore l’ancien comportement.

Pourquoi votre site WordPress affiche cf-cache-status: DYNAMIC ?

C’est la question la plus fréquente sur ce sujet, et la réponse a de quoi rassurer : sur une page WordPress classique, DYNAMIC est tout à fait normal. Par défaut, Cloudflare ne met en cache ni le HTML ni le JSON. La décision repose sur l’extension du fichier, pas sur son contenu. Les images, le CSS, le JavaScript, les polices et les PDF vont dans le cache, le HTML de vos pages non.

Il y a une bonne raison à cela. WordPress génère les pages de manière dynamique, et Cloudflare ne peut pas savoir si le HTML contient à ce moment un panier, une barre d’administration ou un message de bienvenue personnalisé. S’il mettait ces pages en cache sans qu’on le lui demande, un visiteur pourrait, dans le pire des cas, voir le panier d’un autre.

Vos images et vos scripts, en revanche, devraient afficher HIT. Ne vérifiez donc pas seulement la page d’accueil, mais aussi un fichier CSS ou une image.

Si vous voulez que Cloudflare livre aussi le HTML, deux options s’offrent à vous :

• Cache Rule : vous créez dans le tableau de bord une règle qui marque le HTML comme « Eligible for cache ». C’est alors à vous de veiller à ce que les utilisateurs connectés, l’espace d’administration, le panier et la page de paiement restent exclus.
• APO pour WordPress : l’Automatic Platform Optimization gère ces exceptions pour vous et vide le cache dès que vous modifiez un article. Nous y revenons plus bas.

Si les images ou le CSS affichent eux aussi DYNAMIC, la cause est généralement une règle avec « Bypass cache » ou le Development Mode. Ce dernier désactive complètement le cache pendant trois heures, et on l’oublie facilement.

cf-cache-status BYPASS ou MISS en permanence : d’où vient le problème ?

Avec BYPASS, Cloudflare voulait mettre en cache, mais la réponse de votre serveur l’a interdit. Le guide de dépannage cite surtout les causes suivantes :

• La réponse contient un en-tête Set-Cookie. Sous WordPress, c’est le grand classique : une boutique, un plugin multilingue ou un plugin de tracking dépose un cookie à chaque requête, et plus rien n’est mis en cache.
• Votre serveur envoie Cache-Control: no-store ou private.
• La réponse contient Vary: *.
• Le fichier dépasse la limite de votre offre (512 Mo avec Free, Pro et Business).

Si chaque requête reste sur MISS, le fichier peut bien être mis en cache, mais Cloudflare ne le retrouve jamais. Cela vient souvent de paramètres changeants dans l’adresse, comme utm_source ou un identifiant de session, car chaque variante compte comme un fichier distinct. Sur les sites peu fréquentés, les fichiers rarement demandés quittent aussi le cache plus tôt. Enfin, chaque centre de données a son propre cache : si deux requêtes arrivent à des endroits différents, vous verrez deux fois MISS.

L’en-tête Age est un bon allié. Il indique en secondes depuis combien de temps la copie se trouve dans le cache. Si vous demandez un fichier deux fois de suite et voyez HIT avec une valeur Age qui augmente, tout fonctionne.

Que révèle l’en-tête cf-ray ?

Chaque requête qui passe par Cloudflare reçoit son propre identifiant, le Ray ID. Il figure dans l’en-tête cf-ray et se compose de deux parties : une suite de caractères et un code de trois lettres. Ce code désigne le centre de données qui a répondu. FRA correspond à Francfort, AMS à Amsterdam, CDG à Paris.

Au quotidien, le Ray ID vous rend service de trois façons. Quand Cloudflare affiche une page d’erreur à un visiteur, le Ray ID figure en bas de la page, et il vous permet de retrouver exactement cette requête dans les logs ou les Security Events. Ensuite, le code vous montre si vos visiteurs aboutissent vraiment dans un centre de données proche de chez eux. Enfin, il explique plus d’un MISS mystérieux, quand deux requêtes sont arrivées dans des centres de données différents.

D’ailleurs, Cloudflare envoie aussi ce même Ray ID à votre serveur. Si vous l’inscrivez dans vos logs, vous pouvez suivre une requête depuis le navigateur jusqu’à PHP.

cf-apo-via et cf-edge-cache : comment vérifier qu’APO pour WordPress fonctionne ?

Si vous utilisez l’Automatic Platform Optimization, deux autres en-têtes s’ajoutent. Selon Cloudflare, une configuration qui fonctionne se reconnaît à trois lignes :

• cf-cache-status: HIT montre que le HTML provient du cache.
• cf-apo-via: tcache montre qu’APO a traité la requête.
• cf-edge-cache: cache,platform=wordpress confirme que le plugin Cloudflare est installé et actif dans WordPress.

Si cf-edge-cache est absent, le plugin est généralement désactivé ou n’est pas relié à votre compte. Si cf-apo-via affiche une autre valeur que tcache, APO n’a pas livré la page depuis le cache, par exemple parce que vous êtes connecté. Faites donc toujours vos tests dans une fenêtre de navigation privée.

Que signifie cf-mitigated: challenge ?

Cet en-tête n’apparaît que lorsque Cloudflare livre une page de vérification à la place de votre page, c’est-à-dire le message bien connu indiquant que le visiteur est vérifié pendant un instant. challenge est la seule valeur valide.

Pour un humain, ce n’est en général qu’un léger délai. Pour tout ce qui accède automatiquement à votre site, c’est un vrai obstacle. La page de vérification est toujours en HTML, même quand c’est du JSON qui a été demandé. Si votre propre JavaScript appelle la REST API et reçoit soudain une page de vérification, il se heurte à une erreur que vous auriez bien du mal à comprendre sans cet en-tête. Il en va de même pour les services de monitoring, les prestataires de paiement qui utilisent des webhooks et les outils d’analyse. Si vous voyez cf-mitigated: challenge sur des requêtes qui devraient passer, jetez un œil aux Security Events dans le tableau de bord. Vous y verrez quelle règle s’est déclenchée.

Quels en-têtes Cloudflare arrivent sur votre serveur ?

Tous les en-têtes ne sont pas destinés au navigateur. Cloudflare en ajoute certains à la requête avant qu’elle n’atteigne votre serveur. La liste complète est longue, mais pour WordPress, voici les plus importants :

• CF-Connecting-IP : la véritable adresse IP du visiteur. Sans cet en-tête, votre serveur ne voit que des adresses de Cloudflare.
• X-Forwarded-For : la chaîne de tous les proxys par lesquels la requête est passée. Pour l’adresse du visiteur, Cloudflare recommande plutôt de lire CF-Connecting-IP.
• X-Forwarded-Proto et CF-Visitor : indiquent si le visiteur est arrivé en HTTP ou en HTTPS.
• CF-IPCountry : le pays du visiteur sous forme de code à deux lettres. XX signifie inconnu, T1 désigne le réseau Tor.
• CDN-Loop : empêche qu’une requête tourne indéfiniment en boucle à travers Cloudflare.

La véritable adresse IP est bien plus qu’un détail. Les plugins de sécurité bloquent les attaquants par adresse IP, WordPress l’enregistre avec les commentaires et votre hébergeur l’exploite dans ses logs. Si seule l’adresse de Cloudflare leur parvient, votre plugin risque de bloquer d’un coup tous vos visiteurs. La plupart des hébergeurs et des plugins de sécurité peuvent être configurés en conséquence. Un point important : ne faites confiance à cet en-tête que si la requête provient réellement d’une adresse du réseau Cloudflare. Sinon, n’importe qui peut inscrire l’adresse IP de son choix dans l’en-tête.

Une source d’erreur bien connue est aussi liée à cela. Avec le réglage SSL « Flexible », Cloudflare communique avec votre serveur sans chiffrement. WordPress croit alors que le visiteur est arrivé en HTTP, redirige vers HTTPS, et une boucle de redirection sans fin se crée. La solution propre consiste à installer un certificat sur le serveur et à choisir le réglage « Full (strict) ».

Comment contrôler avec Cache-Control ce que Cloudflare met en cache ?

C’est d’abord votre serveur qui décide combien de temps Cloudflare conserve un fichier. Pour cela, il existe trois en-têtes, que Cloudflare évalue dans cet ordre :

1. Cloudflare-CDN-Cache-Control s’applique uniquement à Cloudflare et n’est pas transmis au navigateur.
2. CDN-Cache-Control s’applique à tous les CDN sur le trajet.
3. Cache-Control s’applique aux navigateurs et, si les deux autres sont absents, également à Cloudflare.

Vous pouvez ainsi piloter séparément le navigateur et le CDN. Un exemple : le navigateur doit conserver un fichier une heure seulement, Cloudflare une journée entière.

Cache-Control: max-age=3600
Cloudflare-CDN-Cache-Control: max-age=86400

Si votre serveur n’envoie aucune indication, ce sont les valeurs par défaut qui s’appliquent. Les réponses avec le statut 200 et 301 restent 120 minutes dans le cache, les redirections 302 et 303 seulement 20 minutes, les erreurs 404 et 410 trois minutes. Ce dernier point en surprend plus d’un : si vous mettez en ligne après coup une image qui manquait, Cloudflare peut continuer à livrer l’ancienne erreur pendant quelques minutes.

Quels autres en-têtes ajoute Cloudflare ?

En plus des lignes bien connues, vous en remarquerez peut-être quelques autres :

• server: cloudflare remplace le nom de votre serveur web. Qu’il s’agisse d’Apache, de nginx ou de LiteSpeed, plus personne ne peut le voir de l’extérieur.
• report-to et nel font partie du Network Error Logging. Grâce à eux, le navigateur signale les erreurs de connexion à Cloudflare. La fonction peut être désactivée dans le tableau de bord, ce qui peut être intéressant pour certains sites du point de vue de la protection des données.
• alt-svc annonce au navigateur que le site est aussi accessible en HTTP/3. Si votre serveur envoie son propre en-tête alt-svc, Cloudflare le supprime.

Au passage, certains en-têtes de votre serveur n’arrivent jamais chez le visiteur. C’est le cas de Cache-Tag et des en-têtes X-Accel de nginx. Ne vous étonnez donc pas si vous les cherchez en vain dans le navigateur.

Comment vérifier les en-têtes Cloudflare avec InspectWP ?

InspectWP lit les en-têtes de votre site lors de la création d’un rapport et vous affiche notamment cf-cache-status et cf-ray dans la section « En-têtes ». Vous voyez donc, sans terminal, si votre site passe par Cloudflare et comment la page d’accueil a été livrée. S’y ajoutent les valeurs liées à la mise en cache : la compression, la version HTTP et les en-têtes de sécurité.

C’est surtout pratique si vous gérez plusieurs sites. Avec les rapports automatiques, vous remarquez quand une page ne sort soudain plus du cache ou quand Cloudflare n’est plus du tout placé devant le site après une migration. Si une page de vérification de Cloudflare bloque le crawl, InspectWP vous le signale. Notre article d’aide Que faire quand le crawl échoue explique comment régler la protection contre les bots en conséquence. Un rapport gratuit vous montre en peu de temps quels en-têtes votre site envoie en ce moment.