❤️ AZDIGI chính thức cập nhật hệ thống blog mới hoàn chỉnh. Tuy nhiên có thể một số bài viết bị sai lệch hình ảnh, hãy ấn nút Báo cáo bài viết ở cuối bài để AZDIGI cập nhật trong thời gian nhanh nhất. Chân thành cám ơn.

Nếu bạn đã thêm domain vào Cloudflare và bật proxy (đám mây cam), thì website của bạn đang được hưởng lợi từ CDN mà chưa cần cấu hình gì thêm. Nhưng để tận dụng tối đa khả năng caching, giảm tải server gốc và tăng tốc thực sự, bạn cần hiểu rõ cơ chế hoạt động và biết cách tinh chỉnh.

Bài này mình sẽ đi từ cách CDN Cloudflare vận hành, mặc định cache những gì, cho đến cách tạo Cache Rules để kiểm soát chi tiết hơn. Cuối bài có hướng dẫn kiểm tra cache bằng dòng lệnh để bạn xác nhận mọi thứ hoạt động đúng.

CDN Cloudflare hoạt động như thế nào?

CDN (Content Delivery Network) là mạng lưới máy chủ phân tán khắp thế giới. Khi ai đó truy cập website của bạn, CDN sẽ phục vụ nội dung từ máy chủ gần nhất thay vì phải đi vòng về server gốc.

Cloudflare sử dụng mô hình anycast network với hơn 300 điểm hiện diện (PoPs) trên toàn cầu. Điều này có nghĩa là mọi PoP đều chia sẻ cùng một địa chỉ IP. Khi người dùng gửi request, hệ thống routing của internet tự động đưa request đó đến PoP gần nhất về mặt mạng.

Ví dụ: server gốc của bạn đặt tại Singapore. Một người dùng ở Hà Nội truy cập website, request sẽ được xử lý tại PoP Hà Nội (hoặc TP.HCM) thay vì phải đi tới Singapore. Nếu nội dung đã được cache tại PoP đó, người dùng nhận response gần như ngay lập tức.

Quy trình cụ thể khi có request:

  1. Người dùng truy cập example.com/style.css
  2. DNS trả về IP anycast của Cloudflare
  3. Request đến PoP gần nhất
  4. Nếu file đã có trong cache (HIT) → trả về ngay, không cần hỏi server gốc
  5. Nếu chưa có (MISS) → PoP lấy từ server gốc, lưu cache, rồi trả về cho người dùng
  6. Các request tiếp theo cho cùng file đó sẽ được phục vụ từ cache

Cloudflare mặc định cache những gì?

Ngay khi bật proxy, Cloudflare tự động cache các file tĩnh (static files) dựa trên phần mở rộng. Danh sách bao gồm:

  • Ảnh: .jpg, .jpeg, .png, .gif, .webp, .svg, .ico, .bmp, .tiff
  • CSS/JS: .css, .js
  • Font: .woff, .woff2, .ttf, .eot, .otf
  • Video/Audio: .mp4, .webm, .mp3, .ogg
  • Tài liệu: .pdf, .doc, .docx, .xls, .pptx
  • Khác: .zip, .gz, .tar, .rar, .7z

Lưu ý quan trọng: Cloudflare KHÔNG cache HTML mặc định. Trang chủ, bài viết, trang sản phẩm đều có CF-Cache-Status: DYNAMIC, nghĩa là mỗi request đều phải về server gốc. Nếu muốn cache HTML, bạn cần tạo Cache Rules (phần tiếp theo).

Bảng thống kê cache CloudFlare

Bạn có thể xem tổng quan cache tại Caching → Overview. Trang này hiển thị số lượng request được cache (served from edge) so với request phải về origin trong 24 giờ qua.

Cache Rules: kiểm soát cache chi tiết

Cập nhật 2026: Page Rules đang trong quá trình ngừng hoạt động (sunset). Cloudflare khuyến nghị chuyển sang Cache Rules tại mục Caching → Cache Rules. Cache Rules mạnh hơn, linh hoạt hơn và có thể tạo nhiều rule hơn so với giới hạn 3 rule miễn phí của Page Rules.

Cache Rules cho phép bạn kiểm soát chính xác những gì Cloudflare cache, cache bao lâu, và khi nào bỏ qua cache. Một số use case phổ biến:

Cache toàn bộ HTML cho trang tĩnh

Nếu website của bạn là blog hoặc landing page ít thay đổi, cache HTML giúp giảm đáng kể tải cho server gốc.

