Sự cố Cloudflare ngày 18/11/2025: Từ lỗi cấu hình đến sự gián đoạn toàn cầu

Ngày 18/11/2025, Cloudflare - nhà cung cấp CDN và dịch vụ an ninh mạng hàng đầu thế giới - đã gặp sự cố nghiêm trọng, khiến hàng loạt trang web và ứng dụng sử dụng hạ tầng của Cloudflare bị gián đoạn truy cập. Mất hàng giờ đồng hồ, sự cố mới được khác phục, tuy vẫn còn ảnh hưởng ở một số khu vực.

Vào khoảng 11:20 UTC (18:20 Việt Nam) ngày 18/11/2025, người dùng toàn cầu không thể truy cập các trang sử dụng Cloudflare như ChatGPT, X, Discord, Canva, v.v.. Tại Việt Nam, ghi nhận đợt gián đoạn truy cập lớn từ 18:48 (giờ Việt Nam) trên nhiều website, trong đó có TotHost .  Theo Reuters, báo cáo từ Downdetectors (*) cho thấy: Đến 15:20 UTC (22:20 Việt Nam), số báo cáo về sự cố giảm từ 11,000 lúc cao điểm xuống 2,800.

Cloudflare xác nhận đây là sự cố nghiêm trọng nhất từ sau vụ outage năm 2019. Những dịch vụ ảnh hưởng nghiêm trọng gồm có:

• Core CDN & Security: Gây lỗi HTTP 5xx toàn cầu.
• Turnstile: Không tải được → ảnh hưởng đăng nhập Dashboard.
• Workers KV: Gây lỗi 5xx nghiêm trọng.
• Dashboard: Người dùng không thể đăng nhập do Turnstile lỗi.
• Cloudflare Access: Lỗi xác thực hàng loạt, mất kết nối tạm thời.
• Email Security: Giảm độ chính xác trong phát hiện spam, tuy nhiên không ảnh hưởng lớn đến khách hàng.

DDoS không phải nguyên nhân sự cố

Theo CloudFlare, nguồn căn của sự cố này không phải do tấn công mạng như dự đoán ban đầu của họ, mà do lỗi cấu hình nội bộ: Một thay đổi quyền truy cập cơ sở dữ liệu khiến tệp cấu hình của module Bot Management bị phình to gấp đôi kích thước. Khi tệp này bị đẩy lên hàng ngàn máy chủ của Cloudflare trên toàn cầu, phần mềm định tuyến mạng không xử lý nổi do kích thước tệp quả lớn. Và kết quả là gây crash và lỗi HTTP 5xx trên diện rộng.

Nguyên nhân kỹ thuật sâu hơn: Tệp cấu hình “feature file” phục vụ hệ thống Bot Management bị tạo ra sai từ truy vấn ClickHouse do cập nhật quyền mới. Tệp chứa hơn 200 features - vượt giới hạn bộ nhớ, gây panic trong module xử lý, tạo ra lỗi HTTP 500 trên toàn mạng. 

Module bot ảnh hưởng đến cả proxy lõi, Workers KV và Access, có mức độ ảnh hưởng đặc biệt nghiêm trọng. Lỗi toàn bộ hệ thống định tuyến core (Frontline/FL) xử lý request HTTP toàn cầu. Khi proxy core sập, mọi request trên toàn mạng Cloudflare bị lỗi HTTP 5xx.

Diễn biến khắc phục

Thời gian gián đoạn kéo dài một phần do lỗi phức tạp, khó nhận diện. Công ty mất gần 3 tiếng để xác định đúng nguyên nhân, và gần 6 tiếng để toàn hệ thống hồi phục.

• 11:05    Thay đổi quyền truy cập trong cơ sở dữ liệu được triển khai.
• 11:28    Bắt đầu có lỗi, traffic HTTP khách hàng bị ảnh hưởng.
• 11:32 - 13:05    Các nhóm kỹ thuật điều tra sự cố, ban đầu nghi ngờ DDoS.
• 13:05    Triển khai bypass tạm thời cho Workers KV & Cloudflare Access.
• 14:24    Dừng phát tán file cấu hình lỗi, triển khai lại bản cũ ổn định.
• 14:30    Khôi phục phần lớn hệ thống.
• 17:06    Tất cả dịch vụ hoạt động trở lại bình thường.

Vì sao sự cố của CloudFlare gây ảnh hưởng toàn cầu?

Cloudflare là một mắt xích lớn, một phần hạ tầng trung tâm của Internet hiện đại:

• Phạm vi khách hàng lớn: Theo W3Techs (2023), Cloudflare là nhà cung cấp CDN lớn nhất thế giới, chiếm hơn 80% thị phần CDN trên các website có CDN, và được dùng bởi khoảng 20% tổng số website toàn cầu. Trong đó, có những ông lớn như X, Discord, Canva, ChatGPT. Khi hệ thống của Cloudflare gặp sự cố, hàng triệu website cùng lúc không thể truy cập, gây gián đoạn quy mô toàn cầu. Đây không chỉ là một “lỗi kỹ thuật”, mà là một điểm nghẽn toàn cầu (global chokepoint).

