Hướng dẫn thiết lập tên miền tùy chỉnh cho web app: các bước DNS rõ ràng, cấp SSL, quy tắc redirect và kế hoạch cutover rủi ro thấp để tránh downtime và lỗi cookie.
Tên miền tùy chỉnh không chỉ là một URL đẹp hơn. Ngay khi bạn chuyển từ địa chỉ nền tảng (ví dụ, một app bạn dựng trên Koder.ai dưới subdomain của nền tảng) sang tên miền của riêng bạn, trình duyệt và mạng sẽ coi đó là một trang khác. Điều này ảnh hưởng đến định tuyến, bảo mật và cách phiên người dùng hoạt động.
Sau khi chuyển sang tên miền tùy chỉnh, vài thứ thay đổi ngay lập tức:
www hay tên miền gốc (apex), và cần quy tắc HTTP→HTTPS nhất quán.old-platform.example sẽ không tự nhiên hoạt động trên app.yourdomain.com.Các gián đoạn ngắn thường do thời điểm. DNS có thể bắt đầu gửi traffic đến host mới trước khi chứng chỉ SSL sẵn sàng, dẫn đến cảnh báo trình duyệt. Hoặc ngược lại: SSL sẵn sàng nhưng nhiều người vẫn tới chỗ cũ vì cache DNS chưa hết hạn.
Redirects cũng có thể làm hỏng đăng nhập một cách tinh vi. Một redirect đổi hostname (từ apex sang www hoặc ngược lại) có thể làm mất cookie nếu cookie được đặt cho host khác. Nhà cung cấp auth có thể lỗi nếu callback URL vẫn là domain cũ.
Một cutover rủi ro thấp nghĩa là bạn lên kế hoạch cho thời gian chồng lấp: giữ URL cũ hoạt động, triển khai domain mới song song, chuyển traffic tại thời điểm đã định và làm cho rollback đơn giản như việc đổi DNS trở lại.
Trước khi thay đổi gì, ghi rõ chính xác tên bạn muốn người dùng gõ vào và tên nào chỉ redirect âm thầm. Hầu hết tình huống “tại sao chỉ hoạt động nửa vời?” bắt nguồn từ việc đội ngũ không đồng ý về hostname chính.
Bắt đầu với lựa chọn lớn: apex (example.com) hay www (www.example.com) làm chính. Cả hai đều được, nhưng chọn một và xử lý cái còn lại như redirect. Điều này quan trọng cho cookie: session thường dễ quản lý hơn khi app sống trên một host nhất quán.
Tiếp theo, quyết định subdomain bạn cần ngay và cái nào để sau. Mô hình phổ biến là app.example.com cho web app và api.example.com cho API, thêm admin.example.com hoặc assets.example.com sau này. Nếu bạn đang cấu hình domain tùy chỉnh trên nền tảng như Koder.ai, những lựa chọn này phản ánh trực tiếp hostname bạn sẽ xác nhận cho SSL và những gì bạn sẽ trỏ trong DNS.
Nhiều người mua domain tại registrar, nhưng DNS có thể được host ở nơi khác. Xác nhận hiện tại nơi chỉnh record, ai có quyền truy cập, và có tự động hóa nào quản lý thay đổi không (IT công ty, agency, hoặc nhà cung cấp DNS quản lý). Nếu bạn không thể đăng nhập để xem record hiện tại, dừng lại và sửa trước.
Cũng kiểm tra xem domain đang dùng cho những gì rồi. Email là bẫy kinh điển: bạn có thể làm hỏng gửi nhận mail nếu xóa hoặc ghi đè record.
Trước khi tiến, ghi lại các quyết định sau:
www) và hướng redirectNếu marketing đang chạy email trên example.com, giữ nguyên các record liên quan mail trong khi bạn chỉ thêm những gì app cần.
Phần lớn rủi ro khi chuyển domain không phải từ app, mà là một thay đổi DNS sai gửi traffic tới chỗ không có gì, làm hỏng email, hoặc khiến xác thực SSL thất bại.
Một A record trỏ một tên tới địa chỉ IP. Nói gọn: “gửi người dùng tới server này.” Thường dùng cho apex (example.com) khi nhà cung cấp cho IP cố định.
Một CNAME record trỏ một tên tới một tên khác. Nói gọn: “xem tên này như bí danh của hostname kia.” Thường dùng cho www.example.com trỏ tới hostname nền tảng.
Nhiều nhà cung cấp DNS cũng hỗ trợ ALIAS/ANAME cho apex. Nó hoạt động như CNAME nhưng cho example.com. Nếu DNS của bạn hỗ trợ, điều này dễ quản lý hơn vì target có thể thay đổi mà không cần bạn đụng IP.
Mô hình đơn giản trong đầu:
Bạn thường thêm TXT để kiểm tra quyền sở hữu domain (xác minh nền tảng) và cho xác thực chứng chỉ SSL (một số CA xác thực qua token TXT). TXT cũng dùng cho chính sách email như SPF. Xóa hoặc ghi đè SPF TXT hiện có có thể làm hỏng gửi mail.
TTL kiểm soát thời gian các hệ thống khác cache câu trả lời DNS. Một ngày trước cutover, hạ TTL trên các record bạn dự định thay đổi (thường 300–600 giây). Sau khi ổn định, tăng lại để giảm tải truy vấn.
Trước khi sửa, xuất hoặc chụp màn hình zone hiện tại. Ghi lại từng record bạn sẽ thay đổi, giá trị cũ, giá trị mới và TTL. Nếu có vấn đề, rollback là khôi phục các giá trị trước.
Điều này quan trọng khi domain đã có MX, DKIM, hoặc TXT cho email.
SSL (biểu tượng ổ khóa) mã hóa traffic giữa trình duyệt và app. Trình duyệt hiện đại và nhiều API mặc định mong HTTPS. Thiếu nó, bạn có thể gặp cảnh báo, yêu cầu bị chặn, và các tính năng như service worker, geolocation hay một số luồng thanh toán có thể ngưng.
Để cấp chứng chỉ, CA phải xác minh bạn kiểm soát domain. Phương pháp phổ biến là HTTP validation và DNS TXT validation:
Xác thực DNS thường dễ hơn khi bạn dùng CDN hoặc app chưa thể truy cập bằng domain mới.
Nơi chứng chỉ được cấp phụ thuộc vào cài đặt của bạn. Một số đội cấp cert trực tiếp trên hosting, một số tại CDN, và một số nền tảng hỗ trợ domain tùy chỉnh lo cho bạn (ví dụ, Koder.ai có thể quản lý chứng chỉ trong quá trình thiết lập domain). Quan trọng là biết ai quản lý vòng đời chứng chỉ, bao gồm renewals.
Cấp phát chứng chỉ không phải lúc nào cũng ngay lập tức. Lan truyền DNS, kiểm tra xác thực và giới hạn tần suất có thể làm chậm. Lên kế hoạch cho thử lại và tránh đặt cutover vào phút cuối.
Kế hoạch thời gian thực tế:
Chứng chỉ phải bao gồm mọi hostname người dùng sẽ truy cập. Kiểm tra SAN (Subject Alternative Names). Nếu app sẽ có mặt trên example.com và www.example.com, chứng chỉ phải chứa cả hai.
Wildcard (như *.example.com) giúp cho nhiều subdomain, nhưng không bao phủ apex (example.com).
Ví dụ cụ thể: nếu bạn chỉ cấp cert cho www.example.com, người dùng gõ example.com vẫn thấy cảnh báo trừ khi bạn redirect ở tầng đã có chứng chỉ hợp lệ cho example.com.
Redirect nghe có vẻ đơn giản, nhưng hầu hết vấn đề domain xuất hiện ở đây: vòng lặp, mixed content, và người dùng bị đăng xuất vì đã bounce giữa host.
Chọn một host chuẩn và kiên trì: www.example.com hoặc example.com (apex). Entry còn lại nên redirect tới host bạn chọn để cookie, session và SEO đồng nhất.
Mặc định an toàn:
http:// sang https:// cho mọi requestVới HTTP → HTTPS, tránh các quy tắc khiến người dùng bị bật lại. Cách dễ nhất để tránh loop là dựa vào yêu cầu thực sự. Nếu app của bạn nằm sau proxy hoặc CDN, cấu hình để nó tôn trọng forwarded headers (ví dụ header nói scheme gốc là HTTP). Nếu không, app có thể nghĩ mọi request là HTTP và tiếp tục redirect vô hạn.
Trong lúc di chuyển, giữ các path cũ còn sống. Nếu bạn đổi route (ví dụ /login thành /sign-in), thêm redirect cho các path đó. Đừng dựa vào redirect chung về trang chủ — nó phá bookmarks và link chia sẻ.
Tránh bật HSTS quá sớm. Nếu bạn bật và sau đó cần phục vụ HTTP để xác thực hoặc debug, trình duyệt có thể từ chối. Chờ đến khi HTTPS ổn định và bạn đã xác nhận phạm vi subdomain.
Để thử redirect mà không ảnh hưởng tới mọi người, dùng hostname thử tạm thời, thử vài deep link thật (kể cả trang auth), và chạy lệnh dòng lệnh để hiển thị từng bước redirect và đích cuối.
Cutover an toàn chủ yếu là thời điểm. Bạn muốn domain mới sẵn sàng và được kiểm tra trước khi người dùng thật bị gửi tới đó, và muốn thay đổi DNS lan nhanh để không bị mắc kẹt trong sự cố.
Hạ TTL DNS (cho các record bạn sẽ thay đổi) sớm. Làm điều này một ngày trước nếu được, rồi chờ hết cửa sổ TTL cũ để cache cập nhật.
Tiếp theo, thêm domain tùy chỉnh vào hosting/provider và hoàn tất xác minh họ yêu cầu. Nếu bạn dùng nền tảng như Koder.ai, thêm domain ở đó trước để nền tảng xác nhận quyền sở hữu và chuẩn bị định tuyến.
Cấp SSL sớm. Chứng chỉ có thể mất vài phút hoặc lâu hơn tùy xác thực, và bạn không muốn độ trễ đó trong lúc chuyển.
Trước khi công khai domain, làm test riêng: truy cập endpoint mới theo cách không phụ thuộc DNS công khai (ví dụ, chỉnh host tạm trên máy bạn) và xác nhận site tải qua HTTPS với chứng chỉ đúng.
Dùng cách tiến hành theo giai đoạn để dừng nhanh nếu có vấn đề:
www) trước khi chuyển user.Nếu bạn không thể làm canary thật ở mức DNS, vẫn có thể giai đoạn bằng cách chỉ chuyển một hostname trước (ví dụ www) và giữ apex cho tới khi tự tin.
Ghi rõ bạn sẽ revert gì (record nào, giá trị ra sao) và ai làm. Rollback thường là đưa DNS về trạng thái trước.
Đảm bảo cấu hình cũ vẫn hợp lệ (cả SSL trên domain cũ) để người dùng có thể fallback mượt trong khi bạn sửa đường đi mới.
Thay đổi domain không chỉ là thay DNS. Với nhiều app, “đã đăng nhập” phụ thuộc cookie mà trình duyệt gắn với hostname cụ thể. Nếu đổi hostname, trình duyệt có thể ngưng gửi cookie cũ và app sẽ thấy người dùng như đã đăng xuất.
Cài đặt cookie thường là nguyên nhân:
app.old.com sẽ không được gửi tới app.new.com. Cookie set cho .example.com có thể dùng chung giữa app.example.com và www.example.com./api), UI web có thể không nhìn thấy.Lax thường ổn, nhưng một số SSO hoặc redirect thanh toán có thể cần None kèm Secure.Để giảm rủi ro, lên kế hoạch chuyển ngắn nơi cả hai domain đều hoạt động. Giữ hostname cũ trả lời request và redirect thận trọng, nhưng cho phép session được làm mới trên domain mới. Nếu có thể, dùng shared session store để người dùng chạm vào hostname nào cũng được nhận diện.
Nếu bạn dùng SSO hoặc OAuth, cập nhật cài đặt trước khi cutover: callback URL, allowed origins và bất kỳ allowlist redirect URI nào. Nếu không, đăng nhập có thể thành công tại provider nhưng thất bại khi trả về app.
Test các luồng dễ hỏng: đăng ký (và xác thực email), login/logout, reset mật khẩu, checkout hoặc return từ thanh toán, và session đa tab.
Ví dụ: nếu bạn redirect www.example.com sang example.com, hãy chắc cookie đặt cho .example.com (hoặc dùng nhất quán một hostname). Nếu không, người dùng bounce giữa hostname và mất session.
Phần lớn vấn đề domain không phải “bí ẩn internet.” Là những sai lệch nhỏ giữa DNS, chứng chỉ và quy tắc redirect chỉ lộ ra khi người dùng thật truy cập.
Cái bẫy dễ gặp là apex (example.com). Nhiều DNS provider không cho phép CNAME thực sự ở apex. Nếu bạn cố ép CNAME ở apex, nó có thể fail im lặng, phân giải không nhất quán hoặc chỉ lỗi trên một số mạng. Dùng gì DNS host hỗ trợ (thường A/AAAA, hoặc ALIAS/ANAME).
Một nguyên nhân downtime phổ biến là thay DNS trước khi SSL sẵn sàng trên endpoint mới. Người dùng tới, app tải, rồi trình duyệt chặn vì chứng chỉ thiếu hoặc chỉ phủ một phần hostname. Thực tế, thường muốn chứng chỉ phủ cả example.com và www.example.com, ngay cả khi bạn định redirect một trong hai.
Những sai lầm thường gây outage hoặc hành vi lạ:
www → apex, rồi apex quay lại www), hoặc ép HTTP ở nơi này và HTTPS ở chỗ kháchttp:// cho tài nguyên, gây cảnh báo trình duyệt và lỗi tính năngMột kiểm tra nhanh: mở cả hai hostname (www và apex) qua HTTPS, đăng nhập, refresh và xác nhận thanh địa chỉ không bao giờ quay lại HTTP.
Nếu bạn làm việc trên nền tảng như Koder.ai, xác nhận custom domains được kết nối và SSL được cấp trước khi động DNS production, và giữ tùy chọn rollback để một redirect hay record xấu không tồn tại lâu.
Cutover bình tĩnh chủ yếu là công việc chuẩn bị. Mục tiêu đơn giản: người dùng tiếp tục đăng nhập, cookie vẫn hoạt động và bạn có thể rollback nhanh nếu thấy vấn đề.
Làm những việc này khi traffic vẫn tới domain cũ. Dành ít nhất một ngày nếu có thể để DNS ổn định.
www, api, v.v.) và chọn phương pháp xác thực SSL (DNS hay HTTP).www → apex (hoặc ngược lại), và một host canonical.Khi bạn flip DNS, coi giờ đầu như buổi tập xử lý sự cố. Theo dõi luồng người dùng thật chứ không chỉ dashboard trạng thái.
Ngay cả khi Koder.ai (hoặc nền tảng khác) lo custom domains và SSL cho bạn, checklist này vẫn quan trọng. Phần lớn vấn đề đến từ DNS và redirects, không phải code app.
App của bạn chạy trên địa chỉ tạm như myapp.koder.ai. Nó hoạt động, nhưng bạn muốn khách hàng dùng example.com, với www.example.com redirect về apex, và mọi thứ ép HTTPS.
Kế hoạch DNS đơn giản giúp giảm rủi ro. Trước khi thay đổi gì, lưu trạng thái hiện tại (chụp snapshot nếu nền tảng hỗ trợ, như Koder.ai) và hạ TTL DNS xuống ngắn một ngày trước.
Thêm record mới trong khi để URL nền tảng nguyên:
example.com: A/ALIAS trỏ tới target hosting nền tảng cung cấpwww.example.com: CNAME trỏ tới example.com (hoặc tới target nền tảng, tùy provider)myapp.koder.ai nguyên để luôn có fallback biết chắc hoạt độngKhi DNS đã sẵn, yêu cầu SSL cho cả hai hostname (example.com và www.example.com). Đừng chuyển traffic trước khi chứng chỉ được cấp và active, nếu không người dùng gặp cảnh báo.
Timeline cutover với checkpoints rõ ràng:
example.com ở cửa sổ ẩn danh (trang chủ, tài nguyên tĩnh, gọi API)www → apex)Sau khi di chuyển, kiểm tra hành vi cookie. Đăng nhập, refresh và kiểm tra vẫn ở trạng thái đăng nhập cả trên www và apex. Nếu session vỡ, thường là do domain cookie hoặc SameSite vẫn giả định host cũ.
Sau cutover thành công, công việc chưa xong. Hầu hết chuyển domain thất bại sau đó vì không ai để ý tới những thay đổi chậm: chứng chỉ sắp hết hạn, một thay đổi DNS vội vàng, hoặc tweak redirect làm hỏng luồng login.
Thiết lập một quy trình giám sát nhỏ mà bạn thực sự duy trì. Không cần công cụ enterprise, nhưng cần vài tín hiệu đáng tin cậy: check availability cho trang chính (home, login và một trang cần auth), cảnh báo hết hạn chứng chỉ (ví dụ 30 ngày và 7 ngày trước), theo dõi tỉ lệ lỗi (giám sát spike 4xx/5xx, không chỉ uptime), và kiểm tra redirect định kỳ (HTTP → HTTPS và hostname ưu tiên thắng).
Giữ cửa sổ rollback ngắn, ngay cả khi mọi thứ có vẻ ổn. Trong 24–72 giờ, giữ cấu hình trước sẵn sàng (old DNS targets, old hosting, old TLS) để revert nhanh khi phát sinh vấn đề ẩn như callback thanh toán hoặc provider OAuth vẫn trỏ về domain cũ.
Khi tự tin, tăng TTL DNS lên. TTL thấp hữu ích khi thay đổi, nhưng tăng tải cho resolver và làm hậu quả của sai sót nhỏ lớn hơn. Chọn TTL bình thường phù hợp tần suất thay đổi (nhiều đội chọn 1–4 giờ).
Cuối cùng, tài liệu trạng thái cuối cùng khi còn nhớ rõ: các record hiện có (type, name, value, TTL), hostname được hỗ trợ, và quy tắc redirect chính xác. Ghi nơi chứng chỉ được cấp, chúng bao phủ gì (apex, www, subdomains) và ai quản lý renewals.
Nếu bạn build và deploy trên nền tảng, hữu ích khi domain được đối xử như tính năng cấp cao và rollback đơn giản. Trên Koder.ai, custom domains đứng cạnh snapshots và rollback, giúp thay đổi domain và redirect bớt căng thẳng khi cần undo nhanh.
Default to one canonical hostname and redirect everything else to it.
example.com (apex) or www.example.com as the “real” one.This keeps cookies, sessions, and bookmarks consistent and prevents half-working behavior.
Lower TTL the day before you plan to switch, then wait long enough for the old TTL to age out.
Only lower TTL on the records you’re actually going to change.
For many app setups:
www.example.com or app.example.com when you’re pointing to a provider hostname.example.com.Don’t switch user traffic until HTTPS is valid on the new hostname(s).
A practical order:
This avoids browser warnings and blocked requests right at cutover.
Most email breakage happens when people delete or overwrite MX and TXT records.
Before changing anything:
Redirect chains and loops usually come from conflicting rules between your CDN/proxy and your app.
Use these safe defaults:
http:// → https://If you’re behind a proxy/CDN, make sure your app respects forwarded scheme headers; otherwise it may think every request is HTTP and keep redirecting forever.
Yes, it’s common if cookies were scoped to the old hostname.
What to check:
old-host won’t be sent to new-hostUpdate identity settings before cutover.
Typical items that must match the new domain exactly:
If these still point to the old domain, sign-in can succeed at the provider but fail when returning to your app.
A rollback is usually just restoring the previous DNS values.
Keep it simple:
If your platform supports snapshots/rollback (Koder.ai does), take one before cutover so you can quickly undo related configuration changes too.
Focus on real user paths, not just the homepage.
Test these on both the canonical host and the redirecting host:
Also verify the address bar ends on and always on , with no mixed-content warnings.
Avoid trying to force a CNAME at the apex if your DNS host doesn’t support an apex alias style record.
A quick safety step is exporting or screenshotting the current zone so you can restore it fast.
A low-risk approach is keeping the old hostname working during a transition so users can refresh sessions on the new domain.