429 Too Many Requests betyder att servern begränsar dig: klienten har skickat fler förfrågningar under en period än servern tillåter och bör vänta innan den försöker igen. Inget är trasigt, och att upprepa förfrågan direkt gör det värre. En väluppfostrad server anger hur länge du ska vänta i en Retry-After-header; en väluppfostrad klient väntar minst så länge, och utan headern backar den av med allt längre pauser. När en monitor får en 429 är den vanliga lösningen att undanta monitorn från gränsen eller att kontrollera en endpoint utan gräns.
Så fungerar rate limiting
RFC 6585 definierar 429 men lämnar reglerna åt varje server. En gräns har tre delar:
Vem som räknas: en IP-adress, en API-nyckel, ett användarkonto eller en kombination. Gränser per IP räknar alla bakom samma adress tillsammans.
Vad som räknas: alla förfrågningar eller bara vissa, som inloggningar, sökningar eller en kostsam API-endpoint, ofta med en strängare gräns.
Hur tiden räknas: ett fast fönster nollställs varje hel minut; ett glidande fönster tittar på de senaste 60 sekunderna; en token bucket fylls på i jämn takt och tillåter korta toppar upp till sin storlek.
Svaret berättar ofta var du står:
HTTP/2 429
retry-after: 30
x-ratelimit-limit: 100
x-ratelimit-remaining: 0
x-ratelimit-reset: 1793091600
Retry-After är standard och är antingen ett antal sekunder eller ett HTTP-datum. X-RateLimit-*-headers är en vanlig konvention snarare än en standard, och betydelsen varierar: reset kan vara en Unix-tid eller ett antal sekunder, så läs API:ets dokumentation. Ett IETF-utkast definierar standardfälten RateLimit och RateLimit-Policy, som vissa API:er har börjat skicka.
Var 429-svar kommer ifrån
Tredjeparts-API:er som du anropar, som tjänster för betalningar, e-post, kartor eller chatt, som begränsar varje nyckel eller konto.
Din egen API-gateway eller ditt ramverk, via middleware för rate limiting.
Din webbserver. nginx limit_req svarar 503 som standard; sätt limit_req_status 429 så att klienterna vet att de ska sakta ner i stället för att anta att det är ett avbrott.
CDN:er och WAF:er, via regler för rate limiting. Beroende på regeln blir svaret en 429, en 403 eller en utmaningssida.
Skydd för inloggning och formulär i ett CMS eller ett säkerhetsplugin, som begränsar antalet försök per adress.
Så hanterar du en 429 som klient
Respektera Retry-After. Vänta minst så länge som den anger. Att försöka tidigare ger oftast en ny 429 och kan förlänga en blockering.
Backa av exponentiellt, med jitter. Utan Retry-After väntar du längre efter varje misslyckande, till exempel 1, 2, 4 och 8 sekunder, plus en slumpmässig del, så att många klienter inte försöker igen i samma ögonblick.
Begränsa antalet nya försök. Ge upp efter några försök och rapportera felet, eller lägg arbetet i en kö till senare.
Skicka färre förfrågningar. Cacha svar, använd batch-endpoints, be om större sidor och använd webhooks i stället för polling där API:et har det.
Sprid ut schemalagt arbete. Cron-jobb som alla startar på hela timmen slår i gränserna samtidigt; förskjut dem några minuter. Guiden till cron-uttryck visar hur.
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’);
}
Den här skissen läser bara Retry-After som sekunder; produktionskod bör även hantera datumformen.
Så sätter du rate limits på din egen sajt
Svara 429, inte 503 eller 403. En 503 ser ut som ett avbrott och en 403 som ett permanent nej; en 429 talar om för klienter och övervakningsverktyg exakt vad som hände.
Skicka Retry-After, så att klienterna inte behöver gissa.
Begränsa per nyckel eller konto där det går. Gränser per IP straffar kontor, skolor och mobilnät där många delar samma adress.
Tillåt toppar. En sidladdning kan göra dussintals förfrågningar på en gång; en token bucket med utrymme för toppar undviker att vanliga besökare blockeras.
Undanta din övervakning, eller ge den en egen health check-endpoint utan gräns.
# 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;
}
}
Därför kan en upptidsövervakning få en 429
En kontroll i minuten låter harmlöst, men det blir mer än man tror på sätt som är lätta att missa:
Flera monitorer på samma värd. Tio monitorer mot samma API, som var och en kontrollerar varje minut, blir tio förfrågningar i minuten från samma klient, plus de bekräftande omkontrollerna när något fallerar.
Strikta gränser på den kontrollerade sökvägen. Inloggningssidor, sökning och formulär-endpoints tillåter ofta bara några få förfrågningar i minuten per adress.
Delade adresser. En övervakningstjänsts kontroller kommer från ett fåtal kända adresser. En gräns per IP räknar alla kontroller från den adressen tillsammans, även andra användares kontroller av samma publika sajt eller API.
En bot-regel som begränsar. Vissa brandväggar räknar automatiserade klienter för sig och begränsar dem hårdare än webbläsare.
Gör så här, i tur och ordning: undanta monitorn från gränsen via dess IP-adresser, övervaka en health-endpoint som saknar gräns, kontrollera mer sällan eller slå ihop monitorer som träffar samma API. Godta inte 429 som uppe över hela linjen, eftersom en gräns som börjar blockera dina riktiga användare är värd att känna till. HTTP-statuskoder i övervakning tar upp vilka koder som ska räknas som fel, och checklistan för API-övervakning vad mer du bör hålla koll på i ett API.
429-svar och Uptimecheck
I Uptimechecks upptidsövervakning och API-övervakning ligger 429 utanför de förväntade statusarna som standard (200 till 399), så den räknas som nere när en andra kontroll har bekräftat den. När servern svarar med en ren 429 anger incidenten att våra kontroller begränsas, citerar Retry-After-värdet när servern skickade ett och föreslår att du undantar förfrågningar vars user agent innehåller ”Uptimecheck”, kontrollerar mer sällan eller använder en endpoint utan gränsen. Kontrollerna körs från Stockholm; så släpper du igenom Uptimecheck i en brandvägg listar adresserna att undanta, med regler för Cloudflare, även dess regler för rate limiting, och för nginx. Du väljer intervall för varje monitor, från varje minut till varje timme.
Uptimecheck följer samma regler när vi skickar dina larm. Om Slack, Microsoft Teams, Discord eller PagerDuty svarar 429 skickas larmet igen efter 30 sekunder, 2 minuter, 10 minuter och 30 minuter, och aldrig tidigare än tjänstens Retry-After begär, upp till en timme. Läs varför larm kanske inte kommer fram för vad som händer när en kanal fortsätter att fallera.
Skilj en rate limit från ett avbrott. Prova Uptimecheck gratis i 14 dagar, inget kreditkort krävs.