Estudio de caso: Cloudflare 403 frente a una caída real
Actualizado: 21 de abril de 2026 · Por el equipo editorial de Comprobador de sitios web
Un equipo de soporte informó que el «sitio caído» tras recibir respuestas 403 en las comprobaciones de monitorización. Los usuarios finales seguían pudiendo cargar la página de inicio en los navegadores. Este caso explica cómo resolver esa contradicción.
Síntomas observados
- Las comprobaciones automatizadas devolvieron HTTP 403.
- Los usuarios en navegador vieron páginas de desafío ocasionales y luego éxito.
- Sin indicios de caídas del servidor de origen ni errores 5xx.
Secuencia de diagnóstico utilizada
- Ejecute la URL en Comprobador de sitios web y capture el texto de estado y las notas.
- Compruebe si la respuesta incluye patrones de protección contra bots (indicios de desafío Cloudflare).
- Pruebe desde el navegador y compare con el comportamiento de la comprobación del lado del servidor.
- Revise los umbrales de política WAF/límite de velocidad en la configuración del edge.
Causa raíz
El sitio estaba en línea, pero la configuración WAF trató el tráfico no navegador como sospechoso. Las comprobaciones sintéticas se bloquearon en el edge antes de alcanzar el contenido completo de la página.
Corrección y validación
- Se ajustaron las reglas de bot/WAF para el comportamiento de monitorización esperado.
- Se redujeron los ajustes agresivos de límite de velocidad para los endpoints de diagnóstico.
- Nueva prueba: el comprobador pasó de estado bloqueado/limitado a respuestas en línea estables.
Conclusiones
- 403 no siempre equivale a caída.
- Distintos tipos de solicitud pueden recibir resultados diferentes.
- Cruce el estado del comprobador con los registros de seguridad del edge antes de declarar una interrupción.
Lecturas relacionadas: Guía 500/502/503 y Metodología.