Cabeceras de Cloudflare: qué significan cf-cache-status, cf-ray y compañía

Has puesto tu sitio WordPress detrás de Cloudflare y quieres saber si el CDN está haciendo algo de verdad. De repente, en las respuestas de tu servidor aparecen líneas como cf-cache-status: DYNAMIC o cf-ray: 8f2a1c3d4e5f6a7b-FRA. Estas cabeceras son algo así como el prospecto de Cloudflare: te dicen si un archivo salió de la caché, qué centro de datos respondió y si alguna regla de seguridad se interpuso. Aquí descubrirás qué significa cada valor y qué conclusiones puedes sacar para tu sitio web.

¿Qué son las cabeceras de Cloudflare y cómo puedes verlas?

Cloudflare se sitúa como proxy entre tus visitantes y tu servidor. Cada solicitud pasa por la red de Cloudflare y, por el camino, se le añaden cabeceras. Algunas las ve el navegador de tus visitantes, otras solo llegan a tu servidor. Cómo funciona una red así en general te lo explicamos en nuestro artículo ¿Qué es un CDN?.

La forma más rápida de ver las cabeceras es abrir las herramientas para desarrolladores de tu navegador. Abre la pestaña «Red», recarga la página y haz clic en la primera fila. En la terminal es todavía más rápido:

curl -sI https://example.com/

La respuesta tendrá más o menos este aspecto:

HTTP/2 200
content-type: text/html; charset=UTF-8
cache-control: max-age=0
cf-cache-status: DYNAMIC
server: cloudflare
cf-ray: 8f2a1c3d4e5f6a7b-FRA

Si no aparece ninguna línea que empiece por cf-, la solicitud no pasa por Cloudflare. Lo habitual es que el registro DNS esté configurado como «DNS only» (nube gris) en lugar de «Proxied» (nube naranja).

¿Qué significa cf-cache-status? Todos los valores de un vistazo

La cabecera cf-cache-status es la más importante de todas. Te dice cómo ha tratado Cloudflare exactamente esta respuesta. La documentación oficial recoge nueve valores:

• HIT: El archivo estaba en la caché y lo sirvió directamente Cloudflare. Tu servidor ni se enteró. Es el valor que quieres ver.
• MISS: El archivo se puede guardar en caché, pero todavía no estaba en este centro de datos. Cloudflare lo ha pedido a tu servidor. En la siguiente solicitud debería aparecer HIT.
• EXPIRED: El archivo estaba en la caché, pero había caducado. Cloudflare ha pedido una copia nueva a tu servidor.
• REVALIDATED: La copia en caché había caducado. Cloudflare preguntó a tu servidor si había cambiado algo y la respuesta fue que no. Así que el archivo salió de la caché, pero el visitante tuvo que esperar a esa consulta.
• UPDATING: La copia había caducado y aun así se entregó al momento, mientras Cloudflare la renueva en segundo plano. Esto ocurre cuando tu servidor envía stale-while-revalidate.
• STALE: Cloudflare entregó una copia caducada porque no pudo contactar con tu servidor. Es una señal de alarma que deberías tomarte en serio.
• BYPASS: En principio, el archivo era candidato para la caché, pero la respuesta de tu servidor lo impidió, por ejemplo por una cookie.
• DYNAMIC: Cloudflare ni siquiera miró en la caché, porque según las reglas vigentes este contenido no se guarda en caché.
• NONE/UNKNOWN: Cloudflare generó la respuesta por sí mismo, por ejemplo en una redirección a HTTPS, un bloqueo del firewall o un Worker.

Conviene saber que, desde el 26 de mayo de 2026, Cloudflare separa con más claridad dos de estos valores. Antes, algunas respuestas que no se podían guardar en caché recibían un MISS en cada solicitud. Desde el cambio siempre muestran BYPASS. MISS ya solo significa una cosa: se puede guardar en caché, pero ahora mismo no está ahí. Muchas guías antiguas que circulan por internet todavía describen el comportamiento anterior.

¿Por qué tu sitio WordPress muestra cf-cache-status: DYNAMIC?

Es la pregunta más frecuente sobre este tema, y la respuesta es tranquilizadora: en una página normal de WordPress, DYNAMIC es lo habitual. Con la configuración por defecto, Cloudflare no guarda en caché ni HTML ni JSON. Decide según la extensión del archivo, no según el contenido. Las imágenes, el CSS, el JavaScript, las fuentes y los PDF acaban en la caché. El HTML de tus páginas, no.

Hay una buena razón para ello. WordPress genera las páginas de forma dinámica, y Cloudflare no puede saber si en el HTML hay en ese momento un carrito de compra, una barra de administración o un saludo personal. Si guardara esas páginas en caché sin que nadie se lo pidiera, en el peor de los casos un visitante vería el carrito de otro.

En cambio, tus imágenes y scripts sí deberían dar HIT. Por eso, no compruebes solo la página de inicio, sino también un archivo CSS o una imagen.