Vào Caching → Cache Rules → Create rule, cấu hình như sau:

  • Rule name: Cache HTML toàn site
  • When: Hostname equals example.com
  • Then → Cache eligibility: Eligible for cache
  • Edge TTL: 2 hours (hoặc tùy nhu cầu)
  • Browser TTL: 10 minutes

Bypass cache cho trang admin

Bạn không muốn cache trang quản trị WordPress hoặc các trang có nội dung động theo user:

  • When: URI Path starts with /wp-admin OR Cookie contains wordpress_logged_in
  • Then → Cache eligibility: Bypass cache

Tuỳ chỉnh TTL cho từng đường dẫn

Một điểm mạnh của Cache Rules so với Page Rules cũ là khả năng đặt TTL khác nhau cho từng loại nội dung:

  • Trang chủ: Edge TTL 1 giờ (cập nhật thường xuyên)
  • Bài viết cũ: Edge TTL 1 ngày (ít thay đổi)
  • Ảnh/CSS/JS: Edge TTL 1 tháng (gần như không đổi)

Giao diện tạo Cache Rule khá trực quan. Bạn chọn điều kiện match (hostname, URI, cookie, header…) rồi chọn hành động cache tương ứng.

Browser TTL và Edge TTL: khác nhau chỗ nào?

Đây là hai khái niệm dễ nhầm lẫn nhưng hoạt động ở hai tầng hoàn toàn khác nhau:

Edge TTL (thời gian cache tại Cloudflare edge server):

  • Quyết định Cloudflare giữ bản copy của file bao lâu
  • Khi hết TTL, request tiếp theo sẽ phải về server gốc lấy bản mới
  • Edge TTL dài = ít request về origin = giảm tải server

Browser TTL (thời gian cache trên trình duyệt người dùng):

  • Quyết định trình duyệt giữ file trong bộ nhớ cache bao lâu
  • Khi hết TTL, trình duyệt sẽ gửi request mới (dù có thể vẫn nhận HIT từ edge)
  • Browser TTL dài = ít request hơn = trang load nhanh hơn cho lần truy cập sau

Nguyên tắc chung: Edge TTL nên dài hơn hoặc bằng Browser TTL. Ví dụ Edge TTL 4 giờ, Browser TTL 1 giờ. Như vậy dù trình duyệt hết cache và gửi request mới, Cloudflare vẫn phục vụ từ edge mà không cần về origin.

Mặc định, Cloudflare tuân theo header Cache-Control từ server gốc. Nếu server gốc trả Cache-Control: max-age=3600, Cloudflare sẽ dùng giá trị đó cho cả Edge TTL và Browser TTL (trừ khi bạn ghi đè bằng Cache Rules).

Purge Cache: xóa cache khi cần

Khi bạn cập nhật nội dung (sửa bài viết, đổi CSS, upload ảnh mới), bản cũ vẫn nằm trong cache cho đến khi hết TTL. Để nội dung mới hiển thị ngay, bạn cần purge (xóa) cache.

Cloudflare cung cấp 3 cách purge tại Caching → Configuration:

cf-05-purge.png

Purge Everything

Xóa toàn bộ cache trên tất cả PoP. Đơn giản nhưng tàn khốc: sau khi purge, mọi request đều phải về origin cho đến khi cache được xây dựng lại. Chỉ dùng khi thật cần thiết (ví dụ deploy phiên bản mới hoàn toàn).

Purge by URL

Chỉ xóa cache của một hoặc vài URL cụ thể. Phù hợp khi bạn sửa một bài viết hay thay một file CSS.

Hoặc cũng có thể sử dụng API để xoá cache như ví dụ bên dưới.

# Ví dụ purge URL cụ thể qua API
curl -X POST "https://api.cloudflare.com/client/v4/zones/ZONE_ID/purge_cache" \
  -H "Authorization: Bearer API_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"files":["https://example.com/style.css","https://example.com/bai-viet-da-sua/"]}'

Purge by Cache-Tag / Prefix

Gói Enterprise hỗ trợ purge theo tag hoặc prefix. Bạn gắn header Cache-Tag vào response từ origin, sau đó purge toàn bộ file có chung tag đó. Rất hữu ích cho site lớn với nhiều loại nội dung.

Trong thực tế, nếu bạn dùng WordPress, hầu hết các plugin cache (WP Rocket, W3 Total Cache, hay plugin chính thức Cloudflare) đều tự động purge cache khi bạn cập nhật bài viết, nhưng cần phải chú ý cấu hình tích hợp CloudFlare vào plugin đó.

Tiered Cache: giảm tải origin bằng cache nhiều tầng

