Cloudflare's Major 18th Outage

פרטים: נכתב על ידי IT Pro; קטגוריה: Blog; פורסם ב19 נובמבר 2025; כניסות: 6219

ב-18 בנובמבר 2025 נפלה פיסת אינטרנט ענקית.
אם פתחתם צ'אטGPT, X (טוויטר), League of Legends, Shopify, Coinbase או אינספור אתרים קטנים יותר, התקבלתם עם דף שגיאה של 5xx ממושמעת Cloudflare - או שהאתרים פשוט לא היו עומסים כלל. מה שנראה בהתחלה כמו עוד רגע גדול של "האינטרנט שבור" התברר כמשהו יותר עדין, ובמובנים מסוימים, מדאיג יותר: חרק עצמי עמוק בתוך התשתית של Cloudflare.

להלן מסלול מפורט של מה קרה ב-Cloudflare Outage (18 בנובמבר 2025)למה זה קרה, מי זה השפיע, ומה צריכים קבוצות תשתיות לקחת ממנו.

מה באמת קרה אתמול?

On On יום שלישי, 18 בנובמבר 2025בשעות הבוקר המאוחרות UTC החלה Cloudflare להחזיר כמויות גדולות של HTTP 5xx שגיאות שרת לתנועה שעברה דרך הרשת שלה. עבור משתמשי הקצה, זה אומר "שגיאה של שרת ביננאלית" או "שגיאות מהירות" דפים כאשר מנסים לגשת לאתרים פופולריים רבים ואפליקציות.

על פי הבלוג של Cloudflare, ה-Outage:

החל להשפיע על תנועת HTTP של לקוחות 11:28 UTC
נמצאו שגיאות 5xx נפוצות ב- CDN הליבה ושירותי אבטחה
היו צעדים משמעותיים מסביב 13:05-14:30 UTC
החזרת נפח שגיאה 5xx לבסיס 17:06 UTC בלוג Cloudflare

Cloudflare עצמה תיארה את זה ההוצאה הגרועה ביותר מאז 2019כי זה לא רק השפיע על תכונה אחת או לוח המחוונים - זה משבש את שכבת הפרוקסי הליבה שמסלולה את רוב התנועה של הלקוחות דרך הרשת שלה. בלוג Cloudflare

מעקב אחר צד שלישי תמך בכך. סיסקו אלפיים ראה תגית: Global Outage המשפיע על Cloudflare, עם מגבלות זמן ו-5xx על שירותים כמו X, OpenAI (ChatGPT), ו Anthropic, בעוד נתיבי רשת עצמם נראים בריאים. זה מצביע חזק על כישלונות בשירותלא בעיה של ISP או מחיקה. אלפי

מי הושפע?

מכיוון ש-Cloudflare יושב מול חלק מסיבי של האינטרנט (בסביבות) 20% מאתרי האינטרנט להסתמך על Cloudflare עבור ביצועים וביטחון, רדיוס הפיצוץ היה עצום. AP News+1

בין השירותים דווחו כמשפיעים:

ChatGPT - OpenAI
X (לשעבר Twitter)
Canva, Shopify, Dropbox, Coinbase
League of Legends פלטפורמות משחקים אחרות
שונים תחבורה ציבורית ומקומות ממשלתייםכולל New Jersey Transit and France's SNCF רכבות דיגיטליות AP News+1

עקבו אחרי Downdetector אלפי דוחות בנושא בשיא. סוכנות הידיעות רויטרס דיווחה על כ-5,000 משתמשים שנפגעו ב- X לבדה בשלב מסוים, לפני שספירות ירדו כאשר התיקונים התגלגלו. רויטרס

מנקודת מבטו של המשתמש, הדבר בא לידי ביטוי כ:

אתרים שלא נטענים בכלל
זרמי כניסה תלויים או נכשלים (במיוחד היכן ש-Cloudflare Access או Turnstile היו מעורבים)
APIs מגיבים לסירוגין או עם 5xx שגיאות
לוח הבקרה ופאנלי הניהול תזמון החוצה

במילים אחרות: חלקים עצומים של האינטרנט "מרגיש למטה", למרות שהסיבה השורשית הייתה מרוכזת במערכות הפנימיות של ספק אחד.

כיצד Cloudflare פועל בדרך כלל (במונחים פשוטים)

כדי להבין מדוע הזינוק הזה היה כה חמור, הוא עוזר לדעת את הנתיב המחוספס של בקשה באמצעות רשת Cloudflare.