• Cung cấp dịch vụ CDN, Cloudflare hoạt động như một proxy trung gian giữa người dùng và server gốc: Bởi vậy, nếu proxy lỗi, request không thể tiếp cận server gốc, dù server vẫn hoạt động. Khi sự cố xảy ra, tất cả truy cập đều bị chặn lại tại Cloudflare, dẫn đến hiện tượng "mạng vẫn có, server vẫn sống, nhưng website không vào được".

Khi mắt xích này gặp vấn đề, việc toàn bộ hệ sinh thái Internet bị ảnh hưởng là điều không thể tránh khỏi. 

Nên làm gì khi gặp sự cố gián đoạn do CloudFlare?

Khi sự cố như vửa rồi xảy ra, người dùng dịch vụ gần như không thể chủ động khắc phục hoàn toàn vì lỗi nằm ở core proxy của Cloudflare. Đặc biệt, nếu bạn chỉ dùng DNS của Cloudflare mà không có quyền ở nơi khác, hoặc website của bạn bắt buộc phải đi qua Cloudflare (proxy bắt buộc). Nếu không, vẫn có một số biện pháp tạm thời giúp giảm thiểu thiệt hại hoặc nhanh chóng phục hồi.

1. Tạm thời bypass Cloudflare

Cách này chỉ áp dụng được nếu bạn không sử dụng WAF, firewall, hoặc Access bắt buộc qua Cloudflare. Nếu dùng SSL từ Cloudflare, cần đảm bảo server gốc có SSL riêng.

Cách làm:

• Thay đổi DNS record từ proxy (Orange cloud) sang DNS only (Gray cloud) trên dashboard (nếu vẫn truy cập được).
• Hoặc cập nhật DNS trỏ trực tiếp về IP gốc từ bên ngoài (nếu dashboard không truy cập được, nhưng bạn còn quyền với DNS domain ở nơi khác).

2. Tách phần backend ra khỏi Cloudflare

Nếu kiến trúc site/app bạn có thể phân vùng (có kiến trúc microservice):

• Cho phép frontend tạm thời down, nhưng backend/API vẫn hoạt động riêng.
• Có thể chuyển một số traffic sang vùng backup không đi qua Cloudflare (nếu có thiết lập multi-CDN từ trước).

3. Liên hệ Cloudflare Enterprise Support

Khách hàng Enterprise có SLA và hotline riêng, có thể được hỗ trợ sớm hơn hoặc cung cấp bản vá/kênh proxy tạm thời.

Tóm lại, khi Cloudflare gặp sự cố nặng như ngày 18/11/2025, khả năng xử lý của người dùng rất hạn chế, trừ khi đã có sẵn kiến trúc phân tầng, DNS riêng hoặc gói Enterprise.

4. Biện pháp tốt nhất là lập phương án dự phòng về lâu dài

• Xây dựng multi-CDN hoặc kiến trúc fallback (VD: thêm AWS CloudFront, Akamai…)
• Giữ lại quyền quản trị DNS độc lập (VD: sử dụng Cloudflare chỉ cho proxy, nhưng DNS chính đặt ở registrar khác như Namecheap, DNSPod...)
• Có bản cập nhật hệ thống cho người dùng khi xảy ra downtime bất khả kháng.
• Duy trì kênh thông tin thay thế cho người dùng như Facebook, Telegram, email, Discord, Zalo,... Khi đó, dù không truy cập được website, bạn vẫn có thể liên hệ, cập nhật tình hình với khách hàng.

Sau khi khắc phục được sự cố, Cloudflare đã mạnh mẽ tuyên bố: “Bất kỳ sự ngưng trệ nào trong hệ thống của chúng tôi đều là điều không thể chấp nhận”. Họ cũng cam kết sẽ thực hiện nhiều thay đổi hệ thống để đảm bảo tính ổn định cao hơn trong tương lai. Tuy vậy, sự cố lần này thêm một lần nữa khẳng định "Được mùa lo thất bát" là không bao giờ thừa. Việc đầu tư vào kiến trúc phân tầng, dự phòng CDN hay giữ quyền kiểm soát DNS riêng là bước chuẩn bị cần thiết – dù có thể chưa thấy lợi ích ngay, nhưng sẽ vô cùng giá trị khi rủi ro xảy ra.

(*) Note: Downdetectors là công cụ theo dõi sự cố ngừng hoạt động bằng cách tổng hợp các báo cáo trạng thái từ nhiều nguồn. Do số liệu dựa trên báo cáo do người dùng gửi, nên số lượng người dùng bị ảnh hưởng có thể khác với thực tế.