DNS 与 SSL 问题的自定义域名故障排查清单

“自定义域名不可用”通常意味着什么

“自定义域名不可用”是一个笼统的说法，涵盖了几类不同的失败。浏览器显示的是症状，而不是原因。在改任何东西之前，先写清楚你实际看到的是什么。

典型症状包括：

• 显示“域名未找到”的页面
• 域名加载了错误的网站
• 即便启用了 HTTPS，仍显示“不安全”警告
• 重定向循环（在 http 和 https 之间，或在根域与 www 之间来回跳转）

大多数情况下，问题通常集中在一件事上：

• DNS 指向错误的位置，或缺少必要的记录
• 托管目标未为该主机名配置（服务器不识别你的域名）
• SSL 尚未签发、签发给了不同的主机名，或因为 DNS 不匹配而无法签发
• 缓存隐藏了你的更改（浏览器缓存、DNS 解析器缓存，或旧的 TTL）

在排查前，确保你能访问两个地方：编辑 DNS 记录的位置（域名注册商或 DNS 提供商）和在托管方绑定域名的设置界面。举例来说，如果你要把已部署的应用在 Koder.ai 上绑定自定义域名，你既需要对域名的 DNS 有编辑权限，又要能在应用的托管/部署设置里添加该域名。

有些修复是瞬时的（比如更正拼写错误）。有些则需要时间。DNS 更改可能需要一段时间才会生效，而 SSL 通常要等 DNS 正确且域名可访问后才会完成。目标是按顺序确认每层，而不是盲目猜测。

重要的 DNS 基本概念（无需术语）

大多数域名问题归结为三者不匹配：（1）你测试的主机名、（2）谁在管理 DNS、以及（3）记录实际指向何处。一旦这三者一致，SSL 通常就是最后一步。

域名有两种常见形式：根域（example.com，也叫 apex）和子域（www.example.com、app.example.com）。它们相关但可以有不同的 DNS 记录。因此出现 www 可用而根域不可用，或相反，是很常见的。

Nameservers（域名服务器）决定谁负责你的 DNS 区域。如果你在一家注册商购买域名，但 nameservers 指向另一家，你必须在 nameservers 指向的地方编辑 DNS。很多“我已经更新了但没有变化”的情况，都是因为在错误的控制面板里修改了记录。

以通俗方式理解常见的 DNS 记录类型

下面是主要记录类型在做什么：

• A：将一个名称指向一个 IPv4 地址（例如 203.0.113.10）
• AAAA：将一个名称指向一个 IPv6 地址
• CNAME：将一个名称指向另一个主机名（常用于 www）
• TXT：存储用于验证和安全的文本（所有权校验、SPF 等）

TTL 是“缓存多长时间”的计时器。TTL 越低，缓存刷新越快；TTL 越高，即使你修正了记录也可能需要更长时间才能看到变化，暂时仍看到旧值是正常现象。

分步决策树：定位问题的简单流程

当自定义域名出现故障时，通常可将问题分为四类：DNS 无法解析、DNS 解析到错误位置、SSL 未准备好，或因为缓存导致只有部分用户受影响。

按下列决策树操作：

1. 域名能解析吗？ 如果你看到 NXDOMAIN（或“域名未找到”），说明记录缺失、你在错误的 DNS 区域编辑，或 nameservers 并非你所想。
2. 如果能解析，是否指向正确目标？ 如果页面能加载但内容是错误站点、停放页或旧服务器，说明 A/AAAA/CNAME 目标错误或有遗留记录在优先级上覆盖了正确记录。
3. 如果指向正确，但仅 HTTPS 失败？ 如果 HTTP 能正常但 HTTPS 报证书警告，说明 SSL 可能还在签发中、证书主机名不匹配，或平台在等待 DNS 稳定。
4. 是否在某些设备或网络上可用而在另一些上不可用？ 视为缓存或传播问题。
5. 重定向是否出问题（www 与 apex）？ 如果 www 可用但根域不可（或反之），很可能只配置了一个主机名，或存在冲突的重定向规则。

记录下失败的确切主机名（apex 还是 www）和确切错误信息，可以加速判断。在自动化域名和证书的平台上，“找不到主机”与“证书待签发”的区别会直接告诉你是修 DNS 还是等 SSL。

