El rate limiting tradicional cuenta cuántas peticiones manda cada IP y bloquea la que se pasa. Funciona de maravilla contra un atacante individual insistente — y es completamente inútil contra un ataque de denegación de servicio real, porque una botnet usa cientos o miles de IPs distintas a la vez: cada una manda solo un puñado de peticiones y empieza su propio contador limpio. DDoS Resilience está pensado exactamente para ese escenario.
Por qué contar por IP no basta
Si el umbral de tu rate limiting es «bloquear tras 100 peticiones por minuto», una botnet de 1.000 IPs mandando 50 peticiones cada una nunca activa el límite en ninguna IP individual — y aun así son 50.000 peticiones por minuto reales cayendo sobre tu servidor. El problema no está en el número mal calibrado: está en medir la unidad equivocada.
Cómo funciona DDoS Resilience
Cuenta el tráfico global del sitio, no IP por IP
En vez de un contador por dirección, DDoS Resilience suma todas las peticiones de todo el sitio, de todas las IPs juntas, en ventanas de 10 segundos. Cuando ese total supera el umbral que configures (peticiones por minuto, a nivel de sitio completo), se activa el «modo flood» — y sigue activo unos minutos más aunque el tráfico baje un momento, para no encenderse y apagarse constantemente si el ataque fluctúa cerca del límite.
Un desafío que un bot nunca resuelve, y un humano nunca nota
Con el modo flood activo, cualquier visitante nuevo recibe una página ligera en vez de tu WordPress completo: un mensaje breve de «comprobando tu navegador» con un pequeño script que suma dos números al azar y envía la respuesta solo, en menos de un segundo. Un navegador real lo resuelve sin que el visitante haga nada ni se entere. Un bot de flood típico —un script que solo manda peticiones HTTP en bruto, sin motor de JavaScript— nunca ejecuta ese script, nunca manda la respuesta, y se queda fuera para siempre.
Firmado y con caducidad — no se puede falsificar ni reutilizar
La respuesta va firmada con HMAC usando el propio secreto interno de WordPress, y caduca en 60 segundos. Eso descarta que alguien pueda pre-calcular una respuesta válida o reenviar una guardada de antes. Al acertar, el visitante recibe una cookie —también firmada— que lo deja pasar sin más desafíos durante el tiempo que configures (15 minutos por defecto).
Quién nunca ve el desafío
Antes de mostrarlo a nadie, quedan exentos: administradores que ya tienen sesión iniciada, IPs en tu lista blanca, crawlers verificados de verdad (Google, GPTBot… comprobado por DNS inversa, no basta con que el User-Agent lo diga), y las rutas internas de WordPress —login, cron, admin-ajax, REST API— cuyo bloqueo accidental rompería la gestión de tu propio sitio. Solo se desafían peticiones de navegación (GET); los formularios y llamadas a APIs pasan sin tocar, para no romper pagos ni integraciones justo en medio de un ataque.
Qué pasa en tu servidor durante el ataque
La parte importante: este desafío se sirve antes de que WordPress llegue a cargar. Un bot atrapado en el bucle del desafío nunca hace que tu base de datos ni tu PHP trabajen de verdad — recibe una página estática de unos pocos kilobytes y un 503, no una ejecución completa de WordPress. Eso es lo que permite que tu sitio siga respondiendo con normalidad para visitantes reales aunque el volumen total de peticiones sea altísimo.
Preguntas frecuentes
¿Esto bloquea a Google o a mis visitantes reales?
No. Los crawlers verificados de verdad quedan exentos, y cualquier visitante real con JavaScript activado (la inmensa mayoría) resuelve el desafío solo, en menos de un segundo, sin ver ni un CAPTCHA ni tener que hacer nada.
¿Tengo que hacer algo cuando empieza un ataque?
No — se activa y se desactiva solo, según el tráfico global del sitio en tiempo real. Puedes ajustar el umbral, cuánto dura verificado un visitante, y el margen de enfriamiento tras el pico, desde el panel.
¿Sustituye a un CDN como Cloudflare?
No del todo, y es importante saberlo: DDoS Resilience protege la capa de aplicación (nivel 7) — el tráfico HTTP que le llega a WordPress. No sustituye a una red perimetral pensada para absorber ataques a nivel de red (capa 3/4) antes de que lleguen siquiera a tu servidor. Es una capa adicional, no la única que deberías tener si el riesgo de DDoS es alto para tu negocio.