Rate limiting จำกัดจำนวนคำขอที่ client ทำได้ในช่วงเวลาหนึ่ง คุณนำมันไปใช้ที่ หลายชั้น เพราะแต่ละชั้นเห็นสิ่งที่ต่างกัน และคุณ key มันด้วย สิ่งที่ระบุตัวผู้ก่อกวน
Rate limiting จำกัดจำนวนคำขอที่ client ทำได้ในช่วงเวลาหนึ่ง คุณนำมันไปใช้ที่ หลายชั้น เพราะแต่ละชั้นเห็นสิ่งที่ต่างกัน และคุณ key มันด้วย สิ่งที่ระบุตัวผู้ก่อกวน
429 Too Many Requests พร้อม Retry-After เพื่อให้ client back off อย่างสุภาพแทนที่จะกระหน่ำ# 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;
}
}
ที่นี่แต่ละ IP เติมที่ 10 requests/second อาจ burst ได้ถึง 20 และอะไรก็ตามที่เกินจะได้ 429
Rate limiting คือการป้องกันที่ถูกที่สุดและทำงานตลอดเวลาต่อ Layer 7 flood, credential stuffing, และ scraper ที่ควบคุมไม่ได้ การจัดชั้นมัน (edge สำหรับปริมาณ, proxy สำหรับ origin, app สำหรับ business logic) และ key อย่างถูกต้องหยุดผู้ก่อกวนในขณะที่ผู้ใช้จริง — และ burst ที่ชอบธรรม — ผ่านไปได้โดยไม่ถูกแตะต้อง การตั้ง limit จาก baseline จริงคือสิ่งที่ทำให้มันไม่กลายเป็น outage ที่คุณก่อขึ้นเอง