เหตุขัดข้องของ Cloudflare วันที่ 5 ธันวาคม 2025

• เวลา 08:47 UTC ของวันที่ 5 ธันวาคม 2025 โครงข่าย Cloudflare บางส่วนประสบเหตุขัดข้องรุนแรง และได้รับการกู้คืนอย่างสมบูรณ์ในเวลาผ่านไปประมาณ 25 นาที คือ 09:12 UTC
• ประมาณ 28% ของ HTTP traffic ทั้งหมด ได้รับผลกระทบ และมีเพียงลูกค้าที่เข้าเกณฑ์บางอย่างเท่านั้นที่ประสบปัญหานี้
• สาเหตุคือการปรับเปลี่ยน WAF (ตรรกะการ parse body) เพื่อรองรับช่องโหว่ React Server Components (CVE-2025-55182) และไม่เกี่ยวข้องกับการโจมตีทางไซเบอร์
• ข้อผิดพลาดโค้ดใน FL1 proxy ทำให้เกิดข้อผิดพลาด HTTP 500 และใน FL2 proxy ใหม่ที่พัฒนาด้วย Rust ไม่พบข้อผิดพลาดเดียวกัน
• Cloudflare ยอมรับว่าปัญหาคล้ายกันเกิดซ้ำหลังเหตุขัดข้องวันที่ 18 พฤศจิกายน และกำลังดำเนินโครงการ เพิ่มความปลอดภัยการ deploy และความยืดหยุ่น (resilience) เป็นภารกิจลำดับความสำคัญสูงสุด

---

ภาพรวมเหตุขัดข้อง

• เวลา 08:47 UTC ของวันที่ 5 ธันวาคม 2025 เกิดเหตุขัดข้องในโครงข่าย Cloudflare บางส่วน
  • เวลา 09:12 ทั่วระบบได้รับการกู้คืนทั้งหมด ระยะเวลาได้รับผลกระทบรวม 25 นาที
  • โดยมีผลกระทบต่อ HTTP traffic โดยรวมประมาณ 28%
• เหตุขัดข้องนี้ ไม่เกี่ยวข้องกับการโจมตีทางไซเบอร์หรือการกระทำที่เป็นอันตราย และเกิดขึ้นระหว่างการเปลี่ยนแปลงภายใน
• สาเหตุคือการแก้ไข ตรรกะการพาร์ส body ของ WAF เพื่อรับมือกับช่องโหว่ใหม่ของ React Server Components

สาเหตุของเหตุขัดข้องและพื้นหลังทางเทคนิค

• Cloudflare WAF จะบัฟเฟอร์ HTTP request body ลงในหน่วยความจำ เพื่อใช้ตรวจจับ payload ที่เป็นอันตราย
  • ขณะนั้นกำลังขยายขนาดบัฟเฟอร์จาก 128KB เป็น 1MB
• เนื่องจากเครื่องมือตรวจสอบภายในไม่รองรับขนาดบัฟเฟอร์ใหม่ จึงมีการดำเนินการ การเปลี่ยนแปลงครั้งที่สองคือการปิดการใช้งานเครื่องมือนั้น
  • การเปลี่ยนแปลงนี้ถูกเผยแพร่ไปยังเซิร์ฟเวอร์ทั้งหมดทันทีผ่าน ระบบการตั้งค่าทั่วโลก
• การเปลี่ยนแปลงดังกล่าวก่อให้เกิดข้อผิดพลาดใน FL1 proxy และทำให้ตอบกลับ HTTP 500
  • ข้อความข้อผิดพลาด: attempt to index field 'execute' (a nil value)
• ปัญหาถูกระบุได้ทันที และการเปลี่ยนแปลงถูกยกเลิกที่ 09:12

ขอบเขตผลกระทบ

• มีผลกระทบเฉพาะลูกค้าที่ใช้ FL1 proxy และเปิดใช้ Cloudflare Managed Ruleset เท่านั้น
  • คำขอทั้งหมดของไซต์เหล่านั้นจะคืนค่า HTTP 500
  • Endpoint ทดสอบบางรายการ เช่น /cdn-cgi/trace เป็นข้อยกเว้น
