很多网站接入 CDN 后，最容易产生一个疑问：用户访问我的域名时，到底是访问到了 CDN 节点，还是直接访问到了源站服务器？

这个问题看起来简单，但真正排查时会牵涉到 DNS 解析、CNAME、CDN 调度、HTTPS 证书、回源地址、源站安全策略等多个环节。

尤其是跨境电商、外贸官网、图片站、下载站这类业务，如果只看一个 ping 结果，很容易误判。本文用通俗方式把 CDN 后的访问链路讲清楚，并给出实际排查命令和服务器配置建议。

一、用了 CDN 后，用户访问域名时到底访问到哪里？

正常情况下，域名接入 CDN 后，用户访问的第一目标不再是你的源站服务器 IP，而是 CDN 分配的边缘节点 IP。

简单链路可以理解为：

用户浏览器
  ↓
本地 DNS / 递归 DNS
  ↓
查询域名解析记录
  ↓
命中 CDN 的 CNAME 记录
  ↓
CDN 调度系统返回就近节点 IP
  ↓
用户访问 CDN 节点
  ↓
CDN 节点根据缓存情况决定是否回源
  ↓
源站服务器

也就是说：

用户并不是直接访问源站，而是先访问 CDN 节点。

但 CDN 节点是否访问源站，要看资源是否已经缓存。

如果图片、JS、CSS、静态文件已经缓存，CDN 节点会直接返回内容；如果是首次访问、缓存过期、动态接口、登录请求，CDN 节点就会向源站服务器发起回源请求。

二、CDN 接入后，DNS 解析链路发生了什么变化？

没有 CDN 时，域名通常是直接 A 记录解析到源站 IP：

www.example.com → A记录 → 源站服务器IP

接入 CDN 后，常见方式是把域名解析成 CDN 提供的 CNAME：

www.example.com → CNAME → xxx.cdnprovider.com → CDN节点IP

实际访问时，DNS 查询并不是一步完成，而是多级解析：

用户 DNS
  ↓
根 DNS
  ↓
.com 顶级域 DNS
  ↓
example.com 权威 DNS
  ↓
返回 www.example.com 的 CNAME
  ↓
继续解析 CDN 域名
  ↓
CDN 调度返回节点 IP

所以，接入 CDN 后，真正重要的不是“域名有没有解析”，而是要看：

域名是否正确 CNAME 到 CDN
CDN 是否返回节点 IP
不同地区返回的节点 IP 是否不同
源站是否只允许 CDN 回源

三、如何查看域名当前访问到哪里？

1. 先看域名最终解析到了什么

Linux 服务器上可以使用：

dig www.example.com

重点看这几部分：

ANSWER SECTION:
www.example.com.  300  IN  CNAME  xxx.cdnprovider.com.
xxx.cdnprovider.com. 60 IN A      203.0.113.10

如果看到 CNAME 指向 CDN 域名，说明域名已经接入 CDN。

如果直接看到源站 IP，例如：

www.example.com. 300 IN A 45.125.xxx.xxx

那说明这个域名当前还是直接解析到源站，没有经过 CDN。

2. 查看完整 DNS 解析链路

可以使用：

dig +trace www.example.com

这个命令会从根 DNS 一路查到最终解析结果，适合判断解析链路是否完整。

重点看最后几段：

www.example.com.      300 IN CNAME xxx.cdnprovider.com.
xxx.cdnprovider.com.   60 IN A     203.0.113.10

如果中间出现解析中断、权威 DNS 无响应、CNAME 配置错误，就可能导致部分地区打不开网站。

3. 用 nslookup 查看本地 DNS 返回结果

Windows 或 Linux 都可以使用：

nslookup www.example.com

如果想指定 DNS 服务器查询，比如使用 8.8.8.8：

nslookup www.example.com 8.8.8.8

使用国内 DNS 查询：

nslookup www.example.com 223.5.5.5

这一步很重要，因为不同 DNS 返回的 CDN 节点可能不一样。

例如：

223.5.5.5 返回香港 CDN 节点
8.8.8.8 返回美国 CDN 节点
本地运营商 DNS 返回新加坡 CDN 节点

如果 CDN 调度不合理，用户访问延迟就会明显变高。

四、Ping 到的 IP 是源站 IP 还是 CDN IP？

很多人接入 CDN 后会直接执行：

ping www.example.com

然后看到一个 IP，就以为这是网站服务器 IP。这个判断并不严谨。

如果域名已经接入 CDN，ping 到的大概率是 CDN 节点 IP，而不是源站 IP。

例如：

ping www.example.com

Pinging www.example.com [203.0.113.10] with 32 bytes of data:

这个 203.0.113.10 可能只是 CDN 边缘节点。

