Cloudflare: שינוי פנימי משך כרבע מטווחי ה-IP של לקוחות BYOIP ב-20 בפברואר
ב-20 בפברואר 2026 הפסיקה Cloudflare לפרסם כ-1,100 טווחי IP של לקוחות BYOIP, בלי תקיפה. לפי הדוח שלה, משימת ניקוי אוטומטית פירשה בקשה ריקה כ״כל הטווחים״.
TL;DR בקצרה
- לפי Cloudflare, משימת ניקוי שרצה אחרי שינוי ב-Addressing API סימנה את כל טווחי BYOIP למחיקה, ולא רק את הממתינים.
- כ-25% מ-4,306 טווחי BYOIP הפסיקו להתפרסם ב-BGP, ושירותים כמו Spectrum ו-Magic Transit נכשלו אצל חלק מהלקוחות.
- Cloudflare מדגישה שהתקלה לא נגרמה בתקיפה, ושפתרון ה-DNS של 1.1.1.1 עבד כרגיל.
- Laravel Cloud דיווחה על כ-3 שעות ו-15 דקות של ניתוק, כי הטווחים שלה ננעלו במצב Withdrawn.
ב-20 בפברואר 2026 הפסיקה Cloudflare בטעות לפרסם כרבע מטווחי ה-IP של לקוחות שירות BYOIP. לפי הדוח שלה, הסיבה היתה שינוי פנימי ולא תקיפה. אתרים ושירותים שישבו על הטווחים האלה הפסיקו להיות נגישים.
מה קרה ב-Cloudflare BYOIP ב-20 בפברואר
BYOIP, Bring Your Own IP, מאפשר ללקוחות להביא טווחי כתובות משלהם. Cloudflare מפרסמת אותם לאינטרנט, והלקוח מצמיד להם את המוצרים שלה. כשהפרסום נפסק, התעבורה כבר לא מגיעה ליעד.
לפי Cloudflare, ההשפעה החלה ב-17:56 לפי UTC, שהן 19:56 בישראל. בשעה 18:46 עצר מהנדס את המשימה הפגומה. ב-19:19 פרסמה Cloudflare הנחיה ללקוחות: לפרסם מחדש את הטווחים מלוח הבקרה. בסביבות 20:20 שוחזרו כ-800 טווחים. בסביבות 23:03 סיימה Cloudflare לשחזר ידנית את כ-300 הנותרים.
השפעת התקלה תלויה במוצר. שירותי ה-CDN והאבטחה לא משכו תעבורה אל הטווחים, והיו כשלי חיבור. ב-Spectrum אפליקציות BYOIP לא קיבלו תעבורה. ב-Magic Transit נרשמו עיכובים וכשלים. ב-Dedicated Egress לקוחות לא הצליחו לשלוח תעבורה ליעדים. אתר 1.1.1.1 החזיר שגיאת 403, אבל פתרון DNS, כולל DNS over HTTPS, המשיך לעבוד.
למה שינוי קטן משך טווחי BYOIP
שינוי ב-Addressing API הפך שלב ידני לאוטומטי: הסרת טווחי BYOIP לבקשת לקוח. המשימה רצה כל פעם כמשימת ניקוי. היא שלחה בקשה עם דגל pending_delete בלי ערך. השרת פירש את הריק כבקשה לקבל את כל הטווחים, וסימן את כולם למחיקה. יחד איתם סומנו אובייקטים תלויים, כמו קישורי השירות של הלקוחות.
הבדיקות פספסו את זה. בסביבת הבדיקות לא היו מספיק נתוני דמה. הבדיקות גם לא כיסו משימה שמשנה נתונים בלי קלט ישיר. לפי Cloudflare, הקוד הפגום נכנס ב-5 בפברואר, והשחרור שהפעיל אותו עלה ב-20 בפברואר ב-17:46.
לפי Cloudflare, 25% מתוך 4,306 טווחי BYOIP הפסיקו להתפרסם בטעות. בדוח מופיע גם המספר 1,100 טווחים שהוסרו מול עמית BGP אחד. לא כל הלקוחות סבלו מהתקלה, כי השינוי עלה בהדרגה. לדברי Cloudflare, ההשפעה על ה-CDN הוגבלה לטווחים שפורסמו דרך BYOIP. הדוח כולל התנצלות: Cloudflare מודה שהיא איכזבה את הלקוחות.
מה למדו לקוחות Cloudflare BYOIP, ומה היא משנה
Laravel Cloud, שמשתמשת ב-BYOIP, דיווחה על כ-3 שעות ו-15 דקות של ניתוק. האפליקציות ומסדי הנתונים שלה פעלו, אבל הנתיב אליהם נעלם. הטווחים שלה ננעלו במצב Withdrawn, ולכן הפרסום מחדש בלוח הבקרה לא היה זמין. היא נאלצה לחכות ל-Cloudflare.
Laravel מספרת שהמעקב שלה זיהה את התקלה לפני דף הסטטוס של Cloudflare. היא מודה שעדיין אין לה יתירות בשכבת ההכרזה על כתובות ה-IP. לדבריה, סגירת הפער היא בעדיפות עליונה.
Cloudflare מתכננת שלושה שינויים. הראשון הוא סכמת API אחידה, שמאפשרת לבדוק קריאות, כולל הדגל הבעייתי. השני הוא הפרדה בין מצב מבצעי למצב מוגדר, עם צילומי מצב ושחזור מהיר. השלישי הוא מפסק אוטומטי שיעצור שינויים רחבים ומהירים, כמו הסרה המונית של טווחים.
מה זה אומר עבורכם
- בדקו אם אתם ב-BYOIP: אם אין לכם טווחי IP משלכם ב-Cloudflare, התקלה לא נגעה בכם. אם יש, בדקו את הניטור בין 17:56 ל-23:03 לפי UTC.
- תכננו יתירות להכרזת ה-IP: אפליקציה עמידה לא עוזרת כשהנתיב אליה נעלם. שקלו מסלול חלופי ליום שבו הספק נופל.
- הכינו תהליך שחזור: קבעו מי מורשה לפרסם מחדש טווחים, ואיך פונים לתמיכה כשהכפתור נעול.
- נטרו מבחוץ: Laravel זיהתה את התקלה לפני דף הסטטוס של הספק. ניטור נגישות חיצוני מקצר את זמן התגובה.
מקורות והרחבה
- Cloudflare outage on February 20, 2026Cloudflare
- Laravel Cloud Incident Report: February 20, 2026Laravel
הכתבה נכתבה במקור בעברית על ידי מערכת GEEKLIK, על בסיס המקורות שלמעלה ובדיקת העובדות מולם.
מצאתם טעות? דווחו לנו
