עודכן לפני חודש
שגיאת 429 Too Many Requests היא הדרך שבה האינטרנט אומר: "אני משאב משותף, ויש לי גבולות."
כשאתה נתקל בשגיאת 429, השרת הבין את בקשתך בדיוק. הוא פשוט סירב לעבד אותה כי שלחת יותר מדי בקשות מהר מדי. זה לא באג ולא תצורה שגויה — זו מגבלה מכוונת. הגבלת קצב קיימת כי שרתים הם משאבים משותפים, ובלי מגבלות, לקוח אחד חמדן יכול לקלקל את החוויה לכולם.
תחשוב על זה כמו דלפק של מעדנייה. אתה לוקח מספר, מחכה לתורך. אם מישהו ניסה לבצע 100 הזמנות בדקה, הצוות היה בסופו של דבר אומר "האט" — למען כולם שבתור.
איך נראית תגובת 429
הכותרת החשובה ביותר היא Retry-After. היא אומרת לך בדיוק מתי מותר לנסות שוב. לקוח מסודר מכבד אותה; לקוח אגרסיבי שמתעלם ממנה מסתכן בחסימה מוחלטת.
הכותרות שמספרות לך היכן אתה עומד
APIs טובים לא רק דוחים אותך — הם מסבירים למה ומתי תהיה מוזמן שוב:
| כותרת | משמעות |
|---|---|
X-RateLimit-Limit | המכסה שלך (למשל, 100 בקשות לדקה) |
X-RateLimit-Remaining | כמה בקשות נותרו לך |
X-RateLimit-Reset | חותמת זמן Unix שבה המכסה מתאפסת |
Retry-After | שניות (או תאריך) עד שאפשר לנסות שוב |
לקוחות חכמים עוקבים אחרי כותרות אלה מראש. למה לחכות לשגיאת 429 כשאפשר לראות אותה מגיעה?
מדוע אתה מוגבל בקצב
אתה שולח בקשות מהר מדי. רוב הגבלות הקצב הן "X בקשות ל-Y זמן". חרוג מהן, וכל בקשה נוספת תידחה עד שהחלון מתאפס.
אתה שולח בפרצים. ל-APIs מסוימים יש מגבלות פרץ נפרדות — אולי 100 בקשות לדקה בסך הכל, אבל לא יותר מ-10 בשנייה בודדת. זה מונע עומסי שיא פתאומיים.
יש לך יותר מדי בקשות בו-זמניות. שירותים מסוימים מגבילים כמה בקשות יכולות להיות בטיפול בו-זמנית. שש בקשות מקביליות כשהמגבלה היא חמש? השישית מקבלת 429.
טיפול בשגיאות 429 בקוד שלך
הדרך הלא נכונה:
הדרך הנכונה:
עוד יותר טוב — עקוב אחרי המגבלות שלך והימנע מלהגיע אליהן:
יישום הגבלת קצב בשרת שלך
הגישה הפשוטה ביותר עם Express:
עבור מערכות ייצור, השתמש ב-Redis כדי שהמגבלות יישמרו לאחר הפעלה מחדש של השרת ויפעלו על פני מופעים מרובים:
מגבלות שונות למשתמשים שונים
לא כל המשתמשים שווים. לקוח משלם ראוי לקיבולת גבוהה יותר מאשר סורק אנונימי:
תעד את המגבלות האלה בבירור. הפתעות מתסכלות. משתמשים צריכים לדעת את המכסה שלהם לפני שהם פוגעים בה.
אסטרטגיות הגבלת קצב
חלון קבוע: ספור בקשות לפי דקה לפי לוח השנה (00:00-00:59, 01:00-01:59). פשוט, אבל מאפשר פרצים בגבולות — לקוח יכול לשלוח 100 בקשות ב-00:59 ועוד 100 ב-01:00.
חלון הזזה: ספור בקשות ב-60 השניות האחרונות, תמיד. חלק יותר אבל קשה יותר ליישום.
דלי אסימונים: אסימונים מצטברים בקצב קבוע; כל בקשה עולה אסימון אחד. מאפשר פרצים מבוקרים תוך שמירה על מגבלות כוללות.
דלי דולף: בקשות נכנסות לתור ומתנקזות בקצב קבוע. התעבורה החלקה ביותר, אבל מוסיף השהייה.
עבור רוב ה-APIs, חלון הזזה או דלי אסימונים מוצאים את האיזון הטוב ביותר בין הוגנות למורכבות היישום.
שאלות נפוצות על 429 בקשות רבות מדי
מדוע אני מקבל שגיאות 429 כשאני בקושי משתמש ב-API?
ייתכן שאתה חולק הגבלת קצב עם משתמשים אחרים. APIs רבים מגבילים לפי כתובת IP, כך שאם אתה מאחורי NAT ארגוני או פרוקסי משותף, אתה מתחרה עם כולם שמשתמשים באותה IP. אמת את הבקשות שלך — רוב ה-APIs מעניקים למשתמשים מאומתים מכסה עצמאית.
האם כדאי לנסות שוב מיד כשאני מקבל 429?
לא. זה הדבר הגרוע ביותר שאפשר לעשות. השרת בדיוק ביקש ממך להאט; להציף אותו בניסיונות חוזרים יביא כנראה לחסימה מוחלטת. המתן תמיד לפחות כמה שצוין בכותרת Retry-After. אם אין כותרת, השתמש ב-exponential backoff.
מה ההבדל בין 429 ל-503?
שגיאת 429 אומרת שאתה ספציפית שולח יותר מדי בקשות. שגיאת 503 אומרת שהשרת עמוס ואינו יכול לטפל בבקשות של אף אחד כרגע. שניהם מרמזים שכדאי לנסות שוב מאוחר יותר, אבל 429 היא אישית — אתה צריך להאט. 503 אומרת שכולם צריכים לחכות.
האם דף זה היה מועיל?