เกิดเหตุขัดข้องของเครือข่ายทั่วโลกของ Cloudflare

 (cloudflarestatus.com)
1 คะแนน โดย GN⁺ 2025-11-19 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เกิดปัญหาประสิทธิภาพลดลงของบริการภายในบน เครือข่ายทั่วโลกของ Cloudflare ส่งผลให้หลายบริการได้รับผลกระทบเป็นช่วง ๆ
  • บริการหลักอย่าง Access, Bot Management, CDN/Cache, Dashboard, Firewall, Network, WARP, Workers ประสบปัญหาขัดข้องชั่วคราว
  • ทีมวิศวกรรมระบุปัญหาได้และดำเนินการแก้ไข โดย บริการ WARP และ Access กลับมาใช้งานได้ก่อน
  • หลังจากนั้น อัตราข้อผิดพลาดและความหน่วงทั่วโลกค่อย ๆ กลับสู่ระดับปกติ และ บริการ Dashboard ก็ได้รับการกู้คืน
  • ขณะนี้ทุกบริการกลับมาดำเนินงานตามปกติแล้ว และ เหตุการณ์ได้รับการแก้ไขอย่างสมบูรณ์

ภาพรวมของเหตุการณ์

  • Cloudflare ประสบกับ ประสิทธิภาพลดลงของบริการภายใน (Internal Service Degradation) ทำให้บางบริการหยุดชะงักเป็นช่วง ๆ
    • บริการที่ได้รับผลกระทบ ได้แก่ Access, Bot Management, CDN/Cache, Dashboard, Firewall, Network, WARP, Workers เป็นต้น
    • บริษัทเริ่มดำเนินการกู้คืนทันที และอัปเดตความคืบหน้าของการแก้ปัญหาอย่างต่อเนื่อง

การระบุปัญหาและการตอบสนองเบื้องต้น

  • Cloudflare ยืนยันการลดลงของบริการภายในในขั้น กำลังตรวจสอบ (Investigating)
    • ลูกค้าบางส่วนพบข้อผิดพลาดและความหน่วงเป็นช่วง ๆ
    • ทีมวิศวกรรมดำเนินการวิเคราะห์สาเหตุควบคู่กับการกู้คืนระบบ
  • ต่อมามีการ ระบุสาเหตุของปัญหา (Identified) และเริ่มดำเนินการแก้ไข
    • ระหว่างการแก้ไข การเชื่อมต่อ WARP ในลอนดอนถูกปิดใช้งานชั่วคราว ทำให้ผู้ใช้ในพื้นที่นั้นไม่สามารถเชื่อมต่ออินเทอร์เน็ตได้

ความคืบหน้าในการกู้คืนบริการ

  • หลังการแก้ไข บริการ Access และ WARP ได้รับการกู้คืนก่อน โดยอัตราข้อผิดพลาดกลับสู่ระดับก่อนเกิดเหตุ
    • การเชื่อมต่อ WARP ในลอนดอนถูกเปิดใช้งานอีกครั้ง
  • หลังจากนั้นมีการดำเนินการ กู้คืนบริการสำหรับลูกค้า Application Services ต่อเนื่อง
    • มีการปรับใช้การเปลี่ยนแปลงเพื่อกู้คืนบริการ Dashboard
    • แม้ลูกค้าบางส่วนยังพบปัญหาในการเข้าสู่ระบบหรือใช้งาน Dashboard แต่ก็ได้รับการแก้ไขด้วยการปรับปรุงเพิ่มเติม

การทำให้เครือข่ายกลับมามีเสถียรภาพ

  • ทั่วโลก อัตราข้อผิดพลาดและความหน่วง (latency) ค่อย ๆ ลดลงและกลับสู่ระดับปกติ
    • การคำนวณคะแนนของ Bot Management (bot scores) ได้รับผลกระทบชั่วคราว แต่กลับมาเป็นปกติระหว่างกระบวนการกู้คืน
    • ทีมวิศวกรรมเร่งขจัดข้อผิดพลาดที่เหลืออยู่และฟื้นฟูเครือข่ายทั้งหมดให้เร็วขึ้น
  • หลังจากนั้นทุกบริการกลับมาทำงานได้ตามปกติ และ อัตราข้อผิดพลาดกับความหน่วงกลับสู่ภาวะปกติอย่างสมบูรณ์