要判断它是不是 CDN IP，可以从几个角度看：

1. dig 结果是否有 CNAME
2. IP 归属是否属于 CDN 厂商
3. 不同地区解析出的 IP 是否不同
4. 源站真实 IP 是否与 ping 到的 IP 不一致

如果你在香港服务器上执行：

curl -I https://www.example.com

看到类似响应头：

server: cloudflare
x-cache: HIT
cf-cache-status: HIT

或：

x-cache: HIT
via: cache-node

就说明请求大概率命中了 CDN 缓存节点。

五、CDN 节点和源站服务器之间是什么关系？

CDN 不是替代服务器，而是放在用户和源站之间的一层加速与防护网络。

常见结构如下：

用户
 ↓
CDN边缘节点
 ↓
源站服务器

CDN 主要负责：

缓存静态资源
就近调度访问
隐藏源站 IP
降低源站压力
抵御一部分恶意请求
改善跨地区访问速度

源站服务器仍然负责：

网站程序运行
数据库连接
动态接口处理
用户登录
订单提交
后台管理
真实业务数据

所以，CDN 能加速访问，但不能替代源站性能。如果源站 CPU、内存、磁盘 IO 或数据库本身很慢，即使加了 CDN，动态页面依然可能慢。

六、实际业务中推荐的源站服务器配置

对于接入 CDN 的网站，源站服务器不用盲目追求超大公网带宽，但要重点关注 CPU、内存、NVMe 磁盘和回源线路质量。

下面以外贸官网、跨境电商和图片资源站为例。

如果网站主要用户在中国大陆，但源站放在香港，建议选择：

香港 CN2 / CMIN2 / CU 三网优化线路

如果网站用户分布在全球，可以选择：

香港 BGP 多线 + CDN 全球节点

如果静态资源较多，例如图片、视频切片、安装包下载，则建议：

源站使用 1G BGP 带宽
CDN 缓存静态文件
源站限制只允许 CDN 回源 IP

七、如何判断请求是否真的经过 CDN？

1. 查看 HTTP 响应头

执行：

curl -I https://www.example.com

重点看：

x-cache
cf-cache-status
via
age
server
cdn-cache

常见结果：

x-cache: HIT
age: 3600

表示命中 CDN 缓存。

x-cache: MISS

表示 CDN 没有缓存，需要回源。

x-cache: BYPASS

表示该请求被规则绕过，没有缓存。

如果所有请求都是 MISS，说明 CDN 虽然接入了，但缓存规则可能没有配置好。

2. 对比 CDN 域名和源站 IP

假设源站 IP 是：

45.125.xxx.xxx

域名解析结果是：

dig www.example.com

返回：

www.example.com. CNAME xxx.cdnprovider.com.
xxx.cdnprovider.com. A 203.0.113.10

说明用户访问的是 CDN 节点 203.0.113.10，不是源站 45.125.xxx.xxx。

然后可以直接测试源站：

curl -I http://45.125.xxx.xxx -H "Host: www.example.com"

这条命令可以模拟 CDN 回源访问源站时的请求。

如果这个请求正常，说明源站可以响应对应域名。

如果返回 403、404、证书错误、默认站点页面，就说明源站虚拟主机或 Nginx 配置可能有问题。

八、CDN 接入后最常见的几个问题

1. 域名解析到了 CDN，但网站打不开

常见原因：

源站 IP 填错
源站端口未开放
源站防火墙拦截 CDN 回源
CDN 回源协议配置错误
源站没有绑定该域名

排查顺序：

dig www.example.com
curl -I https://www.example.com
curl -I http://源站IP -H "Host: www.example.com"

如果直接访问源站 IP 加 Host 正常，但访问 CDN 不正常，问题大概率在 CDN 配置。

如果源站 IP 加 Host 也不正常，问题在源站 Web 服务。

2. HTTPS 证书正常，但访问还是报错

CDN HTTPS 涉及两段连接：

用户浏览器 → CDN
CDN → 源站

很多人只配置了第一段证书，忽略了第二段。

建议配置方式：

用户到 CDN：HTTPS
CDN 到源站：HTTPS
源站证书：有效证书或 CDN 信任证书

如果 CDN 回源使用 HTTPS，而源站证书过期、域名不匹配，就可能出现 502、525、526 等错误。

源站测试：

openssl s_client -connect 源站IP:443 -servername www.example.com

这条命令可以检查源站在指定域名下是否能正确返回 HTTPS 证书。

3. 后台登录异常、验证码失效、购物车丢失

这类问题通常不是 DNS 问题，而是 CDN 缓存规则问题。

后台、登录、购物车、订单接口不能随便缓存。

建议 CDN 规则中排除：

