域名解析与 CDN 基础：从输入网址到内容送达的全链路

在浏览器地址栏输入一个域名、按下回车，到页面完整呈现，中间其实跑完了两条链路：一条是域名解析，把名字翻译成地址；另一条是内容分发，把数据从离你最近的节点送过来。理解这两条链路，很多“网站打不开”“图片加载慢”的问题就有了排查方向。

一、域名解析：名字怎么变成 IP

电脑只认 IP 地址，域名是给人看的别名。解析过程是一个逐级查询的链条：浏览器先查本地缓存和 hosts 文件，没有命中就问本地 DNS 服务器；本地服务器再从根域名服务器开始，依次问顶级域服务器和权威域名服务器，最终拿到记录。

最常见的几类记录各有分工：A 记录把域名指向 IPv4 地址，AAAA 记录指向 IPv6 地址，CNAME 记录把一个域名指向另一个域名（常用于把业务域名指向云厂商分配的默认域名），MX 记录指定收件服务器。TTL（生存时间）决定了记录在各级缓存里存多久：TTL 太长，改解析后生效慢；TTL 太短，查询量大、解析变慢。做迁移前先把 TTL 临时调小，是个实用的习惯。

排查解析问题时，先分清是“解析不到”还是“解析到了但连不上”。前者看 DNS 返回，后者看连通性。nslookup 或 dig 可以直接看到返回的记录和 TTL；如果本地解析结果与权威结果不一致，多半是某一级缓存还没过期，等 TTL 过去或换个 DNS 视角再验证。

二、CDN：为什么加了 CDN 会变快

CDN 的核心思想很简单：把内容提前放到离用户近的边缘节点，用户请求不再每次都回源站。静态资源（图片、样式表、脚本、安装包）最适合缓存；动态接口一般只做加速或直接回源。

一次带 CDN 的访问大致是这样：用户请求先到边缘节点，节点命中缓存就直接返回；没命中则回源拉取，并按缓存规则把副本留下来，供后续请求复用。缓存规则由源站的响应头（如 Cache-Control、ETag）和 CDN 控制台的配置共同决定。更新了文件但用户仍看到旧版，九成是缓存没按预期失效——这时要么等缓存自然过期，要么在控制台做主动刷新或改文件名加版本号。

三、两者配合时的常见坑

第一，CNAME 接入后要确认解析确实指向了 CDN 分配的域名，而不是仍指向源站 IP；指向错了，加速等于没加。第二，HTTPS 站点用 CDN 时，证书要覆盖到边缘节点：要么在 CDN 上托管证书，要么用 CDN 提供的免费证书，并确认回源链路也是 HTTPS，避免源站只接受 HTTP 导致回源失败。第三，源站做了 IP 白名单或鉴权，要记得把 CDN 回源节点的地址段放行，否则边缘节点回源会被源站挡住，表现为间歇性 502 或 403。

第四，混合内容问题常在这里冒头：页面本身是 HTTPS，但个别资源仍用 HTTP 引用，浏览器会拦截这些不安全请求。根治办法是全站统一 HTTPS，资源引用用相对路径或统一的 HTTPS 地址，而不是在 CDN 侧逐个修补。

四、一个小结清单

域名解析出问题，先看记录类型和 TTL，再分清解析层还是连通层；CDN 变慢或内容陈旧，先看缓存命中情况和缓存规则；两者联动出问题，先核对 CNAME 指向、证书覆盖和回源放行三项。把这条链路画清楚，日常运维里一半以上的“访问异常”都能在十分钟内定位到环节，而不是在各个控制台之间来回猜。