Paramètres Cloudflare pour WordPress qui n’interrompent pas wp-admin

Les quelques règles qui comptent

Le cache en périphérie est un instrument brutal. WordPress est une machine subtile construite sur des cookies, l’état utilisateur, et des nonces limités dans le temps
qui protègent les formulaires et actions. Si vous mettez en cache la mauvaise réponse, vous ne servez pas seulement du HTML périmé — vous servez le mauvais
HTML à la mauvaise personne, et WordPress le remarque. Souvent bruyamment.

Règle 1 : Ne jamais mettre en cache les réponses authentifiées ou à état

En pratique, « authentifié » signifie « possède des cookies d’auth WordPress » et « à état » signifie « cookies de panier/checkout/session » ou
pages qui incluent des nonces. Si une requête transporte des cookies qui modifient ce que l’origine renverrait, vous devez contourner le cache.
Vous pouvez toujours mettre en cache les ressources statiques pour les utilisateurs connectés ; évitez juste de mettre en cache le HTML.

Règle 2 : Mettre en cache le HTML public seulement quand vous pouvez prouver qu’il est public

« Cache Everything » est acceptable si vous le combinez avec de fortes règles de contournement basées sur les cookies et les chemins. Sans règles de contournement, c’est
comme cela que vous vous retrouvez à mettre en cache des réponses /wp-admin/ et les servir à la prochaine personne qui en fait la demande. Oui, ça arrive. Non, ce n’est pas
agréable. Votre modèle de menace devrait inclure « mise en cache bien intentionnée » comme adversaire.

Règle 3 : Utilisez un petit nombre de règles claires, puis observez

Ne construisez pas une cathédrale de 47 règles en périphérie le premier jour. Commencez par : (1) contourner admin/connexion, (2) contourner quand les cookies indiquent
une session connectée ou à état, (3) mettre en cache les ressources statiques agressivement, (4) mettre en cache le HTML public avec un TTL raisonnable et un plan de purge.
Puis mesurez le taux de hit et la charge sur l’origine.

Règle 4 : Si vous ne pouvez pas expliquer une décision de cache, vous ne pouvez pas l’exploiter

Chaque comportement de cache doit correspondre à un signal observable : un en‑tête (CF-Cache-Status), une ligne de log, un cookie ou une correspondance de chemin.
Si la seule façon de « déboguer » est d’appuyer sur rafraîchir et d’espérer, vous ne gérez pas un cache. Vous gérez une machine à sous.

Blague #1 : La mise en cache est facile… jusqu’à ce que ça ne le soit plus — un peu comme le DNS, mais avec plus d’occasions de faire en sorte que votre propre site vous manipule.

Faits intéressants et brève histoire

• Fait 1 : Les nonces WordPress ne sont pas des nonces cryptographiques véritables ; ce sont des jetons basés sur le temps conçus pour la protection CSRF avec une fenêtre de validité.
• Fait 2 : Le cookie wordpress_logged_in_ est le signal le plus simple et fiable qu’une requête ne devrait pas être servie depuis un cache public.
• Fait 3 : Beaucoup de plugins WordPress ajoutent leurs propres cookies (tests A/B, bannières de consentement, analytics). Certains sont inoffensifs ; d’autres modifient le rendu de la page.
• Fait 4 : « Cache Everything » sur Cloudflare est devenu populaire initialement comme solution pour mettre en cache le HTML pour des sites sans reverse proxy comme Varnish.
• Fait 5 : La constante DONOTCACHEPAGE de WordPress existe parce que même les caches côté serveur ne peuvent pas deviner en toute sécurité quand une page est personnalisée.
• Fait 6 : Le cache en périphérie de Cloudflare respecte certains en‑têtes de cache, mais « respecte » et « fait exactement ce que vous pensez » ne sont pas synonymes à moins de tester.
• Fait 7 : Un nombre surprenant d’incidents « wp-admin lent » sont en réalité une contention CPU de l’origine due aux workers PHP, pas la latence réseau.
• Fait 8 : La purge est coûteuse opérationnellement. Même quand elle est « instantanée », elle peut effondrer votre taux de hit et provoquer une ruée vers l’origine.
• Fait 9 : Les fragments de panier de WooCommerce (historiquement via ?wc-ajax=get_refreshed_fragments) sont une source récurrente de confusion sur la mise en cache et de personnalisation partielle.

Ce que signifie réellement « ne casse pas wp-admin »

Le seuil n’est pas « wp-admin se charge ». Le seuil est : la connexion fonctionne, les actions protégées par nonce fonctionnent, les redirections ne bouclent pas, les aperçus affichent
le contenu actuel, les uploads média réussissent, les éditeurs ne voient pas les sessions d’autres utilisateurs, et votre cache ne fuit pas de données privées.
C’est la sécurité minimale viable.

Voici ce qui casse couramment quand les règles de cache sont approximatives :

• Boucles de redirection de connexion : les POST sur /wp-login.php définissent des cookies, puis la périphérie sert une réponse mise en cache qui ignore le nouvel état du cookie.
• UI d’administration obsolète : mise en cache de /wp-admin/ ou des réponses admin-ajax. Un seul message mis en cache « Vous n’êtes pas autorisé » peut ruiner une heure.
• Problèmes d’aperçu et d’éditeur : les liens d’aperçu incluent des paramètres similaires à des nonces ; les mettre en cache est un moyen sûr d’afficher le brouillon d’hier comme « actuel ».
• Fuite de la barre d’administration personnalisée : mettez en cache les pages publiques mais oubliez que les utilisateurs connectés obtiennent la barre admin injectée.
• Problèmes WooCommerce de panier : pages de panier/checkout ou endpoints de fragments mis en cache entraînent des paniers fantômes et des tickets support.