Cloudflare פועל כ הפוך CDN ו שכבת אבטחה:

הדפדפן או האפליקציה שלך מתחברים ל-Cloudflare במקום ישירות לאתר המקור.
Cloudflare מסיים את TLS ו-HTTP בקצהו.
בקשות לזרום לתוך Cloudflare מערכת Proxy, שנקרא FL (Frontline) הדור החדש שלה FL2.
המונחים:
- Applies WAF (Internet Application Firewall) כללים
- ריצה ניהול בוט מודלים
- יד הגנת DDoSצ'נג, תוקפנות למקור
- גישה למוצרים פנימיים אחרים כמו עובדים, R2, גישהוכו'. בלוג Cloudflare

במבצע רגיל אדריכלות זו היא יעילה מאוד: אם למרכז נתונים אחד יש בעיה, התנועה ננקטת דרך אחרים; שינויים בתצורה מגולפים בזהירות; תכונות בודדות צריכות להיכשל בדרכים הכלולות.

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

הסיבה השורשית: קובץ ה- bot-management נעלם

ההסבר הרשמי של Cloudflare מצביע על גורם אחד:
קובץ תצורה תצורה בשימוש על ידי מערכת ניהול בוטים שלהם. בלוג Cloudflare

הנה שרשרת האירועים בשפה פשוטה:

ניהול בוט משתמש ב"קובץ מנצח"
- מודל ה-bot-detection של Cloudflare מסתמך על קבוצה של "מכשולים" – אותות על כל בקשה המשמשת כדי להחליט אם זה אנושי או בוט.
תכונות אלה ארוזות לתוך קובץ תצורה כי הוא regenerated כל כמה דקות וגלגל ברחבי העולם, כך Cloudflare יכול להסתגל במהירות לדפוסי התקפה חדשים. בלוג Cloudflare
שינוי בהתנהגות שאילתה בבית
- קובץ התכונה נוצר על ידי שאילתות נגד מסד נתונים ClickHouse.
Cloudflare עשה שינוי מסביב 11:05 UTC כדי לשפר את האבטחה ואת הרשאות עבור שאילתות מבוזרות - המאפשר למשתמשים לראות metadata לא רק מ default schema אבל גם מבסיס r0 שולחנות בלוג Cloudflare
השאילתה שבנתה את רשימת הפיצ'רים לא הסתנן על ידי שם מסד נתונים; לפתע היא החלה להגיע עמודים כפולים משני default ו r0ביעילות להכפיל את מספר השורות.
הקובץ המאפיין התפוצץ בגודל
- ה-Bot Managementמודול יש גבולות קשים על כמה תכונות הוא יקבל (למשל 200, מעל 60 בדרך כלל בשימוש).
- כאשר הקובץ החדש שנוצר עלה על גבול זה, המודול פגע בכובע ובכובע. פאניקהבשל טעות לא ממומשת בקוד הרולינג שהשתמש Result::unwrap() על ערך שגיאה בלוג Cloudflare
שירותי ה- Proxy החלו להחזיר 5xx שגיאות
- מכיוון ש-Bot Management משולב במסלול הליבה של הפרוקסי, הפאניקה עלתה כמו תגובות HTTP 5xx לכל תנועה שהייתה תלויה במודול זה.
- על החדש FL2 לקוחות ראו שגיאות 5xx מפורשות.
- על המבוגר FL FL מנוע, ציוני בוט הלכו בשקט לאפס, אשר עלול לגרום לחיובים כוזבים בחוקי בלוק בוט. בלוג Cloudflare
החלק המכוער באמת: הקובץ המשיך לדעוך בין "טוב" ו"רע"
- מקבץ Click House היה להיות בהדרגה מעודכנתוקובץ הפיצ'ר התחדש כל חמש דקות.
- לפעמים השאילתה רץ על צמתים מעודכנים (יצירת קובץ רע), לפעמים על צמתים שאינם מחוסנים (יצירת קובץ טוב).
- זה נועד לזמן מה, רשת Cloudflare של Cloudflare הושמדה בין פעולה נורמלית לבין כישלון, שכן גרסאות שונות של הקובץ היו מופצות. בלוג Cloudflare

החנק הזה הפך את המצב למאוד מבלבל פנימי. בתחילה חשדו הצוותים של Cloudflare התקפות DDoS כי דפוס השגיאה לא נראה כמו התרסקות תוכנה פשוטה. אפילו עננים דף סטטוסאשר מתארח מחוץ לתשתיות שלהם, הראה בקצרה שגיאות - צירוף מקרים שהניע עוד יותר את החשדות של התקפה חיצונית. בלוג Cloudflare+1

