Cloudflare: Tính năng, ưu điểm và cách sử dụng

Cloudflare là gì?

Cloudflare không phải dịch vụ hosting theo nghĩa thông thường. Website, cơ sở dữ liệu và ứng dụng vẫn có thể nằm tại nhà cung cấp hosting hoặc hạ tầng riêng. Cloudflare đứng trước origin để tối ưu và bảo vệ các hostname được proxy.

Khi một bản ghi A, AAAA hoặc CNAME ở trạng thái Proxied, người truy cập nhận địa chỉ IP Anycast của Cloudflare thay vì địa chỉ origin được khai báo trong DNS. Request được xử lý tại mạng Cloudflare rồi mới chuyển tới origin nếu không thể trả trực tiếp từ edge.

Với bản ghi DNS Only, Cloudflare chỉ trả lời DNS và không proxy lưu lượng HTTP/HTTPS. Khi đó, các tính năng dựa trên proxy như cache, WAF và bảo vệ origin qua lớp edge không được áp dụng cho hostname đó.

Cloudflare gồm những thành phần nào?

Reverse proxy hoạt động như thế nào?

Reverse proxy nhận request thay cho origin. Nó có thể trả response từ cache, áp dụng quy tắc bảo mật hoặc chuyển tiếp request tới origin rồi trả kết quả về người dùng.

Không phải “mọi dữ liệu đều được Cloudflare quét”. Pipeline thực tế phụ thuộc sản phẩm, gói và rule đang bật. Một request có thể chỉ được proxy, có thể được cache hoặc có thể bị bypass hoàn toàn.

Anycast và mạng edge giúp giảm độ trễ ra sao?

Anycast cho phép cùng một dải địa chỉ IP được quảng bá từ nhiều điểm trên mạng. Hệ thống định tuyến Internet đưa request tới một điểm mạng phù hợp, thường gần về mặt định tuyến chứ không nhất thiết gần nhất theo khoảng cách địa lý.

Nếu origin ở xa người dùng, tài nguyên đã cache có thể được trả từ edge mà không cần quay lại origin. Điều này giảm độ trễ và giảm số request tới máy chủ gốc.

Với cache miss hoặc nội dung động, request vẫn phải đi tới origin. Cloudflare không thể biến một truy vấn cơ sở dữ liệu chậm hoặc plugin WordPress lỗi thành response nhanh chỉ bằng vị trí edge.

Cloudflare cache nội dung gì theo mặc định?

Cloudflare mặc định cache nhiều loại tài nguyên tĩnh theo phần mở rộng file như ảnh, CSS, JavaScript, font, PDF và video. HTML và JSON không được cache theo mặc định nếu không có rule hoặc sản phẩm khác thay đổi hành vi.

Cloudflare cũng xem xét header từ origin. Response có chỉ thị như private, no-store, no-cache hoặc max-age=0 thường không được cache theo hành vi mặc định. Request không phải GET và response có một số header động cũng có thể bị bỏ qua.

Responsive Images và tối ưu dung lượng vẫn cần thiết. CDN không sửa một ảnh quá lớn so với vùng hiển thị nếu doanh nghiệp chỉ lưu đúng một phiên bản.

Cloudflare có tự sao lưu toàn bộ website không?

Không. Cache là bản sao tạm thời phục vụ phân phối, không phải hệ thống backup website. Tài nguyên có thể bị hết hạn, purge, evict hoặc không đủ điều kiện cache.

Doanh nghiệp vẫn cần backup file, cơ sở dữ liệu, cấu hình DNS, mã nguồn và thông tin tích hợp theo lịch. Khi origin mất dữ liệu hoặc ứng dụng hỏng, cache Cloudflare không phải phương án khôi phục đầy đủ.

DNS Proxied và DNS Only khác nhau thế nào?

Chỉ A, AAAA và CNAME dùng cho phân giải địa chỉ IP mới có thể được proxy. MX, TXT và nhiều loại bản ghi khác luôn ở trạng thái DNS Only.