Si votre configuration de cache ne peut pas exprimer « mettre en cache ceci uniquement quand aucun cookie d’état n’est présent », vous n’êtes pas prêt à mettre en cache le HTML.
Heureusement, Cloudflare peut exprimer cela — vous devez juste le faire délibérément.

Paramètres Cloudflare de base pour WordPress (valeurs sûres)

La base propre est : mettre en cache les ressources statiques fortement, ne pas mettre en cache l’administration ou la connexion, et ne mettre en cache le HTML public que si vous avez des règles de contournement par cookie.
Tout le reste est de la garniture.

1) Mettre en cache les ressources statiques agressivement

Celles‑ci sont sûres à mettre en cache en périphérie même pour les utilisateurs connectés parce qu’elles ne varient pas par utilisateur (à moins que vous fassiez quelque chose
de très créatif avec le CSS, ce qui est une discussion séparée et peut-être un appel à l’aide).

• Images : .png .jpg .jpeg .gif .webp .svg
• CSS/JS : .css .js
• Polices : .woff .woff2 .ttf .otf

Utilisez des TTL longs côté navigateur avec des noms de fichiers versionnés. Le cœur de WordPress et beaucoup de thèmes ajoutent déjà des chaînes de requête ; mieux vaut des fichiers hachés,
mais ne laissez pas le parfait empêcher le progrès. Si vous ne pouvez pas fingerprint les ressources, gardez un TTL navigateur modéré et comptez sur la périphérie.

2) Contourner le cache pour les chemins d’administration et de connexion

C’est non négociable :

