Sự cố Ngừng hoạt động của Cloudflare ngày 5 tháng 12 năm 2025

Vào ngày 5 tháng 12 năm 2025, Cloudflare, một trong những công ty cung cấp hạ tầng Internet và an ninh mạng quan trọng nhất thế giới, đã trải qua một sự cố ngừng hoạt động toàn cầu, gây gián đoạn trên diện rộng cho hàng triệu trang web và dịch vụ trực tuyến. Mặc dù sự cố chỉ kéo dài trong thời gian ngắn, tác động của nó đã được cảm nhận sâu sắc trên toàn cầu do vai trò nền tảng của Cloudflare trong việc định tuyến và bảo vệ một phần lớn lưu lượng truy cập Internet. Tài liệu này cung cấp một phân tích kỹ thuật chi tiết về nguyên nhân gốc rễ của sự cố, dựa trên thông tin chính thức được công bố trong báo cáo sự cố của Cloudflare, nhằm làm rõ chuỗi sự kiện và các bài học kinh nghiệm quan trọng. Điều quan trọng cần lưu ý là, không giống như một số báo cáo ban đầu, sự cố này không liên quan đến hoạt động bảo trì theo lịch trình mà hoàn toàn do một thay đổi cấu hình khẩn cấp gây ra.

Dưới đây là tóm tắt các thông tin chính về sự cố:

• Thời gian bắt đầu: Sự cố được ghi nhận bắt đầu vào lúc 08:47 UTC.
• Thời gian kết thúc: Dịch vụ được khôi phục hoàn toàn vào lúc 09:12 UTC.
• Tổng thời gian ảnh hưởng: Tổng thời gian ngừng hoạt động kéo dài khoảng 25 phút.
• Bản chất sự cố: Sự cố gây ra lỗi HTTP 500 Internal Server Error trên một phần mạng lưới của Cloudflare, ảnh hưởng đến khoảng 28% tổng lưu lượng HTTP mà công ty xử lý.

Mặc dù thời gian ngừng hoạt động tương đối ngắn, tác động của nó lại vô cùng sâu rộng do sự phụ thuộc lớn của hệ sinh thái Internet vào các dịch vụ của Cloudflare. Một phân tích chi tiết là cần thiết để hiểu rõ nguyên nhân và các yếu tố góp phần.

Cloudflare không chỉ là một nhà cung cấp Mạng phân phối nội dung (CDN) mà còn là một lớp bảo mật và hiệu suất quan trọng hoạt động giữa người dùng và máy chủ của trang web. Công ty xử lý khoảng một phần năm tổng lưu lượng truy cập Internet, do đó bất kỳ sự gián đoạn nào trong dịch vụ của họ đều có khả năng gây ra hiệu ứng gợn sóng, làm sập hàng loạt các nền tảng không liên quan trực tiếp đến nhau.

Sự cố ngày 5 tháng 12 đã chứng minh rõ ràng sự phụ thuộc này, khi hàng loạt dịch vụ lớn trên khắp các lĩnh vực đều bị ảnh hưởng:

• Nền tảng Giao dịch và Tài chính: Các nền tảng giao dịch chứng khoán và tiền điện tử lớn như Zerodha, Groww, Angel One, Upstox, và Coinbase đã báo cáo sự gián đoạn, ảnh hưởng đến khả năng truy cập và thực hiện giao dịch của người dùng.
• Mạng xã hội và Giao tiếp: Các gã khổng lồ truyền thông xã hội như Instagram, Facebook, LinkedIn, X (trước đây là Twitter), và Discord đều gặp phải sự cố, khiến người dùng không thể tải nội dung hoặc đăng nhập.
• Công cụ Làm việc và Sáng tạo: Các công cụ thiết yếu cho công việc hàng ngày như Shopify, Zoom, Canva, QuillBot, Notion và các nền tảng AI như Claude và Perplexity cũng bị ngừng hoạt động, làm gián đoạn quy trình làm việc của nhiều cá nhân và doanh nghiệp.
• Giải trí và Gaming: Các dịch vụ giải trí phổ biến bao gồm Valorant, Crunchyroll, Fortnite, League of Legends, Spotify, và Letterboxd đều không thể truy cập, gây ảnh hưởng đến hàng triệu người dùng trong giờ cao điểm.
• Hạ tầng và Dịch vụ Web: Một trong những điểm trớ trêu nhất của sự cố là chính Downdetector, trang web mà nhiều người dùng truy cập để kiểm tra tình trạng ngừng hoạt động của các dịch vụ khác, cũng bị sập do phụ thuộc vào Cloudflare.

