Tienes el rate limiting activado, bloqueas IPs que hacen demasiadas peticiones, y aun así tu servidor se cae en cuanto llega un ataque de verdad. No es que el rate limiting no funcione — es que está resolviendo un problema distinto del que te está atacando.
Lo que el rate limiting por IP hace bien
Contar peticiones por IP y bloquear la que se pasa de un umbral funciona muy bien contra un atacante individual: alguien con un script haciendo fuerza bruta contra tu login, o un scraper agresivo desde una sola máquina. En ese escenario, cortar esa IP concreta resuelve el problema al instante.
Por qué falla contra un DDoS real
Un botnet no es una IP, son miles
Un ataque de denegación de servicio distribuido (DDoS) no manda todo el tráfico desde un único origen — lo reparte entre cientos o miles de máquinas distintas, cada una haciendo relativamente pocas peticiones. Si tu límite es «bloquear tras 50 peticiones por minuto desde la misma IP», un botnet bien repartido nunca llega a ese umbral en ninguna IP individual, aunque el total sumado esté tumbando tu servidor.
Cada IP nueva empieza su contador de cero
Aunque bloquees cada IP en cuanto se pasa, el atacante simplemente sigue sumando IPs nuevas. El rate limiting por IP está diseñado para frenar a un abusón, no para reconocer que el tráfico total del sitio se ha disparado por un ataque coordinado.
Qué hace distinto un modo pensado para esto
Contar el tráfico global, no por origen
En lugar de vigilar cada IP por separado, este enfoque mide cuántas peticiones está recibiendo el sitio en total en una ventana corta de tiempo. Si ese total supera lo que es normal para tu web, activa una respuesta — sin necesitar identificar antes cuál de las miles de IPs es «la culpable», porque no hay una sola culpable.
Un reto ligero en vez de tumbar el servidor
Cuando el volumen global se dispara, en vez de dejar que cada petición llegue a ejecutar WordPress entero (con su consulta a base de datos, carga de plugins, etc.), se sirve un pequeño desafío que un navegador normal resuelve solo en un instante, pero que corta a la mayoría del tráfico automatizado antes de que llegue a consumir recursos reales del servidor.
Lo que este tipo de protección no sustituye
Es importante ser honesto sobre los límites: esta capa está pensada para proteger las páginas normales del sitio frente a un pico de tráfico masivo, no para blindar formularios, pagos o la API por sí sola — esas rutas necesitan su propia protección específica, precisamente porque no conviene ponerles un desafío que podría interrumpir una compra real a mitad de proceso.
Preguntas frecuentes
¿El rate limiting por IP sirve entonces para algo?
Sí, sigue siendo útil contra ataques de fuerza bruta, scraping agresivo o abuso desde un origen concreto — solo no es la herramienta adecuada contra un ataque distribuido en miles de IPs.
¿Necesito las dos cosas activas a la vez?
Son complementarias: el rate limiting por IP cubre el abuso individual, y una capa de tráfico global cubre el escenario en el que ninguna IP concreta destaca pero el total del sitio sí.
¿Un ataque DDoS puede tumbar cualquier WordPress sin protección específica?
Sí — sin ninguna capa que mida el volumen total, WordPress procesa cada petición individualmente (base de datos incluida), y un volumen suficientemente alto agota los recursos del servidor aunque cada petición por sí sola parezca inofensiva.