Không bật đám mây cam cho mọi bản ghi theo thói quen. Máy chủ mail, cPanel, FTP hoặc dịch vụ dùng port không được hỗ trợ cần được cấu hình theo tài liệu của nhà cung cấp.

Cloudflare có che địa chỉ IP origin không?

Với hostname được proxy, DNS công khai trả địa chỉ Cloudflare thay vì origin. Điều này giảm khả năng người ngoài tìm origin trực tiếp qua bản ghi hiện tại.

Tuy nhiên, origin IP vẫn có thể bị lộ qua lịch sử DNS, bản ghi phụ, email header, dịch vụ khác, lỗi cấu hình hoặc dữ liệu công khai. Nếu origin chấp nhận traffic trực tiếp từ mọi nơi, người biết IP vẫn có thể bypass Cloudflare.

SSL/TLS trên Cloudflare gồm hai kết nối

Khi Cloudflare proxy website, một request HTTPS thường có hai chặng:

Universal SSL cung cấp certificate công khai miễn phí cho domain đã được kích hoạt, với phạm vi tiêu chuẩn gồm apex domain và first-level subdomain trong full setup. Certificate này bảo vệ chặng visitor–Cloudflare khi hostname được proxy.

Universal SSL không tự bảo đảm chặng Cloudflare–origin được mã hóa đúng. Origin vẫn cần certificate và cấu hình HTTPS phù hợp để dùng Full hoặc Full (strict).

Nên chọn Flexible, Full hay Full (strict)?

Cloudflare khuyến nghị Full hoặc Full (strict), trong đó Full (strict) là lựa chọn phù hợp hơn khi origin đáp ứng yêu cầu. Certificate origin phải còn hạn, khớp hostname và được cấp bởi CA được tin cậy hoặc Cloudflare Origin CA.

Flexible có thể gây vòng lặp redirect khi WordPress hoặc web server ép HTTPS nhưng Cloudflare gọi origin bằng HTTP. Nó cũng để chặng edge–origin không được mã hóa.

Cloudflare có cung cấp WAF miễn phí không?

Cloudflare WAF kiểm tra request web và API bằng ruleset. Gói Free có Cloudflare Free Managed Ruleset, là một tập con của managed ruleset đầy đủ. Gói Pro trở lên có thêm Cloudflare Managed Ruleset và OWASP Core Ruleset theo quyền lợi hiện hành.

Không nên viết rằng mọi gói đều được bảo vệ bởi toàn bộ bộ luật WAF hoặc “AI quét toàn bộ traffic”. Tính năng, số rule, trường điều kiện, logging và quyền tùy chỉnh khác nhau theo plan.

Bảo vệ DDoS hoạt động như thế nào?

Cloudflare cung cấp DDoS Protection tự động trên các gói. Managed ruleset phát hiện và giảm thiểu nhiều loại tấn công ở lớp mạng và lớp ứng dụng.

Bảo vệ DDoS không đồng nghĩa mọi sự cố quá tải đều được giải quyết. Traffic hợp lệ tăng mạnh, request động tốn tài nguyên, truy vấn database chậm hoặc lỗi ứng dụng vẫn có thể làm origin quá tải.

Doanh nghiệp cần kết hợp cache, rate limiting, tối ưu ứng dụng, capacity planning và monitoring. Với API hoặc login, cần giới hạn theo endpoint và hành vi thay vì chặn toàn bộ quốc gia theo cảm tính.

Under Attack Mode có nên bật thường xuyên không?

Không. Cloudflare mô tả Under Attack Mode là biện pháp cuối cùng khi zone đang bị tấn công lớp 7. Tính năng hiển thị Managed Challenge và có thể tạm dừng trải nghiệm truy cập.

Under Attack Mode có thể ảnh hưởng analytics, API, bot và người dùng hợp lệ. Với phần website bị tấn công, nên áp dụng có chọn lọc bằng configuration rule thay vì bật toàn zone nếu có thể.

Cloudflare có làm website đạt LCP dưới 2,5 giây không?