第 1 步：确认主机名与期望目标

很多域名故障起因于简单的不匹配：你为一个主机名设置了 DNS，但测试的是另一个。

先写下你想要上线的确切主机名。根域看起来像 example.com。子域看起来像 www.example.com 或 app.example.com。它们是独立的 DNS 条目，所以“www 可用”并不意味着根域也可用。

接着，从托管平台查找期望的目标。有的平台会给你一个 IP（用于 A/AAAA 记录），有的会给你一个目标主机名（用于 CNAME）。如果托管方在域名设置界面提供了一个值，就把它当作事实来源。

在改动前，先记录当前设置。保持简单：

• 复制你要修改主机名当前的 DNS 记录
• 记录任何现有的 A、AAAA、CNAME 和 TXT 记录
• 记录 TTL

同时确认你正在编辑正确的 DNS 区域。很容易修改到错的域名、错的环境或错的提供商账号上。

第 2 步：选择正确的 DNS 记录类型（A、AAAA、CNAME、TXT）

很多问题仅仅是记录类型错误。先把两个情况分开：根域（example.com）和子域（www.example.com）。在很多 DNS 提供商上它们行为不同。

A 记录将名称指向 IPv4 地址。许多设置会为根域使用 A 记录，因为部分提供商不允许在 apex 上使用 CNAME。如果你的主机给了一个 IP，通常使用 A 记录。

AAAA 是 IPv6 版本。如果有一条遗留的 AAAA 指向旧目的地，可能会造成“有人能访问，有人不能”的混乱，因为部分访客走 IPv6，其他走 IPv4。如果主机没有提供 IPv6 目标，删除错误的 AAAA 记录通常能解决不一致的失败。

CNAME 将子域指向另一个主机名（常用于 www）。当主机希望你指向一个可在后台变更的命名端点时，CNAME 很有用。

TXT 记录用于验证与挑战（包括某些 SSL 校验）。常见错误包括放在了错误的名称下（根域 vs _acme-challenge vs 子域）、多了空格，或粘贴了错误的值。

在继续前，检查冲突。这些冲突最常导致问题：

• 在同一个名称上同时有 CNAME 与其他记录
• 同名存在多个 A 或 AAAA 记录，而你本意只要一条
• 为 www 或根域遗留的旧记录
• 在错误的主机名下创建的 TXT 记录

第 3 步：确认 nameservers，以确保你在正确的位置编辑

很多“自定义域名不可用”的案例并非出在记录值本身，而是因为记录被添加在错误的提供商。如果你的域使用 Provider A 的 nameservers，在 Provider B 的面板改动记录不会生效，即便记录在 B 看起来正确。

确认权威 nameservers

查看域名实际使用的 nameservers。通常在注册商的域名设置里可以看到“Nameservers”。你也可以在电脑上直接向 DNS 询问以做二次确认：

dig NS example.com

该命令返回的 nameservers 就是权威 nameservers。

快速检查要点：

• 如果你的 DNS 主机提供 nameservers 如 ns1...、ns2...，这些精确值必须出现在注册商处。
• 如果你最近更换了 DNS 提供商，确认切换已完成再继续修改记录。
• 如果某个平台显示“建议的 DNS 记录”，那通常只是指导；你仍需在权威 DNS 提供商处添加这些记录。

为什么会出现“我更新了但没有变化”

如果你在错误的提供商处更新记录，常会看到两个面板内容不一致。唯有权威 nameservers 生效。

还要注意在注册商处更改 nameservers 后会有延迟。在切换窗口期间，不同测试点返回的结果可能不一致。如果 nameservers 仍在变更，暂停记录编辑，等 nameservers 集合稳定后再继续操作。

第 4 步：有用的传播与缓存检查

“传播”并不是某个开关，而是一系列 DNS 缓存（ISP、移动运营商、公用解析器以及你自己的设备）以不同速度更新的过程。这就是为什么你的同事能打开而你无法打开域名的原因。

TTL（生存时间）告诉缓存可以保存答案多久。如果旧的 TTL 是 1 小时，有些人会在接近一小时内继续看到旧值。在更改前降低 TTL 只有在你事先设置好后才有帮助。

要把缓存延迟跟真正错误区分开，做几个快速检查：

