Trỏ Tên Miền Về VPS Từ A Đến Z: Cấu Hình Cloudflare DNS, Rà Soát A/AAAA Và Nghiệm Thu Chuẩn

Phạm vi thực hành: Máy chủ thử nghiệm chạy Ubuntu 24.04 LTS độc lập cùng tên miền phụ (subdomain) lab-cf02.localhost.vn. Chỉ thao tác trên tên miền và máy chủ thuộc quyền quản lý của bạn. Hồ sơ thực nghiệm bên dưới ghi nhận kết quả tạo và truy vấn bản ghi A thực tế trên máy LAB-CF-02.

Có một câu nói đùa kinh điển của dân quản trị hệ thống: “Mọi sự cố mạng trên đời đều không phải tại DNS… cho đến khi phát hiện ra đúng là tại DNS thật!” Thực tế, việc trỏ tên miền (domain) về VPS không chỉ dừng lại ở thao tác bấm nút thêm một dòng bản ghi A trên bảng điều khiển. Để người dùng gõ tên miền mà vào đúng trang web của bạn, hai vế phải khớp nhau hoàn hảo: hệ thống DNS phải dẫn đường tới đúng địa chỉ IP của VPS, và phía Web Server (NGINX) phải nhận diện đúng cái tên đó để trả về đúng giao diện. Trong bài này, chúng ta sẽ thực hành bằng một tên miền phụ (subdomain) riêng biệt để thoải mái vọc vạch mà không làm ảnh hưởng tới website hay hệ thống email chính đang hoạt động.

Hồ sơ thực tế: Bản ghi A đã thiết lập trên hệ thống Lab

Vào ngày 30/09/2026, đội ngũ localhost.vn đã tạo bản ghi A cho tên miền phụ lab-cf02.localhost.vn trỏ thẳng về địa chỉ IPv4 103.82.26.183 trên bảng điều khiển Cloudflare, đặt ở chế độ DNS only (đám mây xám) và TTL Auto. Trước khi nhấn nút lưu, địa chỉ IPv4 này đã được đối chiếu khớp 100% với máy ảo localhost-tutorial-lab-02 trên CloudFly. Toàn bộ các bản ghi wildcard và bản ghi phục vụ website/email chính của tên miền gốc đều được giữ nguyên trạng.

Ảnh chụp thực tế giao diện Cloudflare DNS đã lọc riêng theo tên subdomain thực hành, hiển thị rõ bản ghi loại A trỏ về 103.82.26.183 ở chế độ DNS only và TTL Auto.

Biên bản nghiệm thu tầng DNS và tầng Web Server (Origin) vào tối ngày 30/09/2026 (múi giờ UTC+7) ghi nhận chuỗi kết quả rất mạch lạc dưới đây:

Một chi tiết thú vị trên bảng điều khiển Cloudflare là khi bạn chọn TTL Auto ở chế độ DNS only, giá trị thực tế trả về cho các máy trạm trên Internet sẽ là 300 giây (5 phút). Lưu ý rằng các kết quả chuyển hướng HTTP 301 sang HTTPS 200 trong bảng trên được ghi nhận sau khi máy chủ đã được cấu hình đầy đủ Virtual Host và chứng chỉ SSL. Còn nếu bạn đang đi từng bước từ đầu và vừa mới chỉ cài NGINX ở bài trước, việc trỏ bản ghi A thành công sẽ đưa bạn tới trang chào Welcome to nginx! quen thuộc — để máy chủ phân biệt được tên miền riêng và trả về đúng giao diện website mong muốn, chúng ta sẽ cấu hình tiếp Virtual Host (Server Block) ở chặng kế tiếp.

Bằng chứng truy vấn các bộ phân giải DNS trên Console ngày 01/10

