Cloudflare gặp sự cố gián đoạn trên mạng toàn cầu

 (cloudflarestatus.com)
1 điểm bởi GN⁺ 2025-11-19 | 1 bình luận | Chia sẻ qua WhatsApp
  • Mạng toàn cầu của Cloudflare gặp suy giảm hiệu năng dịch vụ nội bộ, khiến nhiều dịch vụ bị ảnh hưởng gián đoạn
  • Các dịch vụ chính như Access, Bot Management, CDN/Cache, Dashboard, Firewall, Network, WARP, Workers đã tạm thời gặp sự cố
  • Đội ngũ kỹ thuật đã xác định vấn đề và tiến hành khắc phục, trong đó dịch vụ WARP và Access được phục hồi trước
  • Sau đó, tỷ lệ lỗi và độ trễ trên toàn cầu dần trở lại mức bình thường, và dịch vụ Dashboard cũng được khôi phục
  • Hiện tại tất cả dịch vụ đang hoạt động bình thường và sự cố đã được giải quyết hoàn toàn

Tổng quan sự cố

  • Cloudflare gặp suy giảm hiệu năng dịch vụ nội bộ (Internal Service Degradation) khiến một số dịch vụ bị gián đoạn từng lúc
    • Các dịch vụ bị ảnh hưởng bao gồm Access, Bot Management, CDN/Cache, Dashboard, Firewall, Network, WARP, Workers
    • Công ty đã ngay lập tức bắt đầu công tác khôi phục và liên tục cập nhật tiến độ xử lý sự cố

Xác định vấn đề và phản ứng ban đầu

  • Cloudflare xác nhận tình trạng suy giảm dịch vụ nội bộ ở giai đoạn đang điều tra (Investigating)
    • Một số khách hàng gặp lỗi và độ trễ không liên tục
    • Đội ngũ kỹ thuật đồng thời phân tích nguyên nhân và thực hiện khôi phục
  • Sau đó, công ty xác định được nguyên nhân (Identified) và bắt đầu triển khai bản sửa lỗi
    • Trong quá trình sửa lỗi, kết nối WARP tại khu vực London đã tạm thời bị vô hiệu hóa, khiến người dùng tại khu vực này gặp lỗi kết nối Internet

Tiến trình khôi phục dịch vụ

  • Sau khi triển khai bản sửa lỗi, dịch vụ Access và WARP được phục hồi trước, đưa tỷ lệ lỗi trở lại mức trước sự cố
    • Kết nối WARP tại khu vực London đã được kích hoạt lại
  • Sau đó, công tác khôi phục dịch vụ cho khách hàng Application Services tiếp tục được triển khai
    • Các thay đổi để khôi phục dịch vụ Dashboard đã được phát hành
    • Một số khách hàng vẫn gặp vấn đề khi đăng nhập hoặc sử dụng Dashboard, nhưng đã được giải quyết bằng các bản sửa đổi bổ sung

Ổn định trở lại trên toàn mạng

  • Trên phạm vi toàn cầu, tỷ lệ lỗi và độ trễ (latency) dần giảm và trở lại mức bình thường
    • Việc tính điểm của Bot Management (bot scores) bị ảnh hưởng tạm thời, nhưng đã được khôi phục trong quá trình xử lý
    • Đội ngũ kỹ thuật đã loại bỏ các lỗi còn lại và đẩy nhanh quá trình khôi phục toàn bộ mạng
  • Sau đó, tất cả dịch vụ hoạt động bình thường và tỷ lệ lỗi cùng độ trễ đã hoàn toàn trở lại bình thường

