2025年11月19日·2 分钟
DNS 与 SSL 问题的自定义域名故障排查清单
使用此自定义域名故障排查清单诊断 DNS 记录问题、传播延迟与 SSL 时序，并提供简单的验证步骤。
使用此自定义域名故障排查清单诊断 DNS 记录问题、传播延迟与 SSL 时序，并提供简单的验证步骤。
“自定义域名不可用”是一个笼统的说法，涵盖了几类不同的失败。浏览器显示的是症状，而不是原因。在改任何东西之前，先写清楚你实际看到的是什么。
典型症状包括：
www 之间来回跳转）大多数情况下，问题通常集中在一件事上：
在排查前，确保你能访问两个地方：编辑 DNS 记录的位置（域名注册商或 DNS 提供商）和在托管方绑定域名的设置界面。举例来说，如果你要把已部署的应用在 Koder.ai 上绑定自定义域名，你既需要对域名的 DNS 有编辑权限，又要能在应用的托管/部署设置里添加该域名。
有些修复是瞬时的（比如更正拼写错误）。有些则需要时间。DNS 更改可能需要一段时间才会生效，而 SSL 通常要等 DNS 正确且域名可访问后才会完成。目标是按顺序确认每层，而不是盲目猜测。
大多数域名问题归结为三者不匹配：（1）你测试的主机名、（2）谁在管理 DNS、以及（3）记录实际指向何处。一旦这三者一致，SSL 通常就是最后一步。
域名有两种常见形式：根域（example.com，也叫 apex）和子域（www.example.com、app.example.com）。它们相关但可以有不同的 DNS 记录。因此出现 www 可用而根域不可用，或相反，是很常见的。
Nameservers（域名服务器）决定谁负责你的 DNS 区域。如果你在一家注册商购买域名，但 nameservers 指向另一家，你必须在 nameservers 指向的地方编辑 DNS。很多“我已经更新了但没有变化”的情况，都是因为在错误的控制面板里修改了记录。
下面是主要记录类型在做什么：
www）TTL 是“缓存多长时间”的计时器。TTL 越低，缓存刷新越快；TTL 越高，即使你修正了记录也可能需要更长时间才能看到变化，暂时仍看到旧值是正常现象。
当自定义域名出现故障时，通常可将问题分为四类：DNS 无法解析、DNS 解析到错误位置、SSL 未准备好，或因为缓存导致只有部分用户受影响。
按下列决策树操作：
www 可用但根域不可（或反之），很可能只配置了一个主机名，或存在冲突的重定向规则。记录下失败的确切主机名（apex 还是 www）和确切错误信息，可以加速判断。在自动化域名和证书的平台上，“找不到主机”与“证书待签发”的区别会直接告诉你是修 DNS 还是等 SSL。
很多域名故障起因于简单的不匹配：你为一个主机名设置了 DNS，但测试的是另一个。
先写下你想要上线的确切主机名。根域看起来像 example.com。子域看起来像 www.example.com 或 app.example.com。它们是独立的 DNS 条目，所以“www 可用”并不意味着根域也可用。
接着，从托管平台查找期望的目标。有的平台会给你一个 IP（用于 A/AAAA 记录），有的会给你一个目标主机名（用于 CNAME）。如果托管方在域名设置界面提供了一个值，就把它当作事实来源。
在改动前，先记录当前设置。保持简单：
同时确认你正在编辑正确的 DNS 区域。很容易修改到错的域名、错的环境或错的提供商账号上。
很多问题仅仅是记录类型错误。先把两个情况分开：根域（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 子域）、多了空格，或粘贴了错误的值。
在继续前，检查冲突。这些冲突最常导致问题：
www 或根域遗留的旧记录很多“自定义域名不可用”的案例并非出在记录值本身，而是因为记录被添加在错误的提供商。如果你的域使用 Provider A 的 nameservers，在 Provider B 的面板改动记录不会生效，即便记录在 B 看起来正确。
查看域名实际使用的 nameservers。通常在注册商的域名设置里可以看到“Nameservers”。你也可以在电脑上直接向 DNS 询问以做二次确认：
dig NS example.com
该命令返回的 nameservers 就是权威 nameservers。
快速检查要点：
ns1...、ns2...，这些精确值必须出现在注册商处。如果你在错误的提供商处更新记录，常会看到两个面板内容不一致。唯有权威 nameservers 生效。
还要注意在注册商处更改 nameservers 后会有延迟。在切换窗口期间，不同测试点返回的结果可能不一致。如果 nameservers 仍在变更，暂停记录编辑，等 nameservers 集合稳定后再继续操作。
“传播”并不是某个开关，而是一系列 DNS 缓存（ISP、移动运营商、公用解析器以及你自己的设备）以不同速度更新的过程。这就是为什么你的同事能打开而你无法打开域名的原因。
TTL（生存时间）告诉缓存可以保存答案多久。如果旧的 TTL 是 1 小时，有些人会在接近一小时内继续看到旧值。在更改前降低 TTL 只有在你事先设置好后才有帮助。
要把缓存延迟跟真正错误区分开，做几个快速检查：
www）如果在你检查的多个地方记录都错误（错误 IP、缺少 www、旧 CNAME），去修复它。如果大多数地方记录正确但某个网络仍然显示旧值，通常是缓存延迟。
SSL 证书失败的常见根本原因是：在证书提供方能验证域名之前，DNS 必须指向正确的位置。
正常的顺序很简单：
常被忽视的阻碍很容易错过。错误的 A 或 CNAME 目标会把校验请求发送到错误服务器。过时的 AAAA 记录可能会让部分访客走向错误的服务器，从而导致只有部分人 HTTPS 失败。缺少必要的 TXT 记录会阻止平台签发证书。
用症状来区分“仍在签发中”与“配置错误”很有帮助：
在等待时，别频繁更改记录。每次改动都会重置时钟，并可能造成不同网络看到不同答案。把记录设置正确一次，然后重复检查解析与验证，直到证书签发。
如果你使用像 Koder.ai 这样的平台注册域名，最安全的流程一样：确认 DNS 指向预期目标，若存在错误的 AAAA 记录则移除，并在 DNS 稳定后给 SSL 一些时间。
良好的排查基本上是比较你看到的与预期的结果：别只凭“我手机能访问”。使用可重复的方法。
使用 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）。经常会出现一种正确而另一种仍指向旧处的情况。
分别打开 apex 和 www 的 http:// 与 https://。目标是有一个明确的“主域名”并由另一个进行干净的重定向。
www）并把另一个重定向到它。如果不同网络返回不同结果，多半是缓存或传播问题。保持一份小日志：你改了什么、在哪里改的、时间和你观察到的现象。
大多数 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 类型的记录。
一个实用的判断流程：
example.com 没有记录（或指向别处）？修复根域记录。正确的最终状态应该是无聊的：example.com 与 www.example.com 都指向同一个应用，一个为规范域名，另一个进行重定向，并且 HTTPS 有效。
当域名设置失败时，大多数修复来自几项快速检查。先在改任何其他东西前做这些。
在 DNS 明确正确后，再检查 SSL。许多平台只有在能稳定解析到正确目标后才会签发证书。如果检查得太早，你可能把正常延迟误判为真实错误。
如果你要在 Koder.ai 上为已部署应用添加自定义域名，把应用的域名设置界面视为预期目标，在权威 DNS 提供商处精确配置对应记录，DNS 传播后再检查状态。
避免重复犯 DNS 与 SSL 错误的最快方法是为每个项目保留一份简短的“域名设置记录”。它是可以重复使用的运行手册，下次发布时直接复制即可。
把它放在项目文档里，且在你动 DNS 之前填写：
发布时指定一个 DNS 负责人。当两个人同时“修复”不同部分时（例如一个人改 nameservers，另一个人在改记录），最容易出问题。
在托管端，考虑能否安全回退。如果平台支持快照或回滚，变更路由前先做快照以便快速恢复到上一个已知可用状态。如果在 Koder.ai 上构建，可以使用 Planning Mode 写下域名步骤，按顺序执行，并在变更破坏生产时回滚。
当你确认 DNS 正确但仍看到失败时，停止猜测并带上证据去升级求助：
升级时包含主机名、预期记录、当前解析结果和时间戳。这能把慢吞吞的来回沟通变成快速的修复。
通常意味着链路中的某一层出问题：DNS 无法解析、DNS 解析到了错误的目标、服务器/托管未识别你的主机名，或 HTTPS/SSL 尚未完成签发。先写下你看到的确切错误和你输入的确切主机名（根域 vs www）。
example.com（根域）和 www.example.com 是不同的主机名、各自有独立的 DNS 记录。常见情况是为 www 配置了正确的 CNAME，而根域没有 A 记录、A 记录错误，或你的 DNS 提供商不支持在根域使用 CNAME。
在注册商处查看域名的 nameservers，并与正在编辑的 DNS 提供商对比。只有列在当前 nameservers 中的提供商才是权威的；在其他地方修改记录不会影响公网解析结果。
当主机方给你一个 IPv4 地址时使用 A 记录；只有在托管方提供 IPv6 地址时才用 AAAA；当托管方给出一个主机名（常用于 www）时用 CNAME。TXT 用于验证与挑战，必须在托管方指定的确切名称下创建。
错误或过时的 AAAA 记录可能会把部分访客导向旧服务器，而其他人走 IPv4 到正确地址，从而产生“对我可用”的混淆。如果你的主机没有提供 IPv6 目标，删除错误的 AAAA 往往是最简单的修复方法。
通常是因为只在托管端配置了一个主机名（只配置了根域或只配置了 www），或存在互相冲突的重定向规则导致来回跳转（HTTP 与 HTTPS、或 apex 与 www）。选择一个规范域名，确保两端都已配置并只存在一条清晰的重定向路径。
会的，但前提是 DNS 必须在多个地方稳定地指向正确目标之后再等待。SSL 签发通常只有在域名一致解析到期望目标后才会完成，频繁切换 DNS 会不断重置签发过程。
TTL 是解析器缓存答案的时长，所以即使你修正了记录，部分网络也会在 TTL 到期前继续返回旧值。建议从两个不同网络（如 Wi‑Fi 和移动数据）进行测试，并且不要每隔几分钟就改动 DNS，这样才能观测传播情况。
使用可重复的检查方法：用 dig 或 nslookup 确认 A/AAAA/CNAME/TXT 的返回值与预期目标一致，然后分别测试 apex 与 www 的 http:// 与 https://。如果不同网络返回不同的 DNS 答案，多半是缓存；如果所有网络都返回错误答案，则是配置问题。
在 Koder.ai 上，把应用的域名设置界面作为预期 DNS 目标的权威来源，在权威 DNS 提供商处精确设置记录。修改 DNS 后等待传播稳定再检查 SSL；在更改生产路由前使用快照/回滚以便快速恢复到已知可用状态。