Cloudflare cho Frontend Developer · Phần 1 — Cloudflare thực ra là gì và lộ trình 13 phần
Mở đầu series: Cloudflare đứng ở đâu trong đường đi của một request, làm được gì cho frontend developer với gói Free, KHÔNG phải là gì — kèm sơ đồ vòng đời request và lộ trình 13 phần.
Bạn code xong, npm run build xong, mua tên miền xong, mua hosting Hostinger xong. Rồi ai đó bảo “nên đưa qua Cloudflare”. Bạn làm theo một video trên YouTube: may thì chạy, không may thì trang báo ERR_TOO_MANY_REDIRECTS, email công ty im bặt, hoặc deploy bản mới mà F5 mãi vẫn thấy bản cũ — và bạn không biết bắt đầu sửa từ đâu.
Khâu này nằm ở vùng giao giữa frontend và hạ tầng: nó không phải code, nhưng cũng chưa đến mức DevOps. Cloudflare là công cụ phổ biến nhất ở vùng giao đó — miễn phí, mạnh, có mặt trong gần như mọi dự án web hiện nay. Series này đi theo đúng thứ tự bạn gặp trong thực tế: mua tên miền → trỏ về hosting → bật HTTPS → hiểu cache → chặn bot → biết mở cái gì ra xem khi trang lỗi.
Phần 1 trả lời câu hỏi nền tảng nhất: Cloudflare đứng ở đâu trong đường đi của một request? Nắm được sơ đồ vòng đời request trong bài này thì mười hai phần sau chỉ là phóng to từng hộp trong đó.
Thuật ngữ kỹ thuật giữ nguyên tiếng Anh (origin, edge, nameserver, zone, cache, proxy, PoP, rule) vì đó là chữ bạn sẽ gặp trong dashboard Cloudflare, trong header HTTP và trong docs. Phần dịch là phần giải thích.
Lộ trình 13 phần
| Phần | Chủ đề | Nguồn gốc |
|---|---|---|
| 1 | Cloudflare thực ra là gì và lộ trình 13 phần | Chương 0, 1 |
| 2 | Nameserver, zone, bản ghi DNS, đám mây cam và xám | Chương 2 |
| 3 | Thiết lập Hostinger + Cloudflare từ A đến Z | Chương 3 |
| 4 | DNS chi tiết và các kịch bản trỏ tên miền | Chương 4 |
| 5 | SSL/TLS: bốn chế độ và lỗi ERR_TOO_MANY_REDIRECTS | Chương 5 |
| 6 | Cache: vì sao deploy xong vẫn thấy bản cũ | Chương 6 |
| 7 | Rules: chuyển hướng và biến đổi ở edge | Chương 7 |
| 8 | Cloudflare Pages: host frontend miễn phí | Chương 8 |
| 9 | Workers: chạy code ở edge | Chương 9 |
| 10 | Bảo mật và hiệu năng: WAF, bot, rate limit, tối ưu | Chương 10, 11 |
| 11 | Debug và sổ tay lỗi 5xx, 1xxx | Chương 12 |
| 12 | Chi phí, giới hạn gói Free và đối chiếu với AWS | Chương 13, 14 |
| 13 | Lộ trình 4 tuần, checklist, từ điển và FAQ | Chương 15, 16, 17 |
Cách đọc: phần 1 đến 3 đọc tuần tự — chúng là nền (Cloudflare đứng ở đâu, sáu khái niệm cốt lõi, rồi tự tay đưa tên miền thật của bạn qua Cloudflare). Phần 4 và 5 là hai chương gây lỗi nhiều nhất trong thực tế, nên đọc ngay sau khi zone của bạn Active. Từ phần 6 trở đi bạn nhảy cóc theo nhu cầu: deploy xong thấy bản cũ thì mở phần 6, cần www chuyển về tên miền gốc thì mở phần 7, muốn host SPA miễn phí thì mở phần 8. Phần 11 là sổ tay lỗi — đánh dấu lại để tra khi web sập. Phần 13 gom lộ trình bốn tuần, checklist và FAQ để bạn tự kiểm tra mình.
Tài liệu gốc là bộ tự học 17 chương, 10 bài lab. Series này gộp các chương ngắn lại, giữ nguyên toàn bộ lab (đánh số theo chương gốc để bạn đối chiếu được), và mở rộng thêm góc nhìn của người làm React, Vite, Next.js.
Series này dạy gì và không dạy gì
Đọc xong series, bạn tự trỏ được tên miền vào bất kỳ nơi nào đang chạy web của mình, bật HTTPS đúng cách, hiểu cache, và biết mở cái gì ra xem khi trang lỗi. Phạm vi được cắt có chủ đích:
| Series này dạy | Không đi vào |
|---|---|
| Nameserver, DNS record, cách trỏ tên miền vào hosting | Thiết kế hạ tầng nhiều vùng cho doanh nghiệp lớn |
| Đám mây cam và đám mây xám — và vì sao chọn sai là hỏng | Cloudflare Zero Trust, Tunnel nâng cao, Magic Transit |
| Bốn chế độ SSL và lỗi lặp chuyển hướng kinh điển | Vận hành mạng doanh nghiệp, BGP |
| Cache: Cloudflare cache gì, vì sao deploy xong vẫn thấy bản cũ | Tối ưu chi phí Enterprise |
| Rules: chuyển hướng, sửa header, chặn bot | Cloudflare Stream, R2 nâng cao, D1 |
| Cloudflare Pages: deploy frontend miễn phí | Lập trình Workers ở mức phức tạp |
| Sổ tay lỗi 5xx và mã lỗi 1xxx của Cloudflare |
Cách học đúng
Cloudflare khác AWS ở một điểm quyết định cách học: gần như mọi thứ trong series này làm được miễn phí và trong một buổi chiều. Không có rào cản chi phí, không sợ hoá đơn bất ngờ, không phải tạo credit card. Vì vậy hãy mở dashboard làm song song ngay từ phần 2, đừng đọc hết rồi mới làm. Đọc về cf-cache-status mà chưa từng nhìn thấy nó trong DevTools thì hai ngày sau quên sạch.
Thứ duy nhất bạn cần chuẩn bị
Một tên miền thật. Cloudflare hoạt động ở tầng tên miền, nên không có tên miền thì không học được gì cả — không có localhost cho DNS. Tên miền .io.vn, .xyz, .site giá khoảng 100–300 nghìn đồng cho năm đầu, hoàn toàn đủ để học và sau đó dùng làm portfolio. Nếu bạn đã có tên miền đang chạy web thật, càng tốt: phần 3 sẽ đưa nó qua Cloudflare mà không gián đoạn, miễn là làm đúng thứ tự.
Trước và sau khi có Cloudflare
Bình thường, khi ai đó truy cập example.com, trình duyệt hỏi DNS xem tên miền đó ứng với IP nào, rồi kết nối thẳng tới máy chủ của bạn (ví dụ máy chủ Hostinger ở Singapore hay Mỹ).
Khi bạn đưa tên miền qua Cloudflare, có một thay đổi căn bản: DNS trả về IP của Cloudflare, không phải IP máy chủ của bạn. Mọi người dùng đều kết nối tới Cloudflare trước. Cloudflare xử lý xong mới quyết định có cần hỏi máy chủ của bạn hay không.
KHÔNG CÓ CLOUDFLARE
────────────────────────────────────────────────────────────
Người dùng ─────────────────────────────► Máy chủ Hostinger
(Hà Nội) kết nối thẳng (Singapore / Mỹ)
IP: 203.0.113.45
▲ ai cũng biết IP này
CÓ CLOUDFLARE (đám mây cam)
────────────────────────────────────────────────────────────
Người dùng ──► Cloudflare ──────────────► Máy chủ Hostinger
(Hà Nội) (PoP Hà Nội) chỉ khi cần IP: 203.0.113.45
│ ▲ IP bị GIẤU
├─ Có cache? → trả luôn, không hỏi origin
├─ Kết thúc HTTPS (chứng chỉ miễn phí)
├─ Lọc bot, chặn tấn công
├─ Nén, tối ưu
└─ Áp dụng rules bạn đặtMột câu định nghĩa: Cloudflare là một reverse proxy toàn cầu. Nó đứng trước máy chủ của bạn, nhận mọi request thay cho máy chủ, và chỉ chuyển tiếp xuống khi thực sự cần. Mọi tính năng của Cloudflare — CDN, SSL, tường lửa, tối ưu, chuyển hướng — đều là hệ quả của vị trí đứng này.
Nếu bạn từng cấu hình server.proxy trong vite.config.ts để /api ở localhost:5173 được chuyển tiếp sang localhost:3000, bạn đã dùng một reverse proxy rồi: trình duyệt chỉ biết Vite, Vite mới biết backend ở đâu. Cloudflare là đúng ý tưởng đó, nhưng chạy ở hơn 300 thành phố, đứng trước tên miền thật của bạn, và có thêm cache, chứng chỉ, tường lửa gắn sẵn ở giữa.
Vòng đời một request qua Cloudflare
Sơ đồ này là xương sống của cả series. Mọi phần sau đều là phóng to một hộp trong đây — phần 2 là hộp ②, phần 5 là hộp ④ và ⑥, phần 6 là hộp ⑤e và ⑧, phần 7 là ⑤b và ⑤c, phần 9 là ⑤d.
① NGƯỜI DÙNG gõ https://example.com/products/123
│
▼
② DNS — hỏi "example.com là IP nào?"
Nameserver của tên miền đang trỏ về Cloudflare,
nên Cloudflare trả lời: IP của chính Cloudflare (vd 104.21.x.x)
│ ← IP máy chủ thật bị giấu
▼
③ KẾT NỐI TỚI PoP GẦN NHẤT
Người ở Hà Nội → PoP Hà Nội. Người ở Đức → PoP Frankfurt.
(Anycast: cùng một IP, có mặt ở nhiều nơi trên thế giới)
│
▼
④ BẮT TAY TLS
Cloudflare xuất "edge certificate" (Universal SSL, miễn phí, tự gia hạn)
│
▼
⑤ CLOUDFLARE XỬ LÝ — theo đúng thứ tự này
├─ (a) Chặn theo IP / quốc gia / WAF / bot → có thể dừng tại đây
├─ (b) Redirect Rules (vd www → không-www) → có thể trả 301 ngay
├─ (c) Transform Rules (sửa URL, sửa header)
├─ (d) Workers (nếu bạn có viết code ở edge)
└─ (e) TRA CACHE
├─ HIT → trả ngay, KHÔNG hỏi origin. cf-cache-status: HIT
└─ MISS → đi tiếp xuống origin
│
▼
⑥ KẾT NỐI TỚI ORIGIN (máy chủ thật của bạn)
- Dùng chế độ SSL bạn chọn (Flexible / Full / Full strict)
- Origin nhìn thấy IP của Cloudflare, KHÔNG phải IP người dùng
(IP thật nằm trong header CF-Connecting-IP)
│
▼
⑦ ORIGIN TRẢ RESPONSE (Hostinger / Vercel / VPS / S3 ...)
│
▼
⑧ CLOUDFLARE NHẬN RESPONSE
- Đọc Cache-Control để quyết định có lưu không, lưu bao lâu
- Nén Brotli / gzip
- Áp dụng Response Header Transform (thêm security header)
│
▼
⑨ TRẢ VỀ TRÌNH DUYỆT
Kèm header: cf-ray, cf-cache-status, server: cloudflare
│
▼
⑩ TRÌNH DUYỆT parse HTML → tải tiếp JS / CSS / ảnh
→ mỗi file lại quay về bước ③Đọc sơ đồ ra được gì
| Quan sát | Ý nghĩa thực tế |
|---|---|
| Cloudflare đứng trước origin | Nếu origin sập mà nội dung có trong cache, trang vẫn hiển thị được. Ngược lại, cấu hình sai ở Cloudflare thì origin hoàn toàn khoẻ mạnh mà web vẫn lỗi. |
| Có hai chặng HTTPS | Người dùng ↔ Cloudflare là chặng một, Cloudflare ↔ origin là chặng hai. Hai chặng này cấu hình riêng. Đây là gốc rễ của lỗi lặp chuyển hướng ở phần 5. |
| Cache nằm ở bước ⑤e, trước origin | Deploy file mới lên hosting không làm Cloudflare biết. Phải purge, hoặc để cache đúng cách từ đầu (phần 6). |
| Origin thấy IP của Cloudflare | Log của bạn sẽ toàn IP Cloudflare. Tính năng “chặn IP” hay “giới hạn theo IP” ở backend sẽ sai nếu không đọc CF-Connecting-IP. |
| Rules chạy trước cache | Chuyển hướng và chặn xảy ra ở edge, không tốn tài nguyên máy chủ. Rất rẻ và rất nhanh. |
Nhìn thấy nó trong DevTools
Mọi thứ trong sơ đồ đều để lại dấu vết trong response header. Mở DevTools → Network trên một trang dùng Cloudflare, chọn request HTML đầu tiên, tab Headers:
HTTP/2 200
server: cloudflare
cf-ray: 8a1b2c3d4e5f6789-HAN
cf-cache-status: DYNAMIC
content-encoding: brserver: cloudflare— request đã đi qua bước ⑤ (đám mây cam đang bật).cf-ray— mã định danh request; ba chữ cuối là PoP đã phục vụ bạn (HANlà Hà Nội,SGNlà TP.HCM,SINlà Singapore). Đó là bước ③.cf-cache-status— kết quả bước ⑤e:HITlà lấy từ cache,DYNAMIClà Cloudflare quyết định không cache loại nội dung này (mặc định với HTML).content-encoding: br— bước ⑧, Brotli.
Thói quen đọc bốn dòng này là kỹ năng debug quan trọng nhất của cả series; phần 11 xây cả quy trình chẩn đoán năm bước quanh chúng.
Cloudflare làm được gì cho một frontend developer
Tất cả những dòng dưới đây đều thuộc gói Free:
| Việc | Không có Cloudflare | Có Cloudflare (gói Free) |
|---|---|---|
| HTTPS | Tự xin Let’s Encrypt, tự gia hạn, dễ quên | Bật một nút, tự gia hạn vĩnh viễn |
| Tốc độ toàn cầu | Người ở xa máy chủ tải chậm | File tĩnh phục vụ từ PoP gần nhất |
| Băng thông | Hosting tính phí hoặc giới hạn | Không giới hạn băng thông qua proxy |
| Chống tấn công | Máy chủ nhỏ sập khi bị DDoS | Chống DDoS không giới hạn, kể cả gói Free |
| Chuyển hướng www, ép HTTPS | Sửa .htaccess hoặc cấu hình nginx | Vài cú click trong Rules |
| Giấu IP máy chủ | Ai cũng quét được | IP thật được che |
| Đổi hosting | Chờ DNS lan truyền 24–48 giờ | Đổi một bản ghi, có hiệu lực gần như tức thì |
| Host frontend | Cần mua hosting | Cloudflare Pages: miễn phí, băng thông không giới hạn |
Lợi ích ít người nói tới nhưng rất lớn: đổi hosting không cần chờ DNS. Khi tên miền đã ở Cloudflare và bản ghi để đám mây cam, người dùng luôn kết nối vào IP của Cloudflare — IP này không bao giờ đổi. Muốn chuyển từ Hostinger sang một VPS khác, bạn chỉ sửa IP đích trong bảng DNS của Cloudflare, hiệu lực trong vài giây. Không còn cảnh “chờ DNS lan truyền 48 tiếng”.
Với người làm frontend, hai dòng đáng tiền nhất là băng thông không giới hạn và Pages. Một portfolio React deploy lên Pages có HTTPS, có CDN toàn cầu, có preview URL cho từng pull request, và không tốn đồng nào — phần 8 làm việc này từ đầu đến cuối.
Cloudflare KHÔNG phải là gì
Bốn hiểu nhầm này gây ra phần lớn câu hỏi sai ngay từ đầu:
- Không phải hosting (trừ khi bạn dùng Cloudflare Pages hoặc Workers). Nó không lưu website của bạn — bạn vẫn cần một nơi chạy web ở phía sau. Đưa tên miền qua Cloudflare không có nghĩa là bỏ Hostinger; bạn vẫn upload code lên Hostinger như cũ. Cache ở edge chỉ là bản sao tạm thời, có thể bị xoá bất cứ lúc nào.
- Không phải nhà đăng ký tên miền mặc định. Bạn vẫn mua tên miền ở Hostinger, Namecheap, PA Việt Nam. Cloudflare chỉ quản lý DNS. (Cloudflare có bán tên miền qua Cloudflare Registrar, nhưng đó là dịch vụ riêng, không bắt buộc.)
- Không tự sửa code chậm của bạn. Bundle 5 MB vẫn là 5 MB — Cloudflare chỉ nén và đưa nó tới gần người dùng hơn. Lighthouse chấm điểm bundle size, render-blocking script, layout shift; những thứ đó sửa ở
vite.config.tsvà trong component, không sửa ở dashboard. - Không thay thế backend. API động vẫn phải chạy ở đâu đó. Workers và Pages Functions là “backend nhẹ” cho vài việc như giấu API key hay proxy tránh CORS, không phải nơi đặt cả hệ thống có database quan hệ.
Bốn sai lầm của tuần đầu tiên
Mỗi lỗi dưới đây có riêng một phần trong series. Biết trước dấu hiệu nhận biết để khi gặp thì mở đúng bài:
1. Sửa DNS trong hPanel Hostinger sau khi đã đổi nameserver. Dấu hiệu: sửa cả buổi mà dig vẫn trả kết quả cũ. Nguyên nhân: sau khi nameserver trỏ về Cloudflare, bảng DNS ở Hostinger không còn ai hỏi tới nữa. Phần 2 giải thích vì sao, phần 3 làm từng bước.
2. Để đám mây cam cho bản ghi email. Dấu hiệu: vài ngày sau khi bật Cloudflare, khách hàng bảo “gửi mail cho bạn bị trả về”. Cloudflare chỉ proxy HTTP/HTTPS, email đi SMTP nên bản ghi MX bắt buộc phải xám. Đây là lỗi gây thiệt hại thật, nằm ở phần 2 và phần 3.
3. Chọn SSL mode Flexible để “hết lỗi”. Dấu hiệu: trang báo ERR_TOO_MANY_REDIRECTS, hoặc chạy được nhưng chặng Cloudflare ↔ origin đi HTTP trần. Phần 5 mổ xẻ vòng lặp này và cách sửa đúng.
4. Deploy xong không thấy bản mới, rồi đổ lỗi cho build. Dấu hiệu: cf-cache-status: HIT với age lớn trên file bạn vừa đổi. Phần 6 nói cách purge và cách đặt Cache-Control để không phải purge nữa.
Thực hành: ba việc nên làm ngay hôm nay
Chương 1 trong tài liệu gốc chưa có lab, nhưng ba việc dưới đây chuẩn bị sẵn mọi thứ cho Lab 2.1 và Lab 3.1 ở hai phần sau. Mỗi việc dưới 15 phút.
- 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. Chọn
.io.vn,.xyzhoặc.site, mua ở bất kỳ nhà đăng ký nào bạn tiện — Hostinger, Namecheap, PA Việt Nam đều được, vì Cloudflare không quan tâm bạn mua ở đâu. - Tạo tài khoản Cloudflare và bật xác thực hai lớp ngay. Vào
dash.cloudflare.com, đăng ký, rồi bật 2FA trước khi làm bất cứ việc gì khác. Tài khoản này sẽ nắm quyền điều khiển DNS của toàn bộ tên miền bạn thêm vào — mất nó là mất tên miền theo nghĩa đen. Chưa cần bấm “Add a site” vội; phần 3 làm bước đó khi bạn đã sao lưu bảng DNS cũ. - Mở DevTools trên một trang web bạn hay dùng, tìm header
cf-ray. Rất nhiều trang Việt Nam dùng Cloudflare. Tab Network → tải lại → chọn request đầu tiên → Response Headers. Đọc ba chữ cái cuối củacf-ray— bạn vừa biết mình đang được phục vụ từ thành phố nào.
Kết quả mong đợi: bạn có một tên miền (hoặc một tên miền sẵn có đang chạy web), một tài khoản Cloudflare đã bật 2FA, và bạn đã nhìn thấy
server: cloudflarecùngcf-ray: ...-HAN(hoặc-SGN) bằng mắt thật. Nếu trang bạn mở không cócf-ray, đơn giản là nó không dùng Cloudflare — thử trang khác.
Tóm tắt
- Cloudflare là một reverse proxy toàn cầu: DNS trả về IP của Cloudflare, mọi request đi qua Cloudflare trước, chỉ khi cần mới xuống máy chủ thật (origin). Mọi tính năng đều là hệ quả của vị trí đứng này.
- Vòng đời một request có mười bước: DNS → PoP gần nhất → TLS → xử lý (chặn, redirect, transform, Workers, cache) → origin → response → cache và nén → trình duyệt. Rules chạy trước cache, cache chạy trước origin.
- Có hai chặng HTTPS cấu hình riêng nhau. Quên điều này là gặp
ERR_TOO_MANY_REDIRECTS. - Origin thấy IP của Cloudflare; IP thật nằm trong
CF-Connecting-IP. Deploy lên hosting không làm cache ở edge tự mới. - Gói Free cho HTTPS tự gia hạn, băng thông không giới hạn, chống DDoS, Rules, Pages — đủ cho gần như mọi dự án cá nhân và nhiều dự án thương mại.
- Cloudflare không phải hosting, không phải nhà đăng ký mặc định, không sửa bundle chậm, không thay backend.
- Ba header cần thuộc ngay từ hôm nay:
server: cloudflare,cf-ray,cf-cache-status.
Phần tiếp theo: Phần 2 — Nameserver, zone, bản ghi DNS, đám mây cam và xám — sáu khái niệm chiếm 80% những gì bạn cần để dùng Cloudflare hằng ngày. Nếu bạn muốn ôn lại tên miền, DNS và hosting là ba thứ khác nhau thế nào trước khi vào Cloudflare, bài Domain, DNS và hosting: mental model trong series Hosting là chỗ tốt để bắt đầu.
Đọc thêm
- Cloudflare Fundamentals — khái niệm nền, cách Cloudflare hoạt động, quản lý tài khoản.
- Cloudflare DNS docs — bản ghi, proxy status, nameserver.
- Cloudflare Cache docs — mặc định cache gì,
cf-cache-status, purge. - Cloudflare Pages docs — host frontend tĩnh miễn phí.