Cum să rezolvați eroarea 429 “Too Many Requests” (Prea multe cereri)

Eroarea HTTP 429 “Too Many Requests” este un cod de răspuns de limitare a vitezei trimis de un server atunci când un utilizator (sau client) depășește numărul de cereri permise într-un anumit interval de timp. Acest status face parte de obicei din mecanisme de securitate, de protecție API sau anti-DDoS.

În mediile de producție, acesta poate întrerupe serviciile, rupe integrările API sau afecta SEO. Acest ghid avansat acoperă modul de diagnosticare, prevenire și rezolvare a erorii 429 atât din perspectiva părții client, cât și din perspectiva părții server.

Ce cauzează eroarea 429?

Scenarii comune:

  • Un utilizator/bot trimite prea multe cereri HTTP (apeluri API, încărcări de pagini etc.)

  • Aplicația dvs. face scraping sau sondează prea agresiv un serviciu terț

  • Firewall-urile pentru aplicații web (WAF) sau proxy-urile inverse (de exemplu, Cloudflare, Nginx) impun limite de viteză

  • API-urile serverului sau ale back-end-ului utilizează biblioteci de limitare a vitezei (de exemplu, express-rate-limit, mod_evasive etc.)

  • Bots sau crawlere inundă site-ul sau punctul final

Pasul 1: Identificarea sursei

✅ 1. Verificați anteturile de răspuns

Serverele trimit adesea un antet Retry-After cu un răspuns 429:

HTTP/1.1 429 Too Many Requests
Retry-After: 60

Aceasta indică clientului cât timp să aștepte (în secunde) înainte de a încerca din nou.

✅ 2. Verificați jurnalele de acces

Pentru Apache:

cat /var/log/apache2/access.log | grep "429"

Pentru Nginx:

cat /var/log/nginx/access.log | grep "429"

Acest lucru ajută la identificarea IP-urilor sau a punctelor finale care declanșează limita.

✅ 3. Utilizați instrumentele de monitorizare

  • Jurnalele Fail2Ban

  • Evenimente Cloudflare Firewall

  • Jurnale la nivel de aplicație (Laravel, Express, Django etc.)

  • Analizele limitelor de rată (dacă utilizați un gateway API)

Etapa 2: Soluții pe partea de server

A. Limitarea ratei Nginx (dacă este activată)

Nginx poate fi configurat astfel:

limit_req_zone $binary_remote_addr zone=api_limit:10m rate=5r/s;

locație /api/ {
limit_req zone=api_limit burst=10 nodelay;
}

Soluție:

  • Creșteți rata sau burst-ul

  • Aplicați la căi specifice (de exemplu, /api/) în loc de la nivel global

  • Lista albă a IP-urilor interne cunoscute

B. Apache (mod_evasive sau mod_security)

Dacă mod_evasive este activ:

sudo nano /etc/apache2/mods-enabled/evasive.conf

Reglați:

DOSPageCount 10
DOSSiteCount 100
DOSBlockingPeriod 10

➡️ Creșteți pragurile sau dezactivați-le pentru anumite IP-uri de încredere.

C. Reguli Cloudflare / CDN

Dacă sunteți în spatele Cloudflare, verificați:

  • Rate Limiting Rules în Security > WAF

  • Modul Bot Fight

  • Regulile Firewall care blochează pe baza User-Agent sau IP

Soluție:

  • Reducerea sensibilității

  • Lista albă a IP-urilor serverului sau a anumitor agenți de utilizator

  • Creați reguli personalizate pentru crawlere și parteneri siguri

D. Limitarea vitezei la nivel de aplicație

Verificați dacă aplicația dvs. impune limite utilizând biblioteci precum:

  • Node.js: express-rate-limit

  • Laravel: ThrottleRequests

  • Django: drf-extensions sau middleware

Actualizați configurația, cum ar fi:

rateLimit({
windowMs: 1 * 60 * 1000, // 1 minut
max: 100, // limitează fiecare IP la 100 de cereri pe minut
})

➡️ Ajustați limitele, adăugați user/IP whitelisting sau măriți cota pe baza token-urilor de autentificare.

Pasul 3: Corecții la nivelul clientului (atunci când consumați API-uri)

Dacă aplicația dvs. este clientul și primește 429s:

✅ Implementați funcția Exponential Backoff

Reîncercați automat cererile cu întârzieri din ce în ce mai mari:

const retryAfter = (attempt) => Math.pow(2, attempt) * 1000;

✅ Respectarea antetelor Retry-After

if (response.status === 429) {
const wait = response.headers['retry-after'] * 1000;
setTimeout(() => retryRequest(), wait);
}

✅ Adăugați limitarea ratei la client

Limitați propriile solicitări în cazul sondajului:

// Utilizați lodash sau throttling personalizat
_.throttle(() => fetchData(), 1000);

Etapa 4: Considerații SEO

O stare 429 servită crawlerelor motoarelor de căutare vă poate afecta clasamentul.

✅ Soluție:

  • Serviți în schimb un status 503 (Service Unavailable) cu Retry-After

  • Utilizați robots.txt pentru a limita rata de urmărire:

    User-agent: *
    Crawl-delay: 10

  • În Cloudflare: Mergeți la Bots > Crawl Management

Pasul 5: Protejați fără a bloca utilizatorii legitimi

În loc de limite dure 429:

  • Utilizați CAPTCHA-uri pentru activități suspecte

  • Implementați întârzieri progresive mai degrabă decât blocarea dură

  • Utilizați limitarea vitezei în funcție de utilizator mai degrabă decât în funcție de IP pentru utilizatorii conectați

  • Oferiți acces autentificat cu limite mai mari ale ratei (de exemplu, prin chei API sau jetoane)

Concluzie

Eroarea 429 Too Many Requests este un instrument util, dar uneori deranjant. Înțelegerea provenienței acesteia – server, CDN sau aplicație – este esențială pentru rezolvarea ei. Cu o configurație adecvată, logare și respectarea limitelor pe partea de client, puteți echilibra protecția cu utilitatea.