Minh chứng cho năng lực ứng biến của hạ tầng Cloudflare

Vào 11:20 UTC ngày 18/11/2025, mạng Cloudflare bắt đầu gặp phải sự cố lớn dẫn đến việc không thể xử lý lưu lượng mạng cốt lõi. Điều này hiển thị với người dùng Internet dưới dạng trang lỗi cho thấy lỗi nội bộ trong mạng Cloudflare. Tuy nhiên, chính trong thời điểm thử thách này, Cloudflare đã chứng minh lý do vì sao họ vẫn là trụ cột của hạ tầng Internet thế giới – tốc độ phản ứng nhanh, khả năng khoanh vùng chính xác, và năng lực phục hồi ở quy mô toàn cầu.

(Hình: Trang lỗi HTTP xuất hiện trong sự cố)

Sự cố không liên quan và không xuất phát từ bất kỳ cuộc tấn công mạng hay hoạt động độc hại nào. Nguyên nhân là do một thay đổi trong phân quyền của hệ thống cơ sở dữ liệu, khiến cơ sở dữ liệu ghi trùng dữ liệu vào “tệp tính năng” (feature file) dùng cho hệ thống Bot Management. Tệp này tăng gấp đôi kích thước và lan truyền đến toàn bộ mạng lưới máy chủ của Cloudflare.

Phần mềm trên các máy chủ này đọc tệp tính năng để cập nhật liên tục mô hình chống bot. Tuy nhiên, phần mềm có giới hạn kích thước tệp, và khi vượt quá giới hạn, phần mềm đã ngừng hoạt động.

Ban đầu, họ hiểu sai triệu chứng và tưởng rằng đó là một cuộc tấn công DDoS quy mô lớn. Sau khi xác định đúng nguyên nhân, họ đã dừng việc phát tán tệp lỗi và thay thế bằng phiên bản ổn định trước đó. Lưu lượng mạng phục hồi phần lớn vào 14:30, và đến 17:06 tất cả hệ thống hoạt động bình thường trở lại.

Với vai trò quan trọng của Cloudflare, bất kỳ sự cố nào làm gián đoạn dịch vụ đều là điều không thể chấp nhận. Việc mạng của chúng tôi không thể định tuyến lưu lượng trong khoảng thời gian đó là điều vô cùng đau xót với toàn bộ đội ngũ.

Bài viết này mô tả chi tiết sự việc, các hệ thống liên quan, nguyên nhân và những gì Cloudflare sẽ làm để ngăn chặn sự cố tương tự xảy ra trong tương lai.

Diễn biến sự cố

Biểu đồ dưới đây cho thấy lưu lượng HTTP 5xx được Cloudflare trả về — vốn dĩ luôn ở mức rất thấp cho đến thời điểm bắt đầu sự cố.

(Hình: Số lượng HTTP 5xx trong mạng Cloudflare)

Phần tăng đột biến và giao động sau đó phản ánh việc hệ thống tải phải tệp tính năng lỗi. Điểm đặc biệt là hệ thống khôi phục tạm thời, rồi lại lỗi — một dấu hiệu hiếm thấy trong lỗi nội bộ.

Nguyên nhân là tệp được tạo lại mỗi 5 phút bởi một truy vấn ClickHouse trong quá trình nâng cấp hệ thống phân quyền. Khi truy vấn chạy trên node đã được cập nhật, nó tạo dữ liệu xấu; khi chạy trên node chưa cập nhật thì tạo dữ liệu tốt. Kết quả là hệ thống liên tục nhận tệp tốt – tệp xấu xen kẽ.

Điều này khiến quá trình chẩn đoán ban đầu khó khăn, và khiến chúng tôi nhầm lẫn rằng có thể đây là một cuộc tấn công. Đến khi tất cả các node ClickHouse đều tạo tệp lỗi, hệ thống dừng ở trạng thái lỗi hoàn toàn.

