了解認證自訂網域及多網域如何提升轉換率、安全性與品牌形象；以及 Logto 如何讓你輕鬆管理它們，無需為 DNS 操心。
如果你曾因為趕著推出產品而略過了一些細節，這個故事你一定感同身受。
你的應用程式安穩地掛在 example.com 下。行銷團隊開跑推廣，使用者註冊帳號，一切看起來都很完美。然後有新用戶點了 登入。
結果瀏覽器沒有導向大家熟悉的網址，例如 auth.example.com ，而是跳去了看起來像測試環境的 my-tenant-123.app.logto
技術上沒問題，網頁依然安全，登入也正常運作。 但用戶第一反應會是：
「等下，我現在去哪了？」
這一秒鐘的疑惑，決定了流失率。
這也是為什麼幾乎每間大公司都會這樣設計：
login.company.comauth.company.comaccounts.company.com他們可不是跟風，這是因為登入網域就是產品體驗的一部份。
這篇文章會跟你聊：
簡單說明一下。
每個 Logto tenant 都會配一個預設網域：{{tenant-id}}.app.logto。所以原本用戶進入的是這種網址：https://my-tenant-123.app.logto/sign-in。
設定認證自訂網域，就是把明顯可見的網址換成你自己的 —— 比方 auth.example.com。登錄頁就變成：https://auth.example.com/sign-in，保持全程在你品牌形象下。
底層還是同一組認證服務，外觀與第一印象完全不同。
在 Logto 裡，自訂網域設計就是要用 子網域，像這樣：
auth.example.comauth.us.example.com實務上，這樣設定認證才是正常需求：
example.com）。domains.logto.app 才能正確流量導向。A、MX、TXT 等記錄），這對 SaaS 這種多租戶方案來說根本不可行。頂層平坦（Apex-flattening，像 ALIAS/ANAME）雖然可以指到我們外部的 IP，但還是不能用來自動管理證書。簡單說，託管登入頁一定要掛在子網域下。你只要用 CNAME 把該子網域指去 Logto，剩下的驗證、SSL、服務可用率全部我們幫你搞定 —— 你的主網域能繼續服務其他用途。
一個很常見的誤會：
「我只要加個 CNAME 就完成了，對吧？」
其實沒那麼單純。
你能看到的登入網域，僅僅是故事的開頭。一旦導入自訂認證網域，你馬上會影響到：
登入及註冊頁網址
用戶現在造訪的是 https://auth.example.com/... 這些託管頁面。
OIDC / OAuth redirect URIs
你的 App 及所有連接器，都必須用這個自訂網域當作 redirect/callback URL，不然就會遇到 redirect_uri_mismatch 這類錯誤。
社群登入及企業 SSO（IdPs）
Google、GitHub、Azure AD、Okta 等等，都會嚴格檢查 redirect URI 或 ACS URL，各種網域要完全吻合。
Passkey（WebAuthn） Passkey（通行密鑰）嚴格綁定註冊時的網域。網域換了，先前的 passkey 就不能用了。
SDK 配置
你的 Logto SDK 端點要正確指向 tenant 網域。如果用到錯網域，應用與身份層就有可能不同步。
所以 DNS 當然是有涉及， 但只停留在「加了 CNAME 就完成」的思維，九成機會會搞壞其他功能。
想像一個流程圖，使用者瀏覽器從這裡開始：
瀏覽器網址列
https://example.com 按下 登入。https://auth.example.com/sign-in。認證伺服器與 Discovery 文件
https://auth.example.com/oidc/.well-known/openid-configurationRedirect URI（OIDC/OAuth 回呼）
https://app.example.com/callback社群登入 / 企業 SSO 跳轉
auth.example.com 跳去 Google、Microsoft Entra ID、Okta 等。郵件及魔術連結 / 密碼重設連結
這幾步驟，每一環「網域」都很關鍵。導入自訂登入網域時，你想讓它貫穿全流程且保持一致。
所以一套成熟的網域策略，重點不是玩 DNS 技巧，而是要有一套一致的身分識別設計架構。
對多數團隊來說，一個像 auth.example.com 這種通用網域完全沒問題。但隨著產品規模、地區、客群成長，如果沒預先設計「多網域」彈性很快就會撞牆。
下面是不同團隊常見的身分驗證網域對應方式：
| 情境 | 範例網域 | 幫助說明 |
|---|---|---|
| 品牌統一登入 | auth.example.com、account.example.com | 用戶看到的網址始終品牌一致，預設 {{tenant-id}}.app.logto 網域保留給內部測試。 |
| 各地區專屬體驗 | auth.us.example.com、auth.eu.example.com、auth.apac.example.com | 一個 tenant 裡可依地區區分本地化內容、合規條款及同意流程。 |
| 環境隔離 | auth.staging.example.com、auth.example.com | 測試或預覽流量可明確隔絕，無須複製 tenant 或連接器。 |
| 客製化企業品牌入口 | auth.customer-a.com、auth.customer-b.com | 大客戶可以專屬登入，仍集中控管所有用戶、組織、SSO，不需後台分割。 |
| 產品品牌 / 產品線 | auth.shop.example.com、auth.app.example.com、auth.studio.example.com | 各子品牌各自有一致登入體驗，身份架構不分散。 |
| 多 TLD（國碼等） | auth.foo.com、auth.foo.co.uk、auth.foo.dev | 各國版或特殊用途網域一併支援，設定一次無須層層複製。 |
| 基礎設施導向 | auth.edge.example.com、auth.api.example.com | 可配合 CDN/Edge 路由，有多登入入口，Logto 還是一條身分主線作 backend。 |
Logto out-of-the-box 給你的，讓你免當 DNS 或 PKI 專家：
auth.example.com 也不會移除 {{tenant-id}}.app.logto，預設網域還能做內部測試或灰度發佈，正式用戶走品牌專屬網址。endpoint，社群／SSO 連接器則自動配置每個有效的 redirect URI、ACS URL，無須人工拚網址。看到這裡，大概只剩這兩種狀況：
你隨時可以直接嘗試多個自訂網域：
endpoint 設定。這是優化用戶體驗、觀察信任度及轉換影響的最快方式。
如果你現在正打算剛起步：
auth.example.com 設成對外的登入主網域。{{tenant-id}}.app.logto 網域，可以做內部測試或開發用途。這樣完全不會有「這網址好像 staging」的突兀體驗，等你成長更快的時候也不用費心解 domain 遷移。
需要全套設定教學，包括 DNS 紀錄、排除障礙、一步步操作？ 請看我們文件的詳細指南：自訂網域（Logto Cloud）