Người dùng cuối trên toàn cầu đã gặp phải các thông báo lỗi chung chung nhưng gây khó chịu, phổ biến nhất là "500 Internal Server Error" và "Bad Gateway". Những lỗi này cho thấy vấn đề không nằm ở phía trang web của nhà cung cấp dịch vụ mà ở lớp trung gian do Cloudflare quản lý. Để hiểu tại sao một sự cố lại có thể lan rộng và xảy ra nhanh chóng như vậy, chúng ta cần xem xét dòng thời gian chính xác của các sự kiện.

Việc phân tích dòng thời gian của một sự cố là rất quan trọng để xác định các điểm quyết định, tốc độ phản ứng của đội ngũ kỹ thuật và các mắt xích yếu trong quy trình xử lý. Dòng thời gian dưới đây, được tái tạo từ báo cáo chính thức của Cloudflare, cho thấy một sự cố được kích hoạt, lan rộng và khắc phục chỉ trong vòng 25 phút.

Dòng thời gian này cho thấy rõ ràng rằng sự cố đã được kích hoạt nhanh chóng bởi một thay đổi duy nhất, và may mắn là cũng được khắc phục nhanh chóng thông qua việc hoàn tác thay đổi đó. Phần tiếp theo sẽ đi sâu vào chi tiết kỹ thuật của thay đổi này.

Nguyên nhân ban đầu của chuỗi sự kiện bắt nguồn từ một hành động có chủ đích tốt: nỗ lực của Cloudflare nhằm bảo vệ khách hàng khỏi một lỗ hổng bảo mật nghiêm trọng mới được phát hiện có mã CVE-2025-55182 trong React Server Components. Để ngăn chặn các cuộc tấn công khai thác lỗ hổng này, đội ngũ kỹ thuật đã triển khai một thay đổi cho Tường lửa Ứng dụng Web (WAF) của mình.

Thay đổi kỹ thuật cụ thể là tăng kích thước bộ đệm (buffer size) cho việc phân tích nội dung HTTP request body từ 128KB lên 1MB. Mục đích là để WAF có thể kiểm tra các yêu cầu lớn hơn, vốn là một phần của vector tấn công tiềm tàng.

Thay đổi tăng kích thước bộ đệm được triển khai dần dần bằng hệ thống triển khai an toàn của Cloudflare. Tuy nhiên, trong quá trình này, một công cụ kiểm thử nội bộ (dùng để thử nghiệm các quy tắc WAF mới) đã phát hiện ra lỗi và bắt đầu báo cáo sự cố.

Tại thời điểm này, đội ngũ kỹ thuật đã đưa ra một quyết định then chốt. Cho rằng công cụ này chỉ dành cho mục đích nội bộ và bản vá bảo mật là rất quan trọng, họ đã quyết định vô hiệu hóa tạm thời công cụ này để tiếp tục triển khai bản vá. Tuy nhiên, hành động vô hiệu hóa này không được thực hiện thông qua hệ thống triển khai dần dần, mà bằng một “hệ thống cấu hình toàn cầu” (global configuration system). Hệ thống này được thiết kế để áp dụng các thay đổi gần như tức thời trên toàn bộ mạng lưới trong vài giây.

Việc vô hiệu hóa công cụ nội bộ thông qua hệ thống cấu hình toàn cầu đã vô tình kích hoạt một lỗi mã (bug) “ngủ yên” tồn tại từ nhiều năm trong FL1, hệ thống proxy cũ của Cloudflare. Khi hệ thống nhận được lệnh vô hiệu hóa quy tắc “execute” của công cụ nội bộ, nó đã bỏ qua việc thực thi quy tắc đó một cách chính xác. Tuy nhiên, một đoạn mã xử lý kết quả sau đó đã gặp lỗi.

Báo cáo sự cố của Cloudflare đã trích dẫn chính xác ngoại lệ LUA gây ra sự cố:

[lua] Failed to run module rulesets callback late_routing: /usr/local/nginx-fl/lua/modules/init.lua:314: attempt to index field 'execute' (a nil value)

Nói một cách dễ hiểu, mã nguồn đã cố gắng truy cập vào một trường dữ liệu có tên execute bên trong một đối tượng kết quả (rule_result.execute). Tuy nhiên, vì quy tắc “execute” đã bị bỏ qua do lệnh vô hiệu hóa, đối tượng này không tồn tại (có giá trị nil). Việc cố gắng truy cập một trường trên một đối tượng không tồn tại đã gây ra một lỗi nghiêm trọng (exception), làm cho tiến trình xử lý yêu cầu bị sập và trả về lỗi HTTP 500 cho người dùng. Tương tự như việc cố gắng tìm một trang cụ thể trong một chương sách đã bị gỡ bỏ khỏi mục lục.

