Cómo limitar peticiones por IP en PrestaShop sin bloquear a Google

Lunes por la mañana. El domingo la tienda se cayó dos veces, en el registro de accesos hay tres direcciones que han pedido ochenta mil páginas cada una, y las bloqueas en el servidor. Te quedas tranquilo. El martes hay cuarenta direcciones nuevas haciendo exactamente lo mismo.

Bloquear por dirección es la primera reacción de todo el mundo y la que menos dura. No porque esté mal pensada, sino porque el problema no es quién pide, sino cuánto pide. Y eso se mide, no se adivina.

Por qué bloquear direcciones no termina nunca

Un rastreador que recorre tu catálogo no viene de una dirección: viene de una red, o de varias, y va rotando. Cuando cortas una, sigue con la siguiente sin perder el ritmo. Con los nombres pasa lo mismo: se presentan como un navegador normal, cambian de identidad cada semana y aparecen tres nuevos cada mes. La lista de bloqueo crece y el consumo no baja.

Lo que no pueden disfrazar es el ritmo. Una persona que compra abre una categoría, marca dos filtros, pasa una página y se va a la ficha del producto: tres o cuatro búsquedas caras en toda la visita. Un rastreador hace tres o cuatro por segundo, desde cada dirección que use. Contar cuántas búsquedas caras hace cada origen en un minuto separa a los dos sin necesidad de saber cómo se llaman.

Qué es limitar por IP, y por qué también por red

Limitar por IP es poner un techo: cuántas peticiones acepta la tienda de una misma dirección en una ventana de tiempo —sesenta segundos, normalmente—. Por debajo del techo, todo pasa; por encima, la petición se responde con un «vuelve dentro de un rato» que no cuesta nada servir.

Solo con eso, un rastreador que reparte el trabajo entre doscientas direcciones de la misma red se queda por debajo del techo en todas. Por eso el segundo límite es por red: se cuentan juntas las direcciones que comparten los primeros tres bloques (lo que un técnico llama un /24). Un operador de móvil puede parecerse a eso, así que ese techo va más alto que el de dirección, pero deja de ser gratis rotar. Y un tercer freno, para toda la tienda, hace de límite de emergencia: cuando el total de búsquedas por minuto supera lo que tu servidor aguanta con holgura, solo pasan los visitantes que ya han demostrado ser personas.

Dónde se pone el límite: en el servidor o en la tienda

Hay tres sitios donde se puede contar, y no ven lo mismo.

• En el CDN (las reglas de limitación de Cloudflare, por ejemplo). Cuenta por dirección y por patrón de URL. No sabe qué petición es cara y cuál es una imagen, no sabe si el visitante tiene sesión abierta y trata a Googlebot como a cualquiera. Para un pico de una tarde sirve; para vivir así, o te pasas de frenada con tus clientes o te quedas corto con los robots.
• En el servidor web (los módulos de limitación de Apache o nginx, o fail2ban leyendo el registro). Cuenta todo lo que entra, también el CSS y las fotos, así que el techo tiene que ser tan alto que apenas frena. Y hay que saber administrar un servidor para tocarlo, cosa que en un hosting compartido ni siquiera está permitida.
• En la propia tienda, antes de que PrestaShop empiece a buscar. Es el único sitio que sabe qué es caro: una búsqueda con filtros, el buscador, una página de listado, un cambio de orden. Solo eso cuenta para el límite. Sabe si el visitante ha iniciado sesión —y entonces no lo limita— y puede comprobar si el que dice ser Googlebot lo es de verdad. Es donde lo pone Anti-Bots para PrestaShop, y por eso el límite puede ser bajo sin molestar a nadie que compre.

Cómo dejar entrar a Google

Este es el miedo que frena a la mayoría, y con razón: un límite mal puesto te borra de Google tú solo. La solución no es una lista de nombres, porque cualquiera puede presentarse como Googlebot: es preguntarle a la red. Cada petición que dice venir de Google se comprueba con una consulta inversa de DNS, y si la dirección no pertenece a Google, esa petición no es de Google, diga lo que diga.

Los buscadores verificados entran con una cuota propia, separada de la de los visitantes, y reciben las páginas de filtros marcadas como no indexables. Es justo lo que Google recomienda para la navegación por facetas: que las combinaciones de filtros no se conviertan en miles de páginas repetidas. Cuando dejas de gastarle el tiempo en ellas, empieza a rastrear mejor las que te interesan.

Qué pasa cuando alguien supera el límite

Un script recibe un «demasiadas peticiones» con la hora a la que puede volver, y no le cuesta nada a tu base de datos. Pero un límite por dirección tiene un caso incómodo: la oficina con treinta personas detrás de una sola conexión, o el cliente que filtra muy deprisa. A esos no hay que echarlos: hay que comprobar que son personas.

La comprobación que funciona es la que no se ve. Una prueba de trabajo —un pequeño cálculo que el navegador resuelve solo en milisegundos, sin puzles ni casillas— y un pase por una hora. El pase no exime del todo, porque resolver esa prueba también es barato para un script: quien lo trae sigue teniendo un techo por dirección, solo que diez veces más alto.

Los números para empezar

Con una ventana de sesenta segundos, treinta búsquedas caras por dirección, noventa por red y seiscientas para toda la tienda cubren a la inmensa mayoría de las tiendas sin que ningún cliente llegue a verlo. Un cliente rápido hace veinte en un minuto; treinta ya es alguien que no está mirando lo que filtra.

Si no te fías, hay un modo de observación: el límite mira y anota lo que habría parado, pero deja pasar todo. Una semana así y el panel te dice cuántas peticiones se habrían quedado en la puerta y de dónde venían, y ya decides con datos.

Cómo saber si el límite está bien puesto

Un límite que no se mide es un límite que un día molesta a un cliente sin que te enteres. Lo que hay que mirar cada semana son tres cosas: cuántas búsquedas caras se han servido y cuántas se han detenido, qué orígenes se han detenido más y con qué motivo, y si alguno de ellos es alguien tuyo —tu monitor de disponibilidad, tu comparador de precios, un cliente que se ha quejado—. A ese se le da un clic de confianza y no vuelve a contarse.

Y para las dudas, un comprobador: pegas la dirección y el navegador que aparecen en el registro, la página que pedían, y te dice exactamente qué haría con esa petición ahora mismo y por qué. Es la forma de tocar un límite sin tocarlo a ciegas.

Todo esto —los tres techos, el rebote de cookies, Google verificado por DNS, la comprobación invisible, el modo observación y el panel con el comprobador— es lo que hace Anti-Bots para PrestaShop desde el minuto en que se instala, en PrestaShop 1.7.6 a 9 y detrás de Cloudflare. Y si antes quieres saber si el problema es este, mándanos el registro de accesos de un día malo desde el formulario de contacto: te decimos gratis cuántas de esas peticiones son personas y cuántas son ruido.