ERR_CACHE_MISS : causes et solutions (Chrome, Edge, Android)
Point clé
ERR_CACHE_MISS signifie que Chrome avait besoin d'une copie enregistrée d'une page et n'en avait aucune. Le plus souvent, vous êtes revenu en arrière sur une page créée par un formulaire (une requête POST) : au lieu de renvoyer le formulaire, Chrome affiche « Confirmer le nouvel envoi du formulaire ». Actualisez la page et cliquez sur « Continuer » seulement si répéter l'action est sans risque (une recherche, pas un paiement) ; sinon, rouvrez la page depuis le site. Dans une application Android, cela signifie généralement que la WebView ne peut pas utiliser le réseau. Côté site, le pattern Post/Redirect/Get évite l'erreur.
Vérifiez maintenant

Commencer la lecture
- Qu'est-ce que ERR_
CACHE_ MISS ? - À quoi ressemble ERR_
CACHE_ MISS - Quelles sont les causes de ERR_
CACHE_ MISS ? - ERR_
CACHE_ MISS ou « Confirmer le nouvel envoi du formulaire » : la différence - Comment corriger ERR_
CACHE_ MISS (pour les utilisateurs) - Solution 1 : actualiser, et renvoyer seulement si c'est sans risque
- Solution 2 : vider le cache (seulement si l'erreur revient)
- Solution 3 : tester en navigation privée
- Solution 4 : désactiver les extensions du navigateur
- Solution 5 : mettre à jour Chrome (et Android System WebView)
- Comment corriger ERR_
CACHE_ MISS (pour les développeurs) - Le pattern Post/Redirect/Get (PRG)
- Vérifiez vos en-têtes Cache-Control
- Corriger les conflits de cache sur WordPress
- ERR_
CACHE_ MISS sur Android (applications et WebView) - ERR_
CACHE_ MISS dans les autres navigateurs - Erreurs de cache associées dans Chrome
- Questions fréquemment posées
Qu'est-ce que ERR_CACHE_MISS ?
ERR_CACHE_MISS signifie que Chrome avait besoin d'une copie enregistrée (en cache) d'une page et n'en avait pas. Le plus souvent, vous avez appuyé sur Retour pour revenir à une page créée par un formulaire, comme le résultat d'une connexion, d'une recherche ou d'un paiement : Chrome ne renvoie pas le formulaire de lui-même, il affiche donc Confirmer le nouvel envoi du formulaire avec le code ERR_CACHE_MISS.
L'erreur ne quitte jamais votre navigateur et ce n'est pas un code de statut HTTP. La liste des erreurs de Chromium la définit comme l'erreur -400 : « The cache does not have the requested entry » (le cache ne contient pas l'entrée demandée) (net_error_list.h). Chrome garde une copie des résultats de formulaire pour que le bouton Retour puisse les réafficher ; si cette copie manque, le seul moyen de reconstruire la page est de renvoyer le formulaire, et Chrome vous laisse cette décision.
C'est un arrêt de sécurité, pas une panne ni une menace : renvoyer un formulaire peut répéter ce qu'il a fait, comme un paiement, une commande ou une publication.
La page envoie-t-elle no-store ? Vérifiez ses en-têtes
À quoi ressemble ERR_CACHE_MISS
Chrome et Edge affichent l'une de ces deux pages, avec ERR_CACHE_MISS écrit sous le message :
- Confirmer le nouvel envoi du formulaire — après Retour ou Avancer vers une page créée par un formulaire : « Pour s'afficher correctement, cette page Web a besoin des données que vous avez saisies précédemment. Vous pouvez envoyer de nouveau ces données. Cependant, en procédant ainsi, vous répéterez toute action déjà effectuée sur cette page. » En dessous : « Veuillez appuyer sur le bouton d'actualisation pour renvoyer les données nécessaires au chargement de la page. »
- Impossible de charger ce site à partir du cache — avec « La copie enregistrée (en cache) de ce site est illisible. » et un bouton Actualiser : une page que Chrome ne pouvait prendre que dans son cache n'y était pas
- La boîte de dialogue de renvoi — quand vous actualisez la première page : « La page que vous recherchez a utilisé des informations que vous avez envoyées. Si vous revenez sur cette page, chaque action précédemment effectuée sera répétée. Souhaitez-vous continuer ? » avec un bouton Continuer
- net::ERR_CACHE_MISS — la même erreur dans la console des DevTools, ou dans le journal de la WebView d'une application Android
Quelles sont les causes de ERR_CACHE_MISS ?
Toutes les causes reviennent à la même chose : Chrome devait utiliser son cache, et la page n'y était pas.
- Revenir en arrière (ou en avant) sur le résultat d'un formulaire — Chrome enregistre la page produite par un formulaire (une requête POST) pour que le bouton Retour puisse la réafficher. Si cette copie a disparu, Chrome devrait renvoyer le formulaire : il s'arrête donc et vous demande.
- La page demandait à ne pas être enregistrée — une page de résultat envoyée avec
Cache-Control: no-storen'est jamais conservée : y revenir avec Retour mène toujours à la page de confirmation du renvoi. - Un cache vidé ou réduit — supprimer les données de navigation, ou laisser Chrome réduire son cache pour gagner de la place, efface la copie enregistrée d'une page de résultat.
- Chargements depuis le cache uniquement — une WebView Android sans accès au réseau, le mode hors connexion d'une application ou un script qui ne demande qu'une copie en cache échouent tous avec ERR_CACHE_MISS quand rien n'est enregistré.
- Un cache endommagé — selon les notes de Chromium, un cache illisible vient généralement d'un arrêt incorrect. Cela affiche la page « Impossible de charger ce site à partir du cache », souvent avec ERR_CACHE_READ_FAILURE.
- Une extension qui modifie les requêtes — plus rarement, une extension qui bloque ou modifie les requêtes empêche une page de se charger normalement. Une fenêtre de navigation privée permet de l'écarter.
ERR_CACHE_MISS ou « Confirmer le nouvel envoi du formulaire » : la différence
Les deux sont liés, mais apparaissent à des moments différents. Actualiser une page produite par un formulaire ouvre aussitôt la boîte de dialogue Confirmer le nouvel envoi du formulaire. Revenir plus tard sur cette page avec Retour ou Avancer, quand Chrome n'en a plus de copie, affiche la page « Confirmer le nouvel envoi du formulaire » avec le code ERR_CACHE_MISS ; actualiser cette page ouvre ensuite la même boîte de dialogue. Continuer renvoie le formulaire, Annuler ne fait rien.
Chrome ne décide pas à votre place, car l'envoi d'un formulaire (POST) n'est pas une requête « sûre » au sens de HTTP : l'envoyer de nouveau peut répéter ce qu'il a fait.
Cliquez sur Continuer pour une recherche, un filtre ou une page que vous avez seulement consultée. Pour un paiement, une commande, une réservation ou une publication, cliquez sur Annuler et vérifiez plutôt l'historique de commandes du site ou vos e-mails.
Comment corriger ERR_CACHE_MISS (pour les utilisateurs)
Suivez ces solutions dans l'ordre. La première règle le cas habituel : une page de formulaire sur laquelle vous êtes revenu. Si tout le site refuse de se charger, vérifiez s'il est en panne pour tout le monde avec notre outil Vérificateur de site en panne.
Solution 1 : actualiser, et renvoyer seulement si c'est sans risque
Sur la page « Confirmer le nouvel envoi du formulaire », appuyez sur Actualiser (ou F5). Chrome vous demande s'il doit renvoyer le formulaire : cliquez sur Continuer seulement si le répéter est sans conséquence. Encore plus sûr : n'utilisez pas Retour. Rouvrez la page depuis le menu du site ou la barre d'adresse, ce qui charge une copie neuve sans passer par le formulaire.
Sur une page normale qui affiche « Impossible de charger ce site à partir du cache », faites une actualisation forcée, qui ignore le cache :
# Windows / Linux
Ctrl + Shift + R
# Mac
Cmd + Shift + R
# Windows / Linux alternative
Ctrl + F5 (or Shift + F5)Avec les DevTools ouverts (F12), vous pouvez aussi faire un clic droit sur le bouton d'actualisation et choisir Vider le cache et effectuer une actualisation forcée.
Solution 2 : vider le cache (seulement si l'erreur revient)
Vider le cache n'aide pas dans le cas du formulaire : cela efface les copies enregistrées et peut même provoquer l'erreur. C'est utile en revanche quand des pages normales affichent sans cesse « Impossible de charger ce site à partir du cache », ce qui indique un cache endommagé :
- Étape 1 : Appuyez sur
Ctrl+Shift+Delete(Mac :Cmd+Shift+Delete) pour ouvrir Supprimer les données de navigation - Étape 2 : Réglez la période sur Depuis le début
- Étape 3 : Cochez Images et fichiers en cache (les cookies sont facultatifs, voir ci-dessous)
- Étape 4 : Cliquez sur Supprimer les données et redémarrez Chrome
Solution 3 : tester en navigation privée
Une fenêtre de navigation privée démarre avec un cache vide et sans vos extensions (sauf si vous les y avez autorisées). Ouvrez-en une avec Ctrl+Shift+N (Windows, Linux) ou Cmd+Shift+N (Mac) et chargez la même page depuis le site, pas avec Retour.
Si la page fonctionne en navigation privée mais pas dans une fenêtre normale, une extension ou le cache est en cause : essayez les solutions 2 et 4.
Solution 4 : désactiver les extensions du navigateur
Les extensions qui bloquent ou réécrivent les requêtes peuvent parfois empêcher une page de se charger normalement.
Allez dans chrome://extensions/, désactivez toutes les extensions, puis rechargez la page. Si l'erreur disparaît, réactivez-les une par une pour trouver la responsable.
Solution 5 : mettre à jour Chrome (et Android System WebView)
Allez dans chrome://settings/help pour installer une éventuelle mise à jour ; Chrome l'applique après un redémarrage. Sur Android, mettez à jour Chrome et Android System WebView dans le Play Store, car les applications qui affichent des pages web utilisent la WebView.
Si l'erreur est apparue juste après une mise à jour et touche des pages qui ne sont pas des formulaires, consultez le suivi des bugs de Chromium pour voir si un problème est connu avec votre version.
Comment corriger ERR_CACHE_MISS (pour les développeurs)
Si des visiteurs rencontrent ERR_CACHE_MISS sur votre site, ils reviennent presque certainement en arrière sur une page que votre serveur a générée directement à partir d'un POST de formulaire. La correction se fait côté serveur : Post/Redirect/Get.
Le pattern Post/Redirect/Get (PRG)
Le pattern Post/Redirect/Get (PRG) est la solution définitive à ERR_CACHE_MISS. Le principe est simple : après avoir traité un formulaire envoyé en POST, répondez par une redirection HTTP (302 ou 303) vers une page de confirmation en GET au lieu d'afficher directement la réponse.
Sans PRG, l'historique du navigateur se termine par une requête POST. Si l'utilisateur actualise, Chrome demande s'il faut renvoyer le formulaire ; s'il y revient avec Retour ou Avancer et que la copie a disparu, Chrome affiche ERR_CACHE_MISS. Avec PRG, l'historique se termine par une requête GET sûre, que l'on peut actualiser ou retrouver avec Retour sans aucun problème.
# Without PRG (causes ERR_CACHE_MISS):
POST /checkout → 200 OK (render confirmation page)
# User reloads → "Confirm Form Resubmission" dialog
# User comes back with Back/Forward, copy gone → ERR_CACHE_MISS
# With PRG (no cache issues):
POST /checkout → 303 See Other → Location: /order/12345
GET /order/12345 → 200 OK (render confirmation page)
# User refreshes → Normal page reload (safe GET request)Utilisez 303 See Other (recommandé) ou 302 Found pour la redirection. La RFC 9110 indique que le code 303 sert « principalement à permettre au résultat d'une action POST de rediriger l'agent utilisateur vers une autre ressource », ce qui est exactement le but recherché. Le Vérificateur de redirections de DNS Robot montre le code de statut que votre formulaire renvoie réellement.
Vérifiez vos en-têtes Cache-Control
Vérifiez ce qu'envoie la page de résultat de votre formulaire avec les DevTools de Chrome (F12 → Réseau → la requête → En-têtes), ou depuis l'extérieur avec le Vérificateur d'en-têtes HTTP de DNS Robot.
Sur une page produite par un formulaire, Cache-Control: no-store empêche Chrome de garder la copie dont Retour a besoin : chaque retour arrière mène alors à la page de confirmation du renvoi. Gardez no-store sur les pages contenant des données personnelles ou de paiement et utilisez PRG, pour que le résultat soit de toute façon une page GET normale.
| Sur la page de résultat d'un formulaire | Ce qui est enregistré | Ce qu'affiche Retour |
|---|---|---|
Cache-Control: no-store | Rien | Confirmer le nouvel envoi du formulaire (ERR_CACHE_MISS) |
no-cache ou max-age=… | Une copie, gardée pour l'historique | La copie enregistrée |
| PRG : 303 vers une page GET | Une page GET normale | La page elle-même ; actualiser est sans risque |
Corriger les conflits de cache sur WordPress
Les plugins de cache de page ne provoquent pas ERR_CACHE_MISS à eux seuls, mais une page de panier, de paiement ou de connexion mise en cache casse les formulaires et fait faire des allers-retours aux visiteurs, et c'est là que l'erreur apparaît.
Si vous utilisez WooCommerce, vérifiez que votre plugin de cache exclut les pages dynamiques : le panier, la page de paiement et « Mon compte » ne doivent jamais être mis en cache. WP Super Cache, W3 Total Cache et LiteSpeed Cache ont tous des réglages pour cela.
- Purgez tous les caches — Videz le cache de votre plugin, le cache de l'hébergeur (le cas échéant) et le cache du CDN simultanément
- Désactivez les plugins en conflit — N'exécutez jamais deux plugins de cache de page complète en même temps
- Excluez les pages dynamiques — Les pages de panier, de paiement et de connexion doivent être exclues du cache
- Vérifiez le cache au niveau du serveur — Votre hébergeur peut ajouter sa propre couche de cache (Varnish, LiteSpeed, etc.) qui entre en conflit avec votre plugin
ERR_CACHE_MISS sur Android (applications et WebView)
Si l'erreur apparaît dans une application (un navigateur intégré, un écran de connexion ou de paiement), mettez à jour Chrome et Android System WebView dans le Play Store, puis videz le cache de l'application : Paramètres → Applications → l'application → Espace de stockage et cache (Stockage sur certains téléphones) → Vider le cache. Si l'erreur persiste, c'est l'application elle-même qui doit être corrigée : signalez-le à son développeur.
Si vous développez l'application : une WebView a besoin de l'autorisation INTERNET. Sans elle, Android bloque par défaut les chargements réseau de la WebView (la valeur par défaut de setBlockNetworkLoads est alors true) : les pages ne peuvent venir que du cache et échouent avec net::ERR_CACHE_MISS.
<!-- AndroidManifest.xml, inside <manifest> -->
<uses-permission android:name="android.permission.INTERNET" />Vérifiez ensuite le mode de cache : LOAD_CACHE_ONLY (« Don't use the network, load from the cache », c'est-à-dire ne pas utiliser le réseau et charger depuis le cache, souvent choisi pour un mode hors connexion) échoue avec ERR_CACHE_MISS pour tout ce qui n'est pas déjà en cache ; utilisez plutôt LOAD_DEFAULT. Dans les applications Flutter et React Native, l'autorisation se déclare aussi dans le fichier AndroidManifest.xml du projet Android.
ERR_CACHE_MISS dans les autres navigateurs
ERR_CACHE_MISS est un code de Chromium : Chrome, Edge, Brave, Opera et Vivaldi affichent donc tous les mêmes pages. Les autres navigateurs s'arrêtent dans la même situation, avec leurs propres mots.
| Navigateur | Ce qu'il affiche | Remarques |
|---|---|---|
| Chrome / Edge / Brave / Opera | Confirmer le nouvel envoi du formulaire, ou Impossible de charger ce site à partir du cache | Mêmes pages et même code Chromium (ERR_CACHE_MISS) |
| Firefox | Le document a expiré | « Le document demandé n'est plus disponible dans le cache de Firefox. » |
| Safari | Une boîte de dialogue avant de renvoyer le formulaire | Demande s'il faut renvoyer le formulaire |
La page de Firefox s'intitule Le document a expiré (« Document Expired » en anglais) : « Le document demandé n'est plus disponible dans le cache de Firefox. Par mesure de sécurité, Firefox ne redemande pas automatiquement de documents sensibles. Cliquez sur Réessayer pour redemander ce document depuis le site web. » La solution est la même : n'actualisez que si le renvoi est sans risque, ou utilisez PRG côté serveur.
Erreurs de cache associées dans Chrome
Les erreurs de cache de Chrome partagent le préfixe ERR_CACHE_. Seules quelques-unes s'affichent sur une page d'erreur ; la plupart (comme -408, une somme de contrôle incorrecte) restent internes au cache.
| Code d'erreur | Définition de Chromium | Cause courante |
|---|---|---|
| ERR_CACHE_MISS (-400) | The cache does not have the requested entry (le cache ne contient pas l'entrée demandée) | Retour vers le résultat d'un formulaire ; chargements depuis le cache uniquement |
| ERR_CACHE_READ_FAILURE (-401) | Unable to read from the disk cache (impossible de lire le cache disque) | Un cache endommagé par un plantage ou un arrêt incorrect |
| ERR_CACHE_WRITE_FAILURE (-402) | Unable to write to the disk cache (impossible d'écrire dans le cache disque) | Un disque plein ou un problème d'autorisations |
ERR_CACHE_READ_FAILURE affiche la même page « Impossible de charger ce site à partir du cache » : vider le cache (solution 2) la corrige. Pour ERR_CACHE_MISS, commencez par les solutions liées aux formulaires ci-dessus. Une autre erreur Chrome ? Consultez ERR_CONNECTION_REFUSED ou ERR_NAME_NOT_RESOLVED.
Vérifiez vos en-têtes HTTP
Utilisez le Vérificateur d'en-têtes HTTP gratuit de DNS Robot pour inspecter les en-têtes Cache-Control de votre serveur et les autres directives de réponse qui affectent la mise en cache du navigateur.
Sources
- net_error_list.h (CACHE_MISS -400), Chromium
- localized_error.cc (the error pages for ERR_CACHE_MISS), Chromium
- RFC 9110 §15.4.4: 303 See Other, IETF
- WebSettings (setBlockNetworkLoads, LOAD_CACHE_ONLY), Android Developers
Questions fréquemment posées
Que signifie ERR_CACHE_MISS ?
Comment corriger ERR_CACHE_MISS dans Chrome ?
Que signifie « Confirmer le nouvel envoi du formulaire » ? Faut-il cliquer sur Continuer ?
Pourquoi ERR_CACHE_MISS apparaît-il quand j'appuie sur Retour ?
ERR_CACHE_MISS est-il un virus ou un problème de sécurité ?
Comment corriger ERR_CACHE_MISS sur Android ?
Qu'est-ce qui cause net::ERR_CACHE_MISS dans une WebView Android ?
Pourquoi vois-je net::ERR_CACHE_MISS dans les DevTools de Chrome ?
Comment les développeurs peuvent-ils éviter ERR_CACHE_MISS ?
ERR_CACHE_MISS se produit-il dans Edge et les autres navigateurs ?
Articles associés
Outils associés
Vérificateur d'en-têtes HTTP
Analysez les en-têtes de réponse HTTP et la notation des en-têtes de sécurité
Vérificateur de Redirections
Vérifiez les redirections d'URL, les chaînes de redirection et les codes de statut HTTP pour le SEO
Vérificateur de site en panne
En panne pour tout le monde ou juste chez vous ? Vérifiez un site depuis 11 lieux et votre propre connexion, avec une capture en direct



