19 thg 11, 2025·8 phút
Bảng kiểm khắc phục sự cố tên miền tùy chỉnh cho DNS và SSL
Dùng bảng kiểm này để chẩn đoán lỗi bản ghi DNS, độ trễ propagation và thời gian cấp SSL, kèm các bước kiểm tra đơn giản.
Dùng bảng kiểm này để chẩn đoán lỗi bản ghi DNS, độ trễ propagation và thời gian cấp SSL, kèm các bước kiểm tra đơn giản.
“Custom domain not working” là một cụm từ bao quát cho vài loại lỗi khác nhau. Trình duyệt hiển thị triệu chứng, không phải nguyên nhân. Trước khi thay đổi gì, hãy gọi tên chính xác những gì bạn đang thấy.
Các triệu chứng điển hình bao gồm:
Hầu hết thời gian, chỉ có một việc sai:
Trước khi khắc phục, đảm bảo bạn có quyền truy cập hai chỗ: nơi chỉnh sửa bản ghi DNS (nhà đăng ký hoặc nhà cung cấp DNS) và nơi bạn đính kèm domain ở phía hosting. Ví dụ, nếu bạn kết nối một app triển khai trên Koder.ai với domain tùy chỉnh, bạn cần quyền DNS cho domain và cài đặt domain trong thiết lập hosting/triển khai của app.
Một số sửa nhanh là ngay lập tức (như sửa lỗi chính tả). Các thay đổi khác cần thời gian. Thay đổi DNS có thể mất một lúc để hiển thị, và SSL thường chỉ hoàn tất khi DNS trỏ chính xác và domain có thể truy cập được. Mục tiêu là ngừng đoán mò và xác nhận từng lớp theo thứ tự.
Hầu hết lỗi domain là do không khớp giữa (1) hostname bạn đang test, (2) nơi DNS được quản lý, và (3) bản ghi thực tế trỏ tới đâu. Khi ba thứ đó khớp, SSL thường là bước cuối.
Domain có hai dạng phổ biến: root domain (example.com, còn gọi là apex) và subdomain (www.example.com, app.example.com). Chúng liên quan nhưng có thể có bản ghi DNS khác nhau. Vì vậy www hoạt động mà apex không phải là chuyện bình thường, hoặc ngược lại.
Nameserver quyết định ai quản lý zone DNS của bạn. Nếu bạn mua domain từ một công ty nhưng nameserver trỏ sang nhà cung cấp khác, bạn phải chỉnh DNS ở nơi mà nameserver trỏ tới. Nhiều trường hợp “tôi đã cập nhật nhưng không thấy thay đổi” xảy ra vì bản ghi được chỉnh ở dashboard sai.
Đây là chức năng của các loại bản ghi chính:
TTL là “thời gian để cache” — thấp hơn thì cache làm mới nhanh hơn. Cao hơn thì bạn có thể phải đợi lâu hơn, ngay cả sau khi sửa bản ghi. Việc thấy giá trị cũ một thời gian là bình thường.
Khi domain tùy chỉnh lỗi, thường rơi vào bốn nhóm: DNS không phân giải, DNS phân giải tới chỗ sai, SSL chưa sẵn sàng, hoặc chỉ một số người bị do cache.
Dùng cây quyết định này:
www hoạt động nhưng root domain không (hoặc ngược lại), có khả năng bạn chỉ cấu hình một hostname, hoặc có quy tắc redirect xung đột.Tiến nhanh hơn bằng cách ghi lại chính xác hostname lỗi (apex hay www) và thông báo lỗi chính xác. Trên các nền tảng hosting tự động hóa domain và chứng chỉ, sự khác biệt giữa “không tìm thấy host” và “chứng chỉ đang chờ” cho bạn biết nên sửa DNS hay chỉ cần đợi SSL sau khi DNS hiển thị.
Nhiều lỗi domain bắt đầu bằng sự không khớp đơn giản: bạn thiết lập DNS cho một hostname nhưng lại test hostname khác.
Đầu tiên, ghi rõ hostname bạn muốn bật. Root domain trông như example.com. Subdomain trông như www.example.com hoặc app.example.com. Đây là các mục nhập DNS riêng, nên “www hoạt động” không có nghĩa apex cũng sẽ.
Tiếp theo, tìm mục tiêu mong đợi từ nền tảng hosting. Một số nền tảng cho địa chỉ IP (cho A hoặc AAAA). Các nền tảng khác cho một hostname đích (cho CNAME). Nếu host cung cấp một giá trị trong màn hình thiết lập domain, coi đó là nguồn sự thật.
Trước khi thay đổi gì, chụp lại thiết lập hiện tại. Giữ đơn giản:
Cũng xác nhận bạn đang chỉnh đúng zone DNS. Rất dễ cập nhật nhầm domain, môi trường, hoặc tài khoản nhà cung cấp.
Nhiều vấn đề chỉ là chọn sai loại bản ghi cho hostname bạn đang kết nối. Bắt đầu bằng cách tách hai trường hợp: root domain (example.com) và subdomain (www.example.com). Chúng xử lý khác nhau trên nhiều nhà cung cấp DNS.
A record trỏ tên tới địa chỉ IPv4. Nhiều cấu hình dùng A record cho root domain vì một số nhà cung cấp không cho phép CNAME ở apex. Nếu host cung cấp IP, A record thường là đúng.
AAAA là phiên bản IPv6. Một AAAA thừa trỏ tới đích cũ có thể tạo ra hành vi “ai thấy khác” vì một số khách truy cập vào IPv6 trong khi người khác vào IPv4. Nếu host không cung cấp mục tiêu IPv6, xóa AAAA sai thường sẽ sửa được lỗi không đồng nhất.
CNAME trỏ một subdomain tới một hostname khác (thường dùng cho www). Nó hữu ích khi host muốn bạn trỏ tới một endpoint đặt tên có thể thay đổi đằng sau.
TXT là cho xác minh và thử thách (bao gồm một số kiểm tra SSL). Lỗi hay gặp là đặt TXT sai tên (root vs _acme-challenge vs subdomain), thêm khoảng trắng thừa, hoặc dán giá trị sai.
Trước khi tiếp tục, tìm xung đột. Đây là những thứ gây rắc rối nhất:
Nhiều trường hợp “custom domain not working” không phải vì giá trị bản ghi. Chúng xảy ra vì bản ghi được thêm ở nhà cung cấp sai. Nếu domain dùng nameserver của Provider A, thay đổi bản ghi ở dashboard Provider B sẽ không có tác dụng, dù các bản ghi trông đúng ở đó.
Kiểm tra nameserver mà domain thực sự dùng. Bạn thường xem được điều này trong cài đặt domain tại registrar dưới phần “Nameservers”. Để kiểm tra từ máy tính của bạn, hỏi DNS trực tiếp:
dig NS example.com
Các nameserver trả về bởi lệnh đó là ones có thẩm quyền.
Một kiểm tra nhanh:
ns1... và ns2..., các giá trị chính xác đó phải xuất hiện ở registrar.Nếu bạn cập nhật bản ghi ở nhà cung cấp sai, bạn thường thấy hai dashboard không khớp nhau. Chỉ nameserver có thẩm quyền mới quan trọng.
Cũng để ý độ trễ sau khi thay đổi nameserver tại registrar. Trong cửa sổ chuyển đổi, kết quả có thể khác nhau tùy nơi bạn test. Nếu nameserver vẫn đang thay đổi, tạm dừng chỉnh bản ghi cho tới khi tập hợp nameserver ổn định, rồi tiếp tục.
“Propagation” không phải một công tắc. Đó là chuỗi các cache DNS (ISP, nhà mạng di động, resolver công cộng, và thiết bị của bạn) cập nhật với tốc độ khác nhau. Đó là lý do vì sao domain có thể hoạt động với đồng nghiệp nhưng không với bạn.
TTL (time to live) nói cho cache biết nó có thể giữ câu trả lời bao lâu. Nếu TTL cũ là 1 giờ, một số người sẽ tiếp tục thấy giá trị cũ trong gần 1 giờ. Hạ TTL giúp chỉ khi bạn thực hiện trước khi thay đổi.
Để tách độ trễ do cache khỏi lỗi thật, thực hiện vài kiểm tra nhanh:
Nếu bản ghi sai ở bất kỳ nơi nào bạn kiểm tra (IP sai, thiếu www, CNAME cũ), hãy sửa. Nếu bản ghi trông đúng ở hầu hết nơi nhưng một mạng vẫn thấy giá trị cũ, đó thường là do cache.
Chứng chỉ SSL thường thất bại vì một lý do cơ bản: nhà cấp không thể xác minh domain cho đến khi DNS trỏ tới chỗ đúng một cách nhất quán.
Thứ tự bình thường là đơn giản:
Các chướng ngại hay bị bỏ sót rất dễ nhận thấy. A hoặc CNAME sai gửi kiểm tra xác minh tới server sai. AAAA cũ có thể ghi đè A hoạt động cho một số khách truy cập, khiến HTTPS chỉ lỗi với họ. Thiếu TXT bắt buộc có thể ngăn nền tảng cấp chứng chỉ.
Dùng triệu chứng để phân biệt “vẫn đang cấp” và “cấu hình sai”:
Khi chờ, đừng thay đổi bản ghi liên tục. Mỗi lần thay đổi đặt lại đồng hồ và có thể tạo ra một thế giới phân tách nơi các mạng khác nhau thấy các câu trả lời khác nhau. Đặt bản ghi đúng một lần, rồi kiểm tra lại độ phân giải và xác minh cho tới khi chứng chỉ được cấp.
Nếu bạn dùng nền tảng như Koder.ai, quy trình an toàn nhất là: xác nhận DNS trỏ tới mục tiêu mong đợi, loại bỏ AAAA sai nếu có, và cho SSL thời gian sau khi DNS ổn định.
Khắc phục tốt chủ yếu là so sánh: những gì bạn thấy so với những gì bạn mong đợi. Đừng dựa vào “nó chạy trên điện thoại của tôi.” Dùng các kiểm tra có thể lặp lại.
Dùng công cụ lookup DNS (như nslookup hoặc dig) và xác nhận giá trị trả về khớp bạn định (IP cho A hoặc AAAA, hostname cho CNAME, token cho TXT).
# Apex (root) domain
dig example.com A
dig example.com AAAA
# www subdomain
dig www.example.com CNAME
# TXT (thường dùng để xác minh)
dig example.com TXT
Kiểm tra cả hai tên bạn có thể dùng: apex (example.com) và www (www.example.com). Thường gặp là một cái đúng trong khi cái kia vẫn trỏ chỗ cũ.
Mở cả http:// và https:// cho apex và www. Bạn muốn một domain "chính" rõ ràng và một redirect sạch.
www) và redirect cái còn lại về nó.Nếu kết quả khác nhau theo mạng, bạn có thể đang thấy cache hoặc propagation. Giữ một nhật ký nhỏ: bạn đã thay đổi gì, nơi thay đổi, thời gian, và quan sát được.
Hầu hết lỗi DNS và SSL không phải điều bí ẩn. Chúng là những sai sót nhỏ khiến bạn kiểm tra sai chỗ, hoặc thay đổi quá nhanh để có kết luận rõ ràng.
Thời gian tồi tệ nhất là chỉnh DNS ở hai chỗ. Điều này thường xảy ra sau khi đổi nameserver: bạn cập nhật bản ghi ở registrar, nhưng DNS thực tế host ở nơi khác (hoặc ngược lại). Mọi thứ trông đúng ở một dashboard, nhưng công khai thì không thay đổi.
Một lỗi cổ điển khác là cố đặt CNAME ở root domain khi nhà cung cấp không hỗ trợ. Bạn có thể cần một A record, hoặc ALIAS/ANAME nếu nhà cung cấp có hỗ trợ.
IPv6 cũng gây rắc rối. Giữ lại AAAA cũ có thể gửi một số khách truy cập tới server sai trong khi người khác tới IPv4 đúng.
Cẩn thận với các bản ghi "just in case". Nhiều A record có thể hoạt như load balancing vô tình nếu một mục tiêu sai, đặc biệt khi trỏ domain tùy chỉnh tới app hosting.
Một quy tắc cuối cùng: ngừng đặt lại đồng hồ.
Những thay đổi nhỏ, bình tĩnh tốt hơn việc tinh chỉnh không ngừng.
Bạn ra mắt app mới và cấu hình cả example.com và www.example.com. Vài phút sau, www.example.com tải tốt, nhưng root domain báo lỗi DNS, tải site cũ, hoặc HTTPS vẫn đang chờ. Mô hình này phổ biến và thường có nguyên nhân nhỏ.
Bắt đầu với câu hỏi tẻ nhạt: bạn có đang chỉnh DNS ở chỗ đúng không? Nếu domain đăng ký ở công ty A nhưng DNS host ở công ty B, bạn có thể thay đổi bản ghi suốt ngày mà không có gì thay đổi. Kiểm tra nameserver trước, rồi mở bảng DNS ở nhà cung cấp mà nameserver đó trỏ tới.
Tiếp theo, so sánh hai hostname. www thường là CNAME. Root domain khó xử hơn: nhiều nhà cung cấp không cho phép CNAME ở apex, nên thường cần A record tới IP, hoặc ALIAS/ANAME nếu được hỗ trợ.
Một lộ trình quyết định thực tế:
example.com không có bản ghi (hoặc trỏ chỗ khác)? Sửa bản ghi apex.Trạng thái cuối cùng đúng là tẻ nhạt: cả example.com và www.example.com đều dẫn tới cùng app, một cái là chuẩn (cái kia redirect), và HTTPS hợp lệ.
Khi thiết lập domain lỗi, phần lớn sửa nằm ở vài kiểm tra nhanh. Chạy những bước này trước khi thay đổi gì khác.
Sau khi DNS rõ ràng đúng, rồi kiểm tra SSL. Nhiều nền tảng chỉ cấp chứng chỉ sau khi có thể phân giải domain tới mục tiêu đúng liên tục. Nếu kiểm tra quá sớm, bạn có thể nhầm một độ trễ bình thường với lỗi thật.
Nếu bạn thêm domain tùy chỉnh vào app triển khai trên Koder.ai, coi màn hình thiết lập domain là tham chiếu cho mục tiêu DNS mong đợi, rồi kiểm tra trạng thái sau khi DNS có thời gian propagation.
Cách nhanh nhất để tránh lặp lại lỗi DNS và SSL là giữ một "ghi chú thiết lập tên miền" ngắn cho mỗi dự án. Đó là runbook tái sử dụng bạn có thể sao chép lần sau khi ra mắt.
Giữ nó trong tài liệu dự án và điền trước khi động tay vào DNS:
Trong lúc ra mắt, giao một người làm chủ DNS. DNS thường hỏng khi hai người cùng "sửa" những thứ khác nhau cùng lúc (ví dụ, một người đổi nameserver trong khi người kia chỉnh bản ghi).
Ở phía hosting, lên kế hoạch cho khôi phục an toàn. Nếu nền tảng hỗ trợ snapshot hoặc rollback, chụp snapshot trước khi thay đổi routing để có thể quay lại trạng thái tốt gần nhất nhanh chóng. Nếu bạn xây trên Koder.ai, dùng Planning Mode để viết các bước domain bạn sẽ làm, áp dụng theo thứ tự, và rollback nếu thay đổi làm hỏng production.
Nếu bạn đã xác nhận DNS đúng mà vẫn thấy lỗi, ngừng đoán và eskalate kèm bằng chứng:
Khi eskalate, gửi hostname, bản ghi mong đợi, kết quả resolver hiện tại, và dấu thời gian. Điều đó biến trao đổi chậm thành sửa nhanh.
Thông thường nghĩa là một lớp trong chuỗi bị sai: DNS không phân giải, DNS phân giải tới mục tiêu sai, máy chủ/hosting không nhận diện hostname của bạn, hoặc HTTPS/SSL chưa được cấp xong. Bắt đầu bằng cách ghi lại chính xác lỗi bạn thấy và hostname bạn đã gõ (apex hay www).
example.com (apex) và www.example.com là hai hostname riêng biệt với các bản ghi DNS riêng. Thường gặp là www có CNAME đúng trong khi apex không có A record, có A record sai, hoặc DNS provider không hỗ trợ cấu hình bạn đang cố gắng dùng.
Kiểm tra nameserver của domain tại nơi đăng ký và so sánh với nhà cung cấp DNS bạn đang chỉnh. Chỉ nhà cung cấp được liệt kê trong nameserver hoạt động là có quyền quyết định; chỉnh bản ghi ở chỗ khác sẽ không ảnh hưởng tới internet công cộng.
Dùng A khi host cung cấp địa chỉ IPv4, AAAA chỉ khi host cung cấp mục tiêu IPv6, CNAME khi host yêu cầu trỏ tới một hostname khác (thường dùng cho www). TXT là cho xác minh và thử thách và phải tạo trên tên chính xác mà host yêu cầu.
Một bản ghi AAAA lỗi thời hoặc sai có thể dẫn một số khách truy cập tới server cũ qua IPv6 trong khi người khác tới đúng server qua IPv4, gây cảm giác "ai cũng thấy khác nhau". Nếu host không cung cấp mục tiêu IPv6, xóa AAAA sai thường là cách sửa đơn giản.
Thường là bạn chỉ cấu hình một hostname ở phía hosting (chỉ apex hoặc chỉ www), hoặc có các quy tắc redirect mâu thuẫn khiến bounce giữa HTTP và HTTPS hoặc giữa apex và www. Chọn một hostname chuẩn, cấu hình cả hai hostname, và đảm bảo chỉ có một đường redirect rõ ràng.
Có. Chờ là hành động đúng khi DNS đã rõ ràng trỏ tới mục tiêu đúng từ nhiều nơi. Việc cấp SSL thường chỉ hoàn tất khi domain phân giải nhất quán tới đích mong muốn; thay đổi DNS liên tục sẽ liên tục thiết lập lại quá trình này.
TTL là thời gian resolver lưu trữ câu trả lời, nên ngay cả khi bạn sửa bản ghi, một số mạng vẫn phục vụ giá trị cũ đến khi TTL hết hạn. Thử từ hai mạng khác nhau (ví dụ Wi‑Fi và dữ liệu di động) và tránh thay đổi DNS mỗi vài phút để quan sát propagation rõ ràng.
Dùng dig hoặc nslookup để xác nhận câu trả lời A/AAAA/CNAME/TXT khớp mục tiêu mong đợi, sau đó thử cả http:// và https:// cho cả apex và www. Nếu một mạng trả về câu trả lời DNS khác với mạng kia, đó thường là caching; nếu tất cả mạng trả về kết quả sai, đó là cấu hình sai.
Trên Koder.ai, hãy coi màn hình thiết lập domain của app là nguồn dữ liệu cho mục tiêu DNS mong đợi, rồi làm cho DNS khớp chính xác ở nhà cung cấp DNS có thẩm quyền. Sau khi đổi DNS, chờ cho ổn định trước khi kiểm tra SSL, và dùng snapshot/rollback nếu bạn điều chỉnh routing trên dự án đang chạy để có thể quay lại trạng thái tốt gần nhất nếu cần.