• /wp-admin/*
• /wp-login.php
• /wp-json/* (au moins pour les contextes authentifiés ; les endpoints publics peuvent être mis en cache au cas par cas)
• /xmlrpc.php (idéalement bloquer s’il n’est pas utilisé ; si utilisé, ne pas mettre en cache)
• /wp-admin/admin-ajax.php (ne pas mettre en cache)

3) Contourner le cache quand certains cookies existent

La périphérie de Cloudflare ne peut pas « comprendre » WordPress, mais elle peut faire des correspondances sur les cookies. Voici les importants :

• wordpress_logged_in_* → utilisateur authentifié
• wordpress_sec_* → auth sur zones admin SSL
• wp-postpass_* → articles protégés par mot de passe
• Cookies WooCommerce : woocommerce_items_in_cart, woocommerce_cart_hash, wp_woocommerce_session_*
• Certaines extensions membership définissent leurs propres cookies ; identifiez‑les et incluez‑les

4) Décidez ce que vous faites pour le HTML

Vous avez deux options sensées :

1. Conservatrice : ne mettez pas le HTML en cache chez Cloudflare du tout. Mettez en cache uniquement les ressources statiques. Utilisez un cache de pages à l’origine (plugin, cache FastCGI Nginx, ou un reverse proxy) pour le HTML. C’est l’option « je veux un comportement prévisible ».
2. Mise en cache HTML en périphérie : mettez en cache le HTML public chez Cloudflare avec des règles de contournement strictes. C’est l’option « je veux un déchargement maximal et une vitesse globale ».

Ce que j’évite : mettre en cache le HTML parfois, mais sans politique claire. C’est comme ça que vous obtenez un site rapide pour vous et cassé pour tout le monde.

Stratégie de cache : statique, HTML et le dangereux milieu

Ressources statiques : ennuyeux, correct et rentable

La mise en cache statique est l’endroit où Cloudflare excelle avec un faible risque. Si votre origine struggle, commencez ici. Vous réduirez la bande passante,
diminuerez les négociations TLS sur votre serveur, et obtiendrez de meilleures performances lors des pics de trafic.

HTML : ça vaut le coup, mais seulement avec des garde‑fous

Mettre en cache le HTML en périphérie peut transformer un VPS à 20$ en quelque chose qui survit à la une d’Internet — jusqu’à ce qu’il serve le mauvais
HTML au mauvais utilisateur. La seule façon sûre est de garantir que la variante mise en cache représente la même réponse que l’origine renverrait
pour tous les utilisateurs du même bucket de cache.

Pour la plupart des sites WordPress, le bucket sûr est « aucun cookie de connexion et aucun cookie session/panier ». C’est votre cache public.
Tout le reste doit contourner.

Le dangereux milieu : endpoints qui semblent statiques mais ne le sont pas

Ceux‑ci sont subtils :

• Pages de recherche : beaucoup de variantes, parfois personnalisées ; la mise en cache peut fonctionner mais nécessite un keying soigné et des TTL courts.
• Flux : peuvent être mis en cache, mais les éditeurs détestent les flux obsolètes ; gardez un TTL court.
• REST API : les endpoints publics peuvent être mis en cache, les endpoints authentifiés ne doivent pas l’être.
• Contenu localisé ou A/B : si le contenu varie par cookie ou en‑tête, votre clé de cache doit l’inclure ou vous devez contourner.

Si vous n’êtes pas sûr, contournez. Rapide et faux reste faux, juste avec de meilleurs temps de ping.

Règles « ne pas mettre en cache » pour wp-admin, connexion et aperçus

Chemins qui doivent toujours contourner le cache

Si vous n’implémentez qu’une chose, implémentez cette liste. Vous pouvez la traduire en Cloudflare Cache Rules (préféré), Page Rules anciennes (legacy), ou un Worker.

• *example.com/wp-admin/* → Bypass cache
• *example.com/wp-login.php* → Bypass cache
• *example.com/wp-admin/admin-ajax.php* → Bypass cache
• *example.com/wp-cron.php* → Bypass cache (ou rate-limit ; ne pas mettre en cache)
• *example.com/?preview=true* → Bypass cache
• *example.com/*preview_id=* and *preview_nonce=*Bypass cache

Désactiver les « améliorations » de performance pour les chemins admin

Certaines optimisations sont excellentes pour le trafic anonyme et pénibles pour les utilisateurs authentifiés. Pour les chemins admin et de connexion,
je préfère le choix ennuyeux :

• Désactivez la minification HTML si elle a déjà cassé votre UI d’administration (ça arrive avec des plugins bizarres).
• Soyez prudent avec les réécritures JS de type Rocket Loader. L’admin charge beaucoup de scripts ; vous n’avez pas besoin de magie en périphérie là‑bas.
• Gardez les fonctions de sécurité (WAF) activées, mais testez qu’elles ne challengent pas les admins au milieu d’une action.

Mise en cache consciente des cookies : votre véritable plan de contrôle

Les règles de chemin protègent wp‑admin. Les règles sur les cookies protègent tout le reste. La plupart des posts « Cloudflare a cassé mon WordPress »
signifient en réalité « nous avons mis en cache du HTML en ignorant des cookies qui changent le contenu ».

Signaux cookie sur lesquels vous devez contourner

Au minimum :

• wordpress_logged_in_*
• wordpress_sec_*
• wp-postpass_*

Ajoutez si présents :

• Cookies d’extensions membership ou LMS (spécifiques au plugin)
• Cookies de sélection de langue si votre site varie selon le cookie
• Cookies de tests A/B s’ils modifient le HTML

Qu’en est‑il des cookies « auteur de commentaire » ?

WordPress définit des cookies comme comment_author_* après qu’un visiteur commente. Ils ne changent souvent pas de manière significative le rendu de la page
pour la plupart des sites. Si vous mettez en cache le HTML et observez un comportement étrange pour des commentateurs récents, contournez aussi sur ces cookies. Si vous poursuivez le taux de hit,
testez d’abord ; ne faites pas du cargo‑cult.

Discipline de la clé de cache : ne variez pas sur chaque cookie

Varier le cache selon chaque cookie détruit le taux de hit et peut amplifier l’utilisation du stockage du cache. L’astuce est de contourner quand des cookies d’état sont présents,
pas de créer un million de variantes de cache.

WooCommerce et autres pages personnalisées

WooCommerce ajoute des sessions client, l’état du panier et des flux de checkout qui sont allergiques à une mise en cache incorrecte. Vous pouvez toujours
mettre en cache les pages de catégories produit et les pages produit pour les utilisateurs anonymes — souvent avec de gros gains — mais vous devez réserver les
chemins transactionnels.

Toujours contourner le cache pour ces chemins WooCommerce

• /cart/*
• /checkout/*
• /my-account/*
• /?wc-ajax=*
• Tout endpoint « add-to-cart » ou paramètre de requête utilisé par votre thème

Contourner sur ces cookies WooCommerce

• woocommerce_items_in_cart
• woocommerce_cart_hash
• wp_woocommerce_session_*

Ce qu’il est sûr de mettre en cache dans WooCommerce

Pages produit publiques, listings de catégories, images statiques, CSS/JS. Gardez un TTL raisonnable (minutes à une heure) sauf si vous avez une intégration de purge robuste lorsque le stock/prix change.

Blague #2 : Si vous mettez en cache la page de checkout, vous n’avez pas construit un site e‑commerce — vous avez construit un jeu de devinette interactif.

En‑têtes d’origine : Cache-Control, Vary et pourquoi ça importe

La politique de mise en cache de Cloudflare est une conversation entre votre origine, les paramètres Cloudflare et la requête. Si vous ne contrôlez qu’un côté de cette conversation, vous allez mal interpréter le résultat.

Cache-Control : l’intention de votre origine

Pour le contenu admin et personnalisé, vous voulez :

• Cache-Control: private, no-store ou no-cache selon votre stack

Pour le HTML public que vous acceptez de mettre en cache :

• Cache-Control: public, max-age=0, s-maxage=... (si vous voulez que la périphérie mette en cache plus longtemps que les navigateurs)
• Ou laissez Cloudflare définir un Edge TTL et maintenez un TTL navigateur modéré

Vary : le multiplicateur silencieux de clés de cache

Vary indique aux caches quelles en‑têtes de requête affectent la réponse. Si votre origine envoie Vary: Cookie,
vous faites effectivement de chaque combinaison de cookies un objet différent. Cela peut être correct pour des réponses personnalisées, et
catastrophique pour les performances si cela se retrouve sur des pages publiques.

Préférez éviter Vary: Cookie sur le HTML public en contournant en fonction des cookies à la place. Si un plugin force cela,
vous devrez peut‑être désactiver ce comportement ou accepter un taux de hit plus faible.

Une citation sur laquelle vous pouvez réellement baser un système

Werner Vogels (idée paraphrasée) : « Tout échoue, tout le temps — concevez pour que les systèmes continuent de fonctionner quoi qu’il arrive. » C’est aussi la mise en cache :
supposez des pannes partielles et des objets obsolètes, puis contenez le rayon des dégâts.

Tâches pratiques : commandes, sorties, décisions (12+)

Voici les vérifications que j’exécute quand quelqu’un dit « Cloudflare a cassé wp-admin » ou « nous avons activé la mise en cache et maintenant c’est étrange ».
Chaque tâche inclut une commande, une sortie d’exemple, ce que cela signifie et la décision à prendre.

Task 1: Confirm whether Cloudflare is caching a public page

cr0x@server:~$ curl -sI https://example.com/ | egrep -i 'cf-cache-status|cache-control|age|server'
server: cloudflare
cf-cache-status: HIT
age: 842
cache-control: max-age=0, s-maxage=3600

Signification : La réponse est servie par Cloudflare (server: cloudflare) et est un HIT de cache avec un âge d’objet de 842 secondes.

Décision : La mise en cache HTML publique est active. Ensuite, vérifiez que le contournement par cookie fonctionne pour les sessions connectées.

Task 2: Verify wp-admin is not cached (it should be BYPASS or DYNAMIC)

cr0x@server:~$ curl -sI https://example.com/wp-admin/ | egrep -i 'cf-cache-status|location|set-cookie|cache-control'
cf-cache-status: DYNAMIC
cache-control: no-store, no-cache, must-revalidate, max-age=0

Signification : Cloudflare n’a pas servi ceci depuis le cache. L’origine indique no-store/no-cache.

Décision : Le contournement de chemin fonctionne pour /wp-admin/. Si les admins ont encore des problèmes, examinez les cookies, les challenges WAF ou la performance de l’origine.

Task 3: Verify wp-login.php is not cached

cr0x@server:~$ curl -sI https://example.com/wp-login.php | egrep -i 'cf-cache-status|cache-control|set-cookie'
cf-cache-status: DYNAMIC
cache-control: no-store, no-cache, must-revalidate, max-age=0

Signification : La page de connexion n’est pas mise en cache. Bien.

Décision : Si des boucles de connexion persistent, vous avez probablement un problème de cookie/redirection ou des paramètres HTTP/HTTPS mélangés entre WordPress et Cloudflare.

Task 4: Simulate a logged-in cookie and ensure public pages bypass

cr0x@server:~$ curl -sI https://example.com/ -H 'Cookie: wordpress_logged_in_abc=1' | egrep -i 'cf-cache-status|cache-control|age'
cf-cache-status: BYPASS
cache-control: private, no-cache, no-store, must-revalidate

Signification : Votre règle de contournement par cookie est effective ; Cloudflare ne met pas en cache le HTML quand le cookie de connexion existe.

Décision : Sûr pour les utilisateurs authentifiés. Si vous voyez HIT ici, arrêtez et corrigez les règles avant de divulguer du contenu personnalisé.

Task 5: Check REST API caching behavior (public endpoint)

cr0x@server:~$ curl -sI https://example.com/wp-json/ | egrep -i 'cf-cache-status|cache-control|content-type'
content-type: application/json; charset=UTF-8
cf-cache-status: DYNAMIC
cache-control: no-cache, must-revalidate, max-age=0

Signification : La racine REST est dynamique et non mise en cache.

Décision : Laissez‑la dynamique sauf si vous avez une raison précise de mettre en cache certains endpoints publics avec un TTL court et une stratégie d’invalidation claire.

Task 6: Detect accidental caching of previews (classic failure)

cr0x@server:~$ curl -sI "https://example.com/?p=123&preview=true" | egrep -i 'cf-cache-status|cache-control|age'
cf-cache-status: DYNAMIC
cache-control: private, no-cache, no-store, must-revalidate

Signification : Les réponses d’aperçu ne sont pas mises en cache.

Décision : Si c’est HIT, ajoutez des règles de contournement pour les paramètres de prévisualisation immédiatement.

Task 7: Confirm admin-ajax is not cached

cr0x@server:~$ curl -sI https://example.com/wp-admin/admin-ajax.php | egrep -i 'cf-cache-status|cache-control'
cf-cache-status: DYNAMIC
cache-control: no-store, no-cache, must-revalidate, max-age=0

Signification : Bien. Mettre en cache admin-ajax casse des parties aléatoires de l’UI admin et des fonctionnalités frontales.

Décision : Si ce n’est pas dynamique, contournez sur ce chemin et envisagez d’ajouter une règle WAF plutôt que de le mettre en cache.

Task 8: Inspect WordPress cookies from the login page

cr0x@server:~$ curl -sI https://example.com/wp-login.php | egrep -i 'set-cookie|location'
set-cookie: wordpress_test_cookie=WP%20Cookie%20check; path=/; secure; HttpOnly; SameSite=Lax

Signification : WordPress définit un cookie test ; le flux de connexion repose sur l’acceptation des cookies.

Décision : Si les cookies sont absents ou altérés, vérifiez les Transform Rules/Workers Cloudflare, les en‑têtes de sécurité, ou un plugin qui manipule les cookies.

Task 9: Verify HTTPS correctness and redirect chain

cr0x@server:~$ curl -sI http://example.com/wp-admin/ | egrep -i 'HTTP/|location|server'
HTTP/1.1 301 Moved Permanently
server: cloudflare
location: https://example.com/wp-admin/

Signification : HTTP redirige correctement vers HTTPS.

Décision : Si vous voyez des boucles (http→https→http), corrigez le mode SSL (généralement Full/Strict) et assurez‑vous que les champs « Site URL » et « Home » de WordPress sont en HTTPS.

Task 10: Check whether Cloudflare is serving cached HTML to a request with WooCommerce cookies

cr0x@server:~$ curl -sI https://example.com/product/widget/ -H 'Cookie: wp_woocommerce_session_123=1; woocommerce_items_in_cart=1' | egrep -i 'cf-cache-status|age'
cf-cache-status: BYPASS

Signification : Comportement correct : ne pas mettre en cache le HTML avec l’état session/panier WooCommerce.

Décision : Si vous voyez HIT, ajoutez des règles de contournement par cookie et contournez immédiatement les chemins transactionnels.

Task 11: Validate response headers from origin directly (bypassing Cloudflare)

cr0x@server:~$ curl -sI https://origin.example.internal/ | egrep -i 'cache-control|vary|set-cookie|server'
server: nginx
cache-control: public, max-age=0, s-maxage=600
vary: Accept-Encoding

Signification : L’origine prévoit une mise en cache en périphérie pendant 600 secondes et ne varie pas selon Cookie. C’est bon pour les pages publiques.

Décision : Alignez l’Edge TTL de Cloudflare avec l’intention de l’origine, ou surchargez‑le prudemment. Si vous voyez Vary: Cookie, attendez‑vous à une douleur sur le taux de hit.

Task 12: Check for surprising cookies on anonymous requests

cr0x@server:~$ curl -sI https://example.com/ | egrep -i 'set-cookie'
set-cookie: pll_language=en; path=/; secure; SameSite=Lax

Signification : Un plugin de langue définit un cookie même pour les utilisateurs anonymes. Cela peut ou non modifier le HTML.

Décision : Si le contenu varie selon ce cookie, soit variez le cache en conséquence (prudemment), soit contournez pour ces utilisateurs ; sinon ignorez‑le pour maintenir un taux de hit élevé.

Task 13: Confirm that a purge actually changes the object (spot stale content)

cr0x@server:~$ curl -sI https://example.com/ | egrep -i 'cf-cache-status|age|etag|last-modified'
cf-cache-status: HIT
age: 3599
etag: "a1b2c3"

Signification : L’objet en périphérie a presque une heure.

Décision : Si vous venez de mettre à jour du contenu et que vous vous attendiez à un changement, vous avez besoin soit (a) de meilleurs triggers de purge, (b) d’un TTL HTML plus court, ou (c) d’un bust de cache via des surrogate keys/tags (si votre configuration le supporte).

Task 14: Check origin health and latency when cache is bypassed

cr0x@server:~$ curl -s -o /dev/null -w 'ttfb=%{time_starttransfer} total=%{time_total}\n' https://example.com/wp-admin/
ttfb=1.842 total=1.913

Signification : Le Time‑To‑First‑Byte est ~1.8s pour l’admin. C’est du temps origine/PHP/DB, pas Cloudflare.

Décision : Arrêtez d’obséder sur la périphérie et profilez les workers PHP, les requêtes DB et le cache d’objets. La vitesse de l’admin dépend majoritairement de l’origine.

Task 15: Inspect PHP-FPM pressure (common wp-admin slowness)

cr0x@server:~$ sudo ss -s
Total: 256 (kernel 0)
TCP:   128 (estab 22, closed 84, orphaned 0, synrecv 0, timewait 84/0), ports 0

Transport Total     IP        IPv6
RAW	  0         0         0
UDP	  6         4         2
TCP	  44        28        16
INET	  50        32        18
FRAG	  0         0         0

Signification : Ceci ne montre pas directement PHP‑FPM, mais indique de l’usure de connexions. Associez‑le à votre statut PHP‑FPM ou au comptage de processus.

Décision : Si l’admin est lent lors d’un trafic élevé et que les chemins contournés s’accumulent, augmentez la capacité PHP‑FPM ou réduisez les plugins admin coûteux plutôt que d’ajuster le TTL en périphérie.

Task 16: Check Nginx access logs for cache-bypass endpoints getting hammered

cr0x@server:~$ sudo tail -n 5 /var/log/nginx/access.log
203.0.113.10 - - [27/Dec/2025:10:14:01 +0000] "POST /wp-login.php HTTP/2.0" 200 4578 "-" "Mozilla/5.0"
203.0.113.11 - - [27/Dec/2025:10:14:02 +0000] "GET /wp-admin/admin-ajax.php?action=heartbeat HTTP/2.0" 200 321 "-" "Mozilla/5.0"
203.0.113.12 - - [27/Dec/2025:10:14:02 +0000] "GET /wp-admin/admin-ajax.php?action=heartbeat HTTP/2.0" 200 321 "-" "Mozilla/5.0"
203.0.113.13 - - [27/Dec/2025:10:14:03 +0000] "GET /wp-admin/admin-ajax.php?action=heartbeat HTTP/2.0" 200 321 "-" "Mozilla/5.0"
203.0.113.14 - - [27/Dec/2025:10:14:03 +0000] "GET /wp-admin/admin-ajax.php?action=heartbeat HTTP/2.0" 200 321 "-" "Mozilla/5.0"

Signification : Les appels heartbeat peuvent s’empiler avec de nombreux éditeurs et gonfler la charge PHP. La mise en cache n’aidera pas car elle ne doit pas être faite.

Décision : Ajustez la fréquence du Heartbeat, réduisez le nombre d’éditeurs concurrents, ou scalez les workers PHP. Envisagez de limiter le débit des patterns abusifs en périphérie.

Mode opératoire de diagnostic rapide

Quand vous êtes sur le pont et que quelqu’un crie « Cloudflare l’a fait », vous avez besoin d’un chemin court vers la vérité. Voici mon flux
vérifiez‑d’abord/puis-deuxième/troisième.

Premier : La mauvaise réponse est‑elle mise en cache ?

• Vérifiez CF-Cache-Status sur l’URL défaillante.
• Si c’est HIT ou STALE sur une URL admin/connexion/aperçu, vous avez déjà trouvé le problème : vos règles de contournement sont erronées.
• Si c’est DYNAMIC ou BYPASS, la mise en cache Cloudflare n’est probablement pas la cause directe. Passez à autre chose.

Deuxième : La requête est‑elle à état (cookies) et vous avez oublié de contourner ?

• Reproduisez la requête avec un cookie simulé wordpress_logged_in_* et assurez‑vous qu’elle contourne.
• Pour WooCommerce, testez avec des cookies de panier/session.
• Si les requêtes porteuses de cookies sont mises en cache, arrêtez‑vous. Corrigez le contournement par cookie et purgez le HTML affecté.

Troisième : Est‑ce un mauvais chaînage de redirection / mode SSL ?

• Vérifiez la chaîne de redirection de HTTP vers HTTPS et de www vers apex (ou inversement).
• Confirmez que « Home URL » et « Site URL » dans WordPress correspondent à ce que Cloudflare sert.
• Le mode SSL Cloudflare devrait être Full (Strict) si votre origine a un certificat valide.

Quatrième : Est‑ce vraiment la performance de l’origine ?

• Mesurez le TTFB pour /wp-admin/ et d’autres endpoints contournés.
• Si le TTFB est élevé, optimisez PHP/DB/cache d’objets. L’admin ne sera jamais rapide si l’origine fond.

Cinquième : Est‑ce une fonctionnalité de sécurité qui interfère (WAF / bot fight / challenges) ?

• Recherchez des 403/429/challenges JS durant les actions admin.
• Allowliste des IPs bureaux ou faites du SSO/VPN pour l’administration, plutôt que de désactiver la protection globalement.

Erreurs courantes : symptôme → cause → correction

1) Symptom: wp-admin shows a cached “Please log in” even after login

Cause racine : /wp-admin/ ou /wp-login.php a été mis en cache via « Cache Everything » sans contournement.

Correction : Ajoutez des règles explicites de contournement pour /wp-admin/*, /wp-login.php, et purgez le cache. Vérifiez avec CF-Cache-Status: DYNAMIC.

2) Symptom: Login redirect loop (wp-login.php → wp-admin → wp-login.php)

Cause racine : Schéma mixte (HTTP/HTTPS) ou mode SSL incorrect ; les cookies sont définis pour HTTPS mais les requêtes transitent par HTTP, ou l’origine croit être en HTTP derrière le proxy.

Correction : Assurez‑vous que Cloudflare est en Full (Strict) vers l’origine, forcez HTTPS, définissez les URLs WordPress en HTTPS, et assurez‑vous que l’origine voit correctement X-Forwarded-Proto / CF-Visitor.

3) Symptom: Preview shows old content or someone else’s draft

Cause racine : Les URLs d’aperçu ont été mises en cache en périphérie. Les paramètres de prévisualisation ne sont pas exclus.

Correction : Contournez le cache pour preview=true, preview_id, preview_nonce, et envisagez de contourner complètement pour les cookies connectés.

4) Symptom: WooCommerce cart displays wrong items or empties randomly

Cause racine : Pages panier/checkout mises en cache ou endpoints de fragments mis en cache. Ou contournement par cookie manquant.

Correction : Contournez le cache pour les chemins cart/checkout/my-account, contournez sur les cookies session/panier WooCommerce, et ne mettez pas en cache ?wc-ajax=*.

5) Symptom: Logged-in users see the admin toolbar missing or half-broken

Cause racine : HTML mis en cache pour les utilisateurs connectés, ou optimisation en périphérie réécrivant JS/CSS dans wp-admin/front‑end pour les sessions authentifiées.

Correction : Contournez le cache HTML pour wordpress_logged_in_*. Désactivez les optimisations de scripts risquées sur les chemins admin/connexion.

6) Symptom: Random 403s in wp-admin, especially on save/publish

Cause racine : Une règle WAF match des POSTs admin, ou des protections bot challengent des actions authentifiées.

Correction : Créez des exceptions WAF ciblées pour les endpoints admin authentifiés, gardez la protection pour le trafic anonyme, et validez qu’aucune page challengée n’est mise en cache.

7) Symptom: Site is fast for anonymous users, but wp-admin is painfully slow

Cause racine : C’est normal si l’origine est surchargée. L’admin ne peut pas être mis en cache en toute sécurité, donc il expose la lenteur PHP/DB.

Correction : Ajoutez du cache d’objets, ajustez PHP‑FPM, réduisez les plugins lourds d’admin, optimisez la base de données, et envisagez de scaler l’origine. N’essayez pas de « mettre en cache wp-admin ».

8) Symptom: Purge “fixes it” but only for a few minutes

Cause racine : Vous masquez une politique de cache erronée ; du contenu est mis en cache alors qu’il ne devrait pas l’être, ou le TTL est trop long sans intégration de purge.

Correction : Corrigez les règles de contournement, ajustez les TTL, et implémentez des purges ciblées sur publication/mise à jour. Purger comme mécanisme d’adaptation n’est pas une stratégie.

Trois mini‑histoires du monde de l’entreprise

Story 1: An incident caused by a wrong assumption

Une entreprise de taille moyenne gérait un site marketing WordPress derrière Cloudflare. Un ingénieur bien intentionné a vu une forte CPU d’origine pendant une
campagne et a activé « Cache Everything » pour toute la zone, supposant que WordPress « saurait » de ne pas mettre en cache les pages d’administration.
Ils ont supposé que les en‑têtes Cache-Control de l’origine les protégeraient partout.

Pendant une heure, tout semblait aller bien — le TTFB a chuté, la charge d’origine est descendue, les dashboards ont reçu des félicitations. Puis les éditeurs ont signalé
qu’ils étaient « déconnectés au hasard ». Quelques minutes plus tard, quelqu’un a posté dans le canal d’incident que wp-admin se chargeait parfois mais affichait l’écran d’une autre personne.
Pas de fuite de contenu, heureusement, mais assez pour déclencher un audit paniqué.

La cause racine était banale : une règle large appliquée à /* sans contournement explicite pour /wp-admin/
et /wp-login.php. Certaines réponses admin avaient des codes de statut cacheables et ont été mises en cache assez longtemps pour créer un carrousel de confusion. L’origine envoyait en
général « no-store », mais pas de manière cohérente pour chaque cas limite et réponse de redirection dans le flux de connexion.

La correction fut également banale : règles explicites de contournement pour admin/connexion plus contournement basé sur les cookies pour les sessions connectées. Puis une purge complète du HTML.
La correction à plus long terme fut culturelle : aucun changement de cache sans une validation rapide par curl des CF-Cache-Status pour admin, login, preview, et une requête porteuse de cookie.

Story 2: An optimization that backfired

Une plus grande organisation voulait une « parité de performance globale » et décida de mettre en cache le HTML public en périphérie avec un long TTL pour réduire les coûts d’origine.
Ils ont mis en place des purges planifiées toutes les heures « juste pour être sûrs ». Ça semblait raisonnable sur un tableur.

En production, la purge horaire a créé une ruée prévisible vers l’origine. Juste après la purge, le taux de hit s’effondrait,
chaque page était un MISS, et l’origine s’est retrouvée submergée. Le load balancer a commencé à mettre en file d’attente, les workers PHP se sont saturés, et wp-admin
est devenu inutilisable pour les éditeurs précisément pendant les périodes où les équipes contenu étaient les plus actives.

Pour empirer les choses, quelques pages étaient personnalisées par un plugin de consentement qui injectait légèrement un HTML différent selon un cookie.
La clé de cache ne variait pas selon ce cookie (parce que varier selon les cookies aurait détruit le taux de hit), donc après chaque purge, la variante qui était mise en cache en premier remportait la loterie
pour tous les autres jusqu’à expiration.

La solution finale n’était pas spectaculaire. Ils ont raccourci le TTL du HTML à quelque chose correspondant à la vélocité du contenu, supprimé la purge planifiée,
et implémenté des purges ciblées sur publication/mise à jour. Pour le plugin de consentement, ils l’ont ajusté pour éviter de modifier le HTML de base pour les anonymes et ont déplacé la personnalisation côté client.

La leçon : si votre cache nécessite des purges complètes fréquentes pour rester correct, la politique de cache est mauvaise. Vous n’avez pas besoin d’un plus gros bouton de purge.
Vous avez besoin de moins de raisons d’appuyer dessus.

Story 3: The boring but correct practice that saved the day

Une autre équipe avait une politique stricte « changer avec preuve ». Chaque changement de mise en cache Cloudflare nécessitait un petit script de test exécuté depuis une bastion :
récupérer une page publique, récupérer wp‑admin, récupérer wp‑login, récupérer une URL d’aperçu, récupérer la page d’accueil avec un cookie simulé connecté, et enregistrer les en‑têtes clés.

Cela semblait lent, surtout quand les équipes produit voulaient des gains de performance instantanés. Mais l’équipe avait des cicatrices. Ils avaient vu des caches
fuir des états auparavant, et ils préféraient l’ennuyeux au spectaculaire.

Un vendredi, une nouvelle optimisation fut proposée : cache en périphérie du HTML pour un ensemble de pages landing marketing. L’ingénieur exécuta le script et remarqua quelque chose d’étrange :
les pages de landing définissaient un cookie d’un outil d’automatisation marketing à la première vue, et le HTML changeait subtilement pour inclure l’état d’un pixel de suivi personnalisé.

Parce que le cookie était présent pour beaucoup d’utilisateurs, le cache aurait servi la variante « cookie‑présent » aux utilisateurs sans cookie et inversement, et l’équipe marketing
aurait accusé l’analytics d’être « instable ». À la place, ils mirent en place la mise en cache en périphérie seulement pour les actifs et gardèrent le HTML conservateur jusqu’à pouvoir refactoriser les scripts de landing.

Rien n’a explosé. Personne n’a reçu d’alerte. Le week‑end est resté intact. C’est souvent cela le succès en opérations : tranquille.

Listes de contrôle / plan étape par étape

Étape par étape : configuration Cloudflare sûre pour WordPress

1. Commencez par les ressources statiques uniquement.
   • Définissez un Edge TTL et un Browser TTL longs pour les actifs versionnés.
   • Validez CF-Cache-Status: HIT pour .css, .js, images.
2. Installez des règles de contournement non négociables.
   • Contournez /wp-admin/*, /wp-login.php, /wp-admin/admin-ajax.php, les paramètres de prévisualisation.
   • Vérifiez qu’ils affichent CF-Cache-Status: DYNAMIC ou BYPASS.
3. Ajoutez un contournement basé sur les cookies pour les sessions authentifiées et à état.
   • Contournez lorsque le cookie correspond à wordpress_logged_in_*, wordpress_sec_*, wp-postpass_*.
   • Si e‑commerce : contournez les cookies WooCommerce et les chemins panier/checkout.
4. Si vous mettez le HTML en cache en périphérie, faites‑le explicitement et de manière ciblée.
   • Mettez en cache le HTML public seulement quand aucun cookie d’état n’est présent.
   • Définissez un TTL raisonnable (commencez 5–15 minutes) et ajustez après observation de la fréquence de mise à jour du contenu.
5. Définissez une politique de purge.
   • Privilégiez les purges ciblées lors des événements de publication/mise à jour.
   • Évitez les purges complètes planifiées à moins que vous n’aimiez les ruées vers l’origine.
6. Testez avec des flux réels.
   • Connectez‑vous, éditez, prévisualisez, publiez, téléchargez des médias, mettez à jour les menus.
   • Vérifiez qu’aucun endpoint admin n’est mis en cache et qu’aucun aperçu obsolète n’apparaît.
7. Observez et itérez.
   • Suivez le taux de hit, le TTFB de l’origine et les taux d’erreur.
   • Tout nouveau plugin qui définit des cookies devient un élément de revue du cache.

Checklist opérations : avant et après tout changement de mise en cache

• Confirmez que /wp-admin/ n’est pas mis en cache.
• Confirmez que /wp-login.php n’est pas mis en cache.
• Confirmez que les URLs d’aperçu ne sont pas mises en cache.
• Confirmez que la page d’accueil est mise en cache pour les requêtes anonymes (si vous avez l’intention de mettre le HTML en cache).
• Confirmez que la page d’accueil contourne quand le cookie wordpress_logged_in_* est présent.
• Confirmez le contournement panier/checkout WooCommerce (si applicable).
• Confirmez que la chaîne de redirection est correcte (HTTP→HTTPS, normalisation www).
• Confirmez qu’aucun challenge WAF n’apparaît en plein milieu d’une action admin.
• Enregistrez les en‑têtes avant/après : CF-Cache-Status, Cache-Control, Vary.
• Ayez un plan de rollback : désactiver la règle de cache HTML, purger le HTML, garder la mise en cache statique.

FAQ

1) Puis‑je mettre wp-admin en cache pour le rendre plus rapide ?

Non, pas en toute sécurité. wp‑admin est authentifié, lourd en nonces et spécifique à l’utilisateur. Améliorez sa rapidité en corrigeant PHP/DB/cache d’objets et en réduisant la charge des plugins d’administration.
Mettez en cache les ressources statiques globalement ; laissez l’administration dynamique.

2) « Cache Everything » est‑il toujours mauvais pour WordPress ?

Pas toujours. C’est dangereux quand utilisé largement sans règles strictes de contournement. Si vous le couplez avec le contournement pour admin/login/preview
et le contournement par cookie pour les sessions à état, cela peut bien fonctionner pour le contenu public.

3) Quelle est la liste minimale de cookies à contourner pour WordPress ?

wordpress_logged_in_*, wordpress_sec_*, et wp-postpass_*. Puis ajoutez les cookies WooCommerce ou les cookies des plugins membership selon les besoins.

4) Pourquoi les aperçus plantent‑ils spécifiquement ?

Les URLs d’aperçu incluent des paramètres qui représentent une permission limitée dans le temps pour voir du contenu brouillon. Si vous mettez cette réponse en cache,
vous pouvez servir des brouillons obsolètes — ou servir un aperçu à quelqu’un qui ne devrait pas le voir. Contournez les paramètres d’aperçu.

5) Dois‑je contourner /wp-json/ ?

Pour les requêtes authentifiées, oui. Pour les endpoints publics, cela dépend. Si vous n’avez pas d’avantage clair et un plan TTL court,
laissez‑le dynamique. Le caching REST est facile à mal gérer subtilement.

6) Mon site définit beaucoup de cookies pour les anonymes. Cela signifie‑t‑il que je ne peux pas mettre le HTML en cache ?

Pas nécessairement. La question est de savoir si le HTML varie à cause de ces cookies. Si c’est le cas, déplacez la personnalisation côté client ou variez le cache prudemment sur un petit ensemble contrôlé.
Si ce n’est pas le cas, ignorez‑les pour les décisions de cache.

7) Pourquoi mon taux de hit est‑il faible alors que j’ai activé la mise en cache ?

Raisons courantes : vous variez sur trop de choses (en‑têtes/cookies), le TTL est trop court, les query strings créent beaucoup de variantes,
ou vous purgez trop souvent. Mesurez CF-Cache-Status sur les URLs principales et réduisez la variation inutile.

8) Dois‑je me fier au Cache-Control d’origine ou aux réglages Edge TTL de Cloudflare ?

Idéalement les deux s’alignent. En pratique, je préfère des règles Cloudflare explicites pour ce qui est mis en cache et pour combien de temps, puis garder les en‑têtes d’origine cohérents :
« no-store » pour admin/personnalisé, des indices de cache raisonnables pour le contenu public. Testez le résultat, ne le débattez pas.

9) Dois‑je purger à chaque mise à jour d’article ?

Si vous mettez le HTML en cache en périphérie et que les rédacteurs attendent des mises à jour quasi instantanées, oui — au moins pour les pages affectées (URL de l’article, page d’accueil,
pages de catégorie). Si vous pouvez tolérer un court délai, définissez un TTL plus court et purgez moins. Choisissez une chose : simplicité opérationnelle ou fraîcheur instantanée.

10) Quel est le gain de performance le plus sûr qui ne touchera pas wp-admin ?

Mettez en cache les ressources statiques en périphérie avec des TTL longs, activez la compression, et optimisez PHP/DB de l’origine pour l’administration. Cela vous donne
une accélération visible sans risquer les flux authentifiés.

Conclusion : prochaines étapes durables

La mise en cache Cloudflare ne « casse » pas wp‑admin. Les gens cassent wp‑admin en mettant en cache des choses qui ne devraient jamais l’être, puis en supposant que la périphérie déduira magiquement l’état utilisateur.
La correction est mécanique : réserver admin/login/preview, contourner en fonction des cookies d’état, et traiter la mise en cache HTML comme une fonctionnalité contrôlée avec des tests.

Prochaines étapes pratiques :

1. Exécutez les vérifications d’en‑têtes pour la page d’accueil, wp‑admin, wp‑login et une URL d’aperçu. Enregistrez CF-Cache-Status.
2. Implémentez des règles de contournement de chemin pour admin/login/admin‑ajax et les paramètres de prévisualisation. Vérifiez immédiatement avec curl.
3. Ajoutez le contournement par cookie pour les cookies d’auth WordPress et les cookies de session e‑commerce.
4. Si vous mettez le HTML en cache, commencez avec un TTL court et des purges ciblées sur publication. Ne planifiez jamais des purges complètes comme style de vie.
5. Quand wp‑admin est lent, arrêtez de blâmer le cache et mesurez le TTFB de l’origine. Ensuite, optimisez PHP‑FPM et la base de données comme un adulte.