用 DNS 将域名连接到服务器

IP 地址还是主机名——对应不同的记录

打开 DNS 管理面板之前，先确认你的目标地址长什么样：

• IPv4 地址，如 198.51.100.42——VPS 常见（DigitalOcean Droplet、Hetzner 服务器等）。使用 A 记录。
• IPv6 地址，如 2001:db8::1——越来越普遍，部分主机仅支持 IPv6。使用 AAAA 记录。
• 主机名，如 my-app.vercel.app——PaaS 平台给你的地址。使用 CNAME 记录。

规则很简单：数字地址用 A（或 AAAA）；名称用 CNAME。混淆两者是排行第一的配置错误。

"顶点"域名——没有子域名的 mybrand.com

在你的 DNS 提供商（注册商面板，或你委托 DNS 管理的地方）：

• 指向 IP：添加一条 A 记录。名称填 @（或留空，代表根域名），值填服务器 IP，TTL 填 3600（一小时）即可。
• 指向主机名：从技术上讲，传统 DNS 不允许在顶点域名设置 CNAME。但现代提供商（Cloudflare、Route 53）用"CNAME 扁平化"或"ALIAS 记录"绕过了这个限制。使用你的主机所叫的名称——在 Cloudflare，直接在 @ 添加 CNAME 就能用。

这条记录让输入 mybrand.com 能访问到你的网站。

大多数网站希望 mybrand.com 和 www.mybrand.com 都能访问

为 www 添加一条记录：

• 如果根域名是 A 记录：添加一条 CNAME，名称填 www，值填 mybrand.com。这样 www 会跟随根域名。
• 如果根域名是 CNAME / ALIAS：再添加一条 CNAME，名称填 www，目标与根域名相同。
• 或者：把根域名和 www 都直接指向同一个目的地。两种方式都行；通过 CNAME 间接跳转的好处是，目的地变化时只需更新一条记录。

选定一种规范形式（"我们希望所有人访问 mybrand.com"），然后让主机把另一个重定向过去。Magic Deploy 和大多数现代主机会自动处理这一步。

记录的"生存时间"

TTL 是以秒为单位的时长，决定全球各地的 DNS 服务器在重新查询之前可以缓存你的记录多久。默认值（通常是 3600，即一小时）对稳定运行的域名来说够用了。两条实用规则：

• 改动前降低 TTL。计划更新记录前一两天，把 TTL 降到 300（五分钟）。这样实际切换时，全球缓存持有旧值的时间会大大缩短。
• 稳定后提高 TTL。新记录生效一天后，把 TTL 提回 3600 或更高。TTL 越低，DNS 查询越频繁——没什么大问题，但也不是没有代价。

对于无关紧要的域名，保持默认值，不用费心思。

不是魔法；是缓存过期

你发布一条新 DNS 记录后，权威服务器（你的注册商 / DNS 提供商）会立即持有它。但全球的每一台 DNS 解析器——你的 ISP 解析器、公共解析器（如 8.8.8.8 和 1.1.1.1）、你笔记本上的本地缓存——都在持有某个带 TTL 的缓存答案。在 TTL 过期之前，这些解析器会愉快地返回缓存中（往往是旧的）答案，而不会重新查询。

"传播"就是等待所有这些缓存过期的过程。实际上：

• 大多数解析器在几分钟内更新（前提是 TTL 设得较低）。
• 有些需要数小时，无论 TTL 设为多少（部分 ISP 解析器会无视 TTL，激进地缓存）。
• "最多 48 小时"是真实存在但属于罕见情况。如果 6 小时后还没传播完，很可能是配置错误，而不是传播太慢。

三条命令；一个真相

在怀疑应用有问题之前，先验证 DNS 本身：

# 1. What does your local resolver see right now?
dig mybrand.com +short
# Expected: your IP. If empty or wrong, the record isn't published or hasn't propagated.

# 2. What does a different resolver see?
dig @1.1.1.1 mybrand.com +short
# Asks Cloudflare's public resolver (1.1.1.1) instead of your local one.
# Different resolver = different cache state. If this agrees with #1,
# both resolvers updated. If it differs, your local cache is just stale —
# that's a wait, not a bug. For the truest view (no caches anywhere):
#     dig +trace mybrand.com
# walks from the root nameservers down, asking each fresh. Slowest, most honest.

# 3. Are you actually reaching the server?
curl -I https://mybrand.com
# Expected: an HTTP response. If you get connection refused or timeout,
# the IP is wrong, the server isn't listening, or the firewall is blocking.

判断逻辑：如果 #1 和 #2 结果不同，传播还在进行中——等一等。如果 #2 结果不对，是你 DNS 提供商那边的记录有误——修正记录。如果两者都对但 #3 失败，DNS 没有问题；问题出在服务器端。

DNS 负责路由流量；TLS 负责加密

DNS 配置好之后，http://mybrand.com 就能访问到你的服务器了。但 https://mybrand.com 还不行，需要先配置 TLS 证书。这是单独的一步，通常由以下方式处理：

• 你的主机（Vercel、Netlify、Cloudflare Pages）——自动完成。在其管理面板添加域名，它们会自动签发证书。Magic Deploy 可以从聊天面板驱动这个流程。
• Cloudflare 代理——如果你的 DNS 在 Cloudflare，并开启了橙色云朵图标，则自动完成。
• Let's Encrypt + certbot，在你自己的服务器上——大多数环境只需一条命令：sudo certbot --nginx -d mybrand.com -d www.mybrand.com --redirect。--redirect 参数会在 nginx 配置中将 HTTP 重写为 HTTPS；certbot 还会安装一个定时任务，每 90 天自动续期。

公开站点绝对不要在没有 HTTPS 的情况下运行。现代浏览器会大声警告；所有人都把它当作标配；而成本为零。TLS 证书是 DNS 之后的第二层，两者合在一起才能让网站安全地被访问到。

A 和 CNAME 覆盖 95%；其余的在需要时才重要

以下这些记录对于纯粹托管网站来说不是必须的，但你迟早会碰到：

• AAAA 记录——A 记录的 IPv6 版本。如果主机同时给了你 IPv4 和 IPv6 地址，两条都发布：IPv6 专属网络的访客（部分移动运营商、部分企业网络）只能解析 AAAA，IPv4 访客只能解析 A。双栈更具弹性，而且免费。
• MX 记录——决定你域名的邮件发往哪里。如果你希望 [email protected] 真的能收到邮件，需要把 MX 记录指向你的邮件主机（Fastmail、Google Workspace、Proton 等）。主机会给你具体的值——名称、优先级、目标——你直接粘贴进去。MX 与 A/CNAME 相互独立，在某个域名上能收邮件并不影响网站的位置。
• TXT 记录——任意文本。两个真实用途：SPF / DKIM / DMARC（为你的邮件防伪造；邮件主机生成值，你粘贴进去），以及域名验证（"粘贴这段 TXT 来证明你拥有该域名"——Vercel、Search Console、Stripe，以及任何要签发 TLS 或确认你控制某域名的主机都会用这种方式）。

经验法则：A/AAAA/CNAME 路由流量；MX 路由邮件；TXT 证明所有权。知道某个问题属于哪种记录类型，就是解决了一半的排查工作。