Không có bảo đảm. CDN, cache và nén có thể giảm thời gian truyền tài nguyên, nhưng LCP còn phụ thuộc TTFB origin, HTML, CSS chặn hiển thị, font, ảnh LCP, JavaScript, preload và thiết bị người dùng.

Ngưỡng LCP tốt là không quá 2,5 giây ở phân vị 75. Đây là mục tiêu trải nghiệm, không phải kết quả tự động sau khi đổi nameserver.

Largest Contentful Paint phải được đo bằng PageSpeed Insights, Search Console và DevTools. Cần kiểm tra phần tử LCP thực tế trước khi chọn Cloudflare setting.

Cloudflare hỗ trợ nén nội dung thế nào?

Cloudflare hỗ trợ Gzip, Brotli và Zstandard tùy browser, plan và Compression Rules. Không nên hướng dẫn mọi người chỉ cần bật “Brotli” vì hành vi mặc định và dashboard đã thay đổi theo thời gian.

Nén áp dụng cho những content type và status code đủ điều kiện. Ảnh JPEG, WebP hoặc AVIF đã nén không giảm nhiều nhờ Brotli; tối ưu ảnh cần resize, chọn định dạng và chất lượng riêng.

Cloudflare Auto Minify là tính năng cũ đã bị deprecated. Bài nguồn hướng dẫn bật Auto Minify HTML, CSS và JavaScript không còn phù hợp với tài liệu hiện hành. Minify nên được thực hiện trong quy trình build, plugin hoặc công cụ đang được hỗ trợ, rồi kiểm thử tránh phá JavaScript và CSS.

Early Hints có luôn cải thiện LCP không?

Early Hints dùng response 103 để gửi Link header preload hoặc preconnect trước response chính. Browser tương thích có thể bắt đầu tải tài nguyên sớm trong thời gian origin đang chuẩn bị HTML.

Tính năng chỉ có tác dụng khi response chứa Link header phù hợp và tài nguyên được hint thực sự quan trọng. Preload sai hoặc quá nhiều tài nguyên có thể cạnh tranh băng thông với ảnh LCP, CSS và font cần thiết.

Early Hints hỗ trợ HTTP/2 và HTTP/3. Doanh nghiệp nên đo waterfall trước–sau, không bật rồi mặc định điểm Core Web Vitals sẽ tăng.

Cloudflare ảnh hưởng Core Web Vitals ra sao?

Core Web Vitals được hệ thống xếp hạng sử dụng trong bức tranh page experience, nhưng điểm tốt không bảo đảm top Google.

Cumulative Layout Shift cần được sửa ở markup và layout. CDN không ngăn nội dung nhảy nếu ảnh hoặc iframe không được giữ chỗ.

Cloudflare có trực tiếp nâng thứ hạng SEO không?

Không nên mô tả Cloudflare như một “điểm SEO kỹ thuật” hoặc cách nhanh nhất để lên top. Google sử dụng nhiều hệ thống và tín hiệu; mức liên quan và nội dung hữu ích vẫn là nền tảng.

Cloudflare có thể hỗ trợ SEO gián tiếp bằng cách cải thiện availability, HTTPS, tốc độ, cache và khả năng phục vụ người dùng. Nó cũng có thể gây hại nếu WAF chặn bot hợp lệ, redirect sai, cache nội dung lỗi hoặc origin trả lỗi 5xx.

Google cho biết Core Web Vitals được dùng trong hệ thống xếp hạng, nhưng không có một tín hiệu page experience duy nhất và kết quả tốt trong công cụ không bảo đảm vị trí đầu. Bounce rate và time on site trong GA4 không được công bố là công thức trực tiếp đẩy thứ hạng.

Technical SEO cần kiểm tra Cloudflare trong bối cảnh crawl, index, canonical, redirect, render và server response.

Cloudflare có bảo vệ ngân sách quảng cáo không?

Website ổn định giúp giảm nguy cơ người dùng trả tiền quảng cáo nhưng gặp trang lỗi hoặc tải quá chậm. Đây là lợi ích vận hành thực tế, không có nghĩa Cloudflare bảo đảm mỗi click tới “landing page hoàn hảo” hoặc tự tối ưu ROAS.

