429 Too Many Requests betyder, at serveren rate limiter dig: klienten har sendt flere requests i en periode, end serveren tillader, og bør vente, før den prøver igen. Intet er gået i stykker, og det gør det kun værre at gentage requesten med det samme. En velopdragen server fortæller, hvor længe du skal vente, i en Retry-After-header; en velopdragen klient venter mindst så længe og bakker uden en sådan header ud med stigende pauser. Når en monitor rammer en 429, er den typiske løsning at undtage monitoren fra grænsen eller tjekke et endpoint uden grænse.
Sådan virker rate limiting
RFC 6585 definerer 429, men overlader reglerne til hver enkelt server. En grænse har tre dele:
Hvem der tælles: en IP-adresse, en API-nøgle, en brugerkonto eller en kombination. Grænser pr. IP tæller alle bag den samme adresse sammen.
Hvad der tælles: alle requests eller kun nogle, fx logins, søgninger eller et ressourcetungt API-endpoint, ofte med en strengere grænse.
Hvordan tiden tælles: et fast vindue nulstilles hvert minut; et glidende vindue ser på de seneste 60 sekunder; en token bucket fyldes op i et jævnt tempo og tillader korte bursts op til sin størrelse.
Svaret fortæller 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 antal sekunder eller en HTTP-dato. X-RateLimit-*-headerne er en udbredt konvention snarere end en standard, og deres betydning varierer: reset kan være et Unix-tidspunkt eller et antal sekunder, så læs API’ets dokumentation. Et IETF-udkast definerer standardfelterne RateLimit og RateLimit-Policy, som nogle API’er er begyndt at sende.
Hvor 429-fejl kommer fra
Tredjeparts-API’er, du kalder, fx betalings-, e-mail-, kort- eller chattjenester, som begrænser hver nøgle eller konto.
Din egen API-gateway eller dit framework, via middleware til rate limiting.
Din webserver. nginx’ limit_req svarer som standard 503; sæt limit_req_status 429, så klienter ved, at de skal sætte tempoet ned i stedet for at antage et nedbrud.
CDN’er og WAF’er, via regler for rate limiting. Afhængigt af reglen er svaret en 429, en 403 eller en challenge-side.
Beskyttelse af login og formularer i et CMS eller et sikkerhedsplugin, som begrænser antallet af forsøg pr. adresse.
Sådan håndterer du en 429 som klient
Respektér Retry-After. Vent mindst så længe, som den siger. Prøver du igen før, får du som regel endnu en 429 og kan forlænge en blokering.
Bak eksponentielt ud, med jitter. Uden Retry-After venter du længere efter hver fejl, fx 1, 2, 4 og 8 sekunder, plus en tilfældig del, så mange klienter ikke prøver igen på samme tid.
Begræns antallet af genforsøg. Giv op efter nogle få forsøg og rapportér fejlen, eller læg arbejdet i en kø til senere.
Send færre requests. Cache svar, brug batch-endpoints, bed om større sider, og brug webhooks i stedet for polling, hvor API’et har dem.
Spred planlagte jobs. Cron-jobs, der alle starter på hele timen, rammer grænserne samtidig; forskyd dem med et par minutter. Guiden til cron-udtryk 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 skitse læser kun Retry-After som sekunder; kode i produktion bør også acceptere datoformen.
Sådan sætter du rate limits på dit eget site
Svar 429, ikke 503 eller 403. En 503 ligner et nedbrud og en 403 en permanent afvisning; en 429 fortæller klienter og overvågningsværktøjer præcis, hvad der skete.
Send Retry-After, så klienter ikke skal gætte.
Begræns pr. nøgle eller konto, hvor du kan. Grænser pr. IP rammer kontorer, skoler og mobilnetværk, hvor mange deler den samme adresse.
Tillad bursts. En sidevisning kan sende snesevis af requests på én gang; en token bucket med plads til et burst undgår at blokere almindelige besøgende.
Undtag din overvågning, eller giv den sit eget health check-endpoint uden grænse.
# 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 ramme en 429
Ét tjek i minuttet lyder harmløst, men det løber op på måder, der er lette at overse:
Flere monitorer på samme host. Ti monitorer på det samme API, der hver tjekker hvert minut, er ti requests i minuttet fra den samme klient plus de bekræftende gentjek, når noget fejler.
Strenge grænser på den tjekkede sti. Login-sider, søgning og formular-endpoints tillader ofte kun få requests i minuttet pr. adresse.
Delte adresser. En overvågningstjenestes tjek kommer fra nogle få kendte adresser. En grænse pr. IP tæller alle tjek fra den adresse sammen, også andre brugeres tjek af det samme offentlige site eller API.
En bot-regel, der rate limiter. Nogle firewalls tæller automatiserede klienter for sig og begrænser dem hårdere end browsere.
Hvad du skal gøre, i rækkefølge: undtag monitoren fra grænsen ud fra dens IP-adresser, overvåg et health-endpoint uden grænse, tjek sjældnere, eller slå monitorer sammen, der rammer det samme API. Acceptér ikke 429 som oppe over hele linjen, for en grænse, der begynder at blokere dine rigtige brugere, er værd at vide om. HTTP-statuskoder i overvågning gennemgår, hvilke koder der skal behandles som fejl, og tjeklisten til API-overvågning, hvad du ellers skal holde øje med på et API.
429-fejl og Uptimecheck
I Uptimechecks oppetidsovervågning og API-overvågning ligger en 429 uden for de forventede standardstatusser (200 til 399), så den tæller som nede, når et ekstra tjek har bekræftet den. Når serveren svarer med en ren 429, fortæller hændelsen, at vores tjek bliver rate limited, gengiver Retry-After-værdien, når serveren sendte en, og foreslår at undtage requests, hvis user agent indeholder “Uptimecheck”, at tjekke sjældnere eller at bruge et endpoint uden grænsen. Tjek kører fra Stockholm i Sverige; sådan tillader du Uptimecheck gennem en firewall viser de adresser, du skal undtage, med regler til Cloudflare, også dets regler for rate limiting, og til nginx. Du vælger hver monitors interval, fra hvert minut til hver time.
Uptimecheck følger de samme regler, når den sender dine alarmer. Hvis Slack, Microsoft Teams, Discord eller PagerDuty svarer 429, sendes alarmen igen efter 30 sekunder, 2 minutter, 10 minutter og 30 minutter, og aldrig før tjenestens Retry-After beder om, op til en time. Se hvorfor alarmer måske ikke kommer frem for, hvad der sker, når en kanal bliver ved med at fejle.
Skeln en rate limit fra et nedbrud. Prøv Uptimecheck gratis i 14 dage, uden kreditkort.