• เครือข่ายในจีนและลูกค้าที่มีโครงสร้างการตั้งค่าแบบอื่นไม่ได้รับผลกระทบ

รายละเอียดข้อผิดพลาดช่วงทำงาน

• ระบบ rulesets ของ Cloudflare ประเมินกฎสำหรับแต่ละคำขอ
  • กฎแต่ละข้อประกอบด้วย filter และ action และ action execute จะเรียกใช้ ruleset อื่น
• ระบบบันทึกภายในใช้ execute เพื่อประเมินกฎทดสอบ
• killswitch system ถูกออกแบบมาเพื่อปิดการทำงานกฎที่ทำงานผิดพลาดแล้ว
  • แต่ครั้งนี้เป็นครั้งแรกที่มีการใช้ killswitch กับกฎที่มี action execute
• เกิดข้อผิดพลาด Lua เมื่อมีการพยายามเข้าถึงวัตถุ execute ขณะที่มันไม่มีอยู่จริง
• ข้อผิดพลาดนี้เป็น บั๊กโค้ดแบบง่าย ๆ ที่มีอยู่มาหลายปียุคแต่ไม่เคยถูกตรวจพบ
  • ใน FL2 proxy ที่เขียนด้วย Rust ไม่เกิดข้อผิดพลาดเดียวกัน

ความคืบหน้าหลังเหตุขัดข้องวันที่ 18 พฤศจิกายน

• วันที่ 18 พฤศจิกายนก็เคยมีเหตุขัดข้องกว้างขวางเช่นกันจาก การ deploy แบบทั่วโลก
• ในขณะนั้นได้มีการติดต่อกับลูกค้ากว่าร้อยรายโดยตรงและแบ่งปันแผนเพื่อป้องกันไม่ให้มีการกระจายอัปเดตเดี่ยวไปทั่วระบบ
• งานปรับปรุงดังกล่าวยังไม่เสร็จ จึงมีผลต่อเหตุขัดข้องรอบนี้
• Cloudflare กำหนดให้เรื่องนี้เป็น ภารกิจลำดับความสำคัญสูงสุดทั้งองค์กร

โครงการเสริมความยืดหยุ่นที่ยังดำเนินการอยู่

• Enhanced Rollouts & Versioning
  • รวมไปถึงการเปลี่ยนแปลงข้อมูลและการตั้งค่าสำหรับการตอบสนองต่อภัยคุกคาม โดยใช้งาน การ deploy แบบค่อยเป็นค่อยไป การตรวจสุขภาพระบบ และความสามารถในการ rollback อย่างรวดเร็ว
• Streamlined Break Glass Capabilities
  • ทำให้สามารถปฏิบัติการฉุกเฉินได้แม้ในช่วงการโต้ตอบระหว่างบริการภายในกับ control plane
• การจัดการข้อผิดพลาดแบบ Fail-Open
  • หากไฟล์การตั้งค่ามีข้อผิดพลาด ให้สลับไปยังสถานะปกติเริ่มต้นหรือส่งผ่าน traffic แทนการบล็อกคำขอ
  • บริการบางรายการจะมีตัวเลือก fail-open/fail-closed ให้เลือก
• คาดว่าจะเผยแพร่รายละเอียดของโครงการเสริมความยืดหยุ่นทั้งหมดภายในสัปดาห์หน้า
• จนถึงวันนั้น Cloudflare จะคงโหมด lockdown โดยระงับการเปลี่ยนแปลงเครือข่ายทั้งหมด

ไทม์ไลน์ (UTC)

• 08:47 – เริ่ม deploy การเปลี่ยนแปลงการตั้งค่าและการเผยแพร่สู่เครือข่าย
• 08:48 – ประสบผลกระทบทั่วเครือข่าย
• 08:50 – ประกาศเหตุขัดข้องผ่านการแจ้งเตือนอัตโนมัติ
• 09:11 – เริ่มยกเลิกการเปลี่ยนแปลง
• 09:12 – กู้คืนครบถ้วน และ traffic ทั้งหมดกลับสู่ภาวะปกติ

