Un cliente te escribe porque tu tienda "no le deja entrar". Vio una página de Cloudflare con un código de cuatro cifras, se rindió y compró en otro sitio. En los logs de tu servidor no hay nada, porque la petición no pasó de Cloudflare. Ocurre en tiendas WooCommerce, en webs WordPress pensadas para captar contactos, en frontends headless con Astro o Next.js y en cualquier aplicación propia que pase por el proxy de Cloudflare. Casi siempre la causa es una regla de tu propia zona, y Cloudflare deja anotado cuál fue.
Esta guía sigue el orden que funciona: consigue el Ray ID, búscalo, mira qué función actuó y después acota esa función para que deje de atrapar a compradores y a las notificaciones de pago. Todo el comportamiento que se describe aquí sale de la documentación para desarrolladores de Cloudflare, tal como estaba en octubre de 2026.
Qué significa el error 1015, 1020 o 1009 de Cloudflare
El código te dice dónde mirar. Una publicación en r/CloudFlare del 21 de octubre de 2026 resumió los códigos, y cada uno coincide con las páginas de resolución de problemas de Cloudflare:
- 1015 (HTTP 429): coincidió una regla de limitación de tasa. Cloudflare recomienda revisar los umbrales y, si una regla cuenta en un periodo muy corto, como un segundo, probar con 10 segundos.
- 1020 (HTTP 403): una regla de seguridad con acción Block y sin respuesta personalizada. La página del 1020 pone como ejemplos la validación de esquemas de API Shield y la validación de JWT, y aclara que las reglas personalizadas y las reglas gestionadas del WAF ya no devuelven el 1020. Muestran en su lugar la página de bloqueo del WAF.
- 1009 (HTTP 403): un veto por país o región configurado en IP Access rules. Ahí, el bloqueo por país es solo para Enterprise; en los demás planes se hace con una regla personalizada, y esa muestra la página de bloqueo del WAF.
- 1010 (HTTP 403): Browser Integrity Check rechazó la firma del navegador.
- “Just a moment…” o una página de desafío: un Managed Challenge procedente de una regla personalizada, de una regla de limitación de tasa, de Bot Fight Mode o de Under Attack Mode.
El detalle del 1020 ahorra horas. Si estás revisando reglas personalizadas en busca de la que devolvió el 1020, estás mirando en la lista equivocada.
Dónde encontrar el Ray ID de Cloudflare
Pide al cliente una captura de la página de error completa. Incluye el código, el Ray ID y una marca de tiempo en UTC. El autor de ese mismo hilo lo añadió en una respuesta:
el código es lo fácil, lo que la gente pasa por alto es el ray id en la misma pantalla. lo pegas en security events y te dice cuál de tus propias reglas saltó.
(u/Hot_Bee_5451, r/CloudFlare, 22 de octubre de 2026, traducción propia)
Cada petición que pasa por Cloudflare lleva un Ray ID, que llega a tu origen en la cabecera cf-ray. Cloudflare advierte que no se garantiza que los Ray ID sean únicos, así que compara también la hora y la IP. Si el cliente no puede mandarte una captura, pídele su dirección IP pública, la hora aproximada y el país. Cuando lo que falla es un desafío hay otra vía, que alguien propuso en otro hilo:
Bueno, puedes darle al administrador de la web el RayID que se genera cuando se ejecuta esa prueba, y él puede consultar el motivo exacto por el que no la pasaste.
(u/Logvin, r/CloudFlare, 21 de octubre de 2026, traducción propia)
Cómo buscar un Ray ID en Security Events de Cloudflare
En el panel, abre Security > Analytics y la pestaña Events. Añade un filtro por Ray ID o por la IP del cliente y ajusta el rango de fechas para que cubra la queja. Antes, pasa la hora UTC de la página de error a tu zona horaria; la página del 1020 de Cloudflare lo menciona de forma expresa.
Aquí importan dos límites que recoge la documentación de Security Events. Los datos se guardan un máximo de 31 días. Además, la lista usa registros muestreados, de modo que en una zona con mucho tráfico una petición concreta puede no aparecer. Si la búsqueda por Ray ID no devuelve nada, reduce la ventana a unos pocos minutos y filtra por IP: cuanto más corta la ventana, más eventos se ven. Una sola petición también puede generar varios eventos si actuaron varias funciones sobre ella.
Cómo saber qué regla de Cloudflare bloqueó al visitante
Despliega el evento. El campo Service indica la función y, en el caso de las reglas, también ves su nombre o su ID. Lo que suele significar cada una:
- Reglas personalizadas: tu propia expresión. Los culpables habituales son los bloqueos por país, los bloqueos por ASN dirigidos a proveedores de alojamiento (que también atrapan a quien usa VPN) y las reglas de ruta demasiado amplias sobre
/wp-login.phpo/checkout. - Reglas gestionadas: una firma de Cloudflare o de OWASP coincidió con algo de la petición. Las búsquedas largas, los campos de formulario con fragmentos de código y algunos envíos de maquetadores visuales las disparan.
- Reglas de limitación de tasa: el caso del 1015. Los compradores que salen por la misma IP de una oficina o de un operador móvil comparten contador cuando la regla cuenta por IP.
- Bot Fight Mode o Super Bot Fight Mode: los productos contra bots. La documentación de bots de Cloudflare dice que ambos pueden desafiar el tráfico de APIs o de aplicaciones móviles.
- Security Level o Under Attack Mode: la pantalla intermedia que afecta a toda la zona.
Una regla eliminada aparece como “Rule unavailable”. Consulta el registro de auditoría para ver quién la borró o la modificó.
Cómo crear una regla Skip en Cloudflare sin abrir todo el sitio
La solución es una regla personalizada con la acción Skip, colocada por encima de la regla que bloqueó y que coincida solo con el tráfico de confianza. Las opciones de Skip de Cloudflare permiten omitir el resto de reglas personalizadas, todas las reglas de limitación de tasa, todas las reglas gestionadas y todas las reglas de Super Bot Fight Mode. A través de la API también puedes omitir Browser Integrity Check, Security Level, User Agent Blocking, Zone Lockdown y Hotlink Protection. Las reglas personalizadas se evalúan en orden, así que la posición importa.
Mantén la expresión estrecha. En la extensión de Stripe para WooCommerce, que usa únicamente /?wc-api=wc_stripe como endpoint de webhooks:
(http.request.uri.query contains "wc-api=wc_stripe" and ip.src in $stripe_webhooks)Aquí $stripe_webhooks es una lista de IP que creas a partir de las direcciones IP de webhooks publicadas por Stripe. Para una integración que llama a la API REST de WooCommerce desde un servidor fijo:
(starts_with(http.request.uri.path, "/wp-json/wc/") and ip.src in $erp_servers)Cuando un falso positivo ha afectado a compradores reales, a menudo es mejor corregir la regla original que añadir una excepción: alarga el periodo de la limitación de tasa, restringe el bloqueo por país a /wp-login.php o cambia un Block por un Managed Challenge. Deja activado Log matching requests en la regla Skip para comprobar que funciona.
Por qué Cloudflare bloquea los webhooks de Stripe y la API REST de WooCommerce
Las llamadas entre servidores no tienen navegador, así que no pueden resolver un desafío de JavaScript. Cualquier función que desafía en vez de bloquear las rompe igualmente. El dueño de una tienda lo describió tal cual en r/CloudFlare:
Cuando activo Under Attack Mode, el tráfico de Singapur desaparece de GA4. Pero Under Attack Mode hace que mi web vaya lenta, y mis llamadas a la API entre servidores (API REST de WooCommerce) reciben el desafío “Just a moment…” de Cloudflare, así que fallan.
(u/lastoneinbatumi, r/CloudFlare, 19 de octubre de 2026, traducción propia)
El impacto depende del proveedor. Stripe reintenta un webhook fallido con espera exponencial durante un máximo de tres días en modo live, así que los pedidos atascados en “pendiente de pago” suelen recuperarse cuando corriges la regla. Shopify reintenta hasta ocho veces en cuatro horas y después elimina la suscripción, algo que te afecta si tu aplicación o tu backend headless recibe webhooks de Shopify detrás de tu zona de Cloudflare. Después de cualquier cambio de seguridad, revisa en el panel de cada proveedor si hay entregas fallidas.
Under Attack Mode está pensado como último recurso durante un ataque. La página de Security Level de Cloudflare indica que uses una regla de configuración para activarlo o desactivarlo en tu API o en cualquier otra parte del dominio. Mantenlo desactivado en /wp-json/, en las rutas de webhooks y en el host de tu API.
Ese mismo hilo dejó una segunda lección. Si el tráfico bloqueado sigue apareciendo en la analítica, pregúntate si de verdad pasa por Cloudflare:
¿Tienes el hosting configurado para aceptar solo tráfico desde y hacia Cloudflare? Si no, se puede llegar directamente por la ip
(u/Wilbo007, r/CloudFlare, 19 de octubre de 2026, traducción propia)
La documentación sobre direcciones IP de Cloudflare recomienda bloquear en el origen el tráfico que no venga de Cloudflare ni de tus socios de confianza. Permite también en ese cortafuegos del origen las direcciones de tus proveedores de pago.
¿Se puede saltar Bot Fight Mode con una regla del WAF?
No. La página de Bot Fight Mode dice que no se puede omitir ni saltar con reglas personalizadas del WAF ni con Page Rules, porque no funciona sobre el Ruleset Engine, así que Skip, Bypass y Allow no tienen efecto. La página de opciones de Skip repite que solo se puede omitir Super Bot Fight Mode. Hay una excepción documentada: Bot Fight Mode no se activa si antes coincide con la petición una regla de IP Access rules.
Así que en el plan Free, si Bot Fight Mode desafía a tu proveedor de pagos, a tu ERP o a tu monitor de disponibilidad, tienes tres opciones: una regla de permiso en IP Access rules para las direcciones de ese proveedor, desactivar Bot Fight Mode o pasar a un plan de pago donde Super Bot Fight Mode acepta reglas Skip. Super Bot Fight Mode tiene además el ajuste Optimize for WordPress, que deja pasar las peticiones loopback de WordPress y arregla los errores de Site Health sin necesidad de una regla personalizada.
Tabla para diagnosticar un bloqueo de Cloudflare
| Qué ve el cliente o el registro | Regla probable | Solución |
|---|---|---|
| Error 1015, HTTP 429 | Regla de limitación de tasa | Periodo de recuento más largo, umbral más alto u omitir la limitación de tasa para IP de confianza |
| Página de bloqueo del WAF, HTTP 403, sin código 1xxx | Regla personalizada o regla gestionada del WAF | Localiza la regla por Ray ID; acota la expresión o añade una regla Skip por encima |
| Error 1020, HTTP 403 | Otro Block sin respuesta personalizada (por ejemplo, API Shield) | Busca en Security Events, no en las reglas personalizadas |
| Error 1009 | Bloqueo por país en IP Access rules | Permite la IP del visitante o lleva el geobloqueo a una regla personalizada acotada |
| Error 1010 | Browser Integrity Check | Omítelo para la ruta afectada mediante la API, o desactívalo |
| Bucle de desafíos en todas las páginas | Under Attack Mode o Security Level | Desactívalo, o limítalo con una regla de configuración |
| Webhook o API REST que falla sin intervención humana | Bot Fight Mode, Under Attack Mode o una regla de desafío | Permiso en IP Access rules o regla Skip de Super Bot Fight Mode; mantén UAM fuera de las rutas de la API |
| Nada en Security Events | Muestreo, zona horaria equivocada o la petición nunca llegó a Cloudflare | Ventana de tiempo más corta, filtro por IP; revisa el DNS y el cortafuegos del origen |
Cómo vigilar los bloqueos de Cloudflare después de corregirlos
No te quedes en un solo cliente. En Security Events, filtra por Action igual a Block o Managed Challenge y agrupa por ruta. Las peticiones a /checkout, /cart, /my-account, /wp-json/ o al endpoint de tu formulario de contacto son las que te cuestan dinero. La URL filtrada se puede compartir, así que un compañero verá lo mismo que tú. Se pueden exportar hasta 500 eventos muestreados en JSON.
Después revisa el otro lado: entregas fallidas en Stripe, PayPal o Shopify, pedidos de WooCommerce atascados en pendiente y envíos diarios del formulario de contacto. Una caída al día siguiente de un cambio de seguridad apunta directamente a la regla que añadiste. Nuestro servicio de Cloudflare en el borde incluye auditorías de reglas como esta, y el mantenimiento WooCommerce incorpora esta vigilancia para tiendas WooCommerce.
Para seguir leyendo: si los ajustes de bots de IA de Cloudflare también frenan a los rastreadores de los buscadores lo explicamos en ¿Cloudflare bloquea a Googlebot?. Cuánto tráfico de un sitio pequeño es automatizado, y por qué eso tienta a poner reglas de bots demasiado duras, lo medimos en 72% de nuestro tráfico no es un navegador. Para llevar lógica al borde, mira Cloudflare Workers y WooCommerce.