• 在家庭或办公 Wi‑Fi 上测试，然后在移动数据上测试
• 让其他网络的同事尝试
• 使用隐身/私密窗口（排除本地缓存的重定向）
• 重启设备或在知道如何操作时清除本地 DNS 缓存
• 再次核对确切主机名（根域 vs www）

如果在你检查的多个地方记录都错误（错误 IP、缺少 www、旧 CNAME），去修复它。如果大多数地方记录正确但某个网络仍然显示旧值，通常是缓存延迟。

第 5 步：SSL 时序与为什么 “等一会儿” 有时是正确的

SSL 证书失败的常见根本原因是：在证书提供方能验证域名之前，DNS 必须指向正确的位置。

正常的顺序很简单：

1. 设置正确的 DNS 记录。
2. 等到它们在多个地方都能正确解析。
3. 完成任何必要的验证（通常是添加 TXT 记录）。
4. 等待证书签发完成。

常被忽视的阻碍很容易错过。错误的 A 或 CNAME 目标会把校验请求发送到错误服务器。过时的 AAAA 记录可能会让部分访客走向错误的服务器，从而导致只有部分人 HTTPS 失败。缺少必要的 TXT 记录会阻止平台签发证书。

用症状来区分“仍在签发中”与“配置错误”很有帮助：

• 仍在签发中： HTTP 可能能访问，但 HTTPS 显示临时默认证书或“尚未生效”类信息。
• 配置错误： 你看到的是不同的网站、ISP 停放页，或 DNS 查询失败（NXDOMAIN）。

在等待时，别频繁更改记录。每次改动都会重置时钟，并可能造成不同网络看到不同答案。把记录设置正确一次，然后重复检查解析与验证，直到证书签发。

如果你使用像 Koder.ai 这样的平台注册域名，最安全的流程一样：确认 DNS 指向预期目标，若存在错误的 AAAA 记录则移除，并在 DNS 稳定后给 SSL 一些时间。

如何逐步验证（避免猜测）

良好的排查基本上是比较你看到的与预期的结果：别只凭“我手机能访问”。使用可重复的方法。

将 DNS 返回与期望目标对比

使用 DNS 查询工具（如 nslookup 或 dig）并确认返回值与你期望的匹配（A/AAAA 返回 IP，CNAME 返回主机名，TXT 返回令牌）。

# Apex (root) domain
dig example.com A

dig example.com AAAA

# www subdomain
dig www.example.com CNAME

# TXT (often used for verification)
dig example.com TXT

同时检查你可能使用的两个名称：根域（example.com）和 www（www.example.com）。经常会出现一种正确而另一种仍指向旧处的情况。

检查浏览器行为（HTTP、HTTPS 与重定向）

分别打开 apex 和 www 的 http:// 与 https://。目标是有一个明确的“主域名”并由另一个进行干净的重定向。

• 选定一个规范域名（apex 或 www）并把另一个重定向到它。
• 避免来回重定向（A 重定向到 B，B 又重定向回 A）。
• 如果 HTTP 可用但 HTTPS 失败，说明 SSL 仍在签发或 DNS 仍指向错误位置。

如果不同网络返回不同结果，多半是缓存或传播问题。保持一份小日志：你改了什么、在哪里改的、时间和你观察到的现象。

浪费时间的常见错误

大多数 DNS 与 SSL 问题并不是谜题，而是小错误导致你一直检查错的东西，或太频繁地改动无法得到清晰结果。

最常见的时间陷阱是同时在两个地方编辑 DNS。这常发生在更换 nameservers 之后：你在注册商处更新了记录，但 DNS 实际托管在别处（或反过来）。在一个面板里一切看似正确，但公网并未改变。

另一个经典错误是尝试在不支持的提供商上对根域使用 CNAME。你可能需要使用 A 记录，或如果 DNS 提供商支持则使用 ALIAS/ANAME 类似的记录。

IPv6 也会造成麻烦。遗留的 AAAA 记录会把部分访客导向错误服务器，而其他人则走 IPv4 到正确地址。

小心那些“以防万一”留下的记录。当某个目标错误时，多个 A 记录会像意外的负载均衡一样工作，导致不稳定表现。

一句最终规则：不要不断地重置时钟。

• 不要每隔几分钟就改记录。
• 不要同时混合旧目标与新目标。
• 等缓存稳定后再评判效果。

