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 reproducir un bloqueo de Cloudflare con curl
La captura cuenta lo que pasó una vez. Repetir la petición te dice si sigue pasando después de tu corrección. Desde una terminal, pide la página que el cliente no pudo abrir y lee las cabeceras:
curl -sI https://example.com/checkout/
curl -sI "https://example.com/?wc-api=wc_stripe"Hay tres cabeceras que importan. server: cloudflare confirma que la respuesta salió del borde. cf-ray te da un Ray ID nuevo para buscarlo en Security Events. Y una cabecera cf-mitigated: challenge significa que la respuesta es una página de desafío: la guía de detección de desafíos de Cloudflare explica que la cabecera aparece en todos los tipos de página de desafío, que challenge es su único valor y que el cuerpo es siempre text/html, sea cual sea el recurso pedido.
Ese último detalle explica un fallo habitual en los sitios headless. Un frontal hecho con Astro o Next.js que llama a su propia API con fetch espera JSON, recibe un desafío en HTML y falla con un error de análisis que parece un fallo del código. Comprueba response.headers.get("cf-mitigated") antes de interpretar la respuesta, regístralo, y en una sola publicación sabrás si Cloudflare es la causa. Tu IP y tu navegador pueden no activar la misma regla que los del cliente, así que una prueba limpia desde tu mesa demuestra menos que una búsqueda limpia en Security Events.
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.
Cómo excluir una sola regla gestionada del WAF
Cuando el evento muestra una regla gestionada, no omitas todas las reglas gestionadas para el proceso de pago. Las excepciones de reglas gestionadas de Cloudflare pueden omitir todas las reglas gestionadas restantes, uno o varios conjuntos de reglas gestionadas, o una o varias reglas concretas, y cada excepción tiene su propia expresión. Copia el ID de la regla desde el evento, crea una excepción solo para esa regla y limítala a la ruta y al método que la activaron, por ejemplo las peticiones POST a la dirección del formulario que llevaba el contenido sospechoso.
El ámbito también cuenta. Una excepción definida a nivel de zona no detiene una coincidencia de un conjunto de reglas gestionadas desplegado a nivel de cuenta, porque los conjuntos de cuenta se ejecutan primero en cada fase. Si gestionas varias tiendas bajo la misma cuenta de Cloudflare, mira dónde están desplegadas las reglas gestionadas antes de escribir la excepción.
Cómo probar una regla de Cloudflare sin bloquear a tus clientes
La guía de reglas personalizadas de Cloudflare ofrece la acción Log para validar una regla antes de aplicarla, pero solo en los planes Enterprise. En el resto de planes propone empezar con Managed Challenge, revisar en Security Events las peticiones que coinciden y pasar a Block cuando esas coincidencias tengan sentido. Un cliente real puede superar un Managed Challenge; ante un Block no puede hacer nada.
Quien supera un desafío recibe una cookie cf_clearance. El ajuste Challenge Passage controla cuánto tiempo sigue siendo válida: 30 minutos por defecto, y Cloudflare recomienda entre 15 y 45 minutos. Esto tiene dos consecuencias para las quejas que te llegan. Un cliente que bloquea las cookies recibe un desafío nuevo en cada página, y lo cuenta como “la web me comprueba todo el rato”. Además, Challenge Passage no se aplica a las reglas de limitación de tasa, así que superar un desafío no anula un 1015.
Cómo configurar la limitación de tasa de Cloudflare para no frenar a compradores
La página de reglas de limitación de tasa indica qué puede ajustar cada plan, y esas cifras deciden cuánto puedes afinar la corrección:
| Plan | Campos en la expresión de la regla | Periodo de recuento | Tiempo de mitigación | Recuento por |
|---|---|---|---|---|
| Free | Path, Verified Bot | 10 s | 10 s | IP |
| Pro | añade Host, URI, Full URI, Query | hasta 1 min | hasta 1 h | IP |
| Business | añade Method, Source IP, User Agent | hasta 10 min | hasta 1 día | IP, IP con soporte de NAT |
| Enterprise con Advanced Rate Limiting | campos generales de la petición y de las cabeceras | hasta 65.535 s | hasta 1 día | añade cabeceras, cookies, ASN, país y más |
Contar por IP es la razón por la que una oficina o un operador móvil acaba activando una regla pensada para un solo bot. Tres cambios sacados de las buenas prácticas de limitación de tasa de Cloudflare lo reducen:
- Excluye a los socios conocidos. El ejemplo de Cloudflare permite 10 peticiones por minuto y por IP a
/status, salvo que la dirección esté en una lista de IP llamadapartner_ips, connot ip.src in $partner_ipsen la expresión. La IP de origen solo está disponible en las expresiones de limitación de tasa a partir de Business; en Free y Pro, pon la lista de socios en una regla personalizada Skip que omita todas las reglas de limitación de tasa, ya que las reglas personalizadas sí pueden filtrar por IP de origen. - Cuenta solo los fallos. A partir de Business tienes una expresión de recuento propia, de modo que una regla de inicio de sesión puede contar solo las peticiones
POSTque devolvieron 401 o 403. Un cliente que entra a la primera nunca suma al contador. - Ajusta la ruta exacta. La misma página advierte que una regla para
/validate/otpno coincide con/api/otp/validate. Comprueba la ruta real en la analítica antes de escribir la regla, y deja/wp-json/y las peticiones AJAX del pago fuera de las reglas pensadas para las páginas de acceso.
En Enterprise, la pestaña Request rate analysis de Security Analytics muestra la distribución de la tasa de peticiones de los 50 clientes más activos y puede rellenar por adelantado una regla de limitación de tasa a partir de la tasa elegida. Cloudflare recomienda desplegar esa regla primero con la acción Log.
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.
Actualización del . Que dejes pasar por Cloudflare los webhooks del proveedor de pagos no significa que el endpoint deba fiarse de cualquiera que lo llame. El informe semanal de vulnerabilidades de Wordfence del 12 al 18 de octubre de 2026 recoge plugins de pago para WooCommerce que aceptaban llamadas falsificadas: Cardinity 3.2.6 a 3.4.1 comprobaba la firma HMAC con un secreto de proyecto vacío, y en Rede Itaú hasta 5.5.2 el webhook 3DS se saltaba la verificación con Rede cuando el identificador de transacción llegaba vacío, de modo que cualquiera podía cambiar el estado de un pedido. iPOSpays hasta 1.4.6 tuvo esa misma semana una forma de saltarse el pago sin autenticación. Cloudflare no distingue un webhook falsificado de uno real, así que la comprobación va en la aplicación: configura el secreto del webhook en los ajustes de la pasarela, mantén el plugin actualizado y comprueba que los pedidos pagados tienen su transacción en el panel del proveedor.
¿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.
Cómo personalizar la página de bloqueo de Cloudflare para tus clientes
La página de bloqueo por defecto no le dice nada al visitante sobre tu tienda. En los planes de pago hay dos opciones. Custom Errors está disponible en Pro, Business y Enterprise, no en Free, y una Error Page del tipo WAF block sustituye la página que se muestra en los bloqueos del WAF en toda la zona. A partir de Pro, una regla personalizada con acción Block también puede devolver su propia respuesta, con un código de estado entre 400 y 499 y un cuerpo en HTML, JSON o texto plano.
Aprovecha esa página para pedir lo que necesitas: una captura con el Ray ID, la hora, y un correo o un teléfono que no dependa de la misma zona. En una ruta de API, devuelve JSON para que las integraciones registren un error legible en lugar de una página HTML. Los ejemplos de reglas de errores personalizados de Cloudflare incluyen uno para los errores 1020 que usa la expresión cf.response.1xxx_code eq 1020, así que el visitante que vea ese código puede recibir también tus datos de contacto.
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.