Cloudflare Free có đủ cho website doanh nghiệp không?

Gói Free phù hợp với nhiều website nhỏ để dùng authoritative DNS, proxy, Universal SSL, cache cơ bản, DDoS protection, Free Managed Ruleset và một số rule. Tuy nhiên, doanh nghiệp không nên chọn plan chỉ dựa vào lượng traffic.

Cần xem xét:

Quyền lợi plan thay đổi theo thời gian. Hãy kiểm tra bảng availability trong tài liệu chính thức trước khi lập báo giá hoặc cam kết tính năng.

Quy trình cài đặt Cloudflare an toàn

Bước 1: Sao lưu và kiểm tra DNS

Cloudflare có thể quét bản ghi khi thêm domain, nhưng kết quả không thay thế việc đối chiếu thủ công. Bản ghi mail, SPF, DKIM, DMARC, verification và subdomain ít dùng có thể bị thiếu.

Trước khi đổi nameserver, hãy lưu:

Bước 2: Đổi nameserver tại registrar

Trong full setup, Cloudflare cấp hai authoritative nameserver. Doanh nghiệp cập nhật chúng tại nơi quản lý tên miền, không phải trong hosting WordPress.

Thời gian thay đổi phụ thuộc registrar, registry và cache DNS. Không nên hứa luôn hoàn tất trong vài phút hoặc cố định 24 giờ.

Trong quá trình chuyển, website thường tiếp tục hoạt động nếu bản ghi Cloudflare khớp DNS cũ. Lỗi phổ biến nhất là thiếu MX/TXT, nhập sai IP hoặc proxy hostname không tương thích.

Bước 3: Cấu hình đám mây cam đúng chỗ

Các record web như apex, www và subdomain ứng dụng có thể đặt Proxied nếu dùng HTTP/HTTPS được Cloudflare hỗ trợ. MX và các record không đủ điều kiện luôn DNS Only.

Bước 4: Thiết lập Full (strict) và HTTPS

Cài certificate hợp lệ tại origin trước. Có thể dùng certificate công khai hoặc Cloudflare Origin CA nếu origin chỉ nhận traffic proxied.

Sau đó chọn Full (strict), kiểm tra website qua HTTPS và mới bật ép HTTPS. Nếu gặp lỗi 525 hoặc 526, cần sửa handshake hoặc certificate origin, không hạ xuống Flexible như giải pháp lâu dài.

Bước 5: Cấu hình cache cho WordPress

WordPress có trang công khai, trang quản trị, phiên đăng nhập và nội dung cá nhân hóa. Doanh nghiệp không nên dùng Cache Everything cho toàn domain mà không có điều kiện bypass.

Với website thông thường, bắt đầu bằng cache tài nguyên tĩnh theo mặc định. Nếu cache HTML, phải loại trừ:

WP Rocket hoặc plugin cache có thể xử lý page cache tại origin. Cần phân định rõ lớp plugin, hosting và Cloudflare để tránh purge không đồng bộ.

WooCommerce cần loại trừ những trang nào?

Giỏ hàng, thanh toán và tài khoản chứa dữ liệu theo phiên. Cache HTML sai có thể làm người dùng nhìn thấy giỏ hàng cũ, trạng thái đăng nhập sai hoặc thông tin không dành cho họ.

Nếu dùng APO, Workers hoặc Cache Rules nâng cao, cần test khách mới, khách đăng nhập, nhiều trình duyệt và các phương thức thanh toán.

Cách kiểm tra tài nguyên có được cache không

Response header CF-Cache-Status cho biết quyết định cache. Các giá trị thường gặp gồm HIT, MISS, DYNAMIC, BYPASS, EXPIRED, REVALIDATED và UPDATING.

Không dùng cache hit làm KPI duy nhất. Một trang checkout nên bypass; một ảnh tĩnh phổ biến nên có khả năng hit cao hơn.

Purge cache thế nào để không làm tăng tải origin?