Si quieres que Cloudflare también entregue el HTML, tienes dos opciones:

• Cache Rule: Creas en el panel una regla que marca el HTML como «Eligible for cache». A partir de ahí te toca a ti asegurarte de que los usuarios con sesión iniciada, el área de administración, el carrito y la página de pago queden excluidos.
• APO para WordPress: La Automatic Platform Optimization se encarga de estas excepciones por ti y vacía la caché en cuanto modificas una entrada. Más abajo te contamos los detalles.

Si también aparece DYNAMIC en imágenes o CSS, la causa suele ser una regla con «Bypass cache» o el Development Mode. Este desactiva la caché por completo durante tres horas y es muy fácil olvidarse de él.

cf-cache-status BYPASS o siempre MISS: ¿a qué se debe?

Con BYPASS, Cloudflare quería guardar la respuesta en caché, pero tu servidor no se lo permitió. La guía de resolución de problemas menciona sobre todo estas causas:

• La respuesta contiene una cabecera Set-Cookie. En WordPress es el clásico: una tienda, un plugin multilingüe o un plugin de seguimiento establece una cookie en cada solicitud y, de repente, ya no se guarda nada en caché.
• Tu servidor envía Cache-Control: no-store o private.
• La respuesta contiene Vary: *.
• El archivo supera el límite de tu plan (512 MB en Free, Pro y Business).

Si cada solicitud se queda en MISS, el archivo sí se puede guardar en caché, pero Cloudflare nunca lo vuelve a encontrar. Detrás suele haber parámetros cambiantes en la dirección, como utm_source o un ID de sesión, porque cada variante cuenta como un archivo distinto. Además, en sitios con pocas visitas, los archivos que casi nadie pide salen antes de la caché. Y cada centro de datos tiene su propia caché: si dos solicitudes llegan a ubicaciones distintas, verás MISS dos veces.

Una buena ayuda es la cabecera Age. Indica en segundos cuánto tiempo lleva la copia en la caché. Si pides un archivo dos veces seguidas y ves HIT con un Age que va subiendo, todo funciona.

¿Qué revela la cabecera cf-ray?

Cada solicitud que pasa por Cloudflare recibe un identificador propio, el Ray ID. Aparece en la cabecera cf-ray y tiene dos partes: una cadena de caracteres y un código de tres letras. El código indica el centro de datos que respondió. FRA corresponde a Fráncfort, AMS a Ámsterdam y CDG a París.

En el día a día, el Ray ID te ayuda en tres situaciones. Cuando Cloudflare muestra a un visitante una página de error, el Ray ID aparece al pie de la página y con él puedes encontrar exactamente esa solicitud en los logs o en los Security Events. En segundo lugar, el código te dice si tus visitantes llegan de verdad a una ubicación cercana. Y en tercer lugar, explica más de un MISS misterioso cuando dos solicitudes han llegado a centros de datos distintos.

Por cierto, Cloudflare también envía el mismo Ray ID a tu servidor. Si lo escribes allí en el log, puedes seguir una solicitud desde el navegador hasta PHP.

cf-apo-via y cf-edge-cache: ¿funciona APO para WordPress?

Si usas la Automatic Platform Optimization, aparecen dos cabeceras más. Según Cloudflare, una configuración que funciona se reconoce por tres líneas:

• cf-cache-status: HIT indica que el HTML salió de la caché.
• cf-apo-via: tcache indica que APO atendió la solicitud.
• cf-edge-cache: cache,platform=wordpress confirma que el plugin de Cloudflare está instalado y activo en WordPress.

Si falta cf-edge-cache, lo normal es que el plugin esté desactivado o no esté conectado a tu cuenta. Si cf-apo-via muestra un valor distinto de tcache, APO no ha entregado la página desde la caché, por ejemplo porque tienes la sesión iniciada. Por eso, haz siempre las pruebas en una ventana privada.

¿Qué significa cf-mitigated: challenge?

Esta cabecera solo aparece cuando Cloudflare entrega una página de verificación en lugar de tu página, es decir, el conocido aviso de que se está comprobando al visitante durante un momento. challenge es el único valor válido.

Para las personas suele ser solo un pequeño retraso. Para todo lo que accede a tu sitio web de forma automática, es un obstáculo real. La página de verificación siempre es HTML, aunque en realidad se haya pedido JSON. Si tu propio JavaScript llama a la REST API y de repente recibe una página de verificación, se produce un error que sin esta cabecera te costaría mucho entender. Lo mismo ocurre con los servicios de monitorización, las pasarelas de pago con webhooks y las herramientas de analítica. Si ves cf-mitigated: challenge en accesos que deberían pasar sin problemas, merece la pena echar un vistazo a los Security Events del panel. Ahí verás qué regla se ha activado.

¿Qué cabeceras de Cloudflare llegan a tu servidor?