小而有序的变更胜过不停地调整。

一个真实场景：www 可用但根域不可用

你发布了新应用并为 example.com 与 www.example.com 都做了设置。几分钟后，www.example.com 能正常加载，但根域显示 DNS 错误、加载旧网站或 HTTPS 一直挂起。这个模式很常见，通常有小而明确的原因。

先问一个无聊却关键的问题：你是不是在正确的位置编辑 DNS？如果域名注册在一家公司但 DNS 托管在另一家，你可能整天改记录也不会生效。优先检查 nameservers，然后在那些 nameservers 所指向的提供商面板中打开 DNS 配置。

接着比较两个主机名。www 通常是 CNAME。根域更麻烦：很多提供商不允许在 apex 使用 CNAME，因此通常需要一个 A 记录指向 IP，或如果支持则使用 ALIAS 或 ANAME 类型的记录。

一个实用的判断流程：

• nameservers 错误或出乎意料？先修复它。
• nameservers 正确但 example.com 没有记录（或指向别处）？修复根域记录。
• 记录看起来正确但不同设备/网络表现不同？等待传播并清理缓存。
• DNS 能解析但 HTTPS 失败或卡住？SSL 正在等待 DNS 一致解析。

正确的最终状态应该是无聊的：example.com 与 www.example.com 都指向同一个应用，一个为规范域名，另一个进行重定向，并且 HTTPS 有效。

5 分钟内可以跑完的快速检查清单

当域名设置失败时，大多数修复来自几项快速检查。先在改任何其他东西前做这些。

• 确认你在正确的位置编辑 DNS（将你的面板与域名的权威 nameservers 对比）。
• 验证主机名与目标是否精确匹配（无漏写子域、无多余点）。将你的记录类型（A、AAAA、CNAME、TXT）与托管方的预期对比。
• 移除冲突（在同一名称上存在 CNAME 与其他记录，或不再需要的旧 A/AAAA 记录）。
• 从两种视角检查（移动数据与 Wi‑Fi）。如果一种网络可用另一种不可用，通常是缓存或传播问题。
• 尊重 TTL。如果 TTL 是 300 秒，等待 5 到 10 分钟再评判；如果 TTL 是 3600，预期接近一小时。

在 DNS 明确正确后，再检查 SSL。许多平台只有在能稳定解析到正确目标后才会签发证书。如果检查得太早，你可能把正常延迟误判为真实错误。

如果你要在 Koder.ai 上为已部署应用添加自定义域名，把应用的域名设置界面视为预期目标，在权威 DNS 提供商处精确配置对应记录，DNS 传播后再检查状态。

接下来：为每次发布把域名设置流程做成可复制的笔记

避免重复犯 DNS 与 SSL 错误的最快方法是为每个项目保留一份简短的“域名设置记录”。它是可以重复使用的运行手册，下次发布时直接复制即可。

简单的域名设置记录模板

把它放在项目文档里，且在你动 DNS 之前填写：

• 域名与主机名（根域、www 以及任何子域）
• 预期的记录类型与目标（A、CNAME、TXT）以及这些值来自哪里
• 在哪里编辑 DNS（哪个提供商）以及当前生效的 nameservers
• SSL 期望（谁来签发、什么状态算“就绪”）
• 你将运行的验证步骤（使用的工具及期望结果）

发布时指定一个 DNS 负责人。当两个人同时“修复”不同部分时（例如一个人改 nameservers，另一个人在改记录），最容易出问题。

在托管端，考虑能否安全回退。如果平台支持快照或回滚，变更路由前先做快照以便快速恢复到上一个已知可用状态。如果在 Koder.ai 上构建，可以使用 Planning Mode 写下域名步骤，按顺序执行，并在变更破坏生产时回滚。

何时升级求助（向谁求助）

当你确认 DNS 正确但仍看到失败时，停止猜测并带上证据去升级求助：

• 注册商显示 nameservers 被锁定或你无法更改
• DNS 编辑在预期的 TTL 时间窗后仍无变化
• SSL 在 DNS 正确解析后仍长时间失败（以小时计而非分钟）
• 出现无法删除的冲突记录（提供商 UI 错误或拆分 DNS）

升级时包含主机名、预期记录、当前解析结果和时间戳。这能把慢吞吞的来回沟通变成快速的修复。