สรุป

• Cloudflare ยอมรับความร้ายแรงของ เหตุขัดข้องต่อเนื่องกันสองครั้ง และขออภัยต่อทั้งลูกค้าและผู้ใช้เครือข่ายอินเทอร์เน็ตทั้งหมด
• บริษัทจะผลักดันแผนป้องกันเหตุซ้ำในอนาคตผ่าน ความปลอดภัยในการ deploy, ความทนทานต่อข้อผิดพลาด และการเสริมความยืดหยุ่นของระบบ

[GN⁺]

ความคิดเห็นจาก Hacker News

• เหตุขัดข้องของ Cloudflare ครั้งนี้ไม่ได้เป็นแค่บั๊ก Lua ธรรมดา แต่เป็นเหตุการณ์ที่เผยให้เห็น ปัญหาเชิงสถาปัตยกรรม ที่รากฐาน
  เดิมทีโครงสร้างเว็บแบบกระจายศูนย์ทนต่อเหตุขัดข้องระดับโลกแบบนี้ได้ดีกว่ามาก ในทางกลับกัน ระบบแบบรวมศูนย์ที่เป็นเนื้อเดียวกันอย่าง Cloudflare สามารถทำให้บริการทั่วโลกหยุดพร้อมกันจากความผิดพลาดเพียงครั้งเดียวได้ ต่อให้เขียนด้วย Rust มนุษย์ก็ยังพลาดได้ สุดท้ายแล้ว การออกแบบที่แข็งแกร่ง ต่างหากที่สำคัญ

  • สรุปคือยิ่งพึ่งพาผู้ให้บริการรายใหญ่อย่าง Cloudflare หรือ AWS มากเท่าไร ความเสถียร ของเว็บก็ยิ่งลดลงเท่านั้น
  • เหมือนอุปมา “แตน 1,000 ตัว vs สุนัข 1 ตัว” ไม่ว่าจะเป็นเหตุขัดข้องระดับโลกหรือระดับท้องถิ่น ความเจ็บปวดต่างกันแค่รูปแบบเท่านั้น ถ้า Cloudflare ล่ม วิศวกรหลายร้อยคนจะเข้ามารับมือทันที แต่ถ้าเซิร์ฟเวอร์ของฉันล่ม คนที่รับผิดชอบอาจจะอยู่บ้านพักบนภูเขาก็ได้
  • พักเรื่องการถกเถียงว่าอำนาจผูกขาดไม่ดีไว้ก่อน ถ้ามองจาก อัตราการพร้อมใช้งานระยะยาว ของ Cloudflare กลับอาจดีกว่าการที่แต่ละเว็บดูแลอินฟราของตัวเองเสียอีก ตรรกะคือบริการทั้งหมดหยุดพร้อมกัน 1 ชั่วโมง ยังดีกว่าสำหรับผู้ใช้มากกว่าที่แต่ละบริการจะล่มแยกกันคนละ 1 ชั่วโมง อย่างไรก็ตาม ถ้า ความเสถียร ของ Cloudflare ตกลงไปต่ำกว่าค่าเฉลี่ย คุณค่านั้นก็จะหายไป
  • ถ้าขนาดใหญ่ถึงขั้นรองรับ 80 ล้านคำขอต่อวินาที ก็รู้สึกว่า โครงสร้างที่ปล่อยให้ผลิตภัณฑ์เดียวใหญ่ขนาดนี้ ต่างหากที่เป็นปัญหา
  • Cloudflare ก็ยังเป็นหนึ่งในบริษัทที่ กู้คืนโครงสร้างพื้นฐานระดับโลก ได้เร็วที่สุดไม่ว่าจะอยู่มุมไหนของโลก ครั้งนี้ก็แก้ปัญหาเครือข่ายล่ม 28% ได้ภายใน 25 นาที และมี downtime น้อยกว่าคลาวด์อื่นอย่างเป็นรูปธรรม