Vào lúc 09:25:59 ngày 01/10/2026 (UTC+7), từ giao diện Console của máy chủ LAB-CF-02, câu lệnh dig gọi qua bộ phân giải cục bộ 127.0.0.53 trả về trạng thái NOERROR, ANSWER: 1 với bản ghi A 103.82.26.183 và TTL 300. Danh sách máy chủ tên miền (NS) của tên miền gốc hiển thị rõ cặp đôi penny.ns.cloudflare.com và arnold.ns.cloudflare.com; đồng thời lệnh nslookup hỏi thăm máy chủ 1.1.1.1 cũng trả về đúng địa chỉ IP trên kèm dòng ghi chú Non-authoritative answer (câu trả lời lấy từ bộ nhớ đệm của máy chủ phân giải trung gian).

Ảnh chụp thực tế màn hình Console ngày 01/10/2026 lúc 09:25:59 (UTC+7) trên máy chủ Ubuntu LAB-CF-02, minh họa kết quả đối chiếu giữa lệnh dig và nslookup. Bấm vào ảnh để xem kích thước đầy đủ.

Bằng chứng truy vấn Authoritative Nameserver và kiểm tra AAAA/CNAME

Tiếp đó, vào lúc 09:32:16 ngày 01/10/2026 (UTC+7), chúng tôi thực hiện truy vấn bản ghi A bằng cách hỏi trực tiếp máy chủ quản lý gốc penny.ns.cloudflare.com (162.159.38.124): kết quả trả về bật sáng cờ thẩm quyền aa (Authoritative Answer), xác nhận 1 câu trả lời với TTL 300 và địa chỉ IP 103.82.26.183. Song song đó, hai lệnh hỏi thăm bản ghi AAAA (IPv6) và CNAME của cùng tên miền phụ đều trả về status: NOERROR, ANSWER: 0 — minh chứng rõ ràng rằng không hề có bản ghi IPv6 hay CNAME nào tồn tại cho tên miền phụ này.

Ảnh chụp màn hình Console lúc 09:32:16 ngày 01/10/2026 (UTC+7), thể hiện rõ cờ thẩm quyền aa khi hỏi trực tiếp Nameserver của Cloudflare và kết quả NOERROR / 0 answer khi rà soát AAAA cùng CNAME. Bấm vào ảnh để phóng to.

Chuẩn bị thông số trước khi mở bảng điều khiển DNS

Trong bài hướng dẫn này, chúng tôi sử dụng tên miền phụ lab-cf02.localhost.vn và địa chỉ IP mẫu trong tài liệu là 203.0.113.10. Khi thực hành, bạn hãy thay thế bằng tên miền thuộc quyền sở hữu của bạn và địa chỉ IPv4 công khai thực tế của chiếc VPS bạn vừa cài NGINX ở bài trước.

Trước khi gõ phím sửa bất kỳ dòng nào trên trang quản lý DNS, hãy tập thói quen của một kỹ sư cẩn trọng: ghi ra giấy tên miền đầy đủ, loại bản ghi định thêm, và chụp ảnh màn hình lưu lại các bản ghi hiện có. Nếu tên miền của bạn đang có sẵn một bản ghi đại diện kiểu *.ten-mien-cua-ban.com (wildcard) đang phục vụ các hệ thống khác, tuyệt đối không xóa hay sửa dòng wildcard đó! Bạn chỉ cần tạo thêm một bản ghi A cụ thể cho riêng nhánh subdomain thử nghiệm (ví dụ lab) — trong hệ thống DNS, bản ghi có tên cụ thể luôn được ưu tiên áp dụng trước bản ghi wildcard.

Sơ đồ 4 nguyên tắc an toàn trước khi chỉnh sửa bản ghi DNS do localhost.vn biên soạn.

Bước 1: Tìm đúng “người cầm sổ hộ khẩu” (Authoritative Nameserver) của tên miền

Một trong những bi kịch hài hước nhất của anh em làm web là mua tên miền ở nhà đăng ký A, đã chuyển Nameserver sang Cloudflare từ đời nào, nhưng hôm nay lại đăng nhập vào trang quản lý của nhà đăng ký A để thêm bản ghi rồi ngồi đợi cả buổi chiều không thấy web chạy! Để không bao giờ rơi vào cảnh “gõ nhầm cửa quan”, bạn hãy mở Terminal trên máy tính cá nhân và hỏi xem ai mới là người đang thực sự giữ quyền phân giải cho tên miền gốc của mình:

dig NS localhost.vn +short

Hãy thay localhost.vn bằng tên miền gốc của bạn. Nếu kết quả trả về là cặp máy chủ có đuôi .ns.cloudflare.com, nghĩa là sổ hộ khẩu DNS đang nằm ở Cloudflare — bạn bắt buộc phải đăng nhập vào đúng tài khoản Cloudflare đó để thêm bản ghi. Ngược lại, nếu kết quả trả về Nameserver của nhà đăng ký tên miền (như Matbao, Tenten, Namecheap…), thì bạn mới vào trang quản lý của nhà đăng ký đó để thao tác.

Và xin nhớ kỹ: khi bạn chỉ muốn trỏ thêm một subdomain mới (như lab.domain.com) về VPS, bạn chỉ cần thêm một dòng bản ghi A tại nơi đang quản lý DNS hiện hành, tuyệt đối không tự ý đổi cặp Nameserver của tên miền gốc kẻo làm sập luôn cả website chính lẫn hệ thống email công ty đang chạy ổn định!

Bước 2: Tạo bản ghi A ở chế độ DNS only (Đám mây xám)

Sau khi đã đăng nhập vào đúng bảng điều khiển Cloudflare quản lý tên miền của mình, bạn vào mục DNS → Records, bấm Add record và điền chính xác 5 thông số theo bảng hướng dẫn sau:

Trước khi nhấn Save, hãy nhìn dòng chữ xem trước ở phía trên biểu mẫu để chắc chắn tên miền không bị lặp đuôi kiểu lab.domain.com.domain.com. Và nhớ rằng ô địa chỉ IPv4 chỉ nhận đúng 4 cụm số cách nhau bởi dấu chấm (ví dụ 103.82.26.183) — tuyệt đối không điền http://, số cổng :80 hay dấu gạch chéo / vào ô này.

Tại sao chúng tôi luôn khuyên bạn phải tắt đám mây vàng sang chế độ DNS only (đám mây xám) ở bước đầu tiên? Bởi vì khi bật đám mây vàng (Proxy), Cloudflare sẽ đứng chắn ở giữa và trả về địa chỉ IP của máy chủ Cloudflare chứ không trả về IP thật của VPS bạn, đồng thời cơ chế SSL linh hoạt của proxy rất dễ tạo ra vòng lặp chuyển hướng vô tận (ERR_TOO_MANY_REDIRECTS) hoặc che khuất các lỗi cấu hình trên VPS. Cứ để đám mây xám cho tới khi bạn nhìn thấy tận mắt IP thật của VPS, cài xong chứng chỉ HTTPS chuẩn chỉnh trên máy chủ rồi sau này muốn bật đám mây vàng lên lúc nào cũng được!

Bước 3: Quét dọn các bản ghi AAAA (IPv6) và CNAME cũ gây xung đột

Sau khi tạo xong bản ghi A, hãy chạy ngay cụm 3 câu lệnh dưới đây để kiểm tra toàn diện tên miền phụ của bạn:

dig lab-cf02.localhost.vn A +short
dig lab-cf02.localhost.vn AAAA +short
dig lab-cf02.localhost.vn CNAME +short

Nếu hai lệnh kiểm tra AAAA và CNAME ở dưới trả về trắng trơn không có dòng nào, đó là tín hiệu tuyệt vời! (Nếu muốn nhìn rõ mã trạng thái, bạn có thể bỏ cờ +short đi để thấy dòng status: NOERROR, ANSWER: 0 — điều này khác hoàn toàn với việc lệnh bị treo connection timed out do đứt mạng).

