Un răspuns 429 Too Many Requests înseamnă că un client a trimis mai multe solicitări decât permite limita de rată într-un anumit interval de timp. Clientul poate fi un vizitator real, un crawler de căutare, o integrare API sau un bot nedorit. Problemele de acces apar atunci când limita este prea mică, aplicată la nivelul greșit sau impusă fără un răspuns de reîncercare sigur.
Limitarea ratei este utilizată pentru a controla valurile de solicitări și pentru a reduce traficul nedorit. Aceasta poate fi configurată pe serverul site-ului web, într-un sistem de protecție împotriva bot-urilor, într-un proxy invers sau într-un mediu de găzduire partajată. Un prim pas util este identificarea stratului care a returnat răspunsul 429.
Cuprins
Cum greșelile de limitare a ratei de acces provoacă un răspuns 429
Limitele de trafic sunt prea stricte
O limită de rafale controlează numărul de solicitări pe care un client le poate trimite într-o perioadă scurtă de timp. Un vizitator care încarcă mai multe resurse ale paginii simultan, un crawler care preia numeroase pagini sau un client API care trimite solicitări în paralel pot depăși limita chiar și atunci când traficul este legitim. O limită concepută exclusiv pentru navigarea lentă, câte o pagină pe rând, poate bloca vârfurile normale de trafic.
Verificați dacă limita se bazează pe un vârf de trafic de scurtă durată, pe o fereastră de solicitare mai lungă sau pe ambele. Modificați regula numai după ce verificați ce tip de trafic este afectat. Creșterea limitei pentru fiecare solicitare poate spori încărcarea serverului, așa că o modificare mai sigură este să vizați punctul final afectat, grupul de clienți sau serviciul de încredere, acolo unde configurația permite acest lucru.
Protecția împotriva boturilor tratează traficul util ca fiind nedorit
Protecția împotriva bot-urilor poate restricționa solicitările automate. O parte din traficul automat este util, inclusiv crawlerele motoarelor de căutare, în timp ce alți bot-uri pot genera spam, activități rău intenționate sau o încărcare excesivă. Distincția este importantă, deoarece o regulă generală poate limita atât bot-urile nedorite, cât și crawlerele legitime. Boții nedoriți pot supraîncărca un server, pot denatura datele analitice și pot încerca să genereze spam sau activități rău intenționate.
Verificați dacă regula se aplică tuturor clienților automatizați, unui model de agent de utilizator, unei adrese IP sau unei căi de solicitare. Asigurați protecția pentru punctele finale sensibile sau costisitoare, dar evitați aplicarea aceleiași reguli stricte paginilor publice și serviciilor critice fără a analiza modelele de trafic ale acestora.
Gazduirea partajată aplică o limită în afara configurației site-ului web
În cazul găzduirii partajate, limitarea ratei sau protecția resurselor pot afecta mai mult de un proces al site-ului web. Un proprietar de site poate modifica o regulă a aplicației și totuși să primească răspunsuri 429, deoarece solicitarea este limitată de mediul de găzduire sau de un alt serviciu situat în fața site-ului.
Comparați ora și sursa răspunsului 429 cu jurnalele disponibile pentru site. Dacă aplicația nu înregistrează cererea sau dacă răspunsul are formatul unui serviciu din amonte, este posibil ca limita să se afle în afara aplicației. Această distincție previne modificările repetate ale unei configurații greșite.
Un proxy invers aplică o regulă diferită față de serverul de origine
Un proxy invers primește cererile înainte de a le redirecționa către serverul site-ului web. Acesta poate aplica propria limită de cereri, propria regulă pentru boți sau propria politică de trafic intens. În acest caz, este posibil ca serverul de origine să nu vadă toate cererile pe care vizitatorii le raportează ca fiind blocate. De asemenea, un proxy poate identifica clienții diferit față de serverul de origine, ceea ce poate face ca mai mulți utilizatori să pară că împart aceeași cheie de limitare a ratei.
Verificați fiecare strat în ordinea solicitărilor: vizitatorul sau clientul API, proxy-ul invers, mediul de găzduire și aplicația de origine. Primul strat care înregistrează solicitarea respinsă este sursa probabilă a răspunsului 429.
Cum se confirmă sursa în jurnale
Utilizați aceeași adresă URL, același client și ora aproximativă ca în cazul erorii raportate. Apoi comparați înregistrările din toate straturile care gestionează solicitarea.
- Înregistrați solicitarea afectată. Notați adresa URL, metoda de solicitare, clientul sau crawlerul, ora răspunsului și dacă problema afectează un singur punct final sau întregul site.
- Verificați jurnalul aplicației. Dacă solicitarea ajunge la aplicație, căutați răspunsul și regula sau limita care a respins-o.
- Verificați jurnalul proxy-ului invers sau al protecției. Un cod 429 înregistrat acolo, dar nu și în aplicație, indică faptul că solicitarea a fost oprită înainte de a ajunge la sursa de origine.
- Comparați mai mulți clienți. Dacă mulți vizitatori sunt blocați simultan, este posibil ca limita să utilizeze o adresă comună, o identitate de proxy sau o regulă generală. Dacă este afectat un singur client, limita poate fi legată de acel client sau de modelul său de solicitare.
- Verificați indicațiile din răspuns. Un antet
Retry-Afterindică clientului când să încerce din nou. Dacă acesta lipsește, clienții nu pot utiliza timpul de reîncercare furnizat de server și ar putea încerca din nou prea devreme.
Recuperare în condiții de siguranță după limitarea traficului legitim
- Pauză între încercările repetate. Un client care repetă imediat o cerere respinsă poate prelungi perioada de trafic intens și poate continua limitarea ratei.
- Utilizați valoarea Retry-After atunci când aceasta este prezentă. Așteptați perioada specificată înainte de a încerca din nou.
- Utilizați încercări controlate atunci când aceasta este absentă. Adăugați întârzieri crescânde între încercări, în loc să trimiteți cereri în mod continuu. Mențineți procesul de reîncercare limitat, astfel încât o singură eșuare să nu creeze o buclă de solicitări.
- Identificați traficul afectat. Separați utilizatorii reali, clienții API cunoscuți, crawlerele de căutare și boții nedoriți înainte de a modifica o regulă.
- Ajustați regula cea mai restrictivă. Măriți limita de trafic sau de solicitări numai pentru punctul final, grupul de clienți sau stratul confirmat de jurnale.
- Protejați separat punctele finale critice. Punctele finale de autentificare, plată, cont și API pot necesita limite mai stricte decât conținutul public. Aplicați modificările cu atenție, astfel încât protecția să nu fie eliminată de pe căile sensibile.
- Testați după efectuarea modificării. Confirmați că vizitatorii obișnuiți și clienții automatizați aprobați pot accesa paginile necesare, în timp ce protecția dorită rămâne activă.
Cum să evitați blocarea utilizatorilor reali și a crawlerelor de căutare
Nu tratați fiecare cerere automatizată ca fiind nedorită. Robotii de indexare pot fi utili, în timp ce botii nedoriți pot genera spam, activități rău intenționate, încărcare excesivă a serverului și analize inexacte. Măsurile de control a boturilor ar trebui să facă distincția între crawlerele utile și traficul care trebuie restricționat.
Revizuiți regulile în funcție de punctul final și de tipul de trafic. Este posibil ca paginile publice să trebuiască să tolereze vârfuri normale de vizitatori. Punctele finale costisitoare sau sensibile pot utiliza limite mai stricte. Clienții API ar trebui să utilizeze întârzieri deliberate între încercări, iar serviciul ar trebui să ofere Retry-After atunci când se atinge o limită temporară.
429 versus 403
| Răspuns | Semnificație | Aspecte tipice |
|---|---|---|
| 429 Prea multe solicitări | Rata solicitărilor a depășit o limită configurată. | Verificați rafalele, gestionarea reîncercărilor, gruparea clienților și stratul care aplică limita. |
| 403 Acces interzis | Serverul a înțeles solicitarea, dar refuză accesul la resursă. | Verificați regulile de acces și permisiunile, în loc să încercați repetat. |
Un cod 403 reprezintă o refuzare a accesului, în timp ce un cod 429 este un răspuns legat de rata cererilor. O eroare 403 înseamnă că accesul la resursa solicitată a fost refuzat. Tratarea unui cod 429 ca pe o blocare permanentă a accesului poate duce la modificări greșite ale configurației.
Când să contactați serviciul de asistență
Contactați serviciul de asistență atunci când jurnalele indică faptul că eroarea 429 este generată de un strat de găzduire sau de un strat din amonte pe care nu îl puteți modifica, atunci când găzduirea partajată pare să grupeze vizitatori fără legătură între ei sau atunci când sursa răspunsului rămâne neclară după compararea jurnalelor disponibile. Includeți adresa URL afectată, timpul de răspuns, tipul clientului și intrările relevante din jurnal, astfel încât stratul de limitare a ratei să poată fi identificat în mod eficient.