DNS 已经解析成功，为什么域名还是打不开？

① 先把后文会反复出现的词认清楚

先认词：“域名打不开”只是一个表象。这里把真正参与排错的核心词按请求发生顺序展开：名称解析 → 网络连接 → 加密握手 → HTTP 路由 → 应用 → 浏览器安全 → 中国大陆接入合规。每张卡都包含直觉、严格定义、当前案例和边界。

② 现在再看这段材料到底在说什么

核心问题不是“域名为什么打不开”，而是：一个浏览器请求从名称解析到页面拿到数据，要穿过多少个彼此独立的门？

工程上最常见的误诊，是看到最终症状都叫“打不开”，于是把所有原因都归到 DNS。实际上同一个表象可以由完全不同的层产生：DNS 可能返回旧地址；443 可能被安全组拦截；TLS 可能拿错证书；Nginx 可能命中默认站点；上游应用可能 502；浏览器也可能已经拿到 200 响应，却因为 CORS 不把数据交给 JavaScript。

为什么要按层排查

把请求过程写成串联系统，可以近似认为成功事件需要每一层都成功：

$$P\left(\mathrm{success}\right)=\prod _i^1{P}_i$$

这里不是为了精确算概率，而是建立一个工程直觉：串联系统里任何一层失败，最终用户都只会看到“失败”。因此排错要按依赖顺序找第一个不成立的必要条件，而不是同时改五处配置。

本案例的特殊之处

前端放在 GitHub Pages，而 API 想落到腾讯云中国大陆服务器。这意味着前端静态页面是否能打开，与 API 域名是否能在大陆 origin 上公开提供服务是两条不同路径。前端 200 不证明 API 正常；API 命令行可访问也不证明浏览器 CORS 正常；DNS 正确更不自动解决大陆接入备案问题。

当前参考：腾讯云：如何快速备案您的网站或 APP · 腾讯云：接入备案 · 腾讯云：网站/APP 阻断相关。

③ 概念关系与最小知识闭包

最小知识闭包 1：DNS 到底证明了什么？

当 dig +short api.example.com 返回预期 IP，你最多可以说：“我询问的这个解析器此刻给出了这个地址。”如果要更严格，可以分别看本地默认解析器、公共解析器和权威 DNS：

dig api.example.com
dig @1.1.1.1 api.example.com
dig @8.8.8.8 api.example.com
dig +trace api.example.com

如果权威 DNS 已更新、公共递归仍返回旧值，常见解释是缓存尚未过 TTL；如果一部分网络走 AAAA 而 IPv6 目标没有配置好，则可能出现“手机流量打不开、公司网络能打开”这类分裂现象。因此 DNS 诊断要记录查询对象、记录类型、回答地址、TTL 和时间。

最小知识闭包 2：为什么 ping 不是网站验收？

ping 使用 ICMP Echo，而 HTTPS 常用 TCP 443。安全组可以允许 ICMP 却拒绝 443，也可以禁止 ICMP 而 HTTPS 完全正常。因此正确问题不是“机器活不活”，而是“从用户网络到目标 IP 的目标端口能不能建立连接”。

nc -vz api.example.com 443
curl -v --connect-timeout 5 https://api.example.com/health

连接超时通常把注意力放在路由、安全组、防火墙和监听地址；立即 connection refused 更像目标可达但端口没有服务；已经进入 TLS 错误，则说明 TCP 层大概率已通过。

最小知识闭包 3：为什么域名访问和 IP 访问不是一回事？

现代 HTTPS 虚拟主机通常同时依赖 TLS 的 SNI 与 HTTP Host。也就是说，服务器不仅看“你连到哪个 IP”，还看“你说你要访问哪个名字”。这也是为什么下面两条命令语义不同：

curl -vk https://203.0.113.10/
curl -vk --resolve api.example.com:443:203.0.113.10   https://api.example.com/health

第二条既强制连接指定 IP，又保留 api.example.com 作为 TLS SNI 与 HTTP 主机名，非常适合排除 DNS 之后单独验证某台 origin 的证书、虚拟主机与应用。

最小知识闭包 4：HTTP 状态码也在告诉你“失败在哪”

最小知识闭包 5：把故障定位成“最早失败的边”

可以把系统抽象为有向图：节点是 DNS、TCP、TLS、HTTP、App、Browser，边代表“前一层成立才能进入后一层”。排错的目标不是找到所有异常，而是找到从用户到业务结果路径上第一条不能被证据证明的边。这会显著减少同时改配置造成的新变量。

最小知识闭包 6：同一个问题为什么要“外部测一次、内部测一次”