Tại sao bước kiểm tra bản ghi AAAA (IPv6) lại quan trọng sống còn đến vậy? Hãy tưởng tượng tên miền của bạn trước đây từng trỏ vào một dịch vụ cũ có cả bản ghi A (IPv4) lẫn AAAA (IPv6). Hôm nay bạn chỉ sửa mỗi bản ghi A sang VPS mới mà quên xóa bản ghi AAAA cũ đi. Kết quả là gì? Những khách hàng dùng mạng cáp quang hay 4G ưu tiên giao thức IPv6 sẽ bị dẫn thẳng về chiếc máy chủ cũ kỹ kia, tạo ra cảnh tượng dở khóc dở cười: máy tính của bạn thì vào web mới ngon lành, còn điện thoại của sếp lại báo lỗi sập trang! Vì vậy, nếu VPS mới của bạn chưa cấu hình hoàn chỉnh IPv6 cho Web Server, hãy mạnh dạn xóa bỏ bản ghi AAAA của subdomain đó.

Tương tự, theo chuẩn DNS quốc tế, một tên miền đã mang bản ghi CNAME (tên bí danh) thì không được phép đứng chung với bản ghi A. Hãy đảm bảo mỗi subdomain thử nghiệm chỉ có một đường trỏ duy nhất, rõ ràng và minh bạch.

Sơ đồ các yếu tố cần rà soát đồng bộ khi trỏ bản ghi A do localhost.vn biên soạn.

Bước 4: Nghiệm thu tách biệt tầng DNS và tầng Web bằng tuyệt chiêu curl –resolve

Khi đã lưu bản ghi trên Cloudflare, bạn hãy kiểm tra xem cả bộ phân giải DNS của nhà mạng đang dùng lẫn máy chủ phân giải công cộng 1.1.1.1 đã nhận được địa chỉ IP mới hay chưa, đồng thời gọi thử HTTP vào tên miền:

dig lab-cf02.localhost.vn A +noall +answer
dig @1.1.1.1 lab-cf02.localhost.vn A +noall +answer
curl -I http://lab-cf02.localhost.vn/

Trong thực tế, đôi khi bạn vừa sửa DNS xong nhưng máy tính cá nhân hoặc modem nhà mạng vẫn còn lưu bộ nhớ đệm (cache) địa chỉ cũ theo thời gian TTL trước đó. Thay vì ngồi khoanh tay chờ đợi hoặc đi sửa file /etc/hosts trên máy tính dễ quên, dân kỹ thuật chuyên nghiệp có một tuyệt chiêu cực kỳ thanh lịch mang tên curl --resolve:

curl --resolve lab-cf02.localhost.vn:80:203.0.113.10 \
  http://lab-cf02.localhost.vn/

Tùy chọn --resolve ten-mien:cổng:IP_VPS ra lệnh cho riêng câu lệnh curl lần này bỏ qua hoàn toàn hệ thống DNS công cộng, phi thẳng tới địa chỉ IP của VPS (nhớ thay 203.0.113.10 bằng IP thật của bạn) và đặt đúng nhãn Host: lab-cf02.localhost.vn lên bàn làm việc của NGINX! Nếu câu lệnh --resolve này trả về đúng trang web mong muốn trong khi gõ tên miền bình thường trên trình duyệt vẫn lỗi, bạn có thể khẳng định 100% Web Server trên VPS đã chuẩn, chỉ cần ngồi nhâm nhi cà phê đợi cache DNS hết hạn là xong.

Trong trường hợp máy chủ đích đã được bạn cấu hình sẵn cả chứng chỉ bảo mật HTTPS ở cổng 443, bạn cũng có thể nghiệm thu luôn cả bước kiểm tra chứng chỉ TLS/SSL bằng câu lệnh tương tự cho cổng 443:

curl --resolve lab-cf02.localhost.vn:443:203.0.113.10 \
  https://lab-cf02.localhost.vn/

Lưu ý tuyệt đối không dùng cờ -k (--insecure) khi nghiệm thu thực tế, bởi chính việc để curl tự kiểm tra khắt khe sẽ giúp bạn xác nhận chứng chỉ bảo mật khớp hoàn toàn với tên miền.

Quy trình hoàn tác (Rollback) bản ghi DNS khi cần thiết

