429 Too Many Requests betyr at serveren begrenser antall forespørsler fra deg (rate limiting): klienten har sendt flere forespørsler i en periode enn serveren tillater, og bør vente før den prøver igjen. Ingenting er ødelagt, og å gjenta forespørselen med en gang gjør det bare verre. En veloppdragen server sier hvor lenge du skal vente, i en Retry-After-header; en veloppdragen klient venter minst så lenge, og uten headeren trapper den ned med stadig lengre pauser. Når en monitor får en 429, er den vanlige løsningen å unnta monitoren fra grensen eller å sjekke et endepunkt uten grense.
Slik fungerer rate limiting
RFC 6585 definerer 429, men overlater reglene til hver enkelt server. En grense har tre deler:
Hvem som telles: en IP-adresse, en API-nøkkel, en brukerkonto eller en kombinasjon. Grenser per IP teller alle bak samme adresse under ett.
Hva som telles: alle forespørsler, eller bare noen, som innlogginger, søk eller et kostbart API-endepunkt, ofte med en strengere grense.
Hvordan tiden telles: et fast vindu nullstilles hvert minutt; et glidende vindu ser på de siste 60 sekundene; en token bucket fylles på i jevnt tempo og tillater korte topper opp til størrelsen sin.
Svaret forteller deg ofte hvor du står:
HTTP/2 429
retry-after: 30
x-ratelimit-limit: 100
x-ratelimit-remaining: 0
x-ratelimit-reset: 1793091600
Retry-After er standard og er enten et antall sekunder eller en HTTP-dato. X-RateLimit-*-headerne er en vanlig konvensjon, ikke en standard, og betydningen varierer: reset kan være et Unix-tidspunkt eller et antall sekunder, så les dokumentasjonen til API-et. Et IETF-utkast definerer standardfeltene RateLimit og RateLimit-Policy, som enkelte API-er har begynt å sende.
Hvor 429-feil kommer fra
Tredjeparts-API-er du kaller, som tjenester for betaling, e-post, kart eller chat, som begrenser hver nøkkel eller konto.
Din egen API-gateway eller ditt eget rammeverk, gjennom middleware for rate limiting.
Webserveren din. nginx’ limit_req svarer 503 som standard; sett limit_req_status 429 så klientene skjønner at de skal sette ned tempoet i stedet for å anta at tjenesten er nede.
CDN-er og WAF-er, gjennom regler for rate limiting. Avhengig av regelen er svaret en 429, en 403 eller en utfordringsside.
Beskyttelse av innlogging og skjemaer i et CMS eller en sikkerhetsutvidelse, som begrenser antall forsøk per adresse.
Slik håndterer du en 429 som klient
Respekter Retry-After. Vent minst så lenge som den sier. Prøver du igjen tidligere, får du som regel en ny 429, og en blokkering kan bli forlenget.
Trapp ned eksponentielt, med jitter. Uten Retry-After venter du lenger etter hver feil, for eksempel 1, 2, 4 og 8 sekunder, pluss en tilfeldig del, så ikke mange klienter prøver igjen i samme øyeblikk.
Begrens antall nye forsøk. Etter noen forsøk gir du opp og rapporterer feilen, eller legger jobben i en kø til senere.
Send færre forespørsler. Mellomlagre svar, bruk batch-endepunkter, be om større sider og bruk webhooks i stedet for polling der API-et har det.
Spre planlagte jobber. Cron-jobber som alle starter på hel time, treffer grensene samtidig; forskyv dem med noen minutter. Guiden til cron-uttrykk viser hvordan.
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’);
}
Denne skissen leser bare Retry-After som sekunder; kode i produksjon bør også godta datoformen.
Slik setter du grenser på ditt eget nettsted
Svar 429, ikke 503 eller 403. En 503 ser ut som nedetid og en 403 som en permanent avvisning; en 429 forteller klienter og overvåkingsverktøy nøyaktig hva som skjedde.
Send Retry-After, så klientene slipper å gjette.
Begrens per nøkkel eller konto der du kan. Grenser per IP rammer kontorer, skoler og mobilnett der mange deler én adresse.
Tillat topper. En sidevisning kan sende dusinvis av forespørsler på én gang; en token bucket med rom for topper unngår at vanlige besøkende blir blokkert.
Unnta overvåkingen din, eller gi den sitt eget health check-endepunkt uten grense.
# 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;
}
}
Hvorfor en oppetidsmonitor kan få en 429
Én sjekk i minuttet høres harmløst ut, men det summerer seg på måter som er lette å overse:
Flere monitorer på samme vert. Ti monitorer på samme API som hver sjekker hvert minutt, er ti forespørsler i minuttet fra samme klient, pluss de bekreftende sjekkene når noe feiler.
Strenge grenser på stien som sjekkes. Innloggingssider, søk og skjemaendepunkter tillater ofte bare noen få forespørsler i minuttet per adresse.
Delte adresser. Sjekkene fra en overvåkingstjeneste kommer fra noen få kjente adresser. En grense per IP teller alle sjekker fra den adressen under ett, også andre brukeres sjekker av det samme offentlige nettstedet eller API-et.
En bot-regel som begrenser tempoet. Noen brannmurer teller automatiserte klienter for seg og begrenser dem hardere enn nettlesere.
Hva du gjør, i denne rekkefølgen: unnta monitoren fra grensen etter IP-adressene, overvåk et health-endepunkt uten grense, sjekk sjeldnere, eller slå sammen monitorer som treffer samme API. Ikke godta 429 som oppe over hele linja, for en grense som begynner å blokkere de faktiske brukerne dine, er verdt å vite om. HTTP-statuskoder i overvåking forklarer hvilke koder du bør behandle som feil, og sjekklisten for API-overvåking hva mer du bør følge med på i et API.
429-feil og Uptimecheck
I Uptimechecks oppetidsovervåking og API-overvåking ligger 429 utenfor de forventede standardstatusene (200 til 399), så den regnes som nede når en ny sjekk har bekreftet den. Når serveren svarer med en ren 429, sier hendelsen at sjekkene våre blir begrenset, siterer Retry-After-verdien når serveren sendte en, og foreslår å unnta forespørsler med en user agent som inneholder «Uptimecheck», å sjekke sjeldnere eller å bruke et endepunkt uten grensen. Sjekkene kjører fra Stockholm i Sverige; slik slipper du Uptimecheck gjennom en brannmur viser adressene du skal unnta, med regler for Cloudflare, inkludert reglene for rate limiting der, og for nginx. Du velger intervallet for hver monitor, fra hvert minutt til hver time.
Uptimecheck følger de samme reglene når vi sender varslene dine. Hvis Slack, Microsoft Teams, Discord eller PagerDuty svarer 429, prøves varselet på nytt etter 30 sekunder, 2 minutter, 10 minutter og 30 minutter, og aldri tidligere enn tjenestens Retry-After ber om, opptil en time. Se hvorfor varsler kanskje ikke kommer frem for hva som skjer når en kanal fortsetter å feile.
Skill en rate limit fra ekte nedetid. Prøv Uptimecheck gratis i 14 dager, uten kredittkort.