Kết thúc sự cố và các bước tiếp theo

  • Cloudflare xác nhận mọi dịch vụ đang hoạt động bình thường và khép lại sự cố
    • Hiện không có thêm thay đổi cấu hình nào, và nền tảng đang được giám sát chặt chẽ
    • Điều tra sau sự cố (post-incident investigation) về nguyên nhân đang được tiến hành và kết quả sẽ được công bố sau
  • Sự cố lần này được ghi nhận là một sự kiện ảnh hưởng đến toàn bộ mạng toàn cầu

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-11-19
Ý kiến trên Hacker News

  • Một người có Cloudflare API token đã chia sẻ lệnh để tắt CF proxy
    Dùng lệnh curl để lấy zone ID và bản ghi DNS, rồi gửi yêu cầu PATCH đặt "proxied": false là được
    Tuy nhiên cần cẩn thận vì có nguy cơ mất chứng chỉ SSL, giảm bảo mật/hiệu năng, và lộ IP backend

    • Nếu chỉ có Global API Key kiểu cũ thì có thể dùng header X-Auth-Email và X-Auth-Key
      Ngoài ra, ai đang cấu hình chỉ cho phép lưu lượng từ Cloudflare thì cũng phải tạm tắt quy tắc đó
    • Tôi đã nghĩ lần sau sẽ dùng cách này, nhưng vì không tạo sẵn API token nên đành phải chờ
      May là giờ mọi thứ đã trở lại online
    • Tôi xử lý qua Terraform provider, nhưng cách này sẽ hữu ích cho những ai không vào được dashboard
    • Mẹo hay. Nhân tiện, trong curl thì GET là mặc định nên không cần -X GET
      Dùng tùy chọn -d sẽ tự động thành POST, còn với PATCH thì đúng là phải dùng -X PATCH
    • Bật Cloudflare WARP thì một số site hoạt động lại. 1.1.1.1 có lẽ cũng có hiệu quả tương tự
      Tuy vậy, kể cả sau khi tunnel thì vẫn còn một số site chỉ khôi phục được một phần

  • Theo CTO của Cloudflare, một lỗi tiềm ẩn trong hệ thống chặn bot đã bùng phát sau một thay đổi cấu hình và gây ra sự cố trên toàn mạng
    Ông giải thích trong nguồn này rằng đây không phải là tấn công mà là vấn đề nội bộ

    • Thật ngạc nhiên là các công ty lớn vẫn không triển khai thay đổi cấu hình theo từng giai đoạn
      Cả code lẫn cấu hình đều là dữ liệu, nhưng mô típ đẩy ra toàn cầu một lần rồi gây sự cố lớn vẫn cứ lặp lại
    • Giá mà thông tin cốt lõi này được đẩy lên đầu phần bình luận. Rất khó tìm giữa các bình luận suy đoán về tấn công mạng
    • Chỉ một thay đổi cấu hình mà cổ phiếu CF đã giảm 4%. Tôi tò mò về tác động kinh tế của những sự cố như vậy lên cả ngành

  • Một đồng nghiệp chạy bổ ra và nói rằng ngay sau khi anh ấy đổi cấu hình Cloudflare thì site bị sập, nên hoảng vì tưởng mình là người làm hỏng
    Xem bài này xong thì mới thở phào

    • Tôi đùa rằng: “Còn tệ hơn thế, chính cậu đã đánh sập toàn bộ Cloudflare đấy”
    • Nhưng biết đâu lại đúng? Trước đây từng có sự cố diện rộng của Fastly nên vẫn còn chút nghi ngờ
    • Tôi tự hỏi có từ nào diễn tả chính xác cảm giác nhẹ nhõm kỳ lạ khi biết rằng không phải có ai đó làm sai không
    • Biết đâu đồng nghiệp đó lại là nhân viên Cloudflare
    • Tôi cũng nhận hàng chục tin nhắn từ khách hàng báo site bị lỗi, mà hôm qua vừa đổi cấu hình nên toát mồ hôi lạnh
      Đến khi thấy dòng “Cloudflare down” thì thật sự nhẹ cả người

  • Kiểm tra ở Hà Lan thì thấy gần như mọi dịch vụ đều sập
    Dashboard Cloudflare cũng không truy cập được, dashboard Betterstack cũng vậy
    Trớ trêu là trang trạng thái vẫn sống nên lại không thể thông báo cho khách hàng

    • Tôi cũng gặp y như vậy. Lý do duy nhất HN vẫn ổn là vì không dùng Cloudflare
      Tôi đã viết một bài blog với quan điểm “đừng đặt sau Cloudflare nếu không cần”
    • Năm nào cũng lại nhận ra phụ thuộc quá nhiều vào AWS hay Cloudflare là rủi ro, nhưng không dễ thay thế
      Dù vậy, khi xảy ra sự cố quy mô lớn thế này thì khách hàng lại tỏ ra thông cảm hơn mình nghĩ
    • Dashboard Cloudflare không hẳn là chết hoàn toàn, mà là nếu đủ kiên trì thì vẫn có thể tắt proxy
      Mất vài phút nhưng tôi đã tách hcker.news khỏi CF
    • Nhìn tình huống này tôi thấy có lẽ sẽ có cơ hội kinh doanh nếu làm một dịch vụ dựng trang trạng thái trên VPS cục bộ
    • Trong side project Total Real Returns của tôi,
      tôi đặt một widget uptime thời gian thực liên kết với trang trạng thái bên ngoài ở phía dưới
      Có thể tham khảo SVG trạng thái và
      trang trạng thái bên ngoài

  • Có một cảm giác khoái trá khi thấy các dịch vụ self-hosted của mình vẫn chạy bình thường lúc Cloudflare hay AWS ngừng hoạt động
    Lúc này tôi còn ổn định hơn mức khả dụng 99.999% của họ

    • Cả site cá nhân đơn sơ của tôi cũng sống sót qua các sự cố của AWS, Azure và Cloudflare
      Giờ có lẽ tôi nên gắn thêm uptime tracker
    • Site self-hosted của tôi lại bị down chính vì Cloudflare proxy. Thật hụt hẫng
    • Các doanh nghiệp truyền thống đang gặp cảnh hệ thống như Oracle, SAP vẫn chạy ổn, còn chỉ các dịch vụ mới dựa trên cloud là dừng lại
      Đây là bài học mà các công ty SaaS non trẻ nên rút ra
    • Nhiều người hỏi xử lý DNS thế nào. Tôi cũng đang host trên Raspberry Pi, mà vừa chuyển DNS sang Cloudflare xong
      Việc site bé tí của mình bị sập vừa buồn cười vừa mang lại cảm giác thỏa mãn kỳ lạ

  • Gần đây có cảm giác sự cố hạ tầng quy mô lớn đang tăng vọt. Cả AWS lẫn Cloudflare đều kém xa SLA đã hứa

    • Điều đó trùng với thời điểm các tập đoàn lớn sa thải hàng loạt rồi tuyên bố thay thế bằng AI
    • Những sự cố như vậy làm tôi nhận ra số lượng số 9 trong SLA chẳng có nhiều ý nghĩa
      Đó chỉ là con số do doanh nghiệp tự định nghĩa chứ không phải uptime thực tế
    • Có người gọi đùa là “vibe code theory”. Một lý thuyết nửa đùa nửa thật rằng càng nhiều code viết theo cảm tính thì bug và outage càng nhiều
    • Cũng có phân tích cho rằng nguyên nhân là văn hóa vội vàng triển khai do vừa có thời gian cấm deploy cuối năm vừa bị áp lực mục tiêu Q4
    • Hoặc cũng có góc nhìn mang tính thuyết âm mưu rằng đây có thể là một cuộc tấn công mạng cấp quốc gia

  • Khi Cloudflare hay AWS ngừng hoạt động, việc một nửa web cũng dừng theo cho thấy vấn đề tập trung hóa nghiêm trọng đến mức nào

    • Người dùng cũng không quá bận tâm. Nhờ nhận thức kiểu “Internet bị hỏng rồi” mà từng dịch vụ riêng lẻ có thể né trách nhiệm
      Đó cũng là lý do cấu trúc này không thay đổi
    • Phòng chống DDoS có lợi thế kinh tế theo quy mô. Càng nhiều khách hàng thì băng thông càng lớn và khả năng phòng thủ càng mạnh
      CDN nhỏ rất khó cạnh tranh, và cuối cùng hình thành cấu trúc độc quyền tự nhiên
      Việc Cloudflare cung cấp gói miễn phí là chiến lược nhắm vào các hiệu ứng mạng như vậy
    • Điều đáng lo hơn cả một điểm lỗi đơn lẻ là sự tập trung hóa kiểu này có thể bóp méo các tiêu chuẩn web và tương lai của tự host
      Đồng thời nó cũng có thể trở thành mục tiêu tập trung cho kiểm duyệt của chính phủ
    • Let's Encrypt cũng là một rủi ro tiềm ẩn.
      Hai phần ba web đang phụ thuộc vào nó, thời hạn chứng chỉ ngày càng ngắn, và nếu bị tấn công hay gặp sự cố thì toàn bộ web có thể tê liệt
      Hiện tại đó là một tổ chức tốt, nhưng cũng đừng quên rằng Google trong quá khứ từng được nhìn nhận như thế
    • Sau làn sóng AWS, các lập trình viên đã phụ thuộc hoàn toàn vào cloud thay vì máy chủ chuyên dụng
      Backup ở cấp phần mềm thì có nhiều, nhưng kiến thức phổ thông về multi-hosting ở cấp hạ tầng lại đang biến mất

  • Trớ trêu thay, DownDetector cũng dùng Cloudflare Turnstile nên bị sập theo

    • Báo cáo AWS down cũng tăng vọt, nhưng rất có thể chỉ là dương tính giả
    • Tôi cũng thấy hiện tượng đó

  • Thông điệp xin lỗi bằng hình ảnh của Cloudflare: “Your browser: Working / Host: Working / Cloudflare: Error” khá ấn tượng

    • Đây là lần đầu tôi thấy màn hình như vậy. Chỉ có điều trong trường hợp của tôi thì “Host” lại là Cloudflare Pages nên ý nghĩa hơi mơ hồ
    • Việc bấm vào “Cloudflare” mà vẫn hiện hướng dẫn nói lỗi nằm ở máy chủ khách hàng thì hơi buồn cười
    • Tôi thích sự thẳng thắn của thông điệp đó, nhưng người dùng thì chỉ phản ứng kiểu “hãy sửa Wi‑Fi đi”
    • Dù sao nó cũng giúp xác định tình hình rõ ràng để ứng phó. Nếu cần thì có thể tắt proxy để giảm thiểu ảnh hưởng đến dịch vụ
    • Tôi cũng đã lục log suốt một tiếng rồi mới nhận ra không phải lỗi ở server của mình

  • Các site dùng Cloudflare Challenge (“I’m not a robot”) cũng trả về lỗi HTTP 500 rồi ngừng hoạt động
    Xuất hiện thông báo “hãy bỏ chặn challenges.cloudflare.com”

    • Dạo này mức độ xử lý lỗi quá tệ. Các công ty né trách nhiệm bằng cách đổ lỗi cho người dùng
      hoặc chỉ hiện màn hình tải vô tận. Trong khi thực tế backend trả lỗi rất rõ, thì frontend lại che đi
      Gần đây tôi còn thấy trường hợp lỗi mật khẩu quá dài bị đổi thành “email đã được sử dụng”
    • Vì sự cố này mà AI Search (GPT5) trên chat.bing.com cũng ngừng hoạt động
      Trớ trêu thay, lại rơi vào cảnh phải chứng minh với AI rằng mình là con người
    • Một số site (như pinkbike) hiển thị thông báo “you have been blocked”
    • Tức là không chỉ robot mà cả người thật cũng bị chặn /s
    • Có vẻ frontend hiểu nhầm rằng người dùng đã chặn domain bằng DNS hoặc extension
      Kiểu phủ nhận theo giọng /s rằng Cloudflare Captcha không thể nào sập được khá buồn cười