רק ברגע שהם הבינו שהגורם הנפוץ היה קובץ ה- bot, התמונה הפכה ברורה.

ציר הזמן של האירוע

בהתבסס על הדיווח של Cloudflare ודיווחי צד שלישי, אנו יכולים להרכיב ציר זמן מחוספס ב-18 בנובמבר 2025: בלוג Cloudflare+2אלפי+2

11:05 UTC - שינוי בקרת גישה מסד נתונים מופרס Click House.
11:20–11:30 UTC - גרסאות רעות של קובץ ה- Bot Management מתחילות להיווצר ולהפיץ.
11:28 UTC • השפעה ראשונית של לקוחות: שגיאות HTTP 5xx גבוהות שנראו על תנועת לקוחות.
11:30-11:32 UTC - כלי ניטור חיצוניים ובדיקות אוטומטיות מתחילים לזהות כישלונות לסירוגין.
11:35 UTC Cloudflare פותחה שיחת אירועים פנימית; החקירה מתחילה.
11:48 UTC Cloudflare מפרסם עדכון סטטוס המאשר אירוע. Reend
11:30-13:05 UTC - צוותים מתמקדים במה שנראה כעובדים מוזנחים KV התנהגות ולחקור גורמים אפשריים רבים (כולל תרחישי התקפה).
13:05 UTC - הקטנת מפתח: פועלים KV ו-Cloudflare Access עוברים כדי לעקוף את הפרוקסי הליבה; ההשפעה מופחתת. בלוג Cloudflare
14:30 UTC - שורש סיבה מזוהה; דור והפצת קבצים תכונה רעה הופסק. קובץ תצורה טובה ידוע מוכנס באופן ידני ואת הליבה Proxy מחדש. רוב תעבורת הליבה חוזרת לנורמלית. בלוג Cloudflare
14:40-15:30 UTC - בעיות דשורד וכתובות משתפות כמו טרסטיליה ו backlog של ניסיונות אימות ליצור ספיגות עומס משני. בלוג Cloudflare
17:06 UTC שיעורי טעויות חוזרים לבסיס; Cloudflare מכריזה על מערכות נורמליות לחלוטין. בלוג Cloudflare

מנקודת מבטו של המשתמש, הזזות חשו גרועות יותר. בשעות הבוקר המוקדמות UTCלמרות שחלונות ההשפעה המדויקת משתנים על ידי האזור ועל ידי אילו מוצרי Cloudflare כל שירות תלויים.

מדוע הזינוק הזה חשוב כל כך

סיכון מרכזי

Cloudflare הוא חלק ממערכת קטנה של ספקי תשתיות אינטרנטלצד פלטפורמות הענן הגדולות (AWS, Azure, GCP) ו- CDN גדולים אחרים. כאשר אחד מהשחקנים האלה נכשל, ההשפעה היא רחבה ולעתים קרובות לא מזיקה.

מקרה זה:

לא הגיעו מ- BGP שיבוש של תקלה או קיצוץ כבל ISP.
לא הגיעו מהתקפה זדונית (למרות חשדות ראשוניים).
בא תצורה אחת ומגבלות באג בתוך מרכיב פנימי.

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

"תלויים" פוגעים גם

חלק מהשירותים המושפעים לא רק השתמשו ב-Cloudflare כ- CDN טיפש. הם היו:

שימוש גישה Cloudflare Access עבור אימות ואפס אמון גישה.
שימוש פועלים KV כחלק ממטוסי בקרה פנימיים.
Relying Turnstile עבור כניסות בוט-resistant. בלוג Cloudflare+1

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

מה ש-Cloudflare אומר שזה ישתנה

בלוגו של Cloudflare מתווה כמה צעדים להפעלה שהחברה כבר לוקחת כדי להפחית את הסיכון של כל דבר דומה חוזר: בלוג Cloudflare

