Todas las guíasForense de rutas · Atribuir la ruta

Cloudflare dejó de servir desde caché: cómo demostrar qué solicitud llegó al origen

Un diagnóstico con dos solicitudes comparables permite localizar la regla, la clave o la cabecera que trasladó trabajo de inteligencia artificial al servidor de origen sin confundir correlación con causa.

Actualizado 2026-09-01 · 4 min de lectura
Escrita para
Responsable técnico de WordPress
Formato
Diferencial de ruta con dos solicitudes
Resultado
Mapa de evidencias entre el perímetro y el origen

El síntoma no identifica todavía la avería

Después de modificar una regla de caché, las páginas vistas pueden permanecer estables y, aun así, aumentar las llamadas de inteligencia artificial (IA) iniciadas en WordPress. Esa combinación no demuestra por sí sola que Cloudflare sea la causa: también puede haber cambiado la URL, una cookie, el método HTTP, una cabecera de autorización o el código que decide cuándo llamar al proveedor.

Antes de tocar otra regla, fije una ventana de quince minutos y elija una única URL reproducible. Guarde la tasa de aciertos de caché, las solicitudes que ve el origen, los intentos registrados por WordPress, los códigos de respuesta y el consumo comunicado por el proveedor. Si cada sistema usa otra zona horaria o intervalo, normalícelo primero; de lo contrario, la discrepancia será artificial.

Construya una pareja de solicitudes que solo difiera en la caché

Realice una solicitud que produzca un acierto conocido y otra que reproduzca el fallo. Mantenga iguales el host, la ruta, la cadena de consulta, el dispositivo de prueba y la sesión siempre que sea posible. Añada un identificador de correlación inocuo, por ejemplo en una cabecera admitida por su aplicación, para localizar el mismo recorrido en el registro del perímetro, el servidor y WordPress.

Capture las cabeceras de respuesta completas, en especial CF-Cache-Status, Age, Cache-Control y cualquier señal de la regla aplicada. Un HIT y un BYPASS no son solo dos etiquetas: deben relacionarse con la clave de caché calculada, la condición que excluyó la segunda solicitud y la presencia —o ausencia— del identificador en el origen. No incluya cookies ni credenciales sin redactarlas.

Rellene el mapa de evidencias

El mapa siguiente convierte una discusión entre paneles en una cadena comprobable. Complete una columna por solicitud; no mezcle promedios. La fila decisiva es la primera en la que las dos columnas divergen y cuya consecuencia aparece en las capas posteriores.

Si la solicitud B muestra BYPASS, aparece en el acceso del origen y genera un identificador del proveedor que no existe para A, ya hay una explicación de extremo a extremo. Si B llega al origen pero no inicia IA, el gasto está en otra ruta. Si el proveedor registra trabajo sin correlación con WordPress, investigue una llamada directa o un segundo componente antes de culpar a la caché.

Punto de observaciónSolicitud A: controlSolicitud B: incidentePrueba que debe conservarse
EntradaURL y parámetrosURL y parámetrosMarca UTC e identificador de correlación
CloudflareCF-Cache-Status y AgeCF-Cache-Status y AgeRegla coincidente y clave de caché
OrigenNo aparece o apareceNo aparece o apareceLínea de acceso con el mismo identificador
WordPressIntento de IA: sí/noIntento de IA: sí/noHook o endpoint que lo inició
ProveedorID y tokensID y tokensRegistro de uso en la misma ventana

Cambie la condición responsable, no todo el sistema

Una vez identificada la primera divergencia, formule el cambio más estrecho posible. Puede ser retirar una cookie irrelevante de la clave, corregir una expresión de omisión o restaurar una directiva Cache-Control, pero no haga las tres cosas a la vez. Exporte o capture la regla anterior, defina quién puede revertirla y repita exactamente la pareja de solicitudes después del cambio.

No intente almacenar en caché una respuesta personalizada o sensible solo para recuperar el porcentaje anterior. La decisión debe respetar autenticación, privacidad y frescura del contenido. El objetivo no es maximizar HIT, sino evitar que una variación accidental envíe al origen trabajo de pago que antes no era necesario, sin compartir respuestas entre visitantes.

Cierre con una prueba que otra persona pueda repetir

Considere resuelto el incidente cuando la solicitud de control conserve su comportamiento, la solicitud afectada siga la ruta prevista y los tres contadores —origen, WordPress y proveedor— vuelvan a una relación explicable durante otra ventana de quince minutos. Anote también los resultados negativos: una regla descartada evita que el siguiente turno repita la misma conjetura.

Guarde el mapa con fecha, zona, versión de la regla y responsable. La guía de implantación del producto explica cómo pasar de observación a protección después de verificar la ruta; úsela como siguiente paso, no como sustituto de esta prueba. Un porcentaje agregado puede avisar del problema, pero solo la pareja de solicitudes demuestra dónde empezó.

Use la Mapa de evidencias entre el perímetro y el origen de «Cloudflare dejó de servir desde caché: cómo demostrar qué solicitud llegó al origen» en una primera instalación real. Descargue AI Cost Circuit Breaker gratis, empiece en Monitoring y active el bloqueo solo después de verificar señales y reversión.

Fuentes primarias consultadas

Siguiente guíaCerrar la pestaña no siempre detiene el coste de una respuesta en streaming