Cấu hình CDN Cloudflare cho website (bản cập nhật 2026)

Cloudflare đứng giữa người dùng và máy chủ gốc (origin — máy chủ thật chứa website của bạn). Khi cấu hình đúng, phần lớn yêu cầu được trả từ điểm biên gần người dùng nhất thay vì đi tới origin, kéo thời gian phản hồi byte đầu (TTFB) xuống và gián tiếp cải thiện LCP (Largest Contentful Paint — thời điểm phần tử lớn nhất hiện ra). Web22 dùng chính Cloudflare cho web22.dev, nên hướng dẫn dưới đây bám theo bảng điều khiển thật của năm 2026 — nơi nhiều tính năng cũ như Page Rules hay Auto Minify đã bị thay thế.

Bước 1 — Bật proxy DNS (đám mây cam)

Mọi thứ bắt đầu ở tab DNS. Mỗi bản ghi A/AAAA/CNAME có một biểu tượng đám mây. Đám mây màu cam nghĩa là lưu lượng đi qua Cloudflare (được proxy, có cache và CDN); đám mây xám nghĩa là chỉ phân giải DNS, lưu lượng đi thẳng tới origin — không có cache, không có CDN.

• Bản ghi gốc @ và www phục vụ HTML → để cam.
• Bản ghi mail, MX, hay subdomain ký SSL riêng (vd cổng SSH, panel host) → để xám để tránh proxy phá kết nối.

Đây là điều kiện cần: nếu đám mây xám, mọi cấu hình cache phía dưới đều vô tác dụng vì Cloudflare không nhìn thấy lưu lượng.

Bước 2 — Chế độ SSL và mức cache

Vào SSL/TLS → Overview, chọn chế độ Full (strict) nếu origin đã có chứng chỉ hợp lệ (gần như mọi host hiện đại đều có). Chế độ Flexible dễ gây vòng lặp chuyển hướng và cảnh báo nội dung hỗn hợp (mixed content) — nên tránh.

Mức cache mặc định nằm ở Caching → Configuration → Caching Level. Để Standard: Cloudflare cache theo phần mở rộng file (ảnh, CSS, JS, font) nhưng không cache HTML. Đó là hành vi an toàn cho phần lớn site động như WordPress, vì HTML thường chứa nội dung tùy người dùng (giỏ hàng, trạng thái đăng nhập).

Bước 3 — Cache Rules thay cho Page Rules

Đây là thay đổi lớn nhất bạn cần biết năm 2026: Page Rules đã bị Cloudflare ngừng phát triển, thay bằng hệ Cache Rules (và Configuration Rules, Redirect Rules) với cú pháp biểu thức linh hoạt hơn. Nếu tài liệu cũ bảo bạn tạo Page Rule “Cache Everything”, hãy bỏ qua — giờ làm ở Caching → Cache Rules.

Tùy chọn tương đương “Cache Everything” cũ giờ là Eligible for cache. Ví dụ một Cache Rule để cache toàn bộ HTML cho một blog tĩnh:

If: (http.request.uri.path contains "/blog/")
   and not (http.cookie contains "wordpress_logged_in")
Then:
   Cache eligibility: Eligible for cache
   Edge TTL: 1 day
   Browser TTL: respect origin

Điều kiện loại trừ cookie đăng nhập rất quan trọng: nó đảm bảo người soạn bài và khách mua hàng luôn thấy bản động, chỉ khách vãng lai mới nhận bản cache. Với WordPress có giỏ hàng, đừng cache đường dẫn giỏ hàng, thanh toán, tài khoản.

Bước 4 — Nén Brotli (giờ tự bật)

Trước đây có một công tắc Brotli riêng. Năm 2026 công tắc đó đã bị gỡ: Brotli được bật mặc định cho mọi zone không phải Enterprise, và bạn điều chỉnh hành vi nén qua Compression Rules nếu cần. Brotli nén văn bản (HTML, CSS, JS) tốt hơn gzip vài phần trăm, giúp file tải nhanh hơn — bạn thường không phải làm gì, chỉ kiểm tra bằng header phản hồi content-encoding: br.

