什么是认证自定义域名，以及为什么多个域名很重要

如果你曾经把产品上线得有点太快，这个故事对你来说一定很熟悉。

你的应用运行在 example.com 上一切顺利。市场推广正在开展活动，用户不断注册，看上去一切都很专业。然后有个新用户点击了 登录。

浏览器没有跳转到熟悉的 auth.example.com，而是跳到了类似测试环境的地址：my-tenant-123.app.logto

技术上来说，一切都没问题。页面是安全的，登录也正常。 但用户的第一反应是：

“等下，我刚才跳到哪里去了？”

这一瞬间的疑惑，正是用户流失发生的地方。

• 转化率 方面，登录和注册是你转化漏斗中最窄的部分。任何“这是什么域名？”的时刻都会增加摩擦。
• 安全性 方面，多年来用户们已经习惯 “检查网址”。如果登录域名和你的品牌不匹配，看起来就更像是在钓鱼，而不像是正式产品。

几乎每家大公司都在用类似以下的域名是有原因的：

• login.company.com
• auth.company.com
• accounts.company.com

他们不是为了好玩才这么做，而是因为登录域名本身就是产品体验的一部分。

在这篇文章里，我们会讨论：

• 认证自定义域名 到底是什么
• 什么时候一个登录域名足够用了，以及你何时应该考虑多个域名
• 登录域名最常见的坑（以及怎么避免“重定向 URI 不匹配”的地狱）
• Logto 的自定义域名支持如何帮你搞定上述一切，不用变成 DNS 工程师

什么是认证自定义域名？#

让我们说得简单点。

每个 Logto 租户都有一个默认域名：{{tenant-id}}.app.logto。所以以往登录会把用户带到：https://my-tenant-123.app.logto/sign-in。

认证自定义域名就是把这个可见的 URL 替换成你自己的，比如 auth.example.com。这样用户就始终停留在你的品牌下，比如：https://auth.example.com/sign-in。

底层还是同样的认证服务，但第一印象完全不同。

为什么用子域名，而不是根域名？#

在 Logto 里，自定义域名专为 子域名 设计，比如：

• auth.example.com
• auth.us.example.com

实际上这也是认证场景下你最想要的：

• 根域名通常用于你的网站主页（example.com）。
• DNS “区域顶点”不能用 CNAME，而且 Logto 托管的登录要求需要一个 CNAME 指向 domains.logto.app 才能进行流量路由。
• Logto 通过 Cloudflare 管理证书。如果要在根域名上终止 TLS，我们得控制整个域区（包括你的 A、MX、TXT 等记录），显然这对多租户 SaaS 来说不现实。

Apex-flattening 记录（ALIAS/ANAME）依然解析到不属于我们的 IP，所以也无法用于我们的托管证书。简单说，托管登录只能放在子域名下。只要用 CNAME 把这个子域名指向 Logto，我们会帮你处理验证、SSL 和可用性，你的主域名就能继续服务站点其他部分。

为什么不是“加个 CNAME 就完了”？#

很常见的误区：

“我加个 CNAME 到 DNS 不就搞定了吗？”

可惜没这么简单。

改变可见的登录域名只是第一步。你一旦引入了自定义认证域名，就会涉及：

• 登录和注册页面 URL
  用户现在会访问 https://auth.example.com/... 这些托管页面。

• OIDC / OAuth 重定向 URI
  你的应用和连接器必须使用同样的域名做重定向/回调，否则就会遇到 redirect_uri_mismatch 的报错。

• 社交登录 & 企业 SSO（身份提供商）
  Google、GitHub、Azure AD、Okta 等都会校验重定向 URI 或 ACS URL，还有里面的域名。

• Passkey（WebAuthn）
  Passkey 与注册时所在的域名严格绑定。域名换了，之前的 passkey 就不能用了。

• SDK 配置
  你的 Logto SDK 配置了一个 endpoint 指向租户域名。如果 endpoint 用错了域名，你的应用和身份层就失去了同步。

所以，是不是还是有 DNS 需要？当然有。 但如果你只想着“我加了 CNAME 就完事了”，基本一定会出别的问题。

一个快速的思维模型：登录域名如何贯穿技术栈#

想象这样一张图，用户浏览器的流程是：

1. 浏览器地址栏

   • 用户在 https://example.com 点击 登录。
   • 然后被重定向到 https://auth.example.com/sign-in。

2. 授权服务器 & 发现文档

   • 你的应用使用 OpenID 配置端点： https://auth.example.com/oidc/.well-known/openid-configuration
   • 这告诉你的应用应该把认证请求和期望获取 Token 的地址。

3. 重定向 URI（OIDC/OAuth 回调）

   • 用户登录后，Logto 会跳转回你的应用，比如： https://app.example.com/callback
   • 身份提供商和你的应用双方都要约定好这些 URL。

4. 社交登录 / 企业 SSO 跳转

   • 从 auth.example.com，用户可能会跳到 Google、Microsoft Entra ID、Okta 等。
   • 这些第三方也会校验带有自定义认证域名的重定向 URI。

5. 邮件及魔法链接 / 重置密码链接

   • 邮件里的链接也应该统一指向你的自定义域名，否则用户会疑惑。

以上每一环节，域名都极其重要。你引入了自定义登录域名后，务必要在整个流程链路上保持一致。

因此，一个清晰统一的自定义域名策略其实重点不是 DNS 技巧，而是完善的身份体系设计。

单个自定义域名和多个自定义域名#

对很多团队来说，像 auth.example.com 这样单一的自定义域名足够用了。但随着你的产品、地区和客户群扩展，如果没有提前规划很快就会遇到局限。

各类型团队通常会这样映射域名和认证体验：

Logto 如何让自定义域名变简单#

Logto 让你不用成为 DNS 或证书专家，就能立刻获得以下能力：

• 一个租户，多域名支持。 按区域、环境、客户或品牌分配独立登录域名，无需复制租户。根据套餐有上限，但核心承诺是：一个身份体系，多入口。
• 默认域名一直可用。 新增 auth.example.com 后，原来的 {{tenant-id}}.app.logto 不会失效。可以把默认域名用于内测或灰度，正式用户用品牌域名。
• 连接器自动适配。 SDK 会自动指向正确的 endpoint，而社交和企业 SSO 连接器会自动列出每个域名下所有合法的重定向 URI 或 ACS URL，无需手动复制 URL。
• SSL 全自动托管。 加好 CNAME 后，Logto 会自动完成 DNS 验证、证书签发和续期。无需自己管理私钥，也不会有证书意外过期。

下一步怎么做#

如果你看到这里，大概率属于下面两类：

已在用 Logto？#

你现在就能体验多自定义域名：

• 前往 控制台 > 设置 > 域名。为即将上线的新地区或某个企业客户添加一个自定义登录域名。
• 在代码中合适的位置更新 SDK 的 endpoint。
• 在社交登录或 SSO 连接器里，添加 Logto 提供的针对新域名的重定向 URI 和 ACS URL 到你的身份提供方系统里。

这样很容易优化你的登录体验，测试用户信任和转化的提升。

新上手 Logto？#

如果你是刚开始用：

• 注册 Logto 并新建租户。
• 去 控制台 > 设置 > 域名，用免费额度设置 auth.example.com 作为你的公开登录入口域名。
• 默认的 {{tenant-id}}.app.logto 域名可保留做内部测试或开发。

这样一开始就能绕过“这个登录地址像测试环境”的问题，等业务做大时也不用再头痛域名迁移。

想要步骤详尽的配置、DNS 记录说明及排查帮助？ 详见我们文档里的完整指引：自定义域名 ，适用于 Logto Cloud。