Sự cố kéo dài đến 14:30, khi tệp lỗi được thay thế bằng bản chuẩn và module Bot Management được khởi động lại. Lưu lượng trở lại bình thường hoàn toàn lúc 17:06.

Các dịch vụ bị ảnh hưởng

Ngoài 5xx, thời gian phản hồi tăng cao do hệ thống telemetry tiêu tốn nhiều CPU để ghi log lỗi.

Cách Cloudflare xử lý yêu cầu – và điều gì đã sai

Lưu lượng đến Cloudflare đi qua:

1. Lớp HTTP/TLS

2. Core proxy (“FL – Frontline”)

3. Pingora – kiểm tra cache hoặc truy vấn origin

Bot Management là một module chạy trong core proxy. Mỗi vài phút, module nhận tệp tính năng mới từ ClickHouse để cập nhật mô hình ML. Đây là tệp bị lỗi trong sự cố này.

Thay đổi trong ClickHouse làm tệp bị trùng dữ liệu và vượt quá giới hạn 200 feature (hiện Cloudflare dùng ~60 feature). Khi tệp bị nhân đôi kích thước và vượt quá 200, module Bot Management bị panic, khiến core proxy trả về 5xx.

Cloudflare đang trong quá trình chuyển traffic sang engine proxy thế hệ mới (FL → FL2).

• Trên FL2, lỗi hiển thị thành 5xx.

• Trên FL, bot score bị trả về 0 — gây false positive cho khách hàng chặn bot.

Một hiện tượng gây nhiễu khác là trang status của Cloudflare cũng lỗi — dù trang này không chạy trên Cloudflare.

Điều này khiến đội ngũ càng tin rằng đây là một cuộc tấn công và không phải lỗi nội bộ.

Nguyên nhân sâu xa: thay đổi hành vi query trong ClickHouse

Cloudflare chuyển đổi cách phân quyền truy vấn trên bảng Distributed của ClickHouse. Thay đổi này cho phép user thấy metadata từ cả database default và r0. Tuy nhiên mã cũ không lọc theo tên database, dẫn đến metadata bị trùng.

Tệp tính năng được tạo từ metadata này → nên số lượng feature tăng hơn gấp đôi.

Vì Bot Management preallocate bộ nhớ dựa trên giới hạn 200 feature → khi vượt ngưỡng → module panic → 5xx.

Ảnh hưởng lan truyền

• Workers KV bị ảnh hưởng → các dịch vụ phụ thuộc vào nó (như Access) cũng lỗi.

• Turnstile ảnh hưởng → người dùng không đăng nhập Dashboard được.

• Dashboard tiếp tục quá tải do backlog login, khôi phục lúc 15:30.

Các bước khắc phục và kế hoạch phòng ngừa

Cloudflare đang thực hiện:

✔ Gia cố quy trình tiếp nhận file cấu hình nội bộ

Như cách Cloudflare xử lý input từ khách hàng.

✔ Thêm kill-switch phạm vi toàn cầu

Cho phép tắt nhanh các tính năng có thể gây lỗi.

✔ Ngăn core dump và error report quá tải hệ thống

✔ Rà soát failure mode của tất cả module core proxy

Cloudflare khẳng định đây là sự cố tệ nhất kể từ 2019, và cam kết xây dựng hệ thống mạnh hơn sau sự cố.

Timeline chi tiết (theo giờ UTC)

Cloudflare đã cam kết rõ ràng:

“Một sự cố như thế này là không thể chấp nhận. Chúng tôi sẽ không để nó xảy ra lần nữa.”

Với triết lý “Build a better Internet”, Cloudflare đang biến sự cố 18/11 thành động lực để:

• Tăng độ tin cậy

• Tăng khả năng tự phục hồi

• Giảm thiểu tác động dây chuyền

• Đảm bảo dù bất kỳ thành phần nào gặp lỗi, mạng lưới vẫn tiếp tục hoạt động

Nguồn: Clouflare Blog