只从用户浏览器外部测试，你能知道最终链路失败，却不容易知道哪一段失败；只在服务器内部测试，你又可能得到“本机全绿、用户仍打不开”的假安全感。最有效的方法是从两端向中间夹逼：外部测试域名与公网 443，内部测试回环应用与本机反代，然后比较两侧最后成功的位置。

例如内部 127.0.0.1:8080/health 成功、本机 443 成功、外部 443 超时，搜索空间基本收缩到主机防火墙、安全组、路由或云平台入口；反之，外部已经收到 502，说明 DNS/TCP/TLS 往往已经走过一大段，应该把精力放在反代到 upstream 的路径。

最小知识闭包 7：缓存会制造“同一时刻不同用户看到不同世界”

DNS 有递归缓存，CDN 有边缘缓存，浏览器也有 DNS/HTTP/TLS 会话相关缓存。一个配置刚修改后，不同观察者可能因为缓存层不同而看到不同结果。这不是“玄学传播”，而是系统中多个带状态缓存节点的正常结果。

所以排错记录应该至少包含时间、客户端网络、解析器、记录类型和响应。只有把观测条件固定住，才有资格比较两次结果。数学上，这相当于承认观测值不是简单的 f(config)，而是 f(config, cache_state, observer, time)。

最小知识闭包 8：不要把“成功返回 HTTP”与“业务成功”混为一谈

HTTP 200 只是应用层协议结果的一部分。一个健康检查可能 200，但登录接口因为数据库迁移缺失返回 500；一个 API 可能 200 返回错误业务码；一个 CDN 也可能把旧的 200 缓存继续发给用户。因此发布验收要把“网络可达”“协议正确”“业务行为正确”分成不同 AC。

④ 把真实案例重新还原

案例拓扑

用户浏览器
  ├─ https://www.example.com
  │      └─ GitHub Pages（静态前端）
  │
  └─ https://api.example.com
         └─ DNSPod
              └─ 腾讯云中国大陆 CVM
                    └─ Caddy / Nginx :443
                          └─ API :8080
                                └─ PostgreSQL / Redis

现在出现现象：“www.example.com 能打开，api.example.com 看起来也已经解析到服务器，但网页调用 API 失败。”如果只说“DNS 有问题”，信息量几乎为零。正确做法是把事实、推断、未知拆开。

诊断路径 A：先证明名称层

dig +short A api.example.com
dig +short AAAA api.example.com
dig @1.1.1.1 api.example.com
dig @8.8.8.8 api.example.com

记录结果，而不是只看“有输出”。你要知道 A/AAAA 分别是什么、是否存在意外旧记录、不同递归解析器是否一致。如果这里错，先修 DNS；如果这里对，就把 DNS 暂时从嫌疑列表中移出。

诊断路径 B：跳过 DNS，单测 origin

curl -vk --resolve api.example.com:443:203.0.113.10   https://api.example.com/health

这条命令非常关键，因为它把“连接哪个 IP”固定住，同时保留正确域名用于 SNI 和 Host。若这条失败，问题在 DNS 之后、浏览器之前；若它成功，而普通域名请求失败，再回头对比 DNS/网络路径。

诊断路径 C：从服务器内部向外证明

# 应用本身
curl -sS http://127.0.0.1:8080/health

# 反向代理是否能到应用
curl -vk https://127.0.0.1/health -H 'Host: api.example.com'

# 监听与进程
ss -lntp
docker ps            # 仅当你的运行方式确实是 Docker
systemctl status caddy

如果本机 8080 正常、443 反代失败，就不要去改数据库；如果本机 443 正常、外部连不上，就把注意力放到安全组、防火墙和平台层。

诊断路径 D：最后检查浏览器

浏览器 Network 面板至少记录：请求 URL、方法、是否触发 OPTIONS、HTTP 状态、Response Headers、Console 报错。如果命令行 API 正常而浏览器提示 CORS，那么请求可能已经到达并成功返回，只是浏览器不允许页面脚本读取。

⑤ 概念如何映射到现实

三种常见上线架构怎么判断

⑥ 现在把它当成一道题

⑦ 分级提示，最后就是实际答案

dig +short A api.example.com
dig +short AAAA api.example.com
dig @1.1.1.1 api.example.com
dig +trace api.example.com

nc -vz api.example.com 443

curl -vk --resolve api.example.com:443:203.0.113.10   https://api.example.com/health

curl -sS http://127.0.0.1:8080/health
ss -lntp
journalctl -u caddy --since '10 min ago'
# 或查看实际使用的 Nginx / 容器 / 应用日志