A sebességkorlát korlátozza, hogy egy kliens hány kérést tehet egy időablakban. Több rétegben alkalmázod, mivel mindegyik mást lát, és a bűnös azonosítására alkalmas érték alapján kulcsozod.
A sebességkorlát korlátozza, hogy egy kliens hány kérést tehet egy időablakban. Több rétegben alkalmázod, mivel mindegyik mást lát, és a bűnös azonosítására alkalmas érték alapján kulcsozod.
429 Too Many Requests értékkel a Retry-After fejléccel így a kliensek udvariasan visszalépnek ahelyett, hogy üthetnének.# 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;
}
}
Itt minden IP 10 kérés/másodperc sebességgel töltődik fel, legfeljebb 20-as sorokkal, és bármi azon túl egy 429 értéket kap.
A sebességkorlát a legolcsóbb, állandóan bekapcsolt védelmed a 7. rétegbeli árvíz, hitelesítési adatok ellopása és futó scrapisták ellen. A rétegezés (edge a térfogathoz, proxy az originálhoz, app az üzleti logikához) és a helyes kulcsozás leállítja a bűnösöket, miközben az igazi felhasználók — és a legitim sorok — áthaladnak érintetlenül. A valós alapvonalakból származó korlátok beállítása az, ami megakadályozza, hogy saját katasztrófa legyen.