• เมื่อคืนเห็น Cloudflare 500 error ในหลายเว็บไซต์ แต่ใน หน้าสถานะระบบ กลับไม่มีการพูดถึงอะไรเลย มีแค่ประกาศบำรุงรักษาที่วางแผนไว้

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

• ดูเหมือนว่า วิศวกรรมคุณภาพ ของ Cloudflare จะตามความเร็วในการผลิตไม่ทัน เคยได้ยินมาว่าในอุตสาหกรรมป้องกันประเทศ ทีมคุณภาพมักจะมีประสบการณ์มากกว่าเสมอ แต่ในวงการซอฟต์แวร์ดูเหมือนจะตรงกันข้าม

  • ทำให้นึกถึงเรื่องเล่าว่าแม้แต่อุตสาหกรรมป้องกันประเทศก็เคยรู้เรื่อง memory leak แต่ก็ปล่อยผ่านโดยบอกว่า “ภายในเวลาการใช้งานไม่มีปัญหา”
  • เรื่องแบบนี้เกิดขึ้นเดือนละสองครั้งแล้ว จะบอกว่า “น่าชื่นชม” ไม่ได้ การเกิดซ้ำไม่มีข้อแก้ตัว

• โครงสร้าง packet switching ของอินเทอร์เน็ตเดิมทีถูกออกแบบมาให้ทนต่อเหตุขัดข้องระดับโลกแบบนี้
  ในยุคสงครามเย็น เครือข่าย DARPA มีเป้าหมายเพื่อรักษาระบบสั่งการเอาไว้แม้ในสถานการณ์โจมตีด้วยนิวเคลียร์
  ตอนนี้ถึงเวลาที่เราควรกลับไปสู่แนวคิดอินเทอร์เน็ตแบบ local-first แล้ว

  • อ้างอิง: The Real Internet Architecture
  • อ้างอิง: Local-first software

• ช่วงหลังรู้สึกว่า Cloudflare กำลังทำให้อินเทอร์เน็ต ช้าลงและใช้งานลำบากขึ้น มีขั้นตอนอย่าง “พิสูจน์ว่าคุณเป็นมนุษย์” เพิ่มขึ้น และการโหลดหน้าก็ช้าลง
  ดูเหมือนว่านี่จะเกี่ยวกับ นโยบายเก็บเงินการ crawl ของ AI มากกว่าการปกป้องเว็บไซต์ (แนะนำ Pay-per-crawl)

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

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

  • ปัญหาคือ การแจ้งเตือนดังช้าเกินไป มีแจ้งเตือนหลัง 2 นาที ทั้งที่ควรตรวจจับได้ในระดับวินาที
    คนที่รับผิดชอบการ deploy ควรดูตัวชี้วัดแบบเรียลไทม์แล้วกดปุ่ม rollback ทันที
    ทั้งที่ในล็อกระบุชัดถึงระดับบรรทัดโค้ด แต่ดูเหมือนว่าทีม deploy กับทีมที่เข้าใจโค้ดจะ แยกขาดจากกัน
  • เหมือนพยายาม rollback หลังเห็นสัญญาณเตือน แต่กระบวนการนั้นกลับเป็นตัวก่อปัญหาเสียเอง
  • เครื่องมือภายในมักมี false positive เยอะ และหลายครั้งตัวมันเองก็พังอยู่แล้ว
  • ฟังดูเหมือนมุกที่ว่า “ไฟเตือนเครื่องยนต์ติดตลอด ก็เลยถอดหลอดไฟทิ้งซะ”

• อัตราการพร้อมใช้งาน ของ Cloudflare ลดลงต่ำกว่า 99.9% แล้ว แย่กว่าพีซีที่บ้านฉันเสียอีก

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

