---
title: "429 Too Many Requests: qué es el error de rate limit"
description: "429 Too Many Requests indica que enviaste más solicitudes de las que un servicio permite en poco tiempo. Cómo funciona el rate limit y cómo resolver el error."
url: https://proxynet.io/es/blog/http-429-too-many-requests
date: 2026-09-19
author: "Acar Diveroli"
category: "Tutoriales, Web scraping"
lang: es
---

# 429 Too Many Requests: qué es el error de rate limit

Estás revisando ofertas de intercambio en una plataforma de juegos, escribes una pregunta tras otra en un chat de inteligencia artificial o abres una y otra vez la misma página para ver si ha quedado libre una cita de visado. De pronto la página cambia y en la pantalla queda una sola línea: «429 Too Many Requests». A veces el mensaje está en español («Demasiados intentos, inténtalo de nuevo más tarde»), a veces aparece dentro de una aplicación como «Request failed with status code 429» y otras veces dice «rate limit exceeded». Todos dicen lo mismo: el servicio del otro lado ha contado las solicitudes que llegan de tu parte y la cuenta ha superado el límite.

En este artículo explicamos qué son el código 429 y el concepto de rate limit (límite de frecuencia), con respecto a qué se cuenta el límite, por qué le aparece a quien «no ha hecho nada» y cuánto hay que esperar. La primera mitad es para quien ve el error en su pantalla; la segunda, para desarrolladores que usan una API y para equipos que recopilan datos.

> **Nota: Respuesta breve**
>
> 429 Too Many Requests es el código de estado HTTP que indica que enviaste más solicitudes de las que un servicio permite en un periodo determinado. Este mecanismo se llama rate limit, es decir, límite de frecuencia. El bloqueo es temporal: el contador depende del tiempo y se abre solo cuando esperas. Recargar la página no reinicia el contador, cuenta como una solicitud nueva. El límite puede llevarse por dirección IP, por cuenta, por sesión o por clave de API; por eso cambiar de IP no cambia nada en la mayoría de los casos. La reacción correcta es esperar y bajar el ritmo de las solicitudes.

## ¿Qué significa 429 Too Many Requests?

