Cloudflare Rate Limiting bloquea la API REST de WP STAGING (HTTP 429)

Si tu sitio está detrás de Cloudflare y tienes activa una regla de rate limiting, esa regla también puede aplicarse a la API REST de WP STAGING. Cloudflare responde entonces a esas peticiones con HTTP 429 (Too Many Requests) y las funciones de WP STAGING que dependen de la API REST dejan de funcionar. La solución es una exclusión de una sola línea en la regla de rate limiting.

¿Por qué el rate limiting de Cloudflare rompe la API REST de WP STAGING?

Las reglas de rate limiting de Cloudflare se evalúan sobre la petición entrante, no sobre el plugin que la ha enviado. Por eso, una regla escrita para todo tu dominio, o para una ruta con mucho tráfico como /booking, también cuenta las peticiones internas que WP STAGING hace a su propia API REST.

Cuando se supera el contador, Cloudflare bloquea el resto de peticiones que coinciden y devuelve HTTP 429. WP STAGING nunca llega a WordPress, así que la función que originó la petición falla o se queda colgada.

Tu sitio está afectado si se cumplen todas estas condiciones:

  • El rate limiting de Cloudflare está activado en la zona.
  • Una regla de rate limiting coincide con el sitio WordPress o con una ruta dentro de él, por ejemplo /booking.
  • Esa regla no excluye la API REST de WP STAGING.

¿Qué funciones de WP STAGING dejan de funcionar?

La API REST de WP STAGING la utilizan varias funciones, entre ellas:

  • Trabajos en segundo plano
  • Remote Sync
  • Magic Login
  • Actualización automática de plugins
  • Otras funciones basadas en la API REST

Si estas peticiones se limitan, fallan con HTTP 429 y la función que las ha lanzado no puede completarse.

¿Cómo excluyo la API REST de WP STAGING del rate limiting de Cloudflare?

Edita la regla de rate limiting para que deje de coincidir con las peticiones a la API REST de WP STAGING.

Paso 1: Abre tus reglas de rate limiting

En el panel de Cloudflare, selecciona tu cuenta y después tu dominio, entra en Security y abre Security rules. Ahí aparecen tus reglas de rate limiting.

Paso 2: Edita la regla que cubre tu sitio WordPress

Abre la regla que cubre el sitio WordPress o la ruta donde aparecen las respuestas 429.

Paso 3: Añade la exclusión a la expresión de la regla

Añade esta condición a la expresión de coincidencia de la regla:

and not http.request.uri.query contains "/wpstg/v1"

Una expresión completa para una regla que protege /booking queda así:

(http.host eq "example.com" and starts_with(http.request.uri.path, "/booking")) and not http.request.uri.query contains "/wpstg/v1"

Paso 4: Despliega la regla

Guarda y despliega. Peticiones como la siguiente ya no se limitan, mientras el resto de tu sitio sigue protegido:

?rest_route=/wpstg/v1/check_magic_login

Nota: wpstg/v1 forma parte de la cadena de consulta, no de la ruta de la URL. WP STAGING llama a su API REST mediante la forma ?rest_route=, así que usa http.request.uri.query en lugar de http.request.uri.path en la exclusión.

Preguntas frecuentes

¿Por qué la exclusión usa http.request.uri.query y no http.request.uri.path?

WP STAGING construye sus URLs REST como https://example.com/?rest_route=/wpstg/v1/<endpoint>. El espacio de nombres wpstg/v1 aparece por tanto en la cadena de consulta. Una regla que evalúa http.request.uri.path nunca lo vería y la exclusión no haría nada.

¿Esta exclusión debilita la protección de mi sitio?

Solo exime a las peticiones cuya cadena de consulta contiene /wpstg/v1. Todas las demás peticiones a tu dominio siguen contando para la regla de rate limiting.

También veo errores 429 en /wp-json/wpstg/v1/. ¿Qué hago?

Algunas configuraciones acceden a la API REST mediante la forma de enlace permanente. En ese caso, añade una segunda condición para la ruta:

and not starts_with(http.request.uri.path, "/wp-json/wpstg/v1/")

¿Puede el 429 tener otra causa además de Cloudflare?

Sí. Los firewalls de aplicaciones web, el rate limiting del propio hosting y los plugins de seguridad también pueden devolver HTTP 429. Revisa los registros del servidor y de los plugins si los errores continúan después de desplegar la exclusión en Cloudflare.

¿Cómo confirmo que la solución ha funcionado?

Vuelve a lanzar la función que fallaba, por ejemplo abre un enlace de Magic Login o inicia un Remote Sync, y consulta el registro Security Events de Cloudflare. Las peticiones que contienen /wpstg/v1 ya no deberían mostrar una acción de bloqueo por rate limiting.

Artículos relacionados

Updated on agosto 4, 2026

Rene Hermenau

Autor: Rene Hermenau

Sobre el autor: René Hermenau es el fundador de WP STAGING. Trabaja en copias de seguridad de WordPress, entornos de staging, migraciones, gestión de bases de datos y flujos de despliegue seguros.