CDN节点怎么查？查看域名节点IP和地区的方法

查一个域名的CDN节点，可以先用在线工具查看不同地区的响应IP，再用DNS查询或浏览器核对具体地址。想知道节点在哪里，还需要结合IP归属信息和厂商线索判断。

这件事最容易让人犯嘀咕的地方，是几份结果看起来对不上：电脑查到一个IP，手机换成移动网络又是另一个；测速页面写着广州，IP查询却显示上海。

刚接入CDN时，看到这些差异，难免担心是不是配置错了。先别忙着改解析。把“从哪里发起测试”和“请求连到了哪里”分清，很多疑问就能解释了。

下面从最容易操作的方法开始。不熟悉命令行，也可以完成前面的查询。

先确定你要查的是哪个域名。

假设你的网站首页能打开，图片却加载很慢。这时只查首页域名，可能找不到问题。

一个网站里的资源，可以分别走不同的域名：

这些是演示域名，操作时换成你实际使用的域名。

如果拿到的是一条完整图片链接，例如 https://img.example.com/images/banner.jpg，做域名检测时先查 img.example.com。排查这张图片的具体响应时，再用浏览器查看完整URL。

另外，example.com和www.example.com也要分开看。它们可能配置了不同的解析，其中一个还可能跳转到另一个。

查对对象，往往比多换几个工具更管用。

不想敲命令，可以先在线查一遍。

打开CDNChart的CDN检测工具，输入刚才确认的域名，点击“开始识别”。

这个步骤主要用来了解网站疑似接入了哪家CDN，以及判断依据是什么。页面会结合CNAME链、HTTP响应头等信号给出线索。读结果时，留意结论中的“疑似”和证据强弱，不要只记下一个厂商名字就结束。

接着打开网站测速与多地区访问测试，输入同一个域名，选择需要检查的运营商类别并发起测试。国内用户为主，可以先看电信、联通、移动；有海外用户，再结合相应监测点的结果。

如果页面仍显示“模拟预览”，先提交你的域名，等本次任务返回结果后再看数据。预览里的IP和耗时不能当作你的网站报告。

在结果表里，先读懂下面几列：

比如，一条记录的监测点是“广东广州”，IP位置显示“上海”。这两个字段可以同时成立：请求从广州发出，报告把响应地址标注在上海。

看节点分布时，把同一轮测试中的响应IP放在一起比较，记录哪些地区、哪些运营商出现了不同地址。这样得到的是本次测试条件下观测到的一组地址。

它不能直接换算成厂商的机房数量。同一个节点可能使用多个IP，多个地区也可能共用同一个对外IP。没有测到某个地区的地址，也不能据此认定厂商在那里没有节点。

想核对本地结果，再查一下DNS。

如果你关心“我这台电脑现在查到什么地址”，系统工具就够用了。

Windows用户可以打开命令提示符，分别执行：

nslookup -type=A www.example.com
nslookup -type=AAAA www.example.com
nslookup -type=CNAME www.example.com

A查IPv4地址，AAAA查IPv6地址，CNAME查别名记录。把示例域名替换成你的目标域名。

nslookup输出顶部通常先显示回答查询的DNS服务器。那是帮你查询的服务器，不是你要找的网站节点。 要看的是后面目标域名对应的回答部分。参数用法可以参考微软的nslookup文档。

macOS或安装了dig的Linux环境，可以执行：

dig www.example.com A +noall +answer
dig www.example.com AAAA +noall +answer
dig www.example.com CNAME +noall +answer

下面是一段演示输出，并非真实域名或CDNChart的实测结果。其中IP使用文档示例地址：

www.example.com.       300  IN  CNAME  edge.example.net.
edge.example.net.       60  IN  A      198.51.100.10
edge.example.net.       60  IN  A      198.51.100.11

这段结果表示：查询返回了一个别名目标，并列出两个IPv4地址。数字300、60是回答中的TTL值，单位是秒，不是延迟。它们可能反映递归DNS缓存中剩余的有效时间。

这里拿到的是DNS回答里的地址列表。浏览器后续选择哪个地址、是否发生跳转，还要继续看实际请求。dig官方手册对查询类型和输出选项有更完整的说明。

有时CNAME查询没有返回内容，也别急着判定“没用CDN”。例如Cloudflare的代理和CNAME扁平化机制，就可能让公开查询直接返回地址记录。Cloudflare的代理状态说明解释了这种行为。

反过来，有CNAME也只能说明存在别名关系，不能仅凭这一条记录确认CDN服务商。需要进一步判断厂商时，可以结合CDN服务商检测中的CNAME、响应头与网络证据一起核对。

浏览器实际连到哪个IP，可以直接看请求。

如果你已经能打开网站，Chrome开发者工具是很直观的检查入口：

1. 打开目标页面，按F12，或从浏览器菜单进入开发者工具。
   

2. 切换到“Network／网络”面板，刷新页面。
   

3. 点击要检查的请求：看首页就选主文档，看图片就选那张图片。
   