Cada vez que tu navegador o una aplicación se conecta a un servidor, el servidor pone al principio de la respuesta un código de estado de tres cifras. `200` significa «correcto», `404` significa «esa página no existe». `429` significa «he entendido tu solicitud, pero no la voy a procesar ahora porque enviaste demasiadas solicitudes en poco tiempo». El código se define en [la sección 4 de RFC 6585](https://www.rfc-editor.org/rfc/rfc6585#section-4). Esa misma sección deja dos cosas en manos del servidor: cómo se identifica al usuario y cómo se cuentan las solicitudes. Es decir, la regla que hay detrás de un 429 es distinta en cada servicio; lo único común es el mensaje.

El mismo error adopta formas distintas según la interfaz del servicio:

| Lo que ves en pantalla | Dónde aparece | Qué significa |
|---|---|---|
| `429 Too Many Requests` | En el navegador, casi siempre en una página blanca sin más | El servidor muestra el código tal cual |
| `HTTP Error 429`, `Request failed with status code 429` | En aplicaciones y herramientas de desarrollo | La aplicación te transmite el 429 que recibió del servidor |
| «Demasiados intentos, inténtalo de nuevo más tarde», «Demasiadas solicitudes» | En cuentas de redes sociales, correo y juegos con interfaz en español | El mismo límite, traducido al lenguaje del usuario |
| `Rate limit exceeded`, `You are being rate limited` | En respuestas de API, plataformas de chat y de juegos | Se ha superado el límite de frecuencia |
| `Error 1015` | En sitios que usan Cloudflare | La página de marca de Cloudflare para un 429 |

La última fila tiene su propio artículo: explicamos cada línea de esa pantalla, el código Ray ID y lo que puede hacer el propietario del sitio en [¿Qué es Error 1015? Solución a You are being rate limited](/es/blog/cloudflare-error-1015).

## ¿Qué es un rate limit y por qué se pone?

Un rate limit es el tope de solicitudes que un servicio acepta de un mismo usuario en un periodo determinado. Es una regla del tipo «60 solicitudes por minuto», «5 intentos de inicio de sesión por hora» o «1000 búsquedas al día». «Rate limit exceeded» dice que ese tope se ha superado, y «rate limited», que te están limitando por ello. En español se habla de límite de frecuencia o límite de solicitudes.

Los servicios ponen este límite por cuatro motivos:

- **Proteger la capacidad.** El número de solicitudes que un servidor puede procesar es finito. Un solo usuario o un programa defectuoso no debería consumir toda la capacidad.
- **Seguridad de las cuentas.** En las páginas de inicio de sesión el límite se mantiene bajo a propósito. Quien intenta adivinar una contraseña quiere hacer miles de intentos; una regla de «espera después de cinco intentos fallidos» frena ese ataque hasta dejarlo sin sentido.
- **Reparto justo.** Los planes gratuitos y de pago tienen cuotas distintas; el límite fija la parte de cada uno.
- **Coste.** Cada solicitud tiene un precio en tiempo de procesador, ancho de banda y, a veces, tarifas de terceros.

## ¿Con respecto a qué se cuenta el límite?

La primera pregunta al recibir un 429 es esta: ¿a nombre de quién se lleva el contador? [La página de MDN sobre el 429](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/429) enumera los métodos posibles: para todo el servidor, para un solo recurso, por dirección IP, por usuario o por aplicación. El método que se use decide qué sirve y qué no.

| A qué está ligado el contador | Ejemplo típico | Qué significa para ti |
|---|---|---|
| Dirección IP | Sitios que se visitan sin iniciar sesión, llamadas a API sin clave | Todos los que salen por la misma dirección comparten un contador |
| Cuenta | Redes sociales, plataforma de juegos, correo | El mismo contador se llena desde el teléfono y desde el ordenador; cambiar de red o de IP no cambia nada |
| Sesión o cookie | Paneles web con sesión iniciada | Cambiar de navegador abre una sesión nueva, pero el contador de la cuenta puede llevarse aparte |
| Clave de API | API oficiales, servicios de inteligencia artificial | Todos tus programas que usan la clave gastan de una sola cuota |
| Endpoint | Funciones concretas como buscar, iniciar sesión o enviar un mensaje | Solo esa función devuelve 429 mientras el resto del sitio carga |

La mayoría de los servicios lleva varios de estos contadores a la vez. GitHub es un buen ejemplo porque escribe su regla abiertamente: según [la documentación de límites de la API REST](https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api), las solicitudes sin autenticar están limitadas a 60 por hora, y ese contador no está ligado al usuario sino a la dirección IP de la que llega la solicitud. El límite de un usuario autenticado es de 5000 solicitudes por hora y está ligado a la cuenta.

## ¿Cómo funciona un rate limit?

Los detalles cambian de un servicio a otro, pero el flujo es el mismo:

1. **El servicio escribe una regla.** La regla tiene tres partes: a quién se cuenta (IP, cuenta, clave), el periodo y el umbral.
2. **Cada solicitud que llega se anota en un contador.** Antes de procesarla, el servidor mira a qué contador pertenece y lo aumenta en uno.
3. **Superado el umbral, la solicitud se rechaza sin procesarla.** En lugar de preparar la página, el servidor envía una respuesta 429 breve.
4. **El servidor puede decirte cuánto tienes que esperar.** Lo hace con una cabecera de respuesta llamada `Retry-After`. La cabecera no es obligatoria y no todos los sitios la envían.
5. **El contador se vacía con el paso del tiempo.** La ventana se cierra o cae una ficha nueva en el cubo, y el acceso se abre solo.
6. **La penalización puede crecer para quien insiste.** Algunos servicios bloquean durante más tiempo, y con un código más duro, al cliente que sigue al mismo ritmo a pesar del 429. La documentación de GitHub lo dice sin rodeos: seguir enviando solicitudes mientras estás limitado puede acabar con el bloqueo de tu integración.

Una nota sobre el segundo paso: abrir una página no es una sola solicitud. El navegador pide por separado imágenes, scripts y consultas en segundo plano; con un solo clic pueden salir decenas de solicitudes hacia el servidor.

## No he hecho nada, ¿por qué me sale un 429?

En las sugerencias de búsqueda, los nombres que más aparecen junto a este error son Steam, Roblox, ChatGPT, Outlook y los sitios de citas de visado. Tienen algo en común: son lugares donde el usuario genera muchas solicitudes sin darse cuenta.

- **Páginas de mercado e intercambio en plataformas de juegos.** Las listas de precios, el inventario y las páginas de ofertas envían muchas consultas en segundo plano cada vez que se abren. Una extensión del navegador que sigue precios puede llenar el límite en minutos. Las herramientas de terceros que has conectado a tu cuenta también envían solicitudes en tu nombre.
- **Chats de inteligencia artificial.** Cada mensaje es una operación cara, así que el límite se pone tanto al total de mensajes como a su frecuencia. Compartir una cuenta entre varias personas o regenerar la respuesta una y otra vez es el camino más rápido hacia el límite.
- **Cuentas de correo.** Los intentos de inicio de sesión con una contraseña incorrecta, un teléfono olvidado que sigue intentando conectarse con la contraseña antigua o un programa de correo llenan el contador por ti.
- **Sitios de citas y entradas.** Aquí quien genera las solicitudes es directamente el usuario: una página recargada cada pocos segundos para ver si ha quedado un hueco.

Si nada de esto encaja contigo, queda la dirección IP compartida. Si el contador está ligado a la IP, todos los que salen a internet por la misma dirección (todos los ordenadores de una oficina, los abonados de datos móviles detrás de la misma dirección pública) cuentan como una sola persona: otro llena el contador y el 429 lo ves tú. Explicamos el mecanismo, y cómo reconocerlo en tu propia conexión, en [Qué es CGNAT, cómo saber si lo tienes y cómo salir](/es/blog/what-is-cgnat). En los servicios gratuitos de VPN y proxy, un grupo mucho más numeroso usa la misma dirección de salida; los detalles están en [¿Son seguros los proxies gratis y los sitios web proxy?](/es/blog/are-free-proxies-safe).

## ¿Cuánto dura un error 429? ¿Por qué recargar no sirve?

No hay una respuesta única, porque la duración no la fija el estándar sino el propio servicio. Una ventana de segundos se abre en unos segundos, una cuota horaria en menos de una hora, una cuota diaria al día siguiente. En la respuesta de ejemplo de MDN aparece `Retry-After: 3600`, es decir, una hora.

Recargar no sirve porque, para el servidor, F5 es una solicitud nueva: o se rechaza directamente o se suma al contador y puede alargar la espera. En un servicio que usa ventana deslizante (la explicamos más abajo), el contador de quien insiste sin parar no se vacía nunca.

En lugar de adivinar la duración, puedes leerla: abre las herramientas de desarrollo con F12, recarga la página una vez con la pestaña Red (Network) abierta y haz clic en la fila del 429. Si entre las cabeceras de respuesta está `Retry-After`, el número que la acompaña es el tiempo de espera en segundos.

## ¿Qué debes hacer si eres visitante?

1. **Para.** Cierra la pestaña, sal de la aplicación y no intentes nada durante unos minutos.
2. **Cierra lo que envía solicitudes en tu nombre.** Otras pestañas abiertas del mismo sitio, extensiones de recarga automática y de seguimiento de precios, una aplicación de escritorio en segundo plano, herramientas de terceros conectadas a tu cuenta.
3. **Si el error está en la pantalla de inicio de sesión, deja de probar contraseñas.** Cada intento fallido puede alargar la espera. Si no estás seguro, espera y después usa la opción «he olvidado mi contraseña». Si hay un dispositivo que sigue probando la contraseña antigua, actualízalo.
4. **Prueba una vez.** Si abre, el problema ha terminado. Si no, alarga la espera: diez minutos, media hora, unas horas.
5. **Mide la parte que le toca a la conexión.** Si tienes una VPN o un proxy gratuito activo, desactívalo y luego prueba con los datos móviles del teléfono. Si allí abre y en la red de la oficina o de casa no, el contador pertenece a la dirección que compartes. Si recibes el mismo error en las dos conexiones, el contador está ligado a tu cuenta y no queda más que esperar.
6. **Si el error aparece a diario con un uso normal, escribe al soporte del servicio.** Indica qué estabas haciendo y qué mensaje viste.

Borrar las cookies, cambiar de navegador o reiniciar el router no están en esta lista porque el contador suele estar ligado a algo que eso no cambia: tu cuenta o la dirección compartida. El aviso parecido que aparece en las búsquedas de Google tiene causas propias; lo tratamos en [nuestro artículo sobre el error de tráfico inusual de Google](/es/blog/google-unusual-traffic-error).

## Algoritmos de rate limit: ventana fija, ventana deslizante y token bucket

A partir de aquí el artículo es para desarrolladores. La regla «10 solicitudes por minuto» se comporta de tres maneras distintas según cómo se lleve el contador.

| Algoritmo | Cómo cuenta | Punto fuerte | Punto débil |
|---|---|---|---|
| Ventana fija (fixed window) | Cuenta en tramos fijos, como cada hora o cada minuto en punto; al acabar el tramo el contador se reinicia | Sencillo, basta un contador | Las solicitudes que se acumulan a ambos lados del borde de la ventana pueden pasar hasta el doble del límite |
| Ventana deslizante (sliding window) | Mira «los últimos 60 segundos»; tiene en cuenta el recuento del tramo anterior en proporción a la parte que queda de él | Detecta la acumulación en el borde y sigue pidiendo poca memoria | Es un cálculo aproximado |
| Token bucket (cubo de fichas) | Al cubo caen fichas a ritmo constante, cada solicitud gasta una ficha y, si el cubo está vacío, la solicitud se rechaza | Permite ráfagas cortas y mantiene la media a largo plazo | Requiere dos ajustes: capacidad del cubo y ritmo de llenado |

Cloudflare muestra el cálculo aproximado de la ventana deslizante con un ejemplo en [el artículo donde describe su propio limitador](https://blog.cloudflare.com/counting-things-a-lot-of-different-things/): el límite es de 50 solicitudes por minuto, en el minuto anterior llegaron 42 y en el segundo 15 del minuto actual se han contado 18. La estimación es `42 × (45/60) + 18 = 49,5`, justo por debajo del límite. Stripe resume el token bucket en [el artículo donde describe sus propios limitadores](https://stripe.com/blog/rate-limiters): cada usuario tiene un cubo, cada solicitud toma una ficha y al cubo van goteando fichas nuevas poco a poco.

La forma más corta de ver la diferencia es darles a los tres el mismo tráfico. El siguiente script de Python no usa conexión de red; solo pregunta a tres contadores por marcas de tiempo.

```python
LIMIT = 10      # solicitudes permitidas por ventana
WINDOW = 60     # duración de la ventana (segundos)

class FixedWindow:
    def __init__(self):
        self.window_id, self.count = None, 0

    def allow(self, now):
        window_id = int(now // WINDOW)
        if window_id != self.window_id:          # ventana nueva: el contador se reinicia
            self.window_id, self.count = window_id, 0
        if self.count >= LIMIT:
            return False
        self.count += 1
        return True

class SlidingWindow:
    def __init__(self):
        self.window_id, self.count, self.previous = None, 0, 0

    def allow(self, now):
        window_id = int(now // WINDOW)
        if window_id != self.window_id:
            # si la ventana anterior pasó vacía, no se arrastra nada
            self.previous = self.count if window_id - 1 == self.window_id else 0
            self.window_id, self.count = window_id, 0
        elapsed = now % WINDOW
        # el recuento de la ventana anterior pesa en proporción a la parte que queda de ella
        estimate = self.previous * (WINDOW - elapsed) / WINDOW + self.count
        if estimate >= LIMIT:
            return False
        self.count += 1
        return True

class TokenBucket:
    def __init__(self):
        self.tokens, self.updated = float(LIMIT), 0.0

    def allow(self, now):
        # se añaden fichas por el tiempo transcurrido; el cubo no supera su capacidad
        self.tokens = min(LIMIT, self.tokens + (now - self.updated) * LIMIT / WINDOW)
        self.updated = now
        if self.tokens < 1:
            return False
        self.tokens -= 1
        return True

def run(name, timestamps):
    print(name)
    for limiter in (FixedWindow(), SlidingWindow(), TokenBucket()):
        accepted = sum(limiter.allow(t) for t in timestamps)
        print(f"  {type(limiter).__name__:<14} {accepted}/{len(timestamps)} aceptadas")

# Escenario 1: dos ráfagas a ambos lados del borde de la ventana (segundos 59 y 61)
run("Ráfaga en el borde", [59.0] * 10 + [61.0] * 10)
# Escenario 2: una solicitud cada 7,5 segundos durante dos minutos (8 por minuto)
run("Ritmo constante", [i * 7.5 for i in range(16)])
```

Salida:

```text
Ráfaga en el borde
  FixedWindow    20/20 aceptadas
  SlidingWindow  11/20 aceptadas
  TokenBucket    10/20 aceptadas
Ritmo constante
  FixedWindow    16/16 aceptadas
  SlidingWindow  16/16 aceptadas
  TokenBucket    16/16 aceptadas
```

En el primer escenario, la ventana fija dejó pasar 20 solicitudes en dos segundos a pesar de la regla de «10 por minuto», porque el contador se reinició en el segundo 60. La ventana deslizante recordó la carga del minuto anterior y aceptó una sola solicitud de la segunda ráfaga (como el cálculo es aproximado, no se detuvo exactamente en 10). El token bucket gastó sus fichas en la primera ráfaga y rechazó la segunda entera. El segundo escenario deja la lección que importa al cliente: el tráfico que va por debajo del límite y llega de forma regular no ve un 429 con ningún algoritmo. Lo que choca con el límite no es la media, es la acumulación.

Hay un ejemplo que usa esta misma lógica de token bucket en el lado del cliente, para frenar tus propias solicitudes, en [Acceso web seguro para LLM: límites y permisos](/es/blog/llm-safe-web-access).

## Si usas una API: ¿cómo se lee el límite en las cabeceras?

Las API bien documentadas hacen que el límite deje de ser una sorpresa: en cada respuesta informan con cabeceras de cuánta cuota te queda. El endpoint de cuota de GitHub es adecuado para probarlo, porque las llamadas a este endpoint no descuentan de tu cuota principal:

```bash
curl -s -o /dev/null -D - https://api.github.com/rate_limit | grep -i -E "^HTTP|^x-ratelimit"
```

En una llamada sin autenticar, la respuesta se parece a esto:

```text
HTTP/1.1 200 OK
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 53
X-RateLimit-Used: 7
X-RateLimit-Resource: core
X-RateLimit-Reset: 1789799592
```

`Limit` da el total disponible en la ventana, `Remaining` lo que queda y `Reset` el momento en que el contador se reinicia (tiempo Unix, en segundos). El 60 de aquí pertenece a tu dirección IP; un compañero que ejecute el mismo comando desde la misma oficina gasta del mismo contador. Un programa que lee estas cabeceras puede frenar por sí solo al acercarse al límite.

Hay tres puntos a tener en cuenta:

- **Los nombres de las cabeceras no son estándar.** `X-RateLimit-*` es una costumbre extendida, pero `Reset` es tiempo Unix en unas API y segundos restantes en otras. Para ordenar esto, el IETF trabaja en [un borrador](https://datatracker.ietf.org/doc/draft-ietf-httpapi-ratelimit-headers/) que define las cabeceras `RateLimit` y `RateLimit-Policy`; cuando se escribió este artículo el texto aún no era un RFC.
- **El límite no siempre llega con un 429.** GitHub escribe en el mismo documento que, al superar el límite, puede devolver `403` o `429`. No mires solo el código, sino también las cabeceras y el mensaje del cuerpo.
- **Límite de frecuencia y cuota son cosas distintas.** Un límite por minuto se abre esperando; una cuota mensual o un saldo agotado se resuelve en el plan y en la facturación. Los dos pueden llegar con el mismo código, y la diferencia la dice el mensaje del cuerpo.

Para lo que viene después de un 429, la regla es corta. Si hay `Retry-After`, respétalo; si no, aplica retroceso exponencial (1, 2, 4, 8 segundos, sumando a cada uno una parte aleatoria), pon un tope al número de intentos y aplica la espera a todas tus solicitudes hacia ese servicio. Dimos las dos formas de `Retry-After` y un ejemplo de Python probado que aplica estas decisiones en [Códigos de estado HTTP en web scraping: 403, 407, 429, 503](/es/blog/http-status-codes-web-scraping); no repetimos aquí el mismo código. El efecto de la concurrencia en la tasa de 429 está en [Concurrencia y paralelismo en web scraping](/es/blog/concurrency-vs-parallelism).

## ¿Se supera un rate limit cambiando de IP?

En la mayoría de los casos, no. Si el contador está ligado a la cuenta, a la sesión o a la clave de API, la dirección IP ni siquiera entra en el cálculo: la solicitud que llega desde una dirección nueva se anota en el contador de la misma cuenta.

Incluso cuando el contador está ligado a la IP, cambiar de IP no resuelve el problema, lo cambia de sitio. Al límite no le preocupa tu identidad, sino la carga que pones sobre el servicio. Repartir el mismo ritmo entre otras direcciones cansa al servidor en la misma medida; el servicio que lo nota escribe la regla según el comportamiento, y el bloqueo pasa de un 429 a algo más permanente. Escribir una dirección falsa en la cabecera `X-Forwarded-For` o cambiar el User-Agent en cada solicitud entra en la misma clase: un servidor bien configurado no se fía de la dirección que escribe el cliente, y las cabeceras incoherentes son una señal visible de tráfico automatizado. Cómo leen los sitios esas señales lo explicamos en [nuestro artículo sobre cómo funciona la detección de bots](/es/blog/how-bot-detection-works).

La rotación de IP tiene un lugar legítimo, pero ese lugar no es «después de recibir un 429». En un trabajo de recopilación de datos autorizado y de gran volumen, primero se baja el ritmo total a un nivel que el sitio pueda soportar y que sea compatible con robots.txt y con las condiciones de uso; después ese tráfico se reparte entre direcciones. Las formas prácticas de respetar el ritmo están en [Cómo hacer web scraping sin que te bloqueen](/es/blog/web-scraping-without-getting-blocked). Cómo funciona la rotación está en [nuestro artículo sobre la rotación de IP](/es/blog/ip-rotation-explained), y la parte de producto, en nuestra página de [proxies rotativos](/es/rotating-proxy).

## ¿Quién lidia con los límites de frecuencia por trabajo?

- **Equipos que siguen precios y existencias.** Un trabajo que lee miles de páginas de producto al día ve subir rápido su tasa de 429 si no ajusta el ritmo al sitio: [solución de monitorización de precios](/es/price-monitoring).
- **Quienes recopilan datos de catálogo y de mercado.** Para cada sitio se lleva un presupuesto de ritmo aparte: [solución de extracción de datos](/es/data-scraping).
- **Quienes se conectan a API que exigen una lista de IP autorizadas.** La cuota se anota en esa dirección o en esa clave: [nuestro artículo sobre IP estática para el acceso a API](/es/blog/static-ip-for-api-access).
- **Quienes montan automatizaciones.** Un flujo que lanza cientos de llamadas en el mismo minuto choca con el límite en la primera ejecución; los ajustes de espera están en [Web scraping con n8n: HTTP Request y ajustes de proxy](/es/blog/n8n-proxy).
- **Equipos de operaciones que trabajan desde una red concurrida.** Si decenas de empleados se conectan al mismo panel desde una sola dirección de oficina, un contador por IP ve el total del equipo. Aquí no se busca superar el límite, sino ligar el contador solo a tu propio uso: [Proxies ISP](https://proxynet.io/es/static-isp-residential-proxy) ofrece una dirección fija, registrada en un proveedor de servicios de internet y que no se comparte con nadie.

## Errores frecuentes

- **Seguir recargando en la pantalla del 429.** Cada recarga se anota en el contador.
- **Seguir probando contraseñas en el límite de inicio de sesión.** La espera se alarga y en algunos servicios la cuenta se bloquea temporalmente.
- **Dar por hecho que el límite está ligado a la IP.** Si el contador está ligado a la cuenta o a la clave, cambiar de red es tiempo perdido.
- **Reintentar sin esperar en el lado del desarrollador.** La respuesta a un reintento inmediato tras un 429 es otro 429.
- **Usar la misma clave de API en muchos programas y buscar el límite en cada programa por separado.** El contador pertenece a la clave; sin ver el total no hay diagnóstico.

## Guía de decisión

| Tu situación | Qué hacer |
|---|---|
| Ves el error por primera vez | Cierra la pestaña, espera unos minutos, prueba una vez |
| En la pantalla de inicio de sesión aparece «demasiados intentos» | Deja de probar contraseñas, espera y, si hace falta, restablece la contraseña; actualiza los dispositivos con la contraseña antigua |
| Abre con datos móviles, pero no en la red de la oficina o de casa | La dirección es compartida; si hay una VPN activa, desactívala y avisa al administrador de la red |
| El mismo error en todas las redes y en todos los dispositivos | El contador está ligado a tu cuenta; quita las herramientas de terceros conectadas y espera |
| En la pantalla pone Error 1015 | Es la página de límite de frecuencia de Cloudflare; sigue los pasos de [nuestro artículo sobre el 1015](/es/blog/cloudflare-error-1015) |
| Tu programa recibe un 429 de una API | Respeta `Retry-After`, lee las cabeceras de cuota, baja la concurrencia |
| Recopilas datos autorizados y de gran volumen | Primero baja el ritmo total, después reparte el tráfico entre direcciones |

## Preguntas frecuentes

### ¿429 Too Many Requests es un bloqueo permanente?

No. Un 429 viene de un contador ligado al tiempo, y el acceso se abre solo cuando el contador se vacía. A tu cuenta no se le hace nada.

### ¿«Too many requests» significa un virus o una avería de internet?

No. El mensaje viene del servidor del servicio al que te conectaste y solo tiene que ver con el número de solicitudes. Si otros sitios abren con normalidad, tu conexión está bien.

### ¿Reiniciar el router resuelve el error 429?

No es un método fiable. Cuando el router vuelve a conectarse, la dirección IP cambia en unas líneas y en otras no; si el contador está ligado a la cuenta, da igual. Explicamos en qué condiciones cambia la dirección IP en [Cómo cambiar la dirección IP: teléfono, PC y router](/es/blog/how-to-change-ip-address).

### ¿Un rate limit y un bloqueo de IP son lo mismo?

No. Un rate limit es un contador ligado al tiempo: se aplica a todos y se abre al esperar. Un bloqueo de IP es una decisión de larga duración sobre una dirección concreta y suele manifestarse con un `403`. Una dirección que fuerza el límite de forma continua puede pasar con el tiempo al segundo grupo.

### ¿Cuánto debo esperar si no hay cabecera Retry-After?

Si eres usuario, empieza con unos minutos y alarga la espera con cada intento fallido. Si escribes un programa, aplica retroceso exponencial y pon un tope al número de intentos.

### ¿Usar un proxy resuelve el error 429?

Si lo que llena el límite es tu propio ritmo o tu comportamiento, no: el mismo ritmo llena también el contador de la dirección nueva, y un contador ligado a la cuenta ni siquiera ve la dirección. El caso en que un proxy marca la diferencia es cuando el contador no lo llenas tú, sino los demás con quienes compartes la dirección. Entonces una dirección fija que sea solo tuya reduce el contador a tu propio uso.

## En resumen

**429 Too Many Requests** es una respuesta temporal que te dice que has chocado con el límite de frecuencia (rate limit) de un servicio. El límite puede contarse por dirección IP, cuenta, sesión, clave de API o un solo endpoint; eso decide qué sirve. Para el usuario, la solución es parar, cerrar lo que envía solicitudes en segundo plano y esperar. Para el desarrollador, es leer las cabeceras de cuota, respetar `Retry-After` y bajar el ritmo. El límite no se supera rotando IP; la rotación solo sirve para repartir una carga planificada desde el principio y respetuosa con el sitio. Puedes encontrar los tipos de dirección adecuados para tu trabajo en [nuestros servicios de proxy](/es/proxy).