把自有域名指向 Convex 应用（DNS 记录 +…

当你已经拥有一个域名，想把它指向自己的 Convex 应用，并需要处理 DNS 记录、自定义域名挂载与登录来源重绑定时使用。

适用场景

解决思路

1. 确定目标：已发布的站点主机（`*.convex.app` 静态托管）或该部署的 HTTP actions URL。
2. 检测用户 DNS 服务商是否有已认证的 DNS CLI，并主动提出可自动创建记录：Cloudflare → `flarectl dns create`（注意 `wrangler` 本身不管理 DNS 记录）或通过其 token 环境变量调用 CF API；Route53 → `aws route53 change-resource-record-sets`；Google Cloud DNS → `gcloud dns record-sets create`；DigitalOcean → `doctl compute domain records create`；Vercel DNS → `vercel dns add`。
3. 先做只读的认证检查（`flarectl user info` / `aws sts get-caller-identity` / `doctl account get`），展示确切命令并在用户确认后再执行。
4. 如果没有已认证的 CLI（或用户拒绝），明确告诉用户需要在其自己的注册商处创建哪些记录：CNAME（或在 apex 使用 A/ALIAS）加上 TXT 验证记录，并给出具体的 host/value 字符串，不要用占位符。
5. 把该域名作为 Convex 自定义域名挂载（dashboard 或 CLI），然后等待验证；注意 DNS 传播可能需要几分钟到几小时。用 `dig +short` 验证记录是否已生效。
6. 如果应用使用了 auth（passkeys/OAuth），把 auth origin 重新绑定到新域名（`SITE_URL` / `RP_ID` / `ORIGIN` 环境变量），并重新部署/重新发布。
7. 最终验证：域名能通过 HTTPS 正常提供应用，且包含已配置的 apex → www 重定向。
8. 绝不索取或处理注册商凭据：使用用户机器上已认证的 CLI 是可以的（凭据留在工具内）；不要为此安装 CLI 或运行其登录/认证流程，也不要回显 token。
9. 线上域名的 DNS 变更对用户可见：执行前展示确切命令并确认，执行后用 `dig` 验证。
10. 始终包含 TXT 验证记录，而不只是 CNAME。
11. 重新绑定域名会改变 auth origin，之后必须重新发布，否则登录会失效。

适用边界 · 注意事项

• 域名不在用户自己控制的注册商/DNS 服务商下（例如只能用平台分配的子域名）时，本流程不适用。
• 需要代为安装或登录 DNS CLI、或要求用户交出注册商凭据的场景不适用——这类操作被明确禁止。
• 应用不需要自定义域名、继续使用默认 `*.convex.app` 域名时无需执行。