4. 在“Headers／标头”的基本信息中查看“Request URL／请求网址”和“Remote Address／远程地址”。
   

远程地址记录的是这次请求的对端IP和端口。例如演示值198.51.100.10:443，前面是IP，后面是端口。Chrome也支持在请求列表中显示Remote address列，便于逐条对照。查看Chrome网络面板说明。

如果资源直接来自浏览器缓存，可能没有新建网络连接。可以在开发者工具打开期间勾选“Disable cache／停用缓存”，再刷新检查。这个选项停用的是浏览器缓存，CDN边缘缓存仍可能参与响应。

网站有跳转时，关注最终页面对应的请求。首页、跳转页、图片请求可能连接不同地址，不能随手点一条请求就把它当成整个网站的节点。

熟悉终端的话，也可以用curl查看。下面的命令适用于macOS、Linux，输出最终请求网址、最近一次连接的对端IP和HTTP状态：

curl -sS -L --max-redirs 5 --connect-timeout 10 --max-time 20 \
  -o /dev/null \
  -w 'url=%{url_effective}\nremote_ip=%{remote_ip}\nhttp_code=%{http_code}\n' \
  'https://www.example.com/'

-L会跟随跳转，所以发生跳转后，要把输出的url和remote_ip一起看。Windows命令行可使用curl.exe，把输出文件/dev/null改为NUL，并将命令写成一行。变量含义见curl官方文档。

如果设备使用了代理或VPN，先确认当前出口。代理连接可能改变你观察到的对端地址，不能把这种结果直接当作普通用户的直连结果。

到这里，你已经能分别回答两件事：DNS给了哪些地址，以及某一次请求实际连到了哪里。

拿到IP以后，地区还需要再核对一步。

可以把IP复制到MaxMind GeoIP查询中，查看其地区、网络及组织信息。对照CDNChart结果时，记录两边的标注；遇到不一致，先保留差异，不必急着选一个当作绝对正确。

IP地理位置数据库提供的是位置估计。更新时差、地址使用方式等因素都可能影响结果；有些结果还会给出精度范围。因此，看到城市名，并不意味着已经确认了那台服务器的物理机房。

Anycast尤其容易让人误会：同一个对外IP，可以在不同网络条件下把请求引向不同地点。 所以“全国查到同一个IP”和“全国都访问同一个机房”不能直接画等号。可以参阅Cloudflare对Anycast的解释。

MaxMind的演示页也提示，Anycast网络没有固定地理位置，可能不提供相应位置数据。遇到地区空白，保留“无法据此确定”比硬填一个城市更可靠。

如果厂商提供节点标识、请求日志或诊断信息，再结合官方说明进一步核验。IP库显示的组织名称或ASN，也只是网络归属线索，未必就是你购买CDN服务时看到的品牌名称。

几种常见结果，可以这样往下查。

手机和电脑查到不同IP，先确认它们是不是同一张网络。手机走移动数据、电脑走家庭宽带，本来就可能得到不同解析；IPv4和IPv6、DNS缓存或代理设置也值得一起检查。

如果要排除网络差异，可以先让两台设备连接同一Wi-Fi，在接近的时间查询同一个完整域名，再记录结果。

换了公共DNS，IP也跟着变了，可以把解析器作为一项对照条件。但在同一台电脑上分别查询两个公共DNS，得到的仍然是两个解析服务的回答，不能当作已经完成了两个城市的真实访问测试。判断地区差异，还需要相应地区的实际探测。

查到了多个IP，却仍不确定CDN有没有生效，就继续核对厂商接入状态和请求证据。负载均衡也可能返回多个地址；“多个IP”这一个现象，不足以单独确认CDN。

如果只查到一个IP，同样不能直接认定没有CDN。一次查询的范围很有限，再结合代理状态、响应证据和多地区观测判断。

至于“IP归属地看着很近，为什么访问还慢”，需要回到具体请求。地域距离之外，连接建立、缓存是否命中、回源处理和资源大小都会影响耗时。把节点地址和测速结果一起看，才有机会找到慢的环节。

这些检查不需要一次全做。先抓住你真正遇到的现象，再选择对应步骤，排查会轻松很多。

把结果记下来，下一次查询才有比较的意义。

如果你正在排查用户反馈，建议至少保存这些信息：查询时间和时区、完整域名、探测地区、运营商、响应IP、访问状态。涉及图片或接口，再补上具体URL。

比如“网站很慢”，很难让技术人员继续查；换成“某天20:15，北京联通访问这张图片，连接到某个IP，连续几次都在连接阶段耗时较高”，就有了可以核对的线索。

比较两次结果时，尽量保持目标资源和测试条件一致；失败记录也要留下。关于采样条件和数据解读，可以查看CDNChart测评方法。

查节点的价值，就在这里：把一句模糊的“好像不对”，变成能够继续定位的问题。

现在可以拿你的网站域名先查一遍：确认接入线索，再看不同地区的响应IP，最后核对自己的浏览器请求。等这几份信息放到一起，哪些差异正常、哪些值得继续排查，通常就清楚多了。