Cloudflare cho Frontend Developer · Phần 13 — Lộ trình 4 tuần, checklist, từ điển và FAQ
Kết series: lộ trình tự học 4 tuần theo từng phần, bốn dự án thực hành, checklist DNS, SSL, cache, routing, bảo mật, hiệu năng và origin, từ điển thuật ngữ Cloudflare, cùng 16 câu hỏi thường gặp kèm câu trả lời ngắn.
Mười hai phần trước là để đọc. Phần này là để dùng: một lộ trình bốn tuần cho người muốn học có kỷ luật thay vì đọc lướt, bốn dự án để chứng minh với chính mình rằng đã học xong, một checklist để rà trước khi công bố bất kỳ tên miền nào, một từ điển để tra khi gặp từ lạ trong dashboard, và câu trả lời ngắn cho những câu hỏi mà gần như ai cũng hỏi trong tháng đầu dùng Cloudflare.
Bạn không cần đọc phần này từ đầu tới cuối. Đánh dấu lại, mở checklist mỗi lần trỏ tên miền mới, mở FAQ mỗi lần có đồng nghiệp hỏi “sao email chết rồi”.
Lộ trình 4 tuần
Thời lượng đề xuất của tài liệu gốc là 4 tuần, khoảng 5–6 giờ mỗi tuần. Mỗi tuần có ba cột: đọc gì, làm lab nào, và “xong khi” — tiêu chí để bạn tự chấm thay vì cảm giác.
| Tuần | Đọc | Làm | Xong khi |
|---|---|---|---|
| 1 — Nền tảng và thiết lập | Phần 1, Phần 2, Phần 3 | Lab 2.1 (quan sát header trên một trang thật). Lab 3.1 (đưa tên miền của bạn qua Cloudflare, cấu hình DNS, bật SSL Full strict). | Tên miền của bạn chạy HTTPS qua Cloudflare; bạn vẽ lại được sơ đồ vòng đời request ở Phần 1; email vẫn nhận được bình thường. |
| 2 — DNS, SSL và Rules | Phần 4, Phần 5, Phần 7 | Lab 4.1 (thêm subdomain, so sánh cam và xám). Lab 5.1 (tự gây và tự sửa lỗi lặp chuyển hướng). Lab 7.1 (ba rule đầu tiên). | Giải thích được bốn chế độ SSL cho người khác; www tự chuyển về tên miền gốc; response có đủ security header. |
| 3 — Cache và Pages | Phần 6, Phần 8 | Lab 6.1 (nghịch cache, purge, Development Mode). Lab 8.1 (deploy SPA lên Pages với _redirects và _headers, gắn tên miền riêng). | Đọc cf-cache-status là hiểu ngay chuyện gì đang xảy ra; F5 ở route con không lỗi; asset cache một năm còn HTML thì không. |
| 4 — Workers, bảo mật, vận hành | Phần 9, Phần 10, Phần 11, Phần 12 | Lab 9.1 (Worker đầu tiên). Tạo một WAF rule ở chế độ quan sát (Managed Challenge, vì Log chỉ có ở Enterprise) và theo dõi Security Events. Tắt Rocket Loader nếu đang bật. Chạy Lighthouse và tối ưu theo kết quả. Rà checklist ở bài này. | Bạn nhìn mã lỗi 5xx là biết lỗi ở đâu; có Worker chạy trên tên miền riêng; điểm Lighthouse Performance trên 90. |
Thứ tự này không ngẫu nhiên. Tuần 1 và 2 phải đi tuần tự vì mỗi phần dựa trên phần trước (không hiểu đám mây cam thì không hiểu vì sao Flexible sinh vòng lặp). Tuần 3 và 4 có thể đảo cho nhau: người đang cần deploy gấp thì làm Pages trước; người đang bị bot quấy thì làm WAF trước.
Chia 5–6 giờ mỗi tuần thế nào
- Hai buổi đọc, mỗi buổi khoảng 1 giờ, mở dashboard song song và bấm theo. Đọc mà không có dashboard là cách chắc nhất để quên.
- Một buổi lab 2–3 giờ liền, vì lab có thời gian chờ (nameserver, chứng chỉ, build) và bạn cần làm việc khác trong lúc chờ mà không mất mạch.
- 30 phút cuối tuần ghi lại: ba lệnh đã dùng nhiều nhất, một lỗi đã gặp và cách nhận ra nó. Sổ tay riêng của bạn có giá trị hơn bất kỳ tài liệu nào sau ba tháng.
Thứ duy nhất bạn cần chuẩn bị trước tuần 1: một tên miền thật. Cloudflare hoạt động ở tầng tên miền, không có tên miền thì không học được gì. Tên miền .io.vn, .xyz, .site giá khoảng vài trăm nghìn đồng cho năm đầu — đủ để học.
Bốn dự án thực hành
| # | Dự án | Rèn luyện | Độ khó |
|---|---|---|---|
| 1 | Portfolio trên Pages + tên miền riêng | DNS, SSL, Pages, _redirects, _headers | Dễ |
| 2 | Website WordPress trên Hostinger qua Cloudflare | Trỏ A record, Full (strict), cache HTML có chọn lọc, khôi phục IP thật | Dễ |
| 3 | SPA + API riêng, không có CORS | Worker proxy /api/*, giấu secret, Cache Rules bypass API | Trung bình |
| 4 | Trang có bảo vệ: rate limit đăng nhập, WAF cho /admin | WAF Custom Rules, Rate Limiting, Security Events | Trung bình |
Mỗi dự án dưới đây có mục tiêu, các bước chính, tiêu chí hoàn thành và bẫy hay gặp. Làm theo thứ tự thì mỗi dự án dùng lại kết quả của dự án trước.
Dự án 1 — Portfolio trên Pages + tên miền riêng
Mục tiêu: có một site tĩnh (Astro, Vite, hay HTML thuần) chạy trên example.com, deploy tự động khi push.
- Tạo repo, build ra
dist/, thêmpublic/_redirectsvàpublic/_headerstheo Phần 8. - Nối repo với Pages, deploy, kiểm tra URL
.pages.dev. - Gắn
example.comvàwww.example.comtrong Custom domains; tạo Redirect Rule gomwwwvề gốc. - Kiểm tra bằng bốn lệnh:
dig example.com +short,curl -sI https://example.com,curl -sI https://www.example.com,curl -sI https://example.com/assets/<file-có-hash>.
Xong khi: site chạy HTTPS trên tên miền riêng, www trả 301 về gốc, asset có max-age=31536000, HTML có no-cache, mỗi PR sinh một preview URL.
Bẫy: _redirects nằm ở src/ thay vì public/; output directory sai; quên bản ghi www nên Redirect Rule không có chỗ chạy.
Dự án 2 — WordPress trên Hostinger qua Cloudflare
Mục tiêu: một site WordPress (hoặc PHP bất kỳ) có sẵn trên Hostinger được đưa qua Cloudflare mà không mất email, không lặp chuyển hướng, và có cache HTML cho trang công khai.
- Chụp bảng DNS ở hPanel, cài SSL trên Hostinger, thêm site vào Cloudflare, đối chiếu bản ghi, đổi nameserver (Phần 3).
- SSL mode Full (strict), bật Always Use HTTPS và Automatic HTTPS Rewrites.
- Cài plugin để WordPress đọc
CF-Connecting-IP, kiểm tra IP trong bình luận hoặc log không còn toàn IP Cloudflare. - Tạo Cache Rule cache HTML cho trang công khai với điều kiện loại trừ
/wp-admin/*,/wp-login.php,/wp-json/*và request có cookie đăng nhập (http.cookie contains "wordpress_logged_in"); Edge TTL vài giờ, Browser TTL vài phút. - Thêm bước purge by URL vào quy trình đăng bài (plugin Cloudflare của WordPress làm được), hoặc chấp nhận độ trễ bằng Edge TTL.
Xong khi: curl -sI https://example.com/ trả cf-cache-status: HIT ở lần gọi thứ hai, nhưng khi đăng nhập thì thanh admin vẫn hiện đúng; email tới tên miền vẫn nhận được; dig example.com MX +short không ra IP Cloudflare.
Bẫy: cache HTML mà không loại trừ cookie đăng nhập, người này thấy thanh admin của người kia; MX bị cam; chọn Flexible vì “chưa cài SSL kịp” rồi gặp ERR_TOO_MANY_REDIRECTS.
Dự án 3 — SPA + API riêng, không có CORS
Mục tiêu: frontend trên Pages, backend ở VPS hoặc dịch vụ khác, và trình duyệt không bao giờ thấy request cross-origin.
- Backend chạy ở
backend.example.net(hoặcapi.example.comđám mây cam), yêu cầu headerX-Api-Key. - Viết Worker proxy
/api/*theo Phần 9, secret đặt bằngwrangler secret put, gắn routeexample.com/api/*. - Frontend gọi
fetch('/api/...')tương đối; xoá mọi cấu hình CORS ở backend để chứng minh không còn cần. - Tạo Cache Rule bypass cho
/api/*để không request nào của API bị cache nhầm; kiểm tracf-cache-status: BYPASShoặcDYNAMIC.
Xong khi: Network tab không có request OPTIONS, không có request nào tới backend.example.net từ trình duyệt; grep -r BACKEND_SECRET src/ trong repo Worker không ra giá trị; curl -sI https://example.com/api/health có cf-ray và không có header CORS.
Bẫy: quên return fetch(request) cho đường dẫn ngoài /api/; cookie của backend mang Domain sai; route gắn vào hostname chưa có bản ghi cam.
Dự án 4 — Trang có bảo vệ
Mục tiêu: /admin chỉ vào được từ Việt Nam, /login bị rate limit, và bạn đọc được Security Events như đọc log.
- WAF Custom Rule:
URI Path starts with /admin AND Country does not equal VN, hành động Managed Challenge trước, Block sau vài ngày theo dõi. - Rate Limiting:
/login, hơn 5 request trong 10 giây từ cùng IP, Managed Challenge (giới hạn gói Free ở Phần 10). - Nếu có webhook: rule Skip cho đường dẫn webhook từ dải IP của nhà cung cấp, đặt trên cùng.
- Mỗi ngày mở Security → Events một lần trong một tuần; ghi lại rule nào bắt gì.
Xong khi: mở /admin qua VPN nước ngoài thấy thử thách hoặc 1020; vòng lặp curl 8 lần vào /login nhận 403 hoặc 429 từ lần thứ sáu; webhook thật vẫn tới; không có người dùng thật nào xuất hiện trong Events với hành động Block.
Bẫy: bật Bot Fight Mode rồi webhook chết mà không có cách Skip ở gói Free; Block ngay từ đầu thay vì Managed Challenge; ngưỡng rate limit tính theo IP chặn cả văn phòng.
Checklist
Rà trước khi công bố một tên miền, và rà lại sau mỗi thay đổi lớn (đổi hosting, thêm subdomain, thêm rule). Mỗi mục là một câu trả lời được, không phải một cảm giác.
DNS
- Nameserver đã trỏ về Cloudflare, zone ở trạng thái Active
- Bản ghi A hoặc CNAME cho
@đúng, đám mây cam - Bản ghi cho
wwwtồn tại và cùng trạng thái proxy với@ - Bản ghi MX để đám mây xám và đã gửi thử email thành công
- Bản ghi TXT (SPF, DKIM, DMARC, xác minh) đã nhập đủ
- Bản ghi FTP, SSH để đám mây xám
- Đã đối chiếu với ảnh chụp bảng DNS cũ, không thiếu bản ghi nào
SSL/TLS
- Chế độ là Full (strict), không phải Flexible
- Origin có chứng chỉ hợp lệ (của hosting hoặc Origin Certificate)
- Always Use HTTPS đã bật
- Automatic HTTPS Rewrites đã bật
- Minimum TLS Version đặt ở 1.2
- Universal SSL ở trạng thái Active
- HSTS: chỉ bật sau khi HTTPS đã ổn định nhiều tuần, bắt đầu với
max-agengắn
Cache
- Asset có hash:
public, max-age=31536000, immutable - HTML:
no-cache, must-revalidate -
config.json,service-worker.js:no-store - Nếu bật cache cho HTML, đã có rule bypass cho
/api/* - Pipeline deploy có bước purge cache (hoặc asset có hash nên không cần)
- Development Mode đã tắt (nó tự tắt sau 3 giờ)
Routing
- Đã chọn một dạng chuẩn (có
wwwhoặc khôngwww) và có Redirect Rule 301 - SPA fallback đã cấu hình (
_redirectshoặc.htaccess) - Đã kiểm tra F5 ở route con
Bảo mật
- Xác thực hai lớp bật cho tài khoản Cloudflare
- Dùng API Token giới hạn quyền, không dùng Global API Key
- Token lưu trong CI secrets, không nằm trong Git
- Security header đã thêm qua Transform Rule hoặc
_headers - Bot Fight Mode: đã cân nhắc ảnh hưởng tới API và webhook
- Under Attack Mode đang tắt
- WAF rule mới đã chạy ở chế độ quan sát (Log ở Enterprise, Managed Challenge ở gói khác) trước khi Block
Hiệu năng
- Rocket Loader đã tắt
- Brotli, HTTP/2, HTTP/3 đã bật
- Minify làm ở bước build, không phụ thuộc Cloudflare
- Tiered Cache đã bật
Origin
- Backend đọc
CF-Connecting-IPđể lấy IP thật của người dùng - Backend tin proxy để nhận biết HTTPS (
X-Forwarded-Proto) - (VPS) Tường lửa chỉ cho phép HTTP/HTTPS từ dải IP Cloudflare
Vận hành (bổ sung)
- Ghi lại bản ghi nào cam, bản ghi nào xám và vì sao, ở README hạ tầng của dự án
- Có giám sát uptime từ bên ngoài (một dịch vụ ping tên miền mỗi phút) và nó không bị Bot Fight Mode chặn
- Mỗi quý mở lại danh sách API Token và rule, thu hồi hoặc xoá thứ không còn dùng
- Biết chính xác dự án đang dùng bao nhiêu phần trăm giới hạn gói Free (rule, Workers, build)
Từ điển thuật ngữ
| Thuật ngữ | Giải thích ngắn |
|---|---|
| Anycast | Một địa chỉ IP tồn tại ở nhiều nơi; mạng đưa bạn tới nơi gần nhất |
| Apex domain | Tên miền gốc, không có subdomain: example.com |
| cf-cache-status | Header cho biết request lấy từ cache hay xuống origin |
| cf-ray | Mã định danh request, ba chữ cuối là PoP đã phục vụ |
| CF-Connecting-IP | Header chứa IP thật của người truy cập |
| CNAME Flattening | Kỹ thuật cho phép dùng CNAME ở tên miền gốc |
| Development Mode | Tạm ngừng cache 3 giờ để tiện phát triển |
| Edge Certificate | Chứng chỉ Cloudflare xuất cho người dùng (chặng trình duyệt ↔ Cloudflare) |
| Full (strict) | Chế độ SSL an toàn nhất, kiểm tra chứng chỉ origin |
| Nameserver | Máy chủ có thẩm quyền trả lời câu hỏi DNS về một tên miền |
| Origin | Máy chủ thật chứa website của bạn |
| Origin Certificate | Chứng chỉ miễn phí của Cloudflare dùng cho chặng Cloudflare ↔ origin |
| Pages | Dịch vụ host frontend tĩnh và SPA miễn phí của Cloudflare |
| PoP | Point of Presence — trung tâm dữ liệu edge |
| Proxied | Đám mây cam — lưu lượng đi qua Cloudflare |
| Purge | Xoá cache ở edge |
| R2 | Dịch vụ lưu trữ object của Cloudflare, tương thích API S3 |
| Universal SSL | Chứng chỉ miễn phí Cloudflare cấp cho mọi zone |
| WAF | Tường lửa ứng dụng web |
| Worker | Đoạn JavaScript chạy ở edge |
| Zone | Một tên miền được quản lý trong Cloudflare |
Bổ sung: những từ bạn sẽ gặp trong dashboard
| Thuật ngữ | Giải thích ngắn |
|---|---|
| DNS only | Đám mây xám — Cloudflare chỉ trả lời DNS, lưu lượng đi thẳng tới origin |
| Flexible | Chế độ SSL chỉ mã hoá chặng trình duyệt ↔ Cloudflare; nguồn gốc của vòng lặp chuyển hướng |
| Always Use HTTPS | Trả 301 sang HTTPS cho mọi request HTTP ngay tại edge |
| Automatic HTTPS Rewrites | Sửa link http:// trong HTML thành https:// để tránh mixed content |
| HSTS | Header bắt trình duyệt chỉ dùng HTTPS cho tên miền trong một khoảng thời gian; khó quay đầu |
| Edge TTL / Browser TTL | Thời gian Cloudflare giữ bản sao ở PoP / thời gian trình duyệt giữ bản sao |
| Tiered Cache | PoP nhỏ hỏi PoP lớn trước khi hỏi origin, tăng tỷ lệ hit |
| Cache Rules | Rule quyết định cache hay không, bao lâu, theo điều kiện |
| Redirect Rules | Rule trả 301/302 tại edge |
| Transform Rules | Rule sửa URL, sửa header request hoặc response |
| Configuration Rules | Rule bật hoặc tắt tính năng Cloudflare theo điều kiện (ví dụ tắt Rocket Loader cho một đường dẫn) |
| Page Rules | Thế hệ rule cũ, gộp nhiều chức năng; gói Free có 3 |
| Managed Challenge | Thử thách do Cloudflare tự chọn mức; người thật thường qua mà không phải làm gì |
| Bot Fight Mode | Tính năng chống bot ở gói Free; không tạo được ngoại lệ bằng rule |
| Rate Limiting | Giới hạn số request trong một chu kỳ theo IP; gói Free có 1 rule chu kỳ 10 giây |
| Security Events | Nhật ký các request bị WAF, rate limiting, bot protection can thiệp |
| Under Attack Mode | Mức bảo mật cao nhất: mọi người phải qua trang kiểm tra 5 giây |
| Turnstile | Widget chống bot thay captcha cho form, miễn phí |
| Rocket Loader | Tính năng đảo thứ tự tải script để trang hiện nhanh; hay làm vỡ SPA |
| Pages Functions | Worker gắn vào dự án Pages, routing theo file trong thư mục functions/ |
_redirects, _headers | Hai file trong thư mục output của Pages để khai báo chuyển hướng và header |
| Wrangler | CLI chính thức để dev, deploy, đặt secret cho Workers và Pages |
| KV, D1, Durable Objects | Bộ nhớ key-value, database SQLite, và đối tượng có trạng thái dành cho Workers |
| Email Routing | Chuyển tiếp email của tên miền riêng về hộp thư có sẵn, miễn phí |
| Access (Zero Trust) | Lớp đăng nhập đặt trước ứng dụng nội bộ hoặc preview deployment |
| 1.1.1.1 | DNS resolver công cộng của Cloudflare; dig @1.1.1.1 để bỏ qua cache máy mình |
Câu hỏi thường gặp
1. Dùng Cloudflare thì có phải bỏ Hostinger không?
Không. Cloudflare không phải hosting — nó đứng trước hosting của bạn. Website vẫn nằm trên Hostinger, Cloudflare chỉ quản lý DNS và làm lớp proxy phía trước. Bạn vẫn upload code lên Hostinger như cũ.
2. Chuyển nameserver sang Cloudflare có làm website sập không?
Không, nếu bạn đã kiểm tra kỹ bảng DNS trong Cloudflare trước khi đổi nameserver. Quá trình chuyển diễn ra dần dần: máy chủ DNS nào đã cập nhật thì dùng Cloudflare, chưa cập nhật thì vẫn dùng nameserver cũ. Cả hai đều trỏ về đúng máy chủ nên người dùng không thấy gián đoạn. Rủi ro thật sự là quên một bản ghi (nhất là MX), không phải bản thân việc chuyển.
3. Sau khi qua Cloudflare, tôi sửa DNS ở đâu?
Chỉ ở dashboard Cloudflare. Bảng DNS trong hPanel Hostinger không còn tác dụng. Đây là nhầm lẫn phổ biến nhất của người mới — sửa cả buổi trong Hostinger mà không có gì thay đổi. Kiểm tra bằng dig example.com NS +short: thấy ns.cloudflare.com là bảng DNS đúng nằm ở Cloudflare.
4. Vì sao bật Cloudflare xong web báo ERR_TOO_MANY_REDIRECTS?
Vì SSL mode đang là Flexible: Cloudflare gọi xuống origin bằng HTTP, origin thấy HTTP nên chuyển hướng sang HTTPS, Cloudflare chuyển tiếp chuyển hướng đó về trình duyệt, trình duyệt gọi lại HTTPS — và vòng lặp lặp lại vô tận. Sửa bằng cách cài chứng chỉ hợp lệ trên origin rồi đổi sang Full (strict). Đừng sửa bằng cách tắt Always Use HTTPS.
5. Đám mây cam và xám khác nhau ra sao?
Cam nghĩa là lưu lượng đi qua Cloudflare: có cache, có SSL của Cloudflare, có WAF, rules có hiệu lực, IP máy chủ được giấu, nhưng chỉ đi qua được các cổng web. Xám nghĩa là Cloudflare chỉ trả lời DNS rồi thôi: người dùng kết nối thẳng tới máy chủ bạn, không có tính năng nào của Cloudflare hoạt động, nhưng mọi cổng và giao thức đều dùng được. Bản ghi email luôn phải để xám.
6. Vì sao email của tôi ngừng hoạt động sau khi dùng Cloudflare?
Gần như chắc chắn là bản ghi MX bị để đám mây cam, hoặc bị quên không nhập lại sau khi chuyển nameserver. Cloudflare chỉ proxy HTTP/HTTPS — email dùng SMTP nên phải để DNS only. Kiểm tra bằng dig example.com MX +short; kết quả phải là máy chủ mail, không phải IP dạng 104.x hay 172.67.x.
7. Deploy xong mà vẫn thấy bản cũ, phải làm sao?
Xem header cf-cache-status và age. Nếu là HIT với age lớn thì đó là cache edge — purge by URL là xong. Nếu purge rồi vẫn cũ thì có thể là cache trình duyệt: kiểm tra Cache-Control của file HTML, nó không được có max-age dài. Cách phòng ngừa lâu dài là để asset có hash trong tên và HTML để no-cache.
8. Có nên bật đám mây cam cho tên miền trỏ vào Vercel hoặc Netlify không?
Thường là không. Các nền tảng đó đã có CDN và SSL riêng; chồng thêm một lớp nữa dễ gây xung đột chứng chỉ, cache hai tầng khó đoán, và có thể ảnh hưởng tính năng riêng của họ. Để đám mây xám, dùng Cloudflare thuần làm DNS. Chỉ bật cam khi bạn thực sự cần một tính năng cụ thể của Cloudflare, và khi đó phải đặt Full (strict).
9. JavaScript của tôi vỡ sau khi bật Cloudflare, vì sao?
Nghi ngờ đầu tiên là Rocket Loader — nó thay đổi thứ tự thực thi script để trang hiện nhanh hơn, và điều đó phá vỡ thư viện phụ thuộc thứ tự tải. Tắt nó ở Speed → Optimization. Nghi ngờ thứ hai là Email Obfuscation nếu bạn dùng framework render phía client. Nghi ngờ thứ ba, nếu lỗi là “Unexpected token” khi gọi API: request bị WAF hoặc Bot Fight Mode trả về trang HTML.
10. Lỗi 521, 522, 526 khác nhau thế nào?
521 là origin từ chối kết nối — máy chủ tắt hoặc tường lửa chặn IP Cloudflare. 522 là hết thời gian chờ khi bắt tay — thường do tường lửa chặn im lặng hoặc máy chủ quá tải. 526 là chứng chỉ origin không hợp lệ khi đang ở chế độ Full (strict) — cài chứng chỉ hợp lệ hoặc dùng Origin Certificate của Cloudflare. Phép thử chung cho cả ba: curl -sI --resolve thẳng tới IP origin.
11. Cloudflare Pages có thay được Hostinger không?
Được, nếu dự án của bạn là frontend tĩnh hoặc SPA — thậm chí tốt hơn: miễn phí, băng thông không giới hạn, tự deploy khi push code, có URL xem trước cho mỗi pull request. Không được, nếu bạn chạy WordPress, PHP, hoặc cần một máy chủ truyền thống với database MySQL.
12. Gói Free có bị giới hạn băng thông không?
Không. Băng thông qua proxy không giới hạn, kể cả gói Free. Đây là điểm khác biệt lớn so với hầu hết CDN khác vốn tính tiền theo GB. Giới hạn thực tế nằm ở chỗ khác: kích thước tối đa mỗi lần upload, thời gian chờ origin, và số lượng rule. Với video và file tải về lớn, dùng R2 hoặc Stream thay vì để origin phục vụ qua proxy.
13. Tên miền mua ở Namecheap, GoDaddy hay PA Việt Nam chứ không phải Hostinger thì làm gì khác?
Chỉ khác bước đổi nameserver: bạn làm ở nhà đăng ký đó, không phải ở hPanel. Mọi bước còn lại (thêm site, đối chiếu bản ghi, SSL, kiểm tra) giống hệt. Sau khi đổi, nhà đăng ký chỉ còn vai trò gia hạn tên miền; bảng DNS nằm ở Cloudflare.
14. Có nên bật HSTS không?
Chỉ sau khi HTTPS đã chạy ổn định nhiều tuần trên mọi subdomain. HSTS là quyết định khó quay đầu: trình duyệt của người đã từng truy cập sẽ từ chối mở trang qua HTTP trong suốt max-age, kể cả khi HTTPS của bạn hỏng. Bắt đầu với max-age vài giờ, tăng dần, và chỉ bật includeSubDomains hay preload khi hiểu rõ hậu quả.
15. Nên dùng Pages, Workers hay giữ Hostinger?
Site tĩnh hoặc SPA: Pages. Cần một chút logic phía máy chủ (giấu khoá API, proxy, chuyển hướng theo cookie): Pages Functions hoặc Worker. Cần PHP, WordPress, database MySQL, hoặc phần mềm cài trên máy chủ: Hostinger hoặc VPS, với Cloudflare đứng trước làm DNS và proxy. Ba lựa chọn không loại trừ nhau — nhiều dự án dùng Pages cho frontend và VPS cho API, nối bằng một Worker.
16. Đổi hosting sau khi đã qua Cloudflare thì phải chờ DNS lan truyền không?
Không, nếu bản ghi đang cam. Người dùng luôn kết nối vào IP của Cloudflare, IP đó không đổi; bạn chỉ sửa IP đích trong bảng DNS của Cloudflare và thay đổi có hiệu lực trong vài giây. Đây là lợi ích ít người nói tới nhưng rất lớn: đổi máy chủ giữa ban ngày mà không ai biết.
Lời kết
Cloudflare là một trong số ít công cụ hạ tầng mà bạn có thể học xong trong một tháng và dùng được ngay, miễn phí, cho mọi dự án về sau. Phần khó nhất không phải kỹ thuật — mà là hiểu rõ mình đang đứng ở tầng nào: tầng DNS, tầng proxy, hay tầng origin. Ba câu hỏi dưới đây giải quyết được hầu hết mọi vấn đề bạn sẽ gặp:
- Bản ghi này đang cam hay xám?
- Lỗi này đến từ Cloudflare hay từ origin? (Tắt proxy tạm thời là biết ngay.)
- Thứ tôi đang thấy là bản mới hay bản cache? (Đọc
cf-cache-status.)
Ba việc nên làm ngay hôm nay:
- Mua một tên miền rẻ nếu chưa có — không có tên miền thì không học được Cloudflare.
- Tạo tài khoản Cloudflare, bật xác thực hai lớp, thêm tên miền vào.
- Mở DevTools trên một trang web bạn hay dùng, tìm header
cf-ray. Đọc ba chữ cái cuối — bạn vừa biết mình đang được phục vụ từ thành phố nào.
Tóm tắt
- Lộ trình bốn tuần: nền tảng và thiết lập (Phần 1–3) → DNS, SSL, Rules (Phần 4, 5, 7) → cache và Pages (Phần 6, 8) → Workers, bảo mật, debug, chi phí (Phần 9–12); mỗi tuần có tiêu chí “xong khi” để tự chấm.
- Bốn dự án tăng dần: portfolio trên Pages, WordPress qua Cloudflare, SPA + API không CORS bằng Worker, trang có WAF và rate limit.
- Checklist bảy nhóm (DNS, SSL/TLS, cache, routing, bảo mật, hiệu năng, origin) cộng nhóm vận hành; rà trước khi công bố và sau mỗi thay đổi lớn.
- Từ điển 21 thuật ngữ gốc cộng 26 từ bạn sẽ gặp trong dashboard.
- 16 câu hỏi thường gặp, từ “có phải bỏ Hostinger” tới “đổi hosting có phải chờ DNS”.
- Ba câu hỏi để debug mọi thứ: cam hay xám, Cloudflare hay origin, bản mới hay bản cache.
Đọc thêm
- Cloudflare DNS docs — cho mục DNS của checklist
- Cloudflare SSL/TLS docs — chế độ mã hoá, Origin Certificate, HSTS
- Cloudflare Cache docs — Cache Rules, purge, Tiered Cache
- Cloudflare WAF docs — custom rules và rate limiting cho dự án 4