Không phải tất cả khách hàng của Cloudflare đều bị ảnh hưởng. Một yêu cầu phải đáp ứng cả hai điều kiện sau để gặp phải lỗi:

• Trang web phải được phục vụ bởi proxy FL1 cũ của Cloudflare.
• Khách hàng phải có triển khai bộ quy tắc Cloudflare Managed Ruleset.

Điều này giải thích tại sao sự cố chỉ ảnh hưởng đến khoảng 28% lưu lượng truy cập. Các hệ thống không bị ảnh hưởng bao gồm những khách hàng đã được chuyển sang proxy FL2 mới hơn của Cloudflare (được viết bằng ngôn ngữ Rust, có khả năng chống lại loại lỗi này) và toàn bộ lưu lượng truy cập qua mạng lưới của Cloudflare tại Trung Quốc.

Ngoài lỗi mã trực tiếp, còn có các yếu tố mang tính hệ thống lớn hơn đã góp phần tạo nên quy mô và mức độ nghiêm trọng của sự cố.

Một sự cố nghiêm trọng hiếm khi chỉ do một lỗi mã duy nhất gây ra. Thông thường, nó là kết quả của sự hội tụ giữa một lỗi kỹ thuật và các vấn đề mang tính hệ thống trong quy trình, kiến trúc và văn hóa kỹ thuật. Sự cố này của Cloudflare cũng không ngoại lệ.

Hệ thống cấu hình toàn cầu thiếu cơ chế an toàn là một yếu tố góp phần chính. Việc sở hữu một hệ thống có khả năng đẩy một thay đổi ra toàn bộ mạng lưới toàn cầu chỉ trong vài giây là một công cụ mạnh mẽ nhưng cũng cực kỳ rủi ro. Hệ thống này thiếu các cơ chế triển khai dần dần (canary deployment) hoặc theo từng giai đoạn. Đáng chú ý, báo cáo của Cloudflare cho biết hệ thống này đã “đang được xem xét” sau một sự cố tương tự xảy ra vào ngày 18 tháng 11. Sự cố ngày 5 tháng 12 xảy ra trong khi các hành động khắc phục từ sự cố trước đó vẫn đang được tiến hành, cho thấy một cửa sổ lỗ hổng nghiêm trọng trong quy trình quản lý thay đổi của họ.

Nợ kỹ thuật (Technical Debt) và hệ thống cũ cũng đóng một vai trò quan trọng. Lỗi mã LUA đã tồn tại “ngủ yên” trong nhiều năm trên hệ thống proxy FL1 cũ. Sự tồn tại của lỗi này là một ví dụ điển hình về rủi ro của nợ kỹ thuật. Ngược lại, proxy FL2 mới hơn, được viết bằng Rust, một ngôn ngữ lập trình có hệ thống kiểu mạnh giúp ngăn ngừa các lỗi truy cập giá trị nil như thế này, đã không bị ảnh hưởng. Điều này cho thấy sự khác biệt rõ rệt về độ tin cậy giữa các hệ thống cũ và mới.

Cuối cùng, việc hai sự cố quy mô lớn xảy ra gần nhau (ngày 18 tháng 11 và ngày 5 tháng 12) cho thấy các vấn đề tiềm ẩn trong quy trình quản lý thay đổi và giảm thiểu rủi ro của Cloudflare tại thời điểm đó. Mặc dù cả hai đều xuất phát từ những thay đổi nhằm cải thiện bảo mật, chúng đều dẫn đến sự cố ngừng hoạt động trên diện rộng, cho thấy sự cần thiết phải xem xét lại sự cân bằng giữa tốc độ và sự ổn định.

Để giải quyết các vấn đề hệ thống này, Cloudflare đã cam kết thực hiện một loạt các hành động khắc phục và phòng ngừa.

Phản ứng của một tổ chức sau sự cố cũng quan trọng như việc xác định nguyên nhân. Trong trường hợp này, Cloudflare đã nhanh chóng khắc phục sự cố và công khai cam kết thực hiện các sáng kiến chiến lược dài hạn để tăng cường khả năng phục hồi của hệ thống.

Hành động khắc phục tức thời là việc hoàn tác thay đổi cấu hình gây lỗi. Vào lúc 09:12 UTC, thay đổi đã được hoàn tác hoàn toàn, và dịch vụ được khôi phục ngay lập tức.