/wp-admin/*
/wp-login.php
/cart/*
/checkout/*
/user/*
/api/*
/admin/*

对于 WordPress、WooCommerce、Laravel、ThinkPHP 等程序，动态接口建议设置：

Cache-Control: no-store

或者在 CDN 中配置不缓存动态路径。

4. 源站真实 IP 暴露后，CDN 防护失效

接入 CDN 后，如果源站 IP 仍然可以被直接访问，那么攻击者可以绕过 CDN 直接打源站。

正确做法是：

源站防火墙只允许 CDN 回源 IP
源站 Web 服务绑定域名访问
源站 IP 直接访问返回 403
后台路径增加访问限制
关闭不必要端口

Nginx 可以简单处理源站 IP 直接访问：

server {
    listen 80 default_server;
    server_name _;
    return 403;
}

正式业务域名单独配置：

server {
    listen 80;
    server_name www.example.com;
    root /www/wwwroot/example.com;
}

这样即使别人知道源站 IP，也无法直接访问网站内容。

九、CDN + 香港服务器的推荐架构

对于面向国内和海外用户的网站，比较稳妥的架构是：

用户
 ↓
CDN 全球节点
 ↓
香港 CN2 / BGP 源站服务器
 ↓
数据库 / 缓存 / 文件存储

推荐源站方案：

CPU：Intel E-2334
内存：32GB DDR4
硬盘：960GB NVMe SSD
带宽：100M BGP + 15M CN2
IP：1-3个
系统：Ubuntu 22.04 / Debian 12 / CentOS 7.x
适合：外贸官网、跨境商城、企业站、API后端

如果是资源型网站，可以升级为：

CPU：Gold 6138
内存：64GB
硬盘：2×960GB NVMe
带宽：1G BGP
适合：图片站、下载站、素材站、静态资源回源

如果网站动态请求较多，例如会员系统、订单系统、后台管理频繁访问，更建议优先提升：

CPU 单核性能
NVMe 磁盘 IO
数据库性能
源站线路质量

而不是只盯着 CDN 节点速度。

十、完整排查流程：从 DNS 到源站一步步看

当用户反馈“用了 CDN 后网站慢、打不开、解析不对”，可以按下面顺序排查。

第一步：确认 DNS 是否走 CDN

dig www.example.com

看是否有 CNAME 指向 CDN。

第二步：查看完整解析链路

dig +trace www.example.com

确认权威 DNS、CNAME、最终 A 记录是否正常。

第三步：测试不同 DNS 返回结果

nslookup www.example.com 223.5.5.5
nslookup www.example.com 8.8.8.8
nslookup www.example.com 1.1.1.1

观察不同地区或不同 DNS 是否返回不同 CDN 节点。

第四步：查看是否命中 CDN 缓存

curl -I https://www.example.com

重点看：

x-cache
age
via
server
cf-cache-status

第五步：模拟直接回源

curl -I http://源站IP -H "Host: www.example.com"

如果 HTTPS 回源：

curl -Ik https://源站IP -H "Host: www.example.com"

第六步：检查链路延迟和丢包

mtr -rw www.example.com

如果要测试源站：

mtr -rw 源站IP

这里要分清楚：

mtr 域名：测试的是 CDN 节点链路
mtr 源站IP：测试的是用户到源站链路

这两个结果不能混在一起判断。

十一、一个容易忽略的细节：CDN 加速的是访问，不是解析本身

DNS 解析只是告诉用户“应该访问哪个 IP”。
CDN 真正发挥作用的是用户连接到 CDN 节点之后，由 CDN 节点处理缓存、调度和回源。

所以访问慢可能有三类原因：

DNS 调度慢：解析到了不合适的 CDN 节点
CDN 节点慢：节点负载高或线路绕路
源站慢：CDN 回源慢、程序慢、数据库慢

排查时一定要分层看：

DNS 层：dig / nslookup
链路层：ping / mtr
HTTP 层：curl -I
源站层：Nginx日志 / PHP日志 / 数据库慢查询

只看一个 ping，很难判断真正问题。

结语

用了 CDN 后，域名访问到哪里，不能只靠感觉判断。正确的理解是：用户先访问 CDN 节点，CDN 再根据缓存情况决定是否回源。DNS 解析链路中，CNAME、CDN 调度、节点 IP、源站回源地址，每一层都可能影响最终访问效果。

对于企业官网、跨境电商、下载站和图片站来说，CDN 能提升访问体验，但源站服务器依然是核心基础。合理的做法是：CDN 负责加速和抗压，香港 CN2 / BGP 源站负责稳定回源和业务处理，再通过 DNS、HTTP 响应头、回源测试和日志分析，把访问链路真正看清楚。