Bước 5 — Minify đã bị khai tử, làm ở origin

Một cảnh báo quan trọng: tính năng Auto Minify (HTML/CSS/JS) đã bị Cloudflare gỡ bỏ hoàn toàn từ 2024. Bảng điều khiển không còn công tắc này. Cloudflare khuyến nghị minify ở origin lúc build — tức để plugin cache trên WordPress (vd LiteSpeed Cache, WP Rocket) hoặc bước đóng gói của bạn lo việc rút gọn JS và CSS.

Bài học thực chiến từ Web22: việc minify ở plugin origin lại sinh một cái bẫy cache với Cloudflare. Khi plugin tạo file minify với tên cố định (vd style.min.css không đổi sau mỗi lần sửa), Cloudflare đã cache bản cũ tại biên sẽ tiếp tục trả bản cũ — khách thấy giao diện vỡ dù bạn đã sửa. Cách chống: dùng plugin gắn chuỗi version vào URL (cache busting), hoặc purge cache sau khi đổi tài nguyên.

Bước 6 — Always Online và Development Mode

Hai công tắc dễ hiểu nhầm trong tab Caching → Configuration:

Development Mode là cách nhanh nhất để gỡ bẫy “khách thấy bản cũ” mà không phải purge thủ công: bật lên, sửa thoải mái, xem kết quả tức thì, rồi để nó tự tắt sau 3 giờ. Đừng quên — nếu để bật lâu, bạn mất toàn bộ lợi ích tốc độ của CDN.

Bước 7 — Tinh chỉnh cache trình duyệt

Cloudflare cache ở biên, nhưng cache phía trình duyệt người dùng mới giúp lần ghé sau gần như tức thì. Bạn kiểm soát thời gian này qua trường Browser TTL trong Cache Rule, hoặc đặt header ở origin. Cách đặt header Cache-Control đúng cho từng loại tài nguyên được mô tả kỹ trong bài cấu hình cache trình duyệt qua HTTP header — đọc kèm để hai tầng cache phối hợp nhịp nhàng.

Kiểm tra sau khi cấu hình

1. Mở DevTools → tab Network, tải lại trang. Tìm header cf-cache-status: HIT là cache trúng, MISS/DYNAMIC là chưa cache (HTML động thường là DYNAMIC — bình thường).
2. Kiểm tra content-encoding: br để xác nhận Brotli đang chạy.
3. Đo lại bằng PageSpeed Insights để xem TTFB và LCP có cải thiện ở dữ liệu thực tế hay không.

Ngưỡng “Good” của Core Web Vitals năm 2026 vẫn là LCP ≤ 2,5s, INP ≤ 200ms, CLS ≤ 0,1 (đo ở phân vị 75 — p75 dữ liệu người dùng thật). CDN giúp nhiều nhất cho TTFB và LCP; INP và CLS phụ thuộc mã nguồn trang, không phải CDN.

Câu hỏi thường gặp

Cloudflare miễn phí có đủ cấu hình CDN không?

Đủ cho phần lớn site nhỏ và vừa. Gói Free đã có proxy DNS, Cache Rules, Brotli và Always Online. Các gói trả phí thêm Argo, Cache Reserve và nhiều rule hơn.

Bật Cloudflare rồi mà tốc độ không đổi?

Thường do HTML không được cache (đúng với site động) nên TTFB lần đầu vẫn phụ thuộc origin. Hãy tạo Cache Rule cho phần tĩnh và tối ưu origin song song; CDN không thay thế được một origin chậm.

Có nên cache toàn bộ HTML không?

Chỉ nên với trang thật sự tĩnh và đã loại trừ người dùng đăng nhập qua điều kiện cookie. Với cửa hàng hay trang có giỏ hàng/tài khoản, cache HTML sai chỗ sẽ làm lộ phiên của người khác.

Nếu bạn muốn ai đó dựng sẵn bộ Cache Rules và đo lại Core Web Vitals giúp, dịch vụ tối ưu tốc độ website của Web22 làm được phần này.