429 Too Many Requests tarkoittaa, että palvelin rajoittaa pyyntöjäsi: asiakasohjelma on lähettänyt tietyssä ajassa enemmän pyyntöjä kuin palvelin sallii, ja sen pitää odottaa ennen uutta yritystä. Mikään ei ole rikki, ja pyynnön toistaminen heti pahentaa tilannetta. Hyvin käyttäytyvä palvelin kertoo odotusajan Retry-After-otsakkeessa; hyvin käyttäytyvä asiakasohjelma odottaa vähintään sen verran ja ilman otsaketta pidentää viivettä vähitellen. Kun valvonta törmää 429:ään, tavallinen ratkaisu on vapauttaa valvonta rajoituksesta tai tarkistaa päätepistettä, jossa rajoitusta ei ole.
Näin pyyntörajoitus toimii
RFC 6585 määrittelee koodin 429, mutta jättää säännöt kunkin palvelimen päätettäviksi. Rajoituksessa on kolme osaa:
Ketä lasketaan: IP-osoitetta, API-avainta, käyttäjätiliä tai näiden yhdistelmää. IP-kohtaiset rajoitukset laskevat kaikki saman osoitteen takana olevat yhteen.
Mitä lasketaan: kaikkia pyyntöjä tai vain osaa niistä, kuten kirjautumisia, hakuja tai raskasta API-päätepistettä, usein tiukemmalla rajalla.
Miten aikaa lasketaan: kiinteä ikkuna nollautuu tasaminuutein; liukuva ikkuna katsoo viimeisiä 60 sekuntia; token bucket täyttyy tasaisella tahdilla ja sallii lyhyet purskeet kokonsa verran.
Vastaus kertoo usein, missä mennään:
HTTP/2 429
retry-after: 30
x-ratelimit-limit: 100
x-ratelimit-remaining: 0
x-ratelimit-reset: 1793091600
Retry-After on standardi, ja sen arvo on joko sekuntimäärä tai HTTP-päivämäärä. X-RateLimit-*-otsakkeet ovat yleinen käytäntö eivätkä standardi, ja niiden merkitys vaihtelee: reset voi olla Unix-aika tai sekuntimäärä, joten lue API:n dokumentaatio. IETF:n luonnos määrittelee standardit RateLimit- ja RateLimit-Policy-kentät, joita osa API:sta on alkanut lähettää.
Mistä 429-virheet tulevat
Kutsumasi kolmannen osapuolen API:t, kuten maksu-, sähköposti-, kartta- tai chat-palvelut, jotka rajoittavat jokaista avainta tai tiliä.
Oma API-yhdyskäytäväsi tai sovelluskehyksesi pyyntörajoituksen välikerroksen kautta.
Verkkopalvelimesi. nginxin limit_req vastaa oletuksena 503; aseta limit_req_status 429, jotta asiakasohjelmat tietävät hidastaa eivätkä oleta katkoa.
CDN:t ja WAF:t pyyntörajoitussääntöjen kautta. Säännöstä riippuen vastaus on 429, 403 tai haastesivu.
Kirjautumisen ja lomakkeiden suojaus julkaisujärjestelmässä tai tietoturvalisäosassa, joka rajoittaa yrityksiä osoitetta kohden.
429:n käsittely asiakasohjelmassa
Noudata Retry-Afteria. Odota vähintään sen ilmoittama aika. Aiempi uusi yritys saa yleensä uuden 429:n ja voi pidentää estoa.
Pidennä viivettä eksponentiaalisesti ja lisää satunnaisuutta. Ilman Retry-Afteria odota jokaisen epäonnistumisen jälkeen pidempään, esimerkiksi 1, 2, 4 ja 8 sekuntia, ja lisää satunnainen osa, jotteivät monet asiakasohjelmat yritä uudelleen samalla hetkellä.
Rajoita uusintayrityksiä. Muutaman yrityksen jälkeen luovuta ja raportoi virhe tai siirrä työ jonoon myöhemmäksi.
Lähetä vähemmän pyyntöjä. Tallenna vastauksia välimuistiin, käytä eräpäätepisteitä, pyydä isompia sivuja ja käytä webhookeja kyselyjen sijaan, jos API tarjoaa niitä.
Hajauta ajastetut työt. Tasatunnein käynnistyvät cron-jobit osuvat rajoihin yhtä aikaa; porrasta niitä muutamalla minuutilla. Opas cron-lausekkeisiin näyttää miten.
async function fetchWithBackoff(url, options = {}, attempts = 5) {
for (let attempt = 0; attempt < attempts; attempt++) {
const response = await fetch(url, options);
if (response.status !== 429) return response;
const retryAfter = Number(response.headers.get(’retry-after’));
const wait = retryAfter > 0 ? retryAfter * 1000 : 2 ** attempt * 1000 + Math.random() * 1000;
await new Promise((resolve) => setTimeout(resolve, wait));
}
throw new Error(’Still rate limited after ’ + attempts + ’ attempts’);
}
Tämä luonnos lukee Retry-After-arvon vain sekunteina; tuotantokoodin pitää hyväksyä myös päivämäärämuoto.
Pyyntörajoitukset omalle sivustolle
Vastaa 429, älä 503 tai 403. 503 näyttää katkolta ja 403 pysyvältä kieltäytymiseltä; 429 kertoo asiakasohjelmille ja valvontatyökaluille tarkalleen, mitä tapahtui.
Lähetä Retry-After, jotta asiakasohjelmien ei tarvitse arvata.
Rajoita avaimen tai tilin mukaan, kun voit. IP-kohtaiset rajoitukset rankaisevat toimistoja, kouluja ja mobiiliverkkoja, joissa moni jakaa saman osoitteen.
Salli purskeet. Yksi sivunlataus voi tehdä kymmeniä pyyntöjä kerralla; token bucket, jossa on tilaa purskeelle, välttää tavallisten kävijöiden estämisen.
Vapauta valvontasi rajoituksesta tai anna sille oma rajoittamaton health check -päätepiste.
# nginx: 10 requests a second per address, bursts of 20, answered with 429
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
server {
location /api/ {
limit_req zone=api burst=20 nodelay;
limit_req_status 429;
}
}
Miksi käytettävyyden valvonta voi saada 429:n
Yksi tarkistus minuutissa kuulostaa harmittomalta, mutta määrä kertyy tavoilla, jotka on helppo ohittaa:
Useita valvontoja samalla palvelimella. Kymmenen valvontaa samassa API:ssa, kukin minuutin välein, tekee kymmenen pyyntöä minuutissa samalta asiakasohjelmalta, ja lisäksi vahvistavat uusintatarkistukset, kun jokin epäonnistuu.
Tiukat rajat tarkistetulla polulla. Kirjautumissivut, haku ja lomakkeiden päätepisteet sallivat usein vain muutaman pyynnön minuutissa osoitetta kohden.
Jaetut osoitteet. Valvontapalvelun tarkistukset tulevat muutamasta tunnetusta osoitteesta. IP-kohtainen rajoitus laskee kaikki saman osoitteen tarkistukset yhteen, myös muiden käyttäjien tarkistukset samaan julkiseen sivustoon tai API:in.
Bottisääntö, joka rajoittaa pyyntöjä. Jotkin palomuurit laskevat automaattiset asiakasohjelmat erikseen ja rajoittavat niitä tiukemmin kuin selaimia.
Mitä tehdä, tässä järjestyksessä: vapauta valvonta rajoituksesta sen IP-osoitteiden perusteella, valvo rajoittamatonta health-päätepistettä, tarkista harvemmin tai yhdistä samaan API:in osuvat valvonnat. Älä hyväksy 429:ää kaikkialla toimivaksi, sillä raja, joka alkaa estää todellisia käyttäjiäsi, on syytä tietää. HTTP-tilakoodit valvonnassa kertoo, mitkä koodit kannattaa käsitellä virheinä, ja API-valvonnan tarkistuslista, mitä muuta API:ssa kannattaa seurata.
429-virheet ja Uptimecheck
Uptimecheckin käytettävyyden valvonnassa ja API-valvonnassa 429 on oletuksena odotettujen tilakoodien (200–399) ulkopuolella, joten se lasketaan katkoksi, kun toinen tarkistus vahvistaa sen. Kun palvelin vastaa pelkällä 429:llä, häiriö kertoo, että tarkistuksiamme rajoitetaan, lainaa Retry-After-arvon, jos palvelin lähetti sen, ja ehdottaa vapauttamaan pyynnöt, joiden user agent sisältää sanan “Uptimecheck”, tarkistamaan harvemmin tai käyttämään päätepistettä ilman rajoitusta. Tarkistukset tehdään Tukholmasta, Ruotsista; Uptimecheckin salliminen palomuurissa listaa vapautettavat osoitteet sääntöineen Cloudflarelle, sen pyyntörajoitussäännöt mukaan lukien, ja nginxille. Valitset jokaisen valvonnan tarkistusvälin minuutista tuntiin.
Uptimecheck noudattaa samoja sääntöjä lähettäessään hälytyksiäsi. Jos Slack, Microsoft Teams, Discord tai PagerDuty vastaa 429, hälytys yritetään uudelleen 30 sekunnin, 2 minuutin, 10 minuutin ja 30 minuutin jälkeen, eikä koskaan aiemmin kuin palvelun Retry-After pyytää, enintään tunnin ajan. Katso miksi hälytykset eivät ehkä tule perille, niin näet, mitä tapahtuu, kun kanava epäonnistuu toistuvasti.
Erota pyyntörajoitus katkosta. Kokeile Uptimecheckiä ilmaiseksi 14 päivää, luottokorttia ei tarvita.