Nếu bạn cần đưa tên miền quay trở về trạng thái ban đầu sau buổi thực hành, hãy mở lại bức ảnh chụp màn hình cấu hình cũ mà bạn đã lưu ở bước chuẩn bị để điền lại chính xác loại bản ghi, địa chỉ đích và trạng thái bật/tắt Proxy. Nếu đây chỉ là một subdomain mới tinh tạo ra để làm bài tập, bạn chỉ cần xóa dòng bản ghi đó đi sau khi đã tắt dịch vụ thử nghiệm. Nhớ rằng ngay cả khi bạn đã hoàn tác trên bảng điều khiển DNS, một số trình duyệt và nhà mạng vẫn sẽ lưu giữ địa chỉ IP vừa thử trong khoảng thời gian bằng đúng con số TTL (ví dụ 5 phút) rồi mới cập nhật lại hoàn toàn.

Sơ đồ quy trình nghiệm thu bằng lệnh và hoàn tác an toàn bản ghi DNS do localhost.vn biên soạn.

Câu hỏi thường gặp (FAQ)

Tôi có bắt buộc phải bỏ tiền mua một tên miền mới tinh chỉ để làm bài thực hành này không? Hoàn toàn không cần! Nếu bạn đã có sẵn một tên miền đang dùng, bạn chỉ cần tạo một tên miền phụ (subdomain, ví dụ hoc-vps.ten-mien-cua-ban.com) là đã có ngay một không gian hoàn toàn độc lập để thực hành từ việc trỏ DNS, cấu hình NGINX cho tới xin cấp chứng chỉ SSL miễn phí Let’s Encrypt mà không hề đụng chạm tới website chính.

Tại sao lệnh dig đã báo đúng IP VPS của tôi mà mở trình duyệt lên vẫn thấy nhảy sang trang web cũ? Thủ phạm thường nằm ở 3 chỗ: một là tên miền đó vẫn còn sót bản ghi AAAA (IPv6) trỏ về máy cũ; hai là trình duyệt web của bạn đã lưu cứng lệnh chuyển hướng HTTP 301 từ lần truy cập trước vào bộ nhớ đệm (hãy mở cửa sổ ẩn danh Incognito hoặc dùng curl -I để kiểm tra); ba là trên NGINX chưa có khối server_name khớp với tên miền đó nên nó đang trả về trang mặc định đầu tiên.

Tôi lấy địa chỉ IP mạng nội bộ (Private IP kiểu 10.x.x.x hoặc 192.168.x.x) của VPS điền vào Cloudflare DNS được không? Không được nhé! Để người dùng từ khắp nơi trên Internet truy cập vào được website, bản ghi A công cộng bắt buộc phải trỏ về địa chỉ Public IPv4 của VPS.

Khi nào thì tôi biết mình đã hoàn thành trọn vẹn bài thực hành này? Khi câu lệnh dig trả về đúng địa chỉ IP công khai của VPS bạn, và khi bạn gõ tên miền phụ đó vào trình duyệt (hoặc curl) thì nhận được phản hồi trực tiếp từ chính Web Server NGINX trên VPS đó (dù hiện tại nó mới chỉ hiện trang Welcome to nginx!). Việc cấu hình để NGINX hiển thị đúng giao diện riêng của từng tên miền sẽ được giải quyết ở các bài tiếp theo.

Tài liệu tham khảo và chặng tiếp theo

Bộ tài liệu kỹ thuật chính thức đã được chúng tôi đối chiếu vào ngày 30/09/2026 bao gồm: Cloudflare: Quản lý bản ghi DNS, Cloudflare: Cơ chế hoạt động của TTL và tài liệu kinh điển NGINX: Cách thức xử lý một yêu cầu HTTP (How nginx processes a request).

Mời bạn xem lại bức tranh tổng thể tại lộ trình cài đặt WordPress trên VPS từ A đến Z. Ở bài tiếp theo, chúng ta sẽ mổ xẻ sâu hơn để không bao giờ còn nhầm lẫn: Nameserver, A, AAAA và CNAME thực chất khác nhau ở thao tác nào?