Corriger « Please wait while your request is being verified » (Imunify360 + Cloudflare)
Mis à jour en septembre 2026
Un indicateur vert affichant « Please wait while your request is being verified… » qui ne disparaît jamais — ou un simple « 403 Forbidden » signé openresty — signifie presque toujours qu'Imunify360 et Cloudflare ne s'entendent pas sur les cookies. Voici le mécanisme, comment le confirmer, et où se trouve désormais le réglage depuis l'abandon des Page Rules.
Ce que vous voyez
Vos visiteurs voient un indicateur vert et « Please wait while your request is being verified… » : la page se recharge et affiche indéfiniment la même chose. Certaines requêtes renvoient plutôt un « 403 Forbidden » brut, signé d'un nom de serveur comme openresty. C'est WebShield d'Imunify360, placé devant votre site sur le serveur lui-même.
C'est souvent intermittent et cela touche certains visiteurs et pas d'autres, ce qui rend la reproduction exaspérante. Le trafic automatisé — moniteurs de disponibilité, robots SEO, supervision de tunnel d'achat comme Relvato — y tombe bien plus sûrement que vous.
La cause : un cookie qui n'arrive jamais
WebShield d'Imunify360 soumet à vérification les visiteurs dont il n'est pas sûr, puis dépose un cookie une fois la vérification réussie pour ne plus redemander. Tout le mécanisme repose sur l'arrivée de ce cookie dans le navigateur.
Cloudflare casse cela dès qu'il met votre HTML en cache avec une TTL forcée. Dans les propres termes de Cloudflare, à propos de Cache Everything : « Respects cache headers from the origin web server unless Edge Cache TTL is also set in the Page Rule. When combined with an Edge Cache TTL > 0, Cache Everything removes cookies from the origin web server response. »
Cloudflare stocke donc la page de vérification et la sert à tout le monde, cookie retiré. Le visiteur réussit la vérification, reçoit une page en cache qui affiche toujours « verifying », et recommence. Voilà la boucle — et pris séparément, aucun des deux produits ne se comporte mal.
Confirmez-le en une commande
Demandez votre page d'accueil et regardez les en-têtes : curl -sI https://example.com/ — sur un WordPress normal, le document HTML ne devrait pas sortir d'un cache CDN.
Deux éléments réunis confirment le conflit. D'abord cf-cache-status: HIT accompagné d'un en-tête Age: sur le document HTML : Cloudflare sert votre page depuis son cache. Ensuite, aucun en-tête Set-Cookie dans cette réponse, car la copie en cache n'en a aucun à donner. Si vous voyez également cf-edge-cache: cache,platform=wordpress, c'est le plugin Cloudflare pour WordPress qui marque votre HTML comme cacheable.
Pour l'autre moitié, affichez le code source et cherchez imunify-bot-check. Si ce lien est injecté dans vos pages, WebShield vérifie activement les visiteurs.
Où se trouve le réglage aujourd'hui (les Page Rules sont abandonnées)
Tous les anciens articles vous disent de modifier une Page Rule. Cloudflare les a abandonnées au profit de produits dédiés : les réglages ont déménagé, le cache se trouve désormais dans Caching → Cache Rules.
Ouvrez Caching → Cache Rules, puis la règle qui rend votre HTML « Eligible for cache ». Descendez jusqu'à sa section « Then… ». Sous Edge TTL, si « Ignore cache-control header and use this TTL » est sélectionné, c'est le nom actuel de l'ancienne Edge Cache TTL — et c'est précisément ce qui supprime le cookie. Choisissez plutôt « Use cache-control header if present, bypass cache if not », puis enregistrez.
Ajoutez ensuite une seconde règle, placée au-dessus, qui garde la vérification hors du cache : If URI Path contains /imunify-bot-check → Cache eligibility: Bypass cache. Il vaut la peine d'étendre ce contournement à /wp-login.php et /wp-admin, qui ne devraient jamais être servis depuis un cache partagé non plus.
Purgez ensuite, sinon vous croirez que cela n'a rien changé. Modifier la règle empêche le cache de se remplir à nouveau, mais une copie enregistrée avant la modification continue d'être servie jusqu'à l'expiration de son ancienne TTL : avec une TTL de deux heures, cela fait jusqu'à deux heures de plus de la même boucle. Allez dans Caching → Configuration → Purge Everything. Revérifiez ensuite les en-têtes : votre HTML ne doit plus revenir avec cf-cache-status: HIT et un en-tête Age.
Si vous utilisez APO ou le plugin Cloudflare pour WordPress
Automatic Platform Optimization met délibérément votre HTML en cache à la périphérie, et sait contourner ce cache lorsqu'il voit les cookies de connexion propres à WordPress. Le cookie d'Imunify360 n'en fait pas partie : il ne déclenche donc pas ce contournement.
Vous pouvez ajouter vos propres cookies de contournement, mais uniquement sur les offres Business et Enterprise — sur Free et Pro, l'option n'existe pas. Si vous êtes sur Pro et que la boucle survit aux changements ci-dessus, désactiver la mise en cache du HTML (couper APO, ou supprimer la règle qui rend le HTML cacheable) est la sortie fiable. Images, CSS et JS restent en cache, et c'est là que se trouve l'essentiel du gain.
Côté origine, et quoi demander à votre hébergeur
Tout ce qui précède concerne Cloudflare, et c'est généralement la solution complète. WebShield, lui, tourne sur votre serveur, le plus souvent installé par votre hébergeur, et cPanel n'offre souvent aucun interrupteur pour le contrôler : assurez-vous donc que le cache est réellement corrigé avant d'ouvrir un ticket.
Cela compte plus qu'il n'y paraît. Sur une boutique réelle, la supervision renvoyait des erreurs HTTP 403 depuis des jours et ressemblait exactement à un blocage de pare-feu que seul l'hébergeur pouvait lever. Après le changement d'Edge TTL et la purge, tous les contrôles sont passés dès l'exécution suivante, sans rien modifier sur le serveur — y compris la page de paiement, qui n'avait jamais abouti une seule fois. Une vérification mise en cache et un blocage réel sont indiscernables de l'extérieur.
Si les contrôles échouent encore une fois le cache confirmé propre, c'est WebShield lui-même que vous heurtez et votre hébergeur doit intervenir. Pour la supervision en particulier, Relvato envoie un en-tête secret stable à chaque requête — X-Relvato-Token, visible dans les Paramètres de votre site — afin que votre hébergeur autorise exactement ce trafic sans rien affaiblir d'autre. Une règle au niveau du CDN ne peut pas y suffire : Imunify bloque à l'origine, après que Cloudflare a déjà laissé passer la requête.
Les conseils Page Rules d'hier, traduits dans le tableau de bord d'aujourd'hui
| Les anciens articles disent | Où c'est aujourd'hui | Que mettre |
|---|---|---|
| Page Rule → « Cache Everything » | Caching → Cache Rules → Cache eligibility | Eligible for cache |
| Page Rule → « Edge Cache TTL » | La même règle → Edge TTL | PAS « Ignore cache-control header and use this TTL » |
| « Retirez l'Edge Cache TTL » | La même règle → Edge TTL | « Use cache-control header if present, bypass cache if not » |
| Contourner le cache pour la vérification | Une Cache Rule placée au-dessus | URI Path contains /imunify-bot-check → Bypass cache |
| Contournement via un cookie personnalisé | Cache Rules / cookies de contournement APO | Offres Business et Enterprise uniquement |
Questions
Est-ce la faute d'Imunify360 ou de Cloudflare ?
D'aucun des deux isolément. Imunify360 s'appuie sur un cookie pour retenir qu'un visiteur a réussi sa vérification, et Cloudflare — lorsqu'on lui demande de mettre du HTML en cache avec une TTL forcée — met la page en cache et retire les cookies de la réponse d'origine. Chacun fait ce qui est documenté ; ensemble, ils se bloquent.
Désactiver le cache HTML va-t-il ralentir mon site ?
Bien moins qu'on ne le croit. Images, CSS, JavaScript et polices représentent l'essentiel de ce que télécharge un navigateur, et restent en cache à la périphérie dans tous les cas. Vous perdez le HTML mis en cache en périphérie, qu'un bon cache de pages côté serveur (LiteSpeed Cache, WP Rocket) remplace largement.
Pourquoi cela ne touche-t-il que certains visiteurs ?
WebShield vérifie ce qu'il juge suspect : la plupart des visiteurs humains sur des connexions ordinaires passent sans rien voir. Les IP de centres de données et les clients automatisés — moniteurs, robots, consommateurs d'API — sont vérifiés bien plus souvent, et c'est pourquoi ils révèlent le problème en premier.
J'ai purgé le cache Cloudflare et c'est revenu.
Purger vide le cache, mais ne change pas la règle qui le remplit à nouveau. En quelques minutes, la page de vérification est de nouveau en cache. Il faut modifier le réglage Edge TTL ou contourner le chemin, pas seulement purger.
Puis-je corriger cela depuis cPanel ?
En général non. Imunify360 est installé et configuré par votre hébergeur au niveau du serveur : la plupart des utilisateurs de cPanel n'ont aucun contrôle sur WebShield. Les changements côté Cloudflare vous appartiennent ; tout ce qui relève d'Imunify360 passe par votre hébergeur.
Cela corrigera-t-il aussi le blocage de mon moniteur de disponibilité ou de mon robot ?
Très probablement, et cela vaut la peine de le tester avant d'incriminer autre chose. Les clients automatisés sont vérifiés bien plus souvent que les humains : ils se retrouvent coincés dans la boucle en premier et le signalent comme un blocage ferme. Dans le cas ci-dessus, une supervision qui échouait depuis des jours avec des 403 est repassée au vert dès l'exécution suivante après la correction du cache, sans rien changer sur le serveur. Corrigez le cache, purgez, relancez — et contactez votre hébergeur seulement ensuite.
Ma supervision reste bloquée après avoir corrigé le cache.
C'est alors WebShield lui-même que vous heurtez, et non la boucle de cache : le conflit de cache et le blocage à l'origine sont deux problèmes distincts. Demandez à votre hébergeur d'autoriser l'en-tête d'identification du moniteur au niveau d'Imunify360 ; une règle Cloudflare ne peut pas contourner un pare-feu qui s'exécute derrière Cloudflare.