Cloudflare DNS từ A đến Z cho người mới: hướng dẫn từng bước 2026
Cloudflare DNS từ lâu không chỉ là nơi bạn khai báo tên miền trỏ về IP máy chủ. Khi cấu hình đúng, nó còn giúp che IP origin, lọc một phần lưu lượng xấu, cấp SSL, cache nội dung tĩnh và giảm tải cho server.
Tuy nhiên, nhiều website bị lỗi ERR_TOO_MANY_REDIRECTS, không gửi được email hoặc trỏ subdomain sai chỉ vì nhầm giữa đám mây cam và đám mây xám. DNS đúng là nền móng, nhưng chỉ cần một bản ghi sai là toàn bộ website, mail hoặc API có thể ngừng hoạt động.
Lưu ý: Cloudflare không thay thế VPS, hosting hay cấu hình web server. Nó đứng giữa người truy cập và origin server đối với các bản ghi được bật proxy.
Vì sao cần dùng Cloudflare DNS từ đầu
DNS là hệ thống chuyển tên miền như example.com thành địa chỉ IP như 203.0.113.10. Khi người dùng gõ tên miền trên trình duyệt, DNS sẽ trả về nơi cần kết nối.
Nếu quản lý DNS trực tiếp ở nhà đăng ký tên miền, bạn vẫn có thể vận hành website bình thường. Nhưng Cloudflare cung cấp dashboard dễ quản lý hơn, cập nhật DNS nhanh, có DNSSEC, hỗ trợ proxy HTTP/HTTPS và nhiều cơ chế bảo vệ bổ sung.
Hai pain point phổ biến nhất là:
- Website bị lộ IP origin, dẫn đến người khác có thể truy cập thẳng server và bỏ qua lớp bảo vệ phía trước.
- Mỗi khi đổi IP VPS hoặc chuyển hosting, DNS cập nhật chậm, cache lâu hoặc khó kiểm soát bản ghi giữa website, mail và dịch vụ phụ.
Cloudflare hỗ trợ authoritative DNS, nghĩa là nameserver của tên miền sẽ trỏ về Cloudflare. Sau khi kích hoạt, mọi thay đổi bản ghi A, AAAA, CNAME, MX, TXT trong dashboard Cloudflare sẽ là cấu hình DNS chính thức cho tên miền.
Với website chạy WordPress, Laravel, Node.js hoặc ứng dụng tự host trên VPS, Cloudflare đặc biệt hữu ích khi bạn muốn tách rõ ba lớp:
- DNS quyết định tên miền trỏ đi đâu.
- Proxy quyết định truy cập web có đi qua Cloudflare hay không.
- Origin server chịu trách nhiệm xử lý ứng dụng, database và nội dung động.
Trước khi thêm tên miền, nên chuẩn bị sẵn IP public của VPS và kiểm tra firewall đã mở cổng 80 và 443. Nếu chưa có máy chủ, bạn có thể xem hướng dẫn cấu hình Nginx làm reverse proxy để hiểu cách một domain được phục vụ từ origin.
Quy trình thêm domain vào Cloudflare
Các bước cơ bản gần như giống nhau với mọi domain:
- Đăng nhập Cloudflare, chọn
Add a site. - Nhập domain gốc, ví dụ
example.com, không nhậpwww.example.com. - Chọn gói phù hợp, sau đó để Cloudflare quét bản ghi DNS hiện có.
- Kiểm tra các bản ghi được import, xóa hoặc sửa những bản ghi không còn dùng.
- Cloudflare cung cấp hai nameserver mới.
- Vào trang quản lý domain tại nhà đăng ký và thay nameserver cũ bằng nameserver Cloudflare.
- Chờ trạng thái domain trên Cloudflare chuyển sang
Active.
Việc đổi nameserver thường hoàn tất nhanh, nhưng có thể mất vài giờ tùy registrar và TTL cũ. Bạn có thể kiểm tra bằng lệnh:
dig NS example.com +short
Nếu kết quả trả về nameserver của Cloudflare, phần ủy quyền DNS đã đúng. Đừng vội xóa DNS cũ tại registrar trước khi Cloudflare đã import đủ các record quan trọng.
Các bản ghi DNS cơ bản cần biết
| Loại bản ghi | Dùng để làm gì | Ví dụ | Có thể bật proxy? |
|---|---|---|---|
A | Trỏ hostname đến IPv4 | example.com -> 203.0.113.10 | Có |
AAAA | Trỏ hostname đến IPv6 | example.com -> 2001:db8::10 | Có |
CNAME | Alias một hostname sang hostname khác | www -> example.com | Có, tùy đích |
MX | Chỉ định mail server nhận thư | mail.example.com | Không |
TXT | Xác minh domain, SPF, DKIM, DMARC | SPF record | Không |
CAA | Chỉ định CA được phép cấp SSL | letsencrypt.org | Không |
SRV | Chỉ định dịch vụ theo cổng/protocol | game, SIP, XMPP | Không |
Với website đơn giản, cấu hình tối thiểu thường là:
A @ 203.0.113.10 Proxied
CNAME www example.com Proxied
Trong đó @ đại diện cho domain gốc. www là subdomain phổ biến, có thể trỏ bằng CNAME về domain gốc để giảm việc phải cập nhật IP ở nhiều nơi.
Nếu bạn dùng IPv6, chỉ thêm bản ghi AAAA khi server thực sự có IPv6 được cấu hình hoàn chỉnh. Một bản ghi AAAA trỏ sai có thể khiến một phần người dùng không vào được site, dù IPv4 vẫn hoạt động.
Proxy bật/tắt trong Cloudflare DNS từ: đám mây cam và xám khác nhau thế nào
Trong trang DNS > Records, Cloudflare dùng biểu tượng đám mây để biểu thị trạng thái proxy:
- Đám mây cam,
Proxied: lưu lượng HTTP/HTTPS đi qua Cloudflare trước khi tới origin. - Đám mây xám,
DNS only: Cloudflare chỉ trả lời DNS, người dùng kết nối trực tiếp đến IP hoặc hostname đích.
Đây là phần quan trọng nhất khi làm quen với Cloudflare DNS. Nhiều lỗi xảy ra vì bật proxy cho dịch vụ không phải web, hoặc tắt proxy nhưng lại kỳ vọng Cloudflare che IP và cache nội dung.
Khi bật đám mây cam, DNS không trả về IP VPS của bạn. Thay vào đó, nó trả về IP anycast của Cloudflare, rồi Cloudflare chuyển tiếp request đến origin.
Lợi ích của Proxied gồm:
- Che IP origin khỏi truy cập thông thường.
- Kích hoạt SSL edge, WAF, rate limiting và cache theo gói dịch vụ/cấu hình.
- Hỗ trợ giảm một phần lưu lượng tấn công HTTP/HTTPS.
- Cho phép áp dụng Rules theo hostname, đường dẫn, quốc gia hoặc loại request.
Khi để DNS only, DNS trả thẳng IP origin hoặc hostname thực. Cloudflare không cache, không lọc request HTTP, không cấp SSL edge cho hostname đó và cũng không che IP server.
Ghi nhớ: Đám mây cam chủ yếu dành cho website chạy HTTP/HTTPS trên các cổng được Cloudflare hỗ trợ. Nó không phải nút bật bảo vệ cho mọi loại dịch vụ.
Ví dụ thực tế:
A example.com 203.0.113.10 Proxied
CNAME www example.com Proxied
A api 203.0.113.10 Proxied
A panel 203.0.113.10 DNS only
A mail 203.0.113.10 DNS only
api có thể bật proxy nếu API phục vụ qua HTTPS và ứng dụng tương thích với IP header của Cloudflare. panel có thể để DNS-only nếu đó là cổng quản trị đặc biệt, VPN hoặc dịch vụ không chạy qua HTTP chuẩn.
Nếu bật proxy cho API, ứng dụng phải lấy IP thật của khách từ header như CF-Connecting-IP hoặc X-Forwarded-For. Với Nginx, bạn cần cấu hình real IP đúng cách, nếu không log sẽ chỉ ghi nhận IP Cloudflare.
Tham khảo danh sách cổng HTTP/HTTPS được proxy trong tài liệu chính thức của Cloudflare. Đừng mặc định rằng mọi cổng như 22, 3306, 25565 hoặc 2087 đều hoạt động qua đám mây cam.
Bản ghi nào bắt buộc phải để DNS-only
Các bản ghi liên quan đến email gần như luôn phải để DNS only. Cloudflare proxy không chuyển tiếp SMTP, IMAP, POP3 theo cách một mail server cần hoạt động.
Nhóm bản ghi cần để đám mây xám gồm:
MXcủa domain.AhoặcAAAAcủa hostname mail, ví dụmail.example.com.TXTchứa SPF, DKIM, DMARC, xác minh email.- Bản ghi autodiscover hoặc autoconfig nếu mail client cần dùng trực tiếp.
SRVcho dịch vụ chuyên dụng.- Bản ghi dùng cho SSH, database, game server, VPN, FTP hoặc các giao thức non-HTTP.
Ví dụ cấu hình mail phổ biến:
A mail 203.0.113.10 DNS only
MX @ mail.example.com DNS only
TXT @ v=spf1 mx -all DNS only
TXT _dmarc v=DMARC1; p=none; DNS only
Nếu bạn bật proxy cho record mail, mail client có thể cố kết nối đến IP Cloudflare thay vì IP mail server. Hệ quả thường là không gửi được mail, nhận mail lỗi hoặc TLS báo sai chứng chỉ.
Một trường hợp khác là subdomain dùng để xác minh dịch vụ. Record TXT luôn là DNS-only vì nó chỉ được resolver truy vấn, không có khái niệm proxy cho TXT.
Cẩn thận với CNAME. Nếu mail.example.com là CNAME đến một hostname khác, hostname đích phải thực sự phục vụ mail và không bị proxy sai cách.
Khi cần quản trị máy chủ qua SSH, bạn có thể tạo ssh.example.com trỏ về IP VPS và để DNS-only. Tuy vậy, an toàn hơn là giới hạn SSH bằng firewall, key-based authentication và VPN, thay vì chỉ dựa vào việc khó đoán hostname.
Xem thêm hướng dẫn cấu hình firewall UFW cho VPS để giới hạn cổng quản trị. Một DNS record đúng không đồng nghĩa server đã an toàn.
SSL mode: Flexible gây vòng lặp chuyển hướng ra sao
Cloudflare có các SSL/TLS mode quyết định kết nối từ Cloudflare đến origin:
| SSL mode | Trình duyệt đến Cloudflare | Cloudflare đến origin | Khuyến nghị |
|---|---|---|---|
Off | Không dùng HTTPS | Không áp dụng | Không dùng cho website công khai |
Flexible | HTTPS | HTTP | Không khuyến nghị |
Full | HTTPS | HTTPS, chấp nhận cert self-signed | Dùng tạm khi cần |
Full (strict) | HTTPS | HTTPS, yêu cầu cert hợp lệ | Khuyến nghị |
Strict (SSL-Only Origin Pull) | HTTPS | HTTPS với kiểm tra chặt hơn | Dành cho cấu hình nâng cao |
Flexible là nguyên nhân kinh điển của lỗi vòng lặp chuyển hướng. Với mode này, người dùng truy cập https://example.com, Cloudflare nhận HTTPS nhưng lại gửi request HTTP đến origin.
Nếu Nginx, Apache hoặc WordPress tại origin ép HTTP sang HTTPS, server sẽ phản hồi chuyển hướng về https://example.com. Cloudflare lại nhận HTTPS và tiếp tục gọi origin bằng HTTP, chu trình lặp lại cho đến khi trình duyệt báo ERR_TOO_MANY_REDIRECTS.
Luồng lỗi có thể hình dung như sau:
Browser HTTPS -> Cloudflare
Cloudflare HTTP -> Origin
Origin redirect HTTP sang HTTPS -> Cloudflare
Cloudflare HTTP -> Origin
Cách xử lý chuẩn là cài SSL hợp lệ tại origin, sau đó chọn Full (strict). Bạn có thể dùng Let’s Encrypt hoặc Cloudflare Origin Certificate, tùy mô hình vận hành.
Cloudflare Origin Certificate chỉ phù hợp cho kết nối giữa Cloudflare và origin, không phù hợp khi người dùng truy cập trực tiếp IP server. Nếu origin có thể bị truy cập trực tiếp, Let’s Encrypt thường tiện hơn cho các kiểm tra và fallback thông thường.
Sau khi SSL origin hoạt động, bật Full (strict) tại SSL/TLS > Overview. Tiếp theo, chỉ giữ một nơi đảm nhiệm redirect HTTP sang HTTPS, thường là Nginx hoặc Cloudflare redirect rule.
Với WordPress, kiểm tra WordPress Address và Site Address phải dùng https://. Nếu website nằm sau proxy, ứng dụng cũng cần nhận biết request HTTPS thông qua header chuyển tiếp để tránh tạo URL HTTP.
Bạn có thể tham khảo cách cài SSL Let’s Encrypt với Nginx trước khi chuyển sang Full (strict).
Cache và purge đúng cách
Cache giúp Cloudflare lưu bản sao nội dung tại edge để trả về nhanh hơn. Tuy nhiên, cache không có nghĩa toàn bộ website được tự động cache an toàn.
Mặc định, Cloudflare chủ yếu cache static asset có phần mở rộng như:
.css,.js,.jpg,.png,.webp,.svg- Font như
.woff2 - Một số file media và tài nguyên công khai
HTML thường không được cache toàn bộ theo mặc định. Đây là hành vi an toàn cho các trang có đăng nhập, giỏ hàng, nội dung theo tài khoản hoặc token cá nhân.
Khi cập nhật CSS/JS mà khách vẫn thấy giao diện cũ, hãy kiểm tra theo thứ tự:
- Có phải file đang dùng cùng URL cũ không.
- Header
Cache-Controltừ origin đang đặt thế nào. - Cloudflare có cache hit hay không.
- Trình duyệt hoặc plugin cache của ứng dụng có giữ bản cũ không.
- Có rule cache nào đang áp dụng quá rộng không.
Purge nên dùng theo phạm vi nhỏ nhất có thể. Nếu chỉ sửa https://example.com/assets/app.css, hãy purge đúng URL đó thay vì purge toàn bộ zone.
Purge toàn bộ cache hữu ích sau khi triển khai lớn hoặc thay đổi template diện rộng. Nhưng nó làm mọi edge mất cache cùng lúc, origin có thể nhận lượng request lớn hơn bình thường.
Cách tốt hơn là dùng version trong tên file:
/app.css?v=20260301
/app.8f3a1c.js
Khi file đổi URL, CDN và browser tự tải bản mới mà ít phải purge. Đây là lý do nhiều pipeline build frontend tạo tên file có hash.
Không nên tạo rule kiểu Cache Everything cho toàn bộ domain mà chưa loại trừ:
/wp-admin/*/wp-login.php/cart/*/checkout/*/account/*- API trả dữ liệu riêng theo user
- Trang có cookie đăng nhập hoặc session
Cache sai có thể làm người dùng thấy dữ liệu của người khác, session bị lỗi hoặc đơn hàng hiển thị không nhất quán. Tốc độ tốt không đáng đổi lấy lỗi bảo mật và logic ứng dụng.
Khi nào Cloudflare KHÔNG giúp gì
Cloudflare không sửa được code PHP chậm, query database thiếu index hoặc VPS hết RAM. Nếu origin mất 10 giây để render trang HTML động, Cloudflare chỉ có thể che bớt vấn đề khi trang đó được cache hợp lý.
Cloudflare cũng không thay thế backup. Nếu database bị xóa, ransomware mã hóa dữ liệu hoặc bạn deploy nhầm, cache edge không phải bản sao lưu đáng tin cậy.
Một số tình huống Cloudflare không giải quyết trực tiếp:
- Server bị quá tải CPU do cron, worker hoặc tiến trình chạy nền.
- MySQL/PostgreSQL chậm vì schema, index hoặc query kém.
- IP origin đã bị lộ và firewall vẫn cho phép mọi người truy cập trực tiếp.
- Dịch vụ chạy cổng hoặc giao thức không được proxy thông thường hỗ trợ.
- DNS cấu hình đúng nhưng ứng dụng trả lỗi
500,502hoặc503. - Email bị vào spam do SPF, DKIM, DMARC hoặc reputation kém.
Nếu thấy lỗi 522, 524 hoặc 520, đừng chỉ purge cache. Hãy kiểm tra log Nginx, log ứng dụng, CPU/RAM, firewall và kết nối từ IP Cloudflare đến origin.
Một nguyên tắc quan trọng là chặn truy cập web trực tiếp vào origin, chỉ cho phép IP Cloudflare vào cổng 80 và 443 nếu mô hình của bạn phù hợp. Danh sách IP Cloudflare có thể thay đổi, nên cần cập nhật firewall theo tài liệu chính thức.
Cloudflare giúp giảm bề mặt tấn công và tối ưu lớp biên. Nó không thay thế hardening server, monitoring, backup định kỳ và quy trình deploy an toàn.
Sai lầm phổ biến
Bật đám mây cam cho mail
Đây là lỗi gây gián đoạn email phổ biến nhất. Record mail phải là DNS-only để SMTP/IMAP/POP3 kết nối trực tiếp đến mail server.
Dùng Flexible vì origin chưa có SSL
Cấu hình này có thể chạy tạm trong vài trường hợp, nhưng dễ tạo redirect loop và khiến kết nối Cloudflare đến origin là HTTP. Hãy cài chứng chỉ tại origin và dùng Full (strict).
Xóa record MX hoặc TXT khi dọn DNS
Một website vẫn có thể chạy dù MX/TXT bị xóa, nên lỗi thường chỉ lộ ra khi mail không nhận được hoặc gửi vào spam. Trước khi chỉnh DNS, export hoặc chụp lại toàn bộ record hiện tại.
Cache mọi thứ để tăng điểm tốc độ
Cache toàn bộ HTML mà không loại trừ trang đăng nhập, dashboard hoặc checkout có thể phá session. Hãy cache tài nguyên tĩnh trước, sau đó chỉ cache HTML công khai khi bạn hiểu rõ cookie và rule.
Tin rằng proxy che IP tuyệt đối
IP origin vẫn có thể lộ qua record DNS cũ, subdomain bỏ quên, mail header, log công khai hoặc cấu hình sai. Sau khi chuyển Cloudflare, rà soát tất cả hostname đang trỏ về VPS.
Đổi nameserver nhưng không kiểm tra zone
Cloudflare chỉ import record tại thời điểm quét, có thể thiếu bản ghi tạo sau đó hoặc record đặc biệt. Trước khi xác nhận chuyển nameserver, đối chiếu DNS ở registrar với zone Cloudflare.
Câu hỏi thường gặp
Cloudflare DNS có miễn phí không?
Cloudflare có gói miễn phí đáp ứng tốt nhu cầu DNS authoritative, proxy website cơ bản, SSL edge và một số tính năng bảo vệ. Các tính năng nâng cao có thể phụ thuộc vào gói dịch vụ và cấu hình cụ thể.
Có cần chuyển nameserver sang Cloudflare không?
Có, nếu bạn muốn Cloudflare quản lý authoritative DNS cho domain. Chỉ thêm record ở Cloudflare nhưng không đổi nameserver tại registrar thì các record đó chưa có hiệu lực với người dùng Internet.
Có thể bật proxy cho subdomain api không?
Có, nếu API dùng HTTP/HTTPS trên cổng được hỗ trợ. Bạn cần kiểm tra CORS, webhook, giới hạn upload, timeout và việc ứng dụng đọc IP thật từ CF-Connecting-IP.
Đám mây xám có còn dùng DNS Cloudflare không?
Có. DNS only vẫn dùng nameserver Cloudflare để phân giải tên miền, nhưng lưu lượng truy cập không đi qua mạng proxy của Cloudflare.
Bao lâu DNS mới cập nhật sau khi sửa record?
Thường thay đổi thấy được trong vài phút, nhưng còn phụ thuộc TTL, resolver của nhà mạng và cache trên thiết bị. Khi kiểm tra, dùng dig, nslookup hoặc DNS checker thay vì chỉ reload trình duyệt.
Có nên dùng Cloudflare cho trang quản trị VPS?
Nếu panel chạy HTTPS chuẩn và bạn hiểu cách giới hạn truy cập, có thể dùng proxy. Tuy nhiên với SSH, database, VPN hoặc panel dùng cổng không hỗ trợ, để DNS-only và bảo vệ bằng firewall, VPN, IP allowlist là cách thực tế hơn.
Tóm tắt nhanh
- Cloudflare DNS quản lý bản ghi domain, còn proxy quyết định lưu lượng web có đi qua Cloudflare hay không.
- Bản ghi website HTTP/HTTPS thường bật đám mây cam để dùng SSL edge, cache và che IP origin.
MX,TXT,mail, SSH, database, VPN và dịch vụ non-HTTP thường phải để đám mây xám, tứcDNS only.- Không dùng SSL mode
Flexiblecho website production, ưu tiênFull (strict)với SSL hợp lệ tại origin. - Purge theo URL cụ thể khi có thể, tránh purge toàn bộ và tránh cache mọi trang HTML một cách mù quáng.
- Cloudflare không sửa được database chậm, code lỗi, VPS quá tải hay backup thiếu.
- Sau mỗi thay đổi DNS, kiểm tra lại bằng
dig, log server, SSL mode và luồng gửi nhận email.