Về lâu dài, Cloudflare đã và đang tiến hành một số dự án cải thiện khả năng phục hồi hệ thống, nhiều trong số đó đã được ưu tiên hàng đầu sau sự cố ngày 18 tháng 11. Các sáng kiến chính bao gồm:

• Triển khai & Phiên bản Nâng cao (Enhanced Rollouts & Versioning): Áp dụng quy trình triển khai dần dần, có kiểm soát và xác thực sức khỏe cho cả các thay đổi cấu hình, tương tự như cách triển khai phần mềm. Điều này sẽ giúp ngăn chặn một thay đổi có lỗi lan rộng ra toàn bộ mạng lưới.
• Khả năng “Phá kính” Hợp lý hóa (Streamlined break glass capabilities): Đảm bảo các hoạt động vận hành quan trọng vẫn có thể được thực hiện một cách an toàn và hiệu quả, ngay cả khi các hệ thống điều khiển chính đang gặp sự cố.
• Xử lý Lỗi “Fail-Open”: Thay đổi logic hệ thống để khi gặp phải một cấu hình bị lỗi hoặc nằm ngoài phạm vi cho phép, hệ thống sẽ mặc định chuyển sang trạng thái tốt đã biết trước đó hoặc bỏ qua thay đổi đó, thay vì làm sập toàn bộ yêu cầu (hard-fail).

Để thể hiện cam kết mạnh mẽ của mình, Cloudflare đã thông báo rằng họ sẽ “phong tỏa mọi thay đổi đối với mạng lưới của họ” cho đến khi các hệ thống giảm thiểu tác động và hoàn tác tốt hơn được đưa vào hoạt động đầy đủ.

Sự cố ngừng hoạt động của Cloudflare vào ngày 5 tháng 12 năm 2025 là một lời nhắc nhở mạnh mẽ về sự mong manh của hạ tầng Internet hiện đại và tầm quan trọng của các quy trình quản lý thay đổi chặt chẽ. Phân tích này đã chỉ ra một chuỗi sự kiện phức tạp: một nỗ lực vá lỗi bảo mật khẩn cấp đã dẫn đến quyết định vô hiệu hóa một công cụ nội bộ bằng một hệ thống cấu hình toàn cầu, và điều này lại kích hoạt một lỗi mã tiềm ẩn trong một hệ thống cũ, gây ra sự cố trên diện rộng.

Từ sự cố này, các chuyên gia kỹ thuật và các nhà quản lý hệ thống có thể rút ra một số bài học kinh nghiệm quan trọng:

1. Rủi ro của Thay đổi Toàn cục, Tức thời: Sự nguy hiểm của các hệ thống cấu hình có khả năng tác động đến toàn bộ cơ sở hạ tầng trong vài giây mà không có giai đoạn triển khai theo vùng (canary deployment) hoặc theo phần trăm là rất lớn. Các cơ chế “killswitch” hoặc thay đổi khẩn cấp cần được thiết kế với các biện pháp bảo vệ tương tự như triển khai phần mềm thông thường.
2. Tầm quan trọng của Việc Hiện đại hóa Hệ thống: Sự cố này làm nổi bật sự khác biệt về độ ổn định giữa hệ thống cũ (FL1 với lỗi LUA) và hệ thống mới (FL2 viết bằng Rust). Điều này cho thấy giá trị to lớn của việc đầu tư vào hiện đại hóa và giải quyết nợ kỹ thuật để tăng cường độ tin cậy và khả năng phục hồi của hệ thống.
3. Sự cân bằng giữa Bảo mật và Ổn định: Tình huống trớ trêu khi một hành động nhằm tăng cường bảo mật lại vô tình gây ra sự cố ngừng hoạt động đã cho thấy một bài toán khó. Nó nêu bật sự xung đột giữa tốc độ cần thiết cho một bản vá bảo mật và sự thận trọng cần thiết cho một lần triển khai ổn định. Điều này nhấn mạnh sự cần thiết của các quy trình kiểm thử, xác thực và triển khai chặt chẽ, ngay cả đối với các bản vá được coi là khẩn cấp.

Cuối cùng, sự minh bạch của Cloudflare trong báo cáo sự cố là một điểm sáng, cung cấp những hiểu biết quý giá cho toàn ngành. Cam kết cải tiến liên tục và học hỏi từ những sai lầm là yếu tố cốt lõi để duy trì sự tin cậy của các dịch vụ nền tảng, vốn là xương sống của Internet ngày nay.