No todas las cabeceras están pensadas para el navegador. Cloudflare añade algunas a la solicitud antes de que llegue a tu servidor. La lista completa es larga, pero para WordPress estas son las más importantes:

• CF-Connecting-IP: la dirección IP real del visitante. Sin esta cabecera, tu servidor solo ve direcciones de Cloudflare.
• X-Forwarded-For: la cadena de todos los servidores proxy por los que ha pasado la solicitud. Para conocer la dirección del visitante, Cloudflare recomienda leer mejor CF-Connecting-IP.
• X-Forwarded-Proto y CF-Visitor: indican si el visitante llegó por HTTP o por HTTPS.
• CF-IPCountry: el país del visitante como código de dos letras. XX significa desconocido y T1 corresponde a la red Tor.
• CDN-Loop: evita que una solicitud dé vueltas sin fin a través de Cloudflare.

La dirección IP real es algo más que un detalle. Los plugins de seguridad bloquean a los atacantes por su dirección IP, WordPress la guarda con los comentarios y tu proveedor de hosting la analiza en los logs. Si ahí solo llega la dirección de Cloudflare, tu plugin puede acabar dejando fuera a todos los visitantes de golpe. La mayoría de los proveedores de hosting y plugins de seguridad se pueden configurar para esto. Eso sí, confía en la cabecera solo si la solicitud procede realmente de una dirección de la red de Cloudflare. Si no, cualquiera puede escribir en la cabecera la dirección IP que quiera.

Aquí también entra en juego una fuente de errores muy conocida. Con el ajuste SSL «Flexible», Cloudflare se comunica con tu servidor sin cifrar. WordPress cree entonces que el visitante llegó por HTTP, redirige a HTTPS y se produce un bucle infinito. La solución limpia es instalar un certificado en el servidor y elegir el ajuste «Full (strict)».

¿Cómo controlas con Cache-Control lo que Cloudflare guarda en caché?

Cuánto tiempo conserva Cloudflare un archivo lo decide, ante todo, tu servidor. Para ello existen tres cabeceras, que Cloudflare evalúa en este orden:

1. Cloudflare-CDN-Cache-Control solo se aplica a Cloudflare y no se transmite al navegador.
2. CDN-Cache-Control se aplica a todos los CDN que haya por el camino.
3. Cache-Control se aplica a los navegadores y, si faltan las otras dos, también a Cloudflare.

Así puedes controlar el navegador y el CDN por separado. Un ejemplo: el navegador debe conservar un archivo solo una hora, y Cloudflare, un día entero.

Cache-Control: max-age=3600
Cloudflare-CDN-Cache-Control: max-age=86400

Si tu servidor no envía ninguna indicación, se aplican los valores por defecto. Las respuestas con estado 200 y 301 permanecen 120 minutos en la caché, las redirecciones con 302 y 303 solo 20 minutos y los errores 404 y 410, tres minutos. Esto último sorprende a mucha gente: si subes una imagen que faltaba, Cloudflare puede seguir entregando el error antiguo durante unos minutos.

¿Qué otras cabeceras añade Cloudflare?

Además de las líneas conocidas, puede que te llamen la atención algunas más:

• server: cloudflare sustituye el nombre de tu servidor web. Desde fuera ya nadie ve si detrás funciona Apache, nginx o LiteSpeed.
• report-to y nel forman parte de Network Error Logging. A través de ellas, el navegador informa a Cloudflare de los errores de conexión. La función se puede desactivar en el panel, algo interesante para algunos sitios web desde el punto de vista de la privacidad.
• alt-svc anuncia al navegador que el sitio web también está disponible por HTTP/3. Si tu servidor envía su propia cabecera alt-svc, Cloudflare la elimina.

Hay incluso cabeceras de tu servidor que nunca llegan al visitante. Entre ellas están Cache-Tag y las cabeceras X-Accel de nginx. Así que no te extrañe si las buscas en el navegador y no las encuentras.

¿Cómo compruebas las cabeceras de Cloudflare con InspectWP?

InspectWP lee las cabeceras de tu sitio web al crear un informe y, en la sección «Cabeceras», te muestra entre otras cf-cache-status y cf-ray. Así ves sin abrir la terminal si tu sitio web pasa por Cloudflare y cómo se entregó la página de inicio. A eso se suman los valores relacionados con la caché: la compresión, la versión de HTTP y las cabeceras de seguridad.

Resulta especialmente práctico si gestionas varios sitios web. Con los informes automáticos te das cuenta cuando una página deja de salir de la caché de un día para otro o cuando, tras una migración, Cloudflare ya no está delante del sitio. Si una página de verificación de Cloudflare bloquea el análisis, InspectWP te avisa. En nuestro artículo de ayuda Qué hacer cuando el crawl falla te explicamos cómo ajustar la protección contra bots para que funcione. Un informe gratuito te muestra en poco tiempo qué cabeceras envía tu sitio web ahora mismo.