Purge Everything xóa toàn bộ tài nguyên đã cache trong zone. Sau đó, request phải làm nóng cache lại và có thể tạo đợt tải tới origin.

Khi chỉ sửa một banner, CSS hoặc bài viết, ưu tiên purge theo URL, prefix, hostname hoặc cache tag khi phù hợp. Từ năm 2025, các phương thức purge này được mở rộng cho mọi plan, nhưng quota và cách triển khai vẫn cần kiểm tra.

Bước 6: Cấu hình WAF và custom rules

Bật managed ruleset theo plan và stack. Với WordPress, có thể ưu tiên nhóm rule liên quan WordPress nhưng vẫn cần kiểm thử form, REST API, upload và plugin.

Bước 7: Bảo vệ origin

Origin là mắt xích quan trọng. Cloudflare không thể bảo vệ hoàn toàn nếu attacker truy cập trực tiếp origin IP hoặc ứng dụng có lỗ hổng chưa vá.

Checklist kiểm thử sau khi kích hoạt

Các lỗi Cloudflare thường gặp

Tình huống chiến dịch lớn nên chuẩn bị thế nào?

Bài nguồn đưa một “case study thực tế” với doanh nghiệp đổi tên, traffic rác tăng 50 lần, lọc 98%, cache 85%, LCP 1,8 giây và doanh thu đạt 150% KPI. Không có hồ sơ, thời gian, phương pháp hoặc dữ liệu đối chứng để xác minh các con số này.

Thay vì dùng một case không kiểm chứng, doanh nghiệp nên xây runbook trước chiến dịch:

Đây là quy trình quản trị rủi ro, không phải lời hứa Cloudflare sẽ bảo vệ mọi chiến dịch hoặc doanh thu.

Cloudflare có những hạn chế nào?

Edge SEO cho phép can thiệp tại lớp edge, nhưng thay đổi title, canonical, redirect hoặc robots cần được kiểm soát như thay đổi mã nguồn production.

Những sai lầm thường gặp khi dùng Cloudflare

Góc nhìn thực tế từ Xuyên Việt Media

“Cloudflare phát huy hiệu quả khi doanh nghiệp hiểu rõ từng lớp: DNS định tuyến gì, proxy bảo vệ hostname nào, cache được phép lưu nội dung nào và origin phải từ chối traffic trực tiếp ra sao. Bật nhiều tính năng không đồng nghĩa cấu hình tốt; một rule đúng và được kiểm thử giá trị hơn mười tùy chọn bật theo cảm tính.”

Anh Thắng Giấu Tên – CEO Xuyên Việt Media

Xuyên Việt Media triển khai Cloudflare trong dự án SEO thế nào?

Xuyên Việt Media không yêu cầu mọi website phải dùng Cloudflare trước khi làm SEO. Quyết định dựa trên hosting, vị trí người dùng, mô hình ứng dụng, rủi ro bảo mật, cache, đội vận hành và ngân sách.

Trong dịch vụ SEO tổng thể, Cloudflare được kiểm tra cùng DNS, HTTPS, redirect, Core Web Vitals, bot access và log server. Dịch vụ quản trị website hỗ trợ theo dõi cache, WAF, plugin, uptime và thay đổi production.

Khi tối ưu nội dung, SEO Onpage và chất lượng trang vẫn được xử lý ở website. Cloudflare không thay nội dung, cấu trúc hoặc Search Intent.

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

Kết luận

Cloudflare là lớp DNS, reverse proxy, CDN và bảo mật đặt trước origin server. Nền tảng có thể giảm độ trễ, giảm tải tài nguyên tĩnh, cung cấp SSL/TLS, WAF và bảo vệ DDoS khi được cấu hình đúng.

Quy trình an toàn gồm sao lưu DNS, chọn đúng bản ghi proxy, dùng Full (strict), bắt đầu với cache mặc định, loại trừ nội dung động, kiểm thử WAF và bảo vệ origin. Cloudflare không thay thế hosting, backup, cập nhật WordPress, tối ưu ứng dụng hoặc chiến lược SEO.