Ce guide concerne NGINX Open Source. Vérifiez la version, les modules compilés ou chargés et les particularités de votre paquet.
La clé décide quelles requêtes partagent une réponse
Un cache réutilise une réponse associée à une clé. Cette clé doit distinguer les propriétés qui changent réellement la représentation : service, URI, arguments et éventuellement d’autres dimensions. Si deux requêtes différentes ont la même clé, elles peuvent partager un contenu qui ne devrait pas l’être.
Commencez par un contenu explicitement public. L’existence d’un cookie ou d’un en-tête d’autorisation impose de vérifier le comportement de l’application et les règles du cache. Ne neutralisez pas les en-têtes de contrôle du backend pour obtenir un meilleur taux de HIT.
Le cache effectue des décisions distinctes de lecture et d’écriture. Les exclusions et la clé doivent préserver la séparation des représentations.
Télécharger le schéma en SVG · version claireSources : NGINX / F5, Module ngx_http_proxy_module.
Séparer index mémoire et contenu sur disque
proxy_cache_path définit notamment le stockage et une zone contenant les métadonnées du cache. inactive concerne les éléments qui ne sont pas accédés pendant une période ; il ne définit pas à lui seul la fraîcheur d’une réponse. La validité relève des en-têtes applicables et de la configuration.
Le fragment déclare une zone en contexte http, puis utilise cette zone dans une location publique. Le chemin doit être préparé pour l’identité du processus approprié. Les limites et durées sont pédagogiques, sans recommandation universelle de dimensionnement.
proxy_cache_path /var/cache/nginx/revision
keys_zone=revision_cache:10m inactive=10m max_size=100m;
server {
listen 127.0.0.1:8080;
location /public/ {
proxy_pass http://127.0.0.1:9000;
proxy_cache revision_cache;
proxy_cache_valid 200 30s;
proxy_cache_bypass $http_authorization $http_cookie;
proxy_no_cache $http_authorization $http_cookie;
}
}Sources : NGINX / F5, Module ngx_http_proxy_module.
Lecture du cache et écriture du cache
proxy_cache_bypass décide de ne pas utiliser une réponse stockée. proxy_no_cache empêche de stocker la réponse reçue. L’une de ces décisions ne remplace pas l’autre : un parcours personnalisé peut nécessiter les deux. Vérifiez aussi Set-Cookie, Cache-Control et Vary selon votre version.
Une durée de validité écoulée, un fichier évincé et un contenu servi en mode stale sont des situations différentes. Définissez quel comportement dégradé est acceptable. Servir une ancienne page publique et servir un ancien état métier d’un utilisateur ne présentent pas les mêmes conséquences.
Sources : NGINX / F5, Module ngx_http_proxy_module.
Recette : public, personnalisé et modification
Rejouez une route publique identique, puis une route authentifiée et une variante d’arguments. Comparez les observations du cache et les accès réellement reçus par le backend. Une réponse rapide ne prouve pas un HIT ; instrumentez le statut du cache dans une trace de laboratoire.
Exercice : expliquez pourquoi un bypass seul ne garantit pas l’absence de stockage de la nouvelle réponse. Puis modifiez le contenu du backend et décrivez quand le client doit voir cette version. Le compte rendu doit distinguer clé, fraîcheur, stockage et exclusion, sans prétendre qu’un cache remplace une politique de confidentialité.
Sources : NGINX / F5, Module ngx_http_proxy_module ; NGINX / F5, Module ngx_http_log_module.
Sources et portée
Les dates de consultation et les versions applicables sont précisées pour chaque référence ci-dessous. Les exemples utilisent des noms et adresses de documentation à remplacer. Les commandes de lecture affichent l’existant ; les captures et requêtes de diagnostic sont à limiter au périmètre autorisé.
- NGINX / F5 — Module ngx_http_proxy_module · Référence officielle ; vérifier le périmètre de version · consulté le 3 octobre 2026.
- NGINX / F5 — Module ngx_http_log_module · Référence officielle ; vérifier le périmètre de version · consulté le 3 octobre 2026.
Retrouver le parcours de lecture F5 NGINX