Bạn đã bật Cloudflare cho WordPress nhưng không chắc cache có thật sự hoạt động? Hoặc tệ hơn: bạn sợ cache nhầm trang đăng nhập, form liên hệ, giỏ hàng hay checkout? Đây là điểm nhiều website WordPress gặp phải: nhìn dashboard Cloudflare thì có vẻ ổn, nhưng response header lại báo MISS, BYPASS hoặc DYNAMIC.
Trong bài này, mình sẽ hướng dẫn bạn audit Cloudflare Cache Rules WordPress bằng cách đọc cf-cache-status, thiết kế rule an toàn và kiểm tra các vùng WordPress không nên cache. Mục tiêu không phải là cache mọi thứ, mà là cache đúng thứ, đúng thứ tự, đúng phạm vi.
Tóm tắt nhanh
- Cloudflare Cache Rules WordPress nên bắt đầu từ audit header cf-cache-status, không bắt đầu bằng rule cache-everything toàn site.
- HIT nghĩa là Cloudflare phục vụ từ cache; MISS nghĩa là response có thể cache nhưng chưa có trong cache tại thời điểm request; BYPASS/DYNAMIC thường cho thấy response không được cache.
- Admin, login, preview, REST API nhạy cảm, form, cart, checkout và account page nên được bypass hoặc test rất kỹ.
- Rule order quan trọng vì nhiều Cache Rules có thể cùng khớp; rule sau có thể ghi đè setting trước trong cùng phase.
- Với WordPress thương mại điện tử hoặc membership, hãy test staging hoặc scope hẹp trước khi cache HTML.
Cloudflare Cache Rules giải quyết vấn đề gì?
Cloudflare Cache Rules cho phép bạn quyết định request nào được cache, bypass cache và dùng Edge TTL ra sao. Với WordPress, Cache Rules hữu ích khi bạn muốn kiểm soát cache static assets, một số trang HTML công khai và các đường dẫn cần loại trừ.
Theo Cloudflare Docs, khi chọn “Eligible for cache”, bạn có thể cấu hình Edge TTL, Browser TTL, cache key và một số hành vi cache khác; khi chọn “Bypass cache”, request khớp rule sẽ không được cache [1]. Nói ngắn gọn: Cache Rules là lớp điều phối trước khi bạn nhìn thấy kết quả HIT/MISS trên header.
Điểm quan trọng: WordPress không phải website tĩnh hoàn toàn. Một trang bài viết công khai có thể cache tốt, nhưng trang admin, preview, form có nonce, tài khoản người dùng hoặc checkout thì không nên cache tùy tiện.
Cách đọc HIT, MISS, BYPASS và DYNAMIC
cf-cache-status là header thực tế nhất để biết Cloudflare xử lý cache ra sao cho từng request. Bạn nên đọc header này bằng DevTools hoặc curl thay vì chỉ nhìn điểm tốc độ.
Cloudflare giải thích rằng CF-Cache-Status cho biết tài nguyên có được cache hay không [2]. Một số trạng thái thường gặp:
| Trạng thái | Ý nghĩa thực tế | Việc cần làm |
|---|---|---|
| HIT | Cloudflare phục vụ response từ cache. | Ổn nếu nội dung đó đúng là nên cache. |
| MISS | Response có thể cache nhưng chưa có trong cache tại data center đó. | Reload lần hai hoặc test lại sau purge để xem có chuyển HIT không. |
| BYPASS | Cloudflare không cache response. | Kiểm tra Cache-Control, Set-Cookie, Authorization hoặc rule bypass. |
| DYNAMIC | Request được xử lý như nội dung động, không cache ở edge. | Xem rule, header origin và loại URL. |
Ngày 26/05/2026, Cloudflare thông báo BYPASS sẽ được trả về nhất quán hơn cho response không cache được; MISS được dành cho response có thể cache nhưng chưa nằm trong cache tại thời điểm request [3]. Đây là thay đổi quan trọng khi bạn audit cache: BYPASS tăng không nhất thiết là lỗi, có thể là header rõ hơn.
# Kiểm tra header cache của một URL WordPress công khai curl -I https://example.com/bai-viet/ # Tìm nhanh header Cloudflare curl -I https://example.com/bai-viet/ | grep -i "cf-cache-status"
Request WordPress nào nên bypass cache?
Những request có dữ liệu cá nhân, phiên đăng nhập, hành động ghi dữ liệu hoặc nội dung thay đổi theo người dùng nên được bypass cache. Đây là nguyên tắc an toàn trước khi bạn tối ưu tốc độ.
Danh sách cần kiểm tra kỹ:
/wp-admin/,/wp-login.phpvà URL preview.- REST API hoặc AJAX endpoint có dữ liệu riêng theo user.
- Form liên hệ, form báo giá, form đăng ký và thank-you flow.
- WooCommerce cart, checkout, my account và endpoint liên quan.
- Trang membership, dashboard khách hàng hoặc nội dung sau đăng nhập.
- Request có cookie phiên, Authorization header hoặc Set-Cookie từ origin.
Mình không khuyên bạn copy một rule “cache everything” cho toàn bộ WordPress rồi thêm bypass sau. Với site đơn giản, cách đó có thể chạy. Với website có form, checkout hoặc membership, lỗi cache nhầm có thể làm lộ thông tin hoặc khiến người dùng thấy giỏ hàng sai.
Bạn đang đọc bài viết thuộc chuyên mục Tăng tốc website của VietnamTutor — nơi mình ưu tiên cách tối ưu có kiểm chứng thay vì bật plugin hoặc rule theo cảm giác.
Thiết kế rule cho static assets và HTML công khai
Static assets nên được cache mạnh hơn HTML; HTML công khai chỉ nên cache khi bạn hiểu rõ cookie, form và trạng thái đăng nhập. Đây là cách giảm rủi ro cho WordPress.
Với static assets, bạn có thể tạo rule cho các phần mở rộng như CSS, JS, JPG, PNG, WebP, AVIF, SVG, WOFF2. Edge TTL có thể dài hơn vì file thường đổi tên khi build hoặc khi WordPress/plugin tạo version mới.
Với HTML công khai, hãy scope hẹp trước: bài viết, trang dịch vụ không có form động, category page nếu không cá nhân hóa. Sau đó test HIT/MISS bằng header. Nếu website đã dùng plugin cache tạo HTML tĩnh, Cloudflare có thể cache lớp HTML đó hiệu quả hơn, nhưng bạn vẫn cần kiểm tra cookie và purge flow.
Nếu bạn cần hiểu nền tảng cache WordPress trước, đọc thêm bài WordPress caching. Nếu đang xử lý origin chậm, bài audit TTFB cho WordPress sẽ giúp tách lỗi server khỏi lỗi cache edge.
Thứ tự rule và lỗi cấu hình thường gặp
Thứ tự Cache Rules quan trọng vì nhiều rule có thể cùng khớp một request và setting sau có thể ghi đè setting trước. Cloudflare Docs mô tả Cache Rules là stackable; nhiều rule khớp cùng URL có thể được áp dụng theo thứ tự [4].
Lỗi thường gặp:
- Rule cache HTML đặt quá rộng, khớp cả trang có cookie hoặc form.
- Rule bypass đặt sau rule cache nhưng setting không như kỳ vọng.
- Quên loại trừ query string preview, search, filter hoặc tracking đặc biệt.
- Không purge cache sau khi đổi rule nên test thấy kết quả cũ.
- Chỉ test khi chưa đăng nhập, bỏ qua trạng thái logged-in.
Cloudflare cũng lưu ý các Rules products có thứ tự thực thi riêng và có thể override Page Rules nếu cùng khớp [4]. Nếu website cũ đang dùng Page Rules, hãy kiểm tra lại để tránh hai hệ rule gây hiểu nhầm.
Test login, form, cart và checkout sau khi đổi rule
Sau khi đổi Cache Rules, bạn cần test cả anonymous user, logged-in user và các flow ghi dữ liệu. Chỉ thấy homepage HIT là chưa đủ để kết luận cấu hình an toàn.
- Mở cửa sổ ẩn danh và kiểm tra URL công khai bằng DevTools Network.
- Đăng nhập WordPress, kiểm tra admin bar, preview và trang user-specific.
- Gửi form liên hệ thử, xác nhận nonce hoặc captcha không bị lỗi.
- Nếu có WooCommerce, thêm sản phẩm vào cart, đổi số lượng, checkout test.
- Kiểm tra response header của từng URL: public page nên có thể HIT; cart/checkout/admin nên BYPASS hoặc DYNAMIC.
- Purge cache, reload 2-3 lần và test lại từ mobile.
Khi nào dùng APO thay vì tự cache HTML?
Nếu bạn muốn cache HTML WordPress ở edge nhưng không muốn tự xử lý quá nhiều logic purge và cookie, Cloudflare APO có thể phù hợp hơn Cache Rules tự cấu hình. Cache Rules vẫn hữu ích cho static assets, bypass và scope đặc biệt.
APO được thiết kế riêng cho WordPress, có plugin hỗ trợ purge khi nội dung thay đổi. Cache Rules linh hoạt hơn, nhưng cũng yêu cầu bạn hiểu rõ đường dẫn, cookie và hành vi của site. Với site doanh nghiệp có vài landing page tĩnh, Cache Rules scope hẹp có thể đủ. Với blog lớn hoặc site cần cache HTML edge bài bản, hãy cân nhắc APO.
VietnamTutor đã có bài riêng về Cloudflare APO WordPress, nên bài này chỉ tập trung vào audit Cache Rules và đọc header. Nếu mục tiêu là Core Web Vitals, bạn cũng nên liên kết cache edge với bài Core Web Vitals WordPress để đo tác động lên LCP và TTFB.
Checklist audit Cloudflare Cache Rules WordPress định kỳ
Audit cache định kỳ giúp bạn phát hiện rule bị rộng quá, cache hit thấp hoặc request động bị cache nhầm trước khi người dùng gặp lỗi. Mình khuyên bạn làm checklist này sau mỗi lần đổi theme, plugin cache, WooCommerce, form hoặc Cloudflare rule.
- Chọn 5 URL đại diện: homepage, bài viết, trang dịch vụ, form, cart/checkout hoặc login.
- Kiểm tra cf-cache-status bằng curl và DevTools.
- Reload URL công khai 2-3 lần để phân biệt MISS ban đầu với HIT sau đó.
- Kiểm tra BYPASS/DYNAMIC ở admin, login, form, cart và checkout.
- Xem origin có gửi Cache-Control: private, no-cache, max-age=0 hoặc Set-Cookie không.
- Kiểm tra rule order, Page Rules cũ và purge cache sau khi chỉnh.
- Ghi lại kết quả để so sánh sau 14-28 ngày.
Nguồn tham khảo
- Cloudflare Docs: Cache Rules settings
- Cloudflare Docs: Cache responses and CF-Cache-Status
- Cloudflare Changelog: BYPASS status for uncacheable responses
- Cloudflare Docs: Cache Rules order and priority
- Cloudflare Docs: Cache documentation
Các câu hỏi thường gặp
Cloudflare Cache Rules WordPress có thay thế plugin cache không?
Không hoàn toàn. Plugin cache thường tạo HTML tĩnh hoặc tối ưu cache ở origin; Cloudflare Cache Rules điều khiển cache ở edge. Hai lớp này nên phối hợp, không thay thế mù quáng cho nhau.
cf-cache-status MISS có phải là lỗi không?
Không nhất thiết. MISS thường nghĩa là response có thể cache nhưng chưa có trong cache tại thời điểm request. Nếu reload nhiều lần vẫn MISS, hãy kiểm tra Cache-Control, Set-Cookie, rule và purge.
BYPASS khác DYNAMIC thế nào?
BYPASS thường cho thấy Cloudflare chủ động không cache response vì rule hoặc header khiến response không cache được. DYNAMIC thường biểu thị request được xử lý như nội dung động và không cache ở edge.
Có nên cache HTML toàn bộ WordPress bằng Cache Rules không?
Không nên làm rộng ngay từ đầu. Hãy scope hẹp cho trang công khai, bypass admin, login, form, cart, checkout và test kỹ cookie. Với cache HTML edge bài bản, bạn có thể cân nhắc Cloudflare APO.
Làm sao kiểm tra Cloudflare Cache Rules đang hoạt động?
Dùng DevTools Network hoặc curl -I để đọc cf-cache-status, cache-control và set-cookie. Test ít nhất hai lượt request vì request đầu có thể MISS, request sau mới HIT nếu response cache được.
Tóm lại, Cloudflare Cache Rules WordPress chỉ an toàn khi bạn audit bằng header thật và hiểu URL nào nên cache. Hãy bắt đầu từ static assets, sau đó mở rộng sang HTML công khai theo scope hẹp. Với mọi vùng có dữ liệu người dùng, form hoặc giao dịch, ưu tiên bypass và test kỹ trước khi tối ưu tốc độ.
