Rate limiting begrenser hvor mange forespørsler en klient kan gjøre i et tidsvindu. Du bruker det på flere lag fordi hvert lag ser noe ulikt, og du nøkler det etter hva som helst som identifiserer misbrukeren.
Rate limiting begrenser hvor mange forespørsler en klient kan gjøre i et tidsvindu. Du bruker det på flere lag fordi hvert lag ser noe ulikt, og du nøkler det etter hva som helst som identifiserer misbrukeren.
429 Too Many Requests med Retry-After slik at klienter trekker seg politt tilbake i stedet for å hamre.# Define a shared-memory zone keyed by client IP.
# rate=10r/s = the steady refill rate (token bucket).
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
server {
location /api/ {
# burst=20: allow a short spike of 20 queued requests
# nodelay: serve the burst immediately instead of spacing it out
limit_req zone=api burst=20 nodelay;
# Return 429 (not the default 503) so clients see a rate-limit signal
limit_req_status 429;
proxy_pass http://backend;
}
}
Her fylles hver IP på nytt med 10 forespørsler/sekund, kan sprekke opp til 20, og alt utover får en 429.
Rate limiting er ditt billigste, alltid-på forsvar mot Layer 7-oversvømmelser, credential stuffing, og løpende skrapere. Lagdeling av det (edge for volum, proxy for serveren, app for forretningslogikk) og riktig nøkling stopper misbrukere mens virkelige brukere — og legitime sprekker — passerer gjennom uskadet. Innstilling av grenser fra virkelige baselines er det som holder det fra å bli en avbrudd du har laget selv.