• ถ้าระดับขนาดของ Cloudflare ต้องมี สภาพแวดล้อมทดสอบ อย่างแน่นอน
  การเปลี่ยนแปลงทุกอย่างควรถูกจำลองในสภาพแวดล้อมโมเดลที่แยกออกมาก่อน แล้วค่อย deploy แบบค่อยเป็นค่อยไป
  สิ่งที่สำคัญกว่า ระบบชนิดข้อมูลที่เข้มงวด คือ มาตรการความปลอดภัยเชิงกระบวนการ

  • บริษัทเรามีระบบ deploy สามขั้น: development → internal integration → production
    ทีมที่พลาดบ่อยมักถูกลดความเร็วลง ส่วนทีมที่เชื่อถือได้มากกว่าจะเดินหน้าเร็วกว่า
    สุดท้ายแล้ว ความเร็วทางเทคนิคเป็นเรื่องของการเลือก ถ้าเริ่มคุกคาม SLA ก็ต้องลดความเร็วและเพิ่มการทดสอบ
  • อาจใช้ผู้ใช้ฟรีเป็น test bed และให้ลูกค้าที่จ่ายเงินได้ใช้เวอร์ชันที่เสถียรกว่าก็ได้
  • คำว่า “ระบบชนิดข้อมูลที่เข้มงวดช่วยคุณไม่ได้” หมายถึง ต่อหน้า ความล้มเหลวเชิงกระบวนการ แล้ว ตัวภาษาก็หมดทางช่วย

• ดูเหมือนว่า คุณภาพซอฟต์แวร์ ของ Cloudflare จะกำลังสั่นคลอน
  เคยมีบั๊กที่การตรวจสอบสิทธิ์เข้าถึงของฟีเจอร์สำหรับลูกค้าองค์กรทำกันแค่ ขั้นตอนสุดท้าย เท่านั้น

  • ฉันเองก็เคยเจอ การตั้งค่าที่ rollback ไม่ได้ ใน Cloudflare API
    ต้องผ่านทีมซัพพอร์ตเท่านั้นถึงจะเปลี่ยนได้ และใช้เวลาหลายวันกว่าจะแก้ไข
    ลิงก์กรณีที่เกี่ยวข้อง
  • มีคนมองว่าบั๊กแบบนี้อาจเป็นโค้ดที่ AI เขียน ก็ได้
  • อยากฟังให้เจาะจงกว่านี้ว่าคำว่า “ตรวจแค่ขั้นตอนสุดท้าย” หมายถึงอะไร

• สงสัยเกี่ยวกับ วัฒนธรรมการปฏิบัติการ ของ Cloudflare
  ระหว่างรับมือประเด็นความปลอดภัยกลับเกิดข้อผิดพลาดขึ้น แต่แทนที่จะ rollback กลับมีการ deploy ระดับโลก อีกรอบ นี่เป็นการตัดสินใจที่เสี่ยง
  เท่ากับละเมิดหลักพื้นฐานที่ว่า “ถ้าดูไม่ชัวร์ก็ rollback ก่อน”

  • อย่างไรก็ตาม ครั้งนี้เป็นสถานการณ์เร่งด่วนคล้ายการรับมือ ช่องโหว่ React Server RCE
    ถ้าชะลอการ deploy ลูกค้าอาจถูกแฮ็กจริงได้ จึงเป็นกรณีที่ ความเร็วเท่ากับความปลอดภัย
  • rollback ไม่ได้เป็นคำตอบที่ถูกเสมอไป ถ้า ไม่คุ้นเคยกับกระบวนการ มันก็กลายเป็นความเสี่ยงในตัวเอง
  • จริง ๆ แล้วการ deploy สองครั้งนั้นเป็น คนละคอมโพเนนต์ กัน
    การแก้ครั้งแรกเพียงเปิดเผยบั๊กแฝงของครั้งที่สอง ดังนั้นบางครั้ง roll forward ก็สมจริงกว่าการ rollback
  • มีความเป็นไปได้สูงว่า Cloudflare สะสม หนี้ทางเทคนิค มาตลอดช่วงเติบโตอย่างรวดเร็ว
    เหตุขัดข้องบ่อยครั้งในช่วงหลังอาจเป็นสัญญาณว่าหนี้นั้นกำลังโผล่ออกมา