การปิดเหตุการณ์และการดำเนินการหลังเหตุการณ์

  • Cloudflare ยืนยันว่า ทุกบริการกลับมาดำเนินงานตามปกติ และปิดเหตุการณ์นี้
    • ขณะนี้ ยังไม่มีการเปลี่ยนแปลงการกำหนดค่าเพิ่มเติม และกำลังเฝ้าติดตามแพลตฟอร์มอย่างใกล้ชิด
    • กำลังมีการ ตรวจสอบหลังเกิดเหตุ (post-incident investigation) เกี่ยวกับสาเหตุของปัญหา และจะเผยแพร่ผลในภายหลัง
  • เหตุขัดข้องครั้งนี้ถูกบันทึกเป็น เหตุการณ์ที่ส่งผลกระทบต่อเครือข่ายทั่วโลก

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-11-19
ความเห็นจาก Hacker News

  • มีคนแชร์คำสั่งสำหรับ ปิดใช้งาน CF proxy สำหรับผู้ที่มี Cloudflare API token
    ใช้คำสั่ง curl เพื่อดึง zone ID และ DNS record แล้วส่งคำขอ PATCH เพื่อตั้งค่า "proxied": false
    แต่ต้องระวังความเสี่ยงเรื่องใบรับรอง SSL หาย, ความปลอดภัย/ประสิทธิภาพลดลง, และการเปิดเผย IP ของแบ็กเอนด์

    • ถ้ามีเพียง Global API Key แบบเก่า ก็ใช้ header X-Auth-Email และ X-Auth-Key ได้
      และถ้าใครตั้งให้อนุญาตเฉพาะทราฟฟิกจาก Cloudflare ก็ต้องปิดกฎนั้นชั่วคราว
    • เดิมทีคิดว่าคราวหน้าจะใช้วิธีนี้ แต่ไม่ได้สร้าง API token ไว้ล่วงหน้าเลยทำได้แค่รอ
      โชคดีที่ตอนนี้ระบบกลับมาออนไลน์แล้ว
    • ผมจัดการผ่าน Terraform provider แต่สำหรับคนที่เข้า dashboard ไม่ได้ วิธีนี้มีประโยชน์มาก
    • เป็นทิปที่ดี และขอเสริมว่าใน curl คำขอ GET เป็นค่าเริ่มต้นอยู่แล้วจึงไม่จำเป็นต้องใส่ -X GET
      ถ้าใช้ตัวเลือก -d จะกลายเป็น POST อัตโนมัติ และสำหรับ PATCH นั้น -X PATCH ถูกต้องแล้ว
    • ถ้าเปิด Cloudflare WARP บางเว็บจะกลับมาใช้งานได้ และ 1.1.1.1 ก็น่าจะให้ผลคล้ายกัน
      แต่แม้จะ tunneling แล้ว บางเว็บก็ยังล่มบางส่วนอยู่ดี

  • Cloudflare CTO ระบุว่า บั๊กแฝงในระบบบล็อกบอต เริ่มทำงานผิดพลาดหนักหลังมีการเปลี่ยนคอนฟิก จนทำให้เกิดปัญหาทั่วทั้งเครือข่าย
    เขาอธิบายในแหล่งที่มาว่าไม่ใช่การโจมตี แต่เป็นปัญหาภายใน

    • น่าแปลกที่บริษัทใหญ่ ๆ ยัง ไม่ทยอยปล่อยการเปลี่ยนคอนฟิกแบบเป็นขั้น
      ทั้งโค้ดและคอนฟิกล้วนเป็นข้อมูล แต่ก็ยังปล่อยพร้อมกันทั่วโลกจนเกิดเหตุล่มใหญ่ซ้ำ ๆ
    • อยากให้ข้อมูลสำคัญแบบนี้ขึ้นมาอยู่ด้านบนของคอมเมนต์ หาเจอยากมากท่ามกลางคอมเมนต์เดาว่าเป็นการโจมตีไซเบอร์
    • แค่คอนฟิกเปลี่ยนครั้งเดียวก็ทำให้หุ้น CF ร่วง 4% เลย เลยอยากรู้ ผลกระทบทางเศรษฐกิจ ของเหตุล่มแบบนี้ต่อทั้งอุตสาหกรรม

  • มีเพื่อนร่วมงานคนหนึ่งวิ่งเข้ามาหาผมทันที บอกว่าเขาเพิ่งเปลี่ยนคอนฟิก Cloudflare แล้วเว็บก็ดับพอดี เลย ตกใจคิดว่าตัวเองทำพัง
    พอเห็นโพสต์นี้ก็โล่งอก

    • มีคนแซวว่า “หนักกว่านั้นอีก นายทำ Cloudflare ล่มทั้งระบบเลยต่างหาก”
    • แต่จะว่าไป มันจะไม่ใช่จริง ๆ เหรอ? เพราะก่อนหน้านี้ก็เคยมีเหตุล่มครั้งใหญ่ของ Fastly
    • สงสัยว่ามีคำไหนที่ตรงกับ ความโล่งใจประหลาด ๆ แบบรู้ว่าไม่ได้มีใครทำพลาดคนเดียวไหม
    • หรือบางทีเพื่อนร่วมงานคนนั้นอาจเป็นพนักงาน Cloudflare ก็ได้
    • ผมเองก็เพิ่งได้รับข้อความจากลูกค้าเป็นสิบ ๆ ข้อความว่าเว็บเข้าไม่ได้ ทั้งที่เมื่อวานเพิ่งเปลี่ยนคอนฟิกไปเลยเหงื่อตก
      พอเห็นข้อความ “Cloudflare down” ก็โล่งใจจากใจจริง

  • เช็กจากเนเธอร์แลนด์แล้วพบว่า แทบทุกบริการล่ม
    ทั้ง Cloudflare dashboard และ Betterstack dashboard ก็เข้าไม่ได้เหมือนกัน
    ที่ย้อนแย้งคือหน้า status ยังใช้งานได้ แต่กลับอยู่ในสถานการณ์ที่แจ้งลูกค้าไม่ได้

    • ผมก็เจอเหมือนกัน เหตุผลที่มีแค่ HN ยังปกติก็เพราะไม่ได้ใช้ Cloudflare
      ผมเคยเขียนบล็อกโพสต์ไว้ว่า “ถ้าไม่จำเป็นก็อย่าเอาเว็บไปไว้หลัง Cloudflare”
    • ทุกปีเราจะได้ตระหนักว่าการพึ่ง AWS หรือ Cloudflare มากเกินไปมันเสี่ยง แต่ ก็หาทางแทนได้ไม่ง่าย
      ถึงอย่างนั้นพอเกิดเหตุล่มใหญ่แบบนี้ ลูกค้ากลับเข้าใจมากกว่าที่คิด
    • Cloudflare dashboard ไม่ได้ตายสนิท แค่ ต้องพยายามมากหน่อยก็ยังปิด proxy ได้
      ใช้เวลาไม่กี่นาทีแต่ก็แยก hcker.news ออกจาก CF ได้
    • พอเห็นสถานการณ์แบบนี้ก็รู้สึกว่า บริการโฮสต์หน้า status บน local VPS น่าจะเป็นโอกาสทางธุรกิจได้
    • ในโปรเจกต์ข้างของผม Total Real Returns
      ผมใส่ วิดเจ็ต uptime แบบเรียลไทม์ ที่เชื่อมกับหน้า status ภายนอกไว้ด้านล่าง
      ดูได้จากstatus SVG และ
      หน้า status ภายนอก

  • เวลาที่ Cloudflare หรือ AWS ล่ม แล้วเห็นว่า บริการ self-hosted ของตัวเองยังทำงานปกติ มันมีความสะใจอยู่เหมือนกัน
    ตอนนี้ผมเสถียรกว่า SLA 99.999% ของพวกเขาเสียอีก

    • แม้แต่เว็บส่วนตัวกาก ๆ ของผมก็ยังรอดจากเหตุล่มของ AWS, Azure และ Cloudflare มาทั้งหมด
      ตอนนี้เริ่มคิดว่าจะติด uptime tracker ดีไหม
    • เว็บ self-hosted ของผมกลับล่มเพราะ Cloudflare proxy เอง เสียความรู้สึกมาก
    • บริษัทแบบดั้งเดิมหลายแห่งกำลังเจอสถานการณ์ที่ระบบอย่าง Oracle หรือ SAP ยังปกติดี แต่ บริการใหม่ที่อยู่บนคลาวด์กลับหยุดหมด
      เป็นบทเรียนที่บริษัท SaaS รุ่นใหม่ควรจำ
    • มีคนถามกันมากว่า DNS จัดการอย่างไร ผมเองก็โฮสต์บน Raspberry Pi แต่เพิ่งย้าย DNS ไป Cloudflare
      เลยทั้งขำทั้งรู้สึกพอใจแปลก ๆ ที่เว็บเล็ก ๆ ของตัวเองล่มตามไปด้วย

  • ช่วงหลังมานี้ดูเหมือนว่า เหตุล่มของโครงสร้างพื้นฐานขนาดใหญ่เพิ่มขึ้นมาก AWS และ Cloudflare ต่างก็ทำได้ต่ำกว่า SLA มาก

    • มันดันตรงกับช่วงที่บริษัทใหญ่ ๆ ปลดคนครั้งใหญ่แล้วประกาศจะเอา AI มาแทน
    • เหตุล่มแบบนี้ทำให้ตระหนักว่า จำนวนเลข 9 ใน SLA นั้นแทบไม่มีความหมาย
      เพราะมันไม่ใช่ uptime จริง แต่เป็นตัวเลขที่บริษัทนิยามขึ้นเอง
    • มีคนเรียกมันว่า “vibe code theory” เป็นทฤษฎีติดตลกว่า ยิ่งมีโค้ดที่เขียนด้วยความรู้สึกล้วน ๆ มากขึ้น บั๊กกับเหตุล่มก็ยิ่งเพิ่ม
    • บางคนวิเคราะห์ว่าสาเหตุมาจาก วัฒนธรรมการรีบ deploy เพราะช่วงห้ามปล่อยระบบปลายปีกับแรงกดดันเป้าหมาย Q4 มาชนกัน
    • หรือไม่ก็อาจเป็น การโจมตีไซเบอร์ระดับรัฐชาติ ก็ได้ ตามมุมมองเชิงสมคบคิด

  • เวลาที่ Cloudflare หรือ AWS หยุดทำงาน ปัญหา ความรวมศูนย์ ที่ทำให้เว็บครึ่งหนึ่งหยุดตามไปด้วยนั้นรุนแรงมาก

    • ผู้ใช้ส่วนใหญ่ก็ไม่ได้ใส่ใจมากนัก เพราะพอรับรู้ว่า “อินเทอร์เน็ตล่ม” บริการแต่ละรายก็สามารถ หลีกเลี่ยงความรับผิดชอบ ได้
      นี่จึงเป็นเหตุผลที่โครงสร้างแบบนี้ไม่เปลี่ยน
    • สำหรับการป้องกัน DDoS นั้น ขนาดย่อมมีความได้เปรียบเชิงเศรษฐกิจ ยิ่งมีลูกค้ามาก แบนด์วิดท์ก็ยิ่งมากและการป้องกันก็ยิ่งแข็งแรง
      CDN รายเล็กแข่งได้ยาก และสุดท้ายก็กลายเป็น โครงสร้างผูกขาดโดยธรรมชาติ
      ที่ Cloudflare มีแพ็กเกจฟรีก็เป็นกลยุทธ์เพื่อเอาประโยชน์จาก network effect แบบนี้
    • สิ่งที่น่ากังวลยิ่งกว่าจุดล้มเหลวเพียงจุดเดียวคือ ความรวมศูนย์แบบนี้อาจ บิดเบือนอนาคตของมาตรฐานเว็บและการโฮสต์อย่างอิสระ
      และยังมีโอกาสกลายเป็นเป้าหมายรวมศูนย์ของการเซ็นเซอร์โดยรัฐด้วย
    • Let's Encrypt ก็มีความเสี่ยงแฝงอยู่เช่นกัน
      เพราะเว็บราว 2/3 พึ่งพามัน อายุใบรับรองก็สั้นลงเรื่อย ๆ และถ้าเกิด การแฮ็กหรือเหตุขัดข้องขึ้นมา เว็บทั้งโลกอาจเป็นอัมพาตได้
      ตอนนี้มันเป็นองค์กรที่มีเจตนาดี แต่ก็อย่าลืมว่า Google ในอดีตก็เคยถูกมองแบบนั้น
    • หลังจากกระแส AWS นักพัฒนาก็ หันไปพึ่งคลาวด์แทน dedicated server กันหมด ซึ่งเป็นปัญหา
      ถึงจะมีแบ็กอัปในระดับซอฟต์แวร์มากมาย แต่ common sense เรื่อง multi-hosting ในระดับโครงสร้างพื้นฐาน กลับหายไป

  • ที่น่าขำคือ DownDetector ก็ใช้ Cloudflare Turnstile เลยล่มตามไปด้วย

    • มีรายงาน AWS ล่มพุ่งขึ้นมากเหมือนกัน แต่คงมีโอกาสเป็น ผลบวกลวง สูง
    • ผมก็เห็นอาการนั้นเหมือนกัน

  • ข้อความแสดงข้อผิดพลาดของ Cloudflare ที่เขียนว่า “Your browser: Working / Host: Working / Cloudflare: Error” เป็น ข้อความขอโทษเชิงภาพที่น่าประทับใจ

    • เพิ่งเคยเห็นหน้าจอแบบนี้ครั้งแรก แต่กรณีของผม “Host” คือ Cloudflare Pages เลยรู้สึกว่าความหมายมันก้ำกึ่ง
    • ที่ตลกคือพอกดที่ “Cloudflare” มันก็ยังพาไปหน้าที่บอกว่าเป็นปัญหาฝั่งเซิร์ฟเวอร์ลูกค้าอยู่ดี
    • ผมชอบที่มันซื่อสัตย์ตรงไปตรงมา แต่ผู้ใช้ส่วนใหญ่ก็ยังตอบแค่ว่า “ช่วยแก้ไวไฟให้หน่อย”
    • ถึงอย่างนั้นก็ยังดีตรงที่รู้สถานการณ์ชัดเจนและรับมือได้ ถ้าจำเป็นก็ ปิดใช้งาน proxy เพื่อลดผลกระทบต่อบริการได้
    • ผมเองก็นั่งไล่ดูล็อกอยู่เป็นชั่วโมงก่อนจะรู้ว่าไม่ใช่ปัญหาที่เซิร์ฟเวอร์ของผม

  • เว็บที่ใช้ Cloudflare Challenge (“I’m not a robot”) ก็ หยุดทำงานพร้อม HTTP 500 error เช่นกัน
    พร้อมข้อความว่า “challenges.cloudflare.com ถูกบล็อกอยู่ กรุณาปลดบล็อก”

    • ทุกวันนี้ คุณภาพการจัดการ error ต่ำเกินไป บริษัทต่าง ๆ พยายามปัดความรับผิดชอบโดยโทษผู้ใช้
      หรือไม่ก็แสดงหน้าหมุนโหลดไม่รู้จบ ทั้งที่จริงแล้วแบ็กเอนด์ส่ง error ที่ชัดเจนกลับมา แต่ฟรอนต์เอนด์กลับซ่อนไว้
      ล่าสุดยังเห็นกรณีที่ error ว่ารหัสผ่านยาวเกินไปถูกแสดงเป็น “อีเมลนี้ถูกใช้งานแล้ว”
    • เพราะเหตุล่มครั้งนี้ AI Search (GPT5) ของ chat.bing.com ก็หยุดทำงานด้วย
      กลายเป็นสถานการณ์ย้อนแย้งที่ต้องพิสูจน์กับ AI ว่าตัวเองเป็นมนุษย์
    • บางเว็บ เช่น pinkbike แสดงข้อความว่า “you have been blocked”
    • สรุปคือไม่ได้บล็อกแค่หุ่นยนต์ แต่บล็อกคนจริงด้วย /s
    • ดูเหมือนฟรอนต์เอนด์จะเข้าใจผิดว่าผู้ใช้บล็อกโดเมนผ่าน DNS หรือส่วนขยายเบราว์เซอร์
      มุกปฏิเสธแบบ /s ว่า Cloudflare Captcha ไม่มีทางล่มได้นั้นขำดี