Arreglar «Please wait while your request is being verified» (Imunify360 + Cloudflare)
Actualizado en septiembre de 2026
Un indicador verde con «Please wait while your request is being verified…» que nunca desaparece —o un escueto «403 Forbidden» de openresty— casi siempre significa que Imunify360 y Cloudflare no se ponen de acuerdo sobre las cookies. Aquí tienes el mecanismo, cómo confirmarlo y dónde está ahora el ajuste, tras la retirada de las Page Rules.
Qué estás viendo
Los visitantes ven un indicador verde y «Please wait while your request is being verified…»: la página se recarga y muestra lo mismo eternamente. Algunas peticiones devuelven en su lugar un simple «403 Forbidden» con un nombre de servidor como openresty al pie. Ese es WebShield de Imunify360, que se sitúa delante de tu sitio en el propio servidor.
Suele ser intermitente y afectar a unos visitantes sí y a otros no, lo que hace exasperante reproducirlo. El tráfico automatizado —monitores de uptime, rastreadores SEO, monitorización de checkout como Relvato— cae en él con mucha más frecuencia que tú.
Por qué ocurre: una cookie que nunca llega
WebShield de Imunify360 verifica a los visitantes de los que no está seguro y, al superarse la comprobación, deja una cookie para no volver a preguntar. Todo el mecanismo depende de que esa cookie llegue al navegador.
Cloudflare lo rompe cuando cachea tu HTML con una TTL sobrescrita. En palabras del propio Cloudflare sobre 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.»
Así que Cloudflare guarda la página de verificación y se la entrega a todo el mundo, sin la cookie. El visitante supera la comprobación, recibe una página cacheada que sigue diciendo «verifying» y vuelve a empezar. Ese es el bucle, y por separado ninguno de los dos productos se comporta mal.
Confírmalo con un comando
Pide tu portada y mira las cabeceras: curl -sI https://example.com/ — en un WordPress normal el documento HTML no debería salir de una caché CDN.
Dos cosas juntas confirman el conflicto. Primero, cf-cache-status: HIT junto con una cabecera Age: en el documento HTML: Cloudflare está sirviendo tu página desde su caché. Segundo, ninguna cabecera Set-Cookie en esa respuesta, porque la copia cacheada no tiene ninguna que dar. Si además ves cf-edge-cache: cache,platform=wordpress, es el plugin de Cloudflare para WordPress el que marca tu HTML como cacheable.
Para la otra mitad, mira el código fuente de la página y busca imunify-bot-check. Si ese enlace se está inyectando en tus páginas, WebShield está verificando visitantes activamente.
Dónde está el ajuste ahora (las Page Rules están retiradas)
Todos los artículos antiguos te dicen que edites una Page Rule. Cloudflare las ha retirado en favor de productos específicos, así que los ajustes se han movido: la caché vive ahora en Caching → Cache Rules.
Abre Caching → Cache Rules y entra en la regla que hace tu HTML «Eligible for cache». Baja hasta su sección «Then…». En Edge TTL, si está marcada «Ignore cache-control header and use this TTL», ese es el nombre actual de la antigua Edge Cache TTL, y es lo que elimina la cookie. Marca en su lugar «Use cache-control header if present, bypass cache if not» y guarda.
Después añade una segunda regla, ordenada por encima, que mantenga la verificación fuera de la caché: If URI Path contains /imunify-bot-check → Cache eligibility: Bypass cache. Conviene extender el mismo bypass a /wp-login.php y /wp-admin, que tampoco deberían servirse nunca desde una caché compartida.
Después purga, o creerás que no ha funcionado. Cambiar la regla evita que la caché se vuelva a llenar, pero una copia guardada antes del cambio se sigue sirviendo hasta que expire su TTL antigua: con dos horas de TTL, eso son hasta dos horas más del mismo bucle. Ve a Caching → Configuration → Purge Everything. Luego vuelve a mirar las cabeceras: tu HTML ya no debería volver con cf-cache-status: HIT y una cabecera Age.
Si usas APO o el plugin de Cloudflare para WordPress
Automatic Platform Optimization cachea tu HTML en el edge a propósito, y sí sabe saltarse la caché cuando ve las cookies de inicio de sesión propias de WordPress. La cookie de Imunify360 no es una de ellas, así que no activa ese bypass.
Puedes añadir tus propias cookies de bypass, pero solo en los planes Business y Enterprise: en Free y Pro esa opción no existe. Si estás en Pro y el bucle sobrevive a los cambios anteriores, desactivar la caché de HTML (apagar APO, o quitar la regla que hace el HTML cacheable) es la salida fiable. Imágenes, CSS y JS siguen cacheados, que es donde está la mayor parte del beneficio.
El lado del origen y qué decirle a tu hosting
Todo lo anterior es del lado de Cloudflare, y normalmente es la solución completa. WebShield se ejecuta en tu servidor, habitualmente instalado por tu proveedor, y en cPanel no suele haber ningún interruptor para él, así que conviene asegurarse de que la caché está realmente arreglada antes de abrir un ticket.
Esto importa más de lo que parece. En una tienda real con la que trabajamos, la monitorización llevaba días devolviendo errores HTTP 403 y parecía exactamente un bloqueo de firewall que solo el proveedor podía levantar. Tras el cambio de Edge TTL y la purga, todas las comprobaciones pasaron en la siguiente ejecución sin tocar nada en el servidor —incluida la página de checkout, que nunca había llegado a completarse—. Una verificación cacheada y un bloqueo real son indistinguibles desde fuera.
Si las comprobaciones siguen fallando una vez confirmado que la caché está limpia, entonces estás chocando con WebShield y tu proveedor tiene que actuar. Para monitorización en concreto, Relvato envía una cabecera secreta estable en cada petición —X-Relvato-Token, visible en los Ajustes de tu sitio—, de modo que tu proveedor puede permitir exactamente ese tráfico sin debilitar nada más. Una regla a nivel de CDN no sirve: Imunify bloquea en el origen, después de que Cloudflare ya haya dejado pasar la petición.
Consejos antiguos de Page Rules, traducidos al panel actual
| Los artículos antiguos dicen | Dónde está ahora | Qué poner |
|---|---|---|
| Page Rule → «Cache Everything» | Caching → Cache Rules → Cache eligibility | Eligible for cache |
| Page Rule → «Edge Cache TTL» | La misma regla → Edge TTL | NO «Ignore cache-control header and use this TTL» |
| «Quita la Edge Cache TTL» | La misma regla → Edge TTL | «Use cache-control header if present, bypass cache if not» |
| Saltarse la caché en la verificación | Una Cache Rule por encima | URI Path contains /imunify-bot-check → Bypass cache |
| Bypass con una cookie propia | Cache Rules / cookies de bypass de APO | Solo planes Business y Enterprise |
Preguntas
¿Es culpa de Imunify360 o de Cloudflare?
De ninguno por separado. Imunify360 usa una cookie para recordar que un visitante superó su comprobación, y Cloudflare —cuando se le pide cachear HTML con una TTL sobrescrita— cachea la página y descarta las cookies de la respuesta del origen. Cada uno hace lo documentado; juntos se bloquean.
¿Desactivar la caché de HTML hará lento mi sitio?
Mucho menos de lo que parece. Imágenes, CSS, JavaScript y fuentes son el grueso de lo que descarga un navegador y siguen cacheados en el edge igualmente. Pierdes el HTML cacheado en el edge, que una buena caché de páginas en el servidor (LiteSpeed Cache, WP Rocket) sustituye en gran medida.
¿Por qué solo afecta a algunos visitantes?
WebShield verifica lo que considera sospechoso, así que la mayoría de visitantes humanos con conexiones normales pasan sin ver nada. Las IP de centros de datos y los clientes automatizados —monitores, rastreadores, consumidores de API— se verifican mucho más a menudo, y por eso detectan el problema primero.
Purgué la caché de Cloudflare y volvió.
Purgar vacía la caché, pero no cambia la regla que vuelve a llenarla. En minutos la página de verificación está cacheada otra vez. Hay que cambiar el ajuste de Edge TTL o saltarse la ruta, no solo purgar.
¿Puedo arreglarlo desde cPanel?
Normalmente no. Imunify360 lo instala y configura tu proveedor a nivel de servidor, así que la mayoría de usuarios de cPanel no tienen controles de WebShield. Los cambios en Cloudflare son cosa tuya; cualquier cosa dentro de Imunify360 pasa por tu hosting.
¿Esto arreglará también que bloqueen mi monitor de uptime o mi rastreador?
Muy probablemente, y conviene comprobarlo antes de culpar a otra cosa. Los clientes automatizados se verifican mucho más a menudo que las personas, así que caen primero en el bucle y lo reportan como un bloqueo duro. En el caso anterior, una monitorización que llevaba días fallando con 403 pasó a verde en la siguiente ejecución tras arreglar la caché, sin tocar nada en el servidor. Arregla la caché, purga, vuelve a ejecutar, y solo entonces escribe a tu proveedor.
Mi monitorización sigue bloqueada tras arreglar la caché.
Entonces estás chocando con WebShield y no con el bucle de caché: el conflicto de caché y el bloqueo en el origen son dos problemas distintos. Pide a tu hosting que permita la cabecera identificativa del monitor a nivel de Imunify360; una regla de Cloudflare no puede saltarse un firewall que corre por detrás de Cloudflare.