Mặc định, khi một PoP không có file trong cache (MISS), nó sẽ gửi request thẳng về server gốc. Với hơn 300 PoP, điều này có nghĩa server gốc có thể nhận rất nhiều request trùng lặp từ các PoP khác nhau.

Tiered Cache thêm một tầng trung gian. Thay vì mọi PoP đều hỏi origin, các PoP nhỏ sẽ hỏi một PoP lớn hơn (upper-tier) trước. Chỉ khi upper-tier cũng không có thì request mới về origin.

Luồng hoạt động:

  1. Người dùng tại Đà Nẵng request file → PoP Đà Nẵng không có cache (MISS)
  2. Thay vì hỏi origin, PoP Đà Nẵng hỏi upper-tier (ví dụ PoP Singapore)
  3. PoP Singapore có file → trả về cho Đà Nẵng (tiết kiệm được một chuyến về origin)
  4. PoP Đà Nẵng lưu cache và phục vụ người dùng

Kết quả: origin server nhận ít request hơn đáng kể, đặc biệt với website có lượng truy cập phân tán ở nhiều khu vực.

Bạn bật Tiered Cache tại Caching → Tiered Cache. Gói Free được dùng Smart Tiered Cache Topology (Cloudflare tự chọn upper-tier tối ưu). Gói trả phí có thêm tùy chọn chọn topology thủ công.

Ghi chú: Ngoài Tiered Cache, Cloudflare còn có Smart Shield, một lớp bảo vệ origin bổ sung với connection reuse và dedicated egress IPs. Smart Shield là product riêng, không thay thế Tiered Cache hay Cache Reserve. Cả 3 hoạt động độc lập và bổ trợ cho nhau.

Tối ưu tốc độ: Auto Minify và Brotli

Ngoài caching, Cloudflare còn có một số tính năng giúp giảm dung lượng file và tăng tốc tải trang. Bạn tìm thấy các tùy chọn này tại Speed → Optimization.

Auto Minify

Tự động loại bỏ khoảng trắng, comment và ký tự thừa trong JavaScript, CSS, HTML. Giảm dung lượng file từ 10 đến 30% tùy trường hợp.

Bạn có thể bật/tắt riêng cho từng loại file:

  • JavaScript: Nên bật. Hầu hết file JS đều có comment và khoảng trắng có thể loại bỏ.
  • CSS: Nên bật. Tương tự JS.
  • HTML: Cẩn thận hơn. Một số template phụ thuộc vào khoảng trắng trong HTML. Bật thử và kiểm tra kỹ layout.

Lưu ý: Nếu bạn đã dùng build tool (Webpack, Vite, esbuild) để minify sẵn, Auto Minify của Cloudflare sẽ không có nhiều tác dụng thêm. Trong trường hợp đó, có thể tắt để tránh xử lý thừa.

Brotli Compression

Brotli là thuật toán nén do Google phát triển, hiệu quả hơn Gzip khoảng 15 đến 20% cho nội dung text (HTML, CSS, JS). Cloudflare bật Brotli mặc định cho tất cả các gói.

Khi trình duyệt gửi header Accept-Encoding: br, Cloudflare sẽ trả response đã nén Brotli. Trình duyệt hiện đại đều hỗ trợ Brotli, nên bạn gần như không cần lo.

cf-05-speed.png

Early Hints và HTTP/2

Hai tính năng này giúp trình duyệt bắt đầu tải tài nguyên sớm hơn, trước khi server gốc trả xong response chính.

Early Hints (103)

Khi trình duyệt gửi request, Cloudflare trả ngay một response sơ bộ (HTTP 103) chứa danh sách các tài nguyên quan trọng (CSS, font, JS) mà trang sẽ cần. Trình duyệt bắt đầu tải các file này trong khi chờ server gốc xử lý xong response HTML chính.

Kết quả là thời gian “chờ trắng” (white screen) giảm đi rõ rệt, đặc biệt với trang có thời gian xử lý phía server lâu (dynamic page, database query nặng).

Bật Early Hints tại Speed → Optimization → Protocol Optimization.

HTTP/2 và HTTP/3

Cloudflare tự động bật HTTP/2 cho mọi domain dùng proxy. HTTP/2 cho phép multiplexing (tải nhiều file song song trên cùng một kết nối), header compression, và server push.

HTTP/3 (dựa trên QUIC) cũng được hỗ trợ sẵn. HTTP/3 cải thiện hiệu suất trên mạng không ổn định (mobile, Wi-Fi yếu) nhờ giảm thiểu ảnh hưởng của packet loss.

