429 Too Many Requests: הגבלת קצב — כשהיא מגינה וכשהיא חוסמת בטעות

429 Too Many Requests הוא קוד תשובה שאומר: שלחת יותר מדי בקשות בפרק זמן קצר, האט. לפי MDN, המנגנון הזה נקרא "הגבלת קצב" (rate limiting), והשרת יכול לצרף לתשובה כותרת Retry-After שאומרת כמה זמן לחכות לפני שמנסים שוב. בניגוד לשגיאות 5xx, 429 היא לא תקלה — היא הגנה שעובדת. השאלה היא רק אם היא עובדת על מי שצריך: על בוט שמפציץ את האתר, או בטעות על גולש אמיתי, על Googlebot, או על אינטגרציה שהעסק שלכם תלוי בה.

שני צדדים של אותה שגיאה

אתר של עסק פוגש 429 בשני תפקידים, ולכל אחד שאלות אחרות:

• האתר שלכם מחזיר 429 — חומת אש, Cloudflare, תוסף אבטחה או השרת מגבילים בקשות שמגיעות אליכם.
• האתר שלכם מקבל 429 — הקוד שלכם פונה לשירות חיצוני (API של סליקה, CRM, משלוחים, מפות, מודל AI) וחורג מהמכסה שלו.

כשהאתר שלכם מחזיר 429

מי בדרך כלל מגביל

הגבלה נכונה היא הגבלה ממוקדת

הגבלת קצב גורפת על כל האתר היא כלי בוטה. הגבלה טובה מתמקדת בנקודות שבאמת מותקפות: דף ההתחברות, טופס יצירת קשר, חיפוש פנימי, נקודות API. שם יש היגיון להגביל — חמישה ניסיונות התחברות בדקה הם יותר ממה שאדם צריך. על הגנה על טפסים מבוטים כתבתי במאמר ספאם בטפסים, ועל ההבדל בין סוגי ההגנה במאמר מה זה WAF.

הזהירו מלחסום את גוגל

לפי התיעוד של גוגל לקודי סטטוס, Googlebot מתייחס ל-429 כסימן שהשרת עמוס — ומאט את הסריקה, בדיוק כמו בשגיאות 5xx. אם 429 נמשך, עמודים שכבר באינדקס עלולים בסופו של דבר לצאת ממנו. כלומר: הגבלת קצב שתופסת את Googlebot לא רק מאטה סריקה, אלא יכולה לעלות לכם בנוכחות בחיפוש. אם צריך להגביל בוטים, ודאו קודם שהתנועה באמת לא מגיעה מגוגל — גוגל ממליצה לאמת את Googlebot לפי בדיקת DNS הפוכה של כתובת ה-IP, ולא לפי שם הדפדפן שהבקשה מציגה.

איך מאבחנים חסימה שגויה

1. אספו מהגולש את השעה המדויקת ואת כתובת ה-IP שלו.
2. חפשו ביומן האבטחה של Cloudflare או של התוסף איזה כלל החזיר 429.
3. בדקו את הסף: האם הוא סביר לשימוש אמיתי? (למשל, דף שטוען עשרות משאבים מאותה כתובת יכול לחצות סף נמוך מדי)
4. החריגו כתובות של שירותים שאתם סומכים עליהם — מערכת סליקה, ניטור, אינטגרציות — במקום להעלות את הסף לכולם.

כשהאתר שלכם מקבל 429 משירות חיצוני

זה המקרה שקשה יותר לראות, כי הגולש לא רואה 429 — הוא רואה טופס שלא נשלח ל-CRM, מחיר משלוח שלא מחושב, או מפה שלא נטענת. כמעט כל API מסחרי מגביל קצב, והאינטגרציה צריכה להיבנות בהתאם:

• לכבד את Retry-After — אם השירות מחזיר את הכותרת, לחכות לפחות את הזמן הזה לפני ניסיון חוזר.
• ניסיונות חוזרים עם המתנה הולכת וגדלה — לא לנסות שוב מיד, ולא בלולאה אינסופית.
• תור במקום שליחה מיידית — פעולות שלא חייבות לקרות בזמן אמת (סנכרון מלאי, שליחת לידים ל-CRM) עדיף להכניס לתור שמתרוקן בקצב שהשירות מאפשר.
• מטמון — לא לבקש מה-API את אותו מידע בכל טעינת עמוד.
• תיעוד והתראה — שכל 429 יירשם, כדי שתדעו על הבעיה לפני שלקוח מתלונן.

על חיבורים כאלה ומה לשאול לפני שמתחילים, כתבתי במאמר API מה זה. גם מפתח API שדלף יכול לגרום ל-429, כי מישהו אחר שורף לכם את המכסה — ראו אבטחת מפתחות API.

שאלות נפוצות

מה ההבדל בין 429 ל-503?

429 אומר "אתה שולח יותר מדי" — ההגבלה היא על הלקוח הספציפי. 503 אומר "השרת לא זמין כרגע" — לכולם. שתיהן יכולות לכלול Retry-After. על 503 כתבתי במאמר שגיאה 500 ושגיאה 503.

גולש רגיל יכול לקבל 429?

כן, אם הסף נמוך מדי, אם הוא גולש ממשרד או מרשת סלולרית שבה הרבה אנשים חולקים את אותה כתובת IP, או אם תוסף בדפדפן שלו שולח בקשות ברקע. זו הסיבה להגביל נקודות ספציפיות ולא את כל האתר.

הגבלת קצב נכונה — שחוסמת בוטים בלי לחסום לקוחות, ואינטגרציות שמכבדות את המגבלות של השירותים שהן מדברות איתם — היא חלק מהעבודה שלי באינטגרציות ו-API. אם משהו באתר שלכם נתקע על 429, כתבו לי.