Harden ingestion of Auto-generated תצורה
התנהגות פנימית יצרה תצורה עם אותה ספקנות ואימות כקלט יישומי למשתמש, כולל schema קפדני ובדיקה בגודל לפני רולט.
יותר מתגי הרג ברחבי העולם
קל יותר להשבית במהירות מודולים פנימיים בעייתיים (כמו ניהול בוט) ברחבי הרשת, כך שהם נכשלים. פתוח פתוח במקום לפאניקה בכל נתיב ה- Proxy.
הגנה על משאבי המערכת מפני סערה
ודא שזרקות הליבה, debug metadata, וכלי observability לא יכול overwhelm CPU וזיכרון כאשר שגיאות מתחילות לעלות.
מצבי כישלונות במודולים הליבה Proxy
באופן שיטתי ביקורת כיצד כל מודול פנימי מתנהג תחת קלט או תצורה בלתי צפויים, ולהבטיח השפלה חננית במקום כישלון גלובלי.
מקררים ומבודדים
בעוד שלא מאויתים בפירוט עצום, האירוע מצביע על כך ש-Cloudflare צפוי לפרט עוד כמה תצורה חדשה והתנהגויות DB propagate, כדי להפחית את הסיכוי ששינוי רע אחד משפיע על כל הצי.

הם גם עיצבו את האירוע ככישלון מוחלט בציפיות החוסן שלהם, וקראו לו "בלתי אפשרי" והכרה מפורשת בכאב שגרם הן ללקוחות והן למשתמשי אינטרנט רגילים. בלוג Cloudflare

שיעורים לקבוצות תשתיות ו-SRE

גם אם אתה לא מנהל משהו ענק כמו Cloudflare, יש כמה עיצוב מעשי מאוד ושיעורים תפעוליים בתחום זה:

לטפל בהגדרה פנימית כמו קלט לא מהימן

קל להניח ש"שלנו" שנוצר הוא תמיד נכון. אתמול נראה למה זה מסוכן:

תמיד לאמת גודל, צורה ומגבלות קבצי תצורה לפני הגשתם.
שקול המונחים של תצורה לכדי תת-קבוצה קטנה של תנועה או צמתים קודם, עם רולבק אוטומטי על חריגות.
שמירה קפדנית גבולות עליון לשבור מעגלים סביב ספירות תכונה, זיכרון preallocation, ואת השימוש CPU.

עיצוב לכישלון חלקי

באג אחד במודול ניהול בוט לא צריך להיות מסוגל פאניקה לכל נתיב ה- Proxy:

אשמה Un-Open vs Fail- Close בשכבות אבטחה מסוימות כאשר החלופה הושלמה.
בנה ברור, נבדק הורג מתגים עבור תכונות לא-core.
להבטיח תת-מערכות קריטיות (auth, דף סטטוס, כלי אירוע) יכול לפעול במצב degraded או באמצעות מסלולים חלופיים.

שימו לב ימין צודק אותות

התיעוש בין "הגדרה טובה" ו"הגדרה רעה" כל חמש דקות גרם לסימן להיראות כמו תנועת התקפה או התנהגות חיצונית רועשת:

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

אל תשים את כל הביצים בסל אחד

לארגונים המשתמשים ב-Cloudflare:

שקול Multi-CDN עיצובים לנכסים קריטיים באמת.
הימנעו מלעשות את דף סטטוס תלוי לחלוטין באותו ספק כמו הערימה העיקרית שלך (Cloudflare עושה את זה, אבל הייתה בעיה מקרית עם דף הסטטוס שלהם מארח אתמול אשר מבלבל דברים נוספים). בלוג Cloudflare+1
חשבו פעמיים לפני שתהפכו את עצמכם אימות אימות, מטוסי ניהול APIו משלוח לאותו ספק ללא נתיבי נפילה.

התמונה הגדולה יותר

בחודשים האחרונים בלבד, ראינו חכמים גדולים. Microsoft Azure, Amazon Web Servicesועכשיו, Cloudflare, אשר כל אלה הפילו באופן זמני נתחים גדולים של שירותי צרכנים וארגוניים באופן לא מקוון. AP News+2וושינגטון פוסט+2

התבנית ברורה:

האינטרנט יותר ויותר תלוי קומץ ספקי תשתיות ענק.
לעתים קרובות self-inflicedמגיע משינויים פנימיים מורכבים ולא מהתקפות חיצוניות.
אפילו ספקים עם שיטות SRE ברמה עולמית עדיין ניתן לנסוע על ידי אינטראקציות בלתי צפויות בין תצורה, התנהגות מסד נתונים ומגבלות קודמות קשות.

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

עבור משתמשים, האירוע ייזכר בעיקר כ"בוקר שבו X ו- ChatGPT לא יטען".
למהנדסים, סביר להניח שילמדו אותה כדוגמה לספר לימוד. באגים של תצורה עדינה במערכת מבוזרת ליבה יכולים לפרוץ לאירוע אינטרנט גלובלי.