Bạn không cần cấu hình gì, cả hai đều được bật mặc định khi dùng Cloudflare proxy. Có thể kiểm tra lại bằng cách dùng công cụ kiểm tra HTTP/3 của AZDIGI tại https://tools.azdigi.com/tools/http-protocol.

Kiểm tra cache bằng CF-Cache-Status header

Sau khi cấu hình xong, bạn cần kiểm tra xem cache có hoạt động đúng không. Cách đơn giản nhất là đọc response header CF-Cache-Status mà Cloudflare trả về cùng mỗi response.

Các giá trị phổ biến:

  • HIT: File được phục vụ từ cache Cloudflare. Đây là trạng thái lý tưởng.
  • MISS: File không có trong cache, phải lấy từ origin. Lần request sau sẽ là HIT (nếu file đủ điều kiện cache).
  • BYPASS: Cloudflare bỏ qua cache (do cookie, query string, hoặc Cache Rule bypass).
  • DYNAMIC: Nội dung không đủ điều kiện cache (ví dụ HTML khi chưa có Cache Rule).
  • EXPIRED: Bản cache đã hết TTL, Cloudflare đang lấy bản mới từ origin.
  • REVALIDATED: Cloudflare xác nhận bản cache vẫn còn hợp lệ với origin (qua If-Modified-Since hoặc ETag).

Dùng curl để kiểm tra

Mở terminal và chạy:

# Kiểm tra header của một URL
curl -I https://example.com/style.css

Kết quả trả về sẽ có dạng:

HTTP/2 200
content-type: text/css
cf-cache-status: HIT
age: 3412
cache-control: public, max-age=14400
cf-ray: 8a1b2c3d4e5f-SGN
server: cloudflare

Những header cần chú ý:

  • cf-cache-status: HIT → File đang được cache, tốt rồi.
  • age: 3412 → File đã nằm trong cache 3412 giây (khoảng 57 phút).
  • cache-control: public, max-age=14400 → TTL là 14400 giây (4 giờ).
  • cf-ray: ...SGN → Phần cuối cho biết PoP phục vụ (SGN = TP.HCM).

Nếu bạn muốn kiểm tra một trang HTML (thường là DYNAMIC):

# Kiểm tra trang HTML
curl -I https://example.com/
# Chỉ lọc header liên quan cache
curl -sI https://example.com/ | grep -i "cf-cache\|cache-control\|age:"

Nếu thấy cf-cache-status: DYNAMIC cho trang HTML và bạn muốn cache nó, quay lại phần Cache Rules ở trên để tạo rule phù hợp.

Tổng kết và tips tối ưu

CDN và caching là nền tảng giúp website nhanh hơn mà không cần nâng cấp server. Tóm lại những gì cần nhớ:

  • Bật proxy (đám mây cam) là bước đầu tiên. Không bật proxy thì không có CDN, không có cache.
  • Static files được cache tự động. Bạn không cần làm gì thêm cho ảnh, CSS, JS.
  • HTML cần Cache Rules. Nếu site ít thay đổi, hãy tạo rule cache HTML với Edge TTL phù hợp.
  • Dùng Cache Rules thay Page Rules. Page Rules đang bị ngừng hỗ trợ, Cache Rules linh hoạt hơn nhiều.
  • Bật Tiered Cache. Giảm tải origin đáng kể, đặc biệt với site có traffic từ nhiều quốc gia.
  • Bypass cache cho trang admin và nội dung động. Tránh phục vụ nội dung cũ cho người dùng đã đăng nhập.
  • Purge cache có chọn lọc. Purge by URL thay vì Purge Everything khi có thể.
  • Kiểm tra bằng curl. Xác nhận CF-Cache-Status là HIT cho những URL bạn muốn cache.
  • Edge TTL ≥ Browser TTL. Đảm bảo Cloudflare luôn có bản cache sẵn khi trình duyệt hết cache.
  • Early Hints + Brotli: Bật cả hai, không tốn gì mà cải thiện tốc độ rõ rệt.

Bài tiếp theo mình sẽ nói về Firewall Rules và bảo mật nâng cao trên Cloudflare. Hẹn gặp bạn ở bài sau!

Chia sẻ:
Bài viết đã được kiểm duyệt bởi AZDIGI Team

Về tác giả

Trần Thắng

Trần Thắng

Chuyên gia tại AZDIGI với nhiều năm kinh nghiệm trong lĩnh vực web hosting và quản trị hệ thống.

Hơn 10 năm phục vụ 80.000+ khách hàng

Bắt đầu dự án web của bạn với AZDIGI