IP、域名、DNS、CDN：一条链路搞懂网络访问与故障排查

IP、域名、DNS、CDN这四个概念到底在解决什么问题做网站开发、网络运维或者刚入门云计算的朋友迟早要跟这四个词打交道IP、域名、DNS、CDN。我面试过不少年轻人问起单个概念都能说个大概但一落到实际场景里——比如为什么我ping域名通、ping IP不通为啥配了CDN反而打不开网页了——就开始犯迷糊。原因很简单这四个词从来不是孤立的知识点它们是一条完整的链路用户输入一个域名到最终看到网页内容中间经历了域名→DNS→IP→CDN→源站这一整条流水线。这篇文章我想把这四个概念串起来讲清楚不堆术语用实际操作和排查案例来说话。适合刚接触网络基础的前端、后端开发也适合被域名解析CDN加速搞到头大的运维新手。看完你至少能明白自己买的域名到底是怎么生效的、网站突然打不开该往哪个环节查、接CDN前后流量路径发生了什么变化。1. 先从一张生活化的图景说起这四个东西各管哪一段很多人把IP、域名、DNS、CDN当四个独立知识点去背这是最大的误区。它们其实是同一件事的不同环节。我习惯用一个寄快递的类比来理解整条链路。1.1 IP地址快递包裹上的实际收货地址IP地址IPv4像114.114.114.114IPv6像2400:da00::6666是网络设备的唯一标识是数据包真正投递的依据。比如你的服务器IP是1.2.3.4那所有发给你的数据包在物理网络层面上都是奔着这个地址去的。路由器不关心你的服务器叫什么名字只看目标IP。这里有个关键认知IP地址是给机器看的。机器之间的通信、路由器的转发、防火墙的过滤策略全部基于IP。所以telnet IP 端口 命令怎么看通不通这类问题本质上就是在问从我这台机器到目标IP的某个端口物理路径上是否可达。这是最底层的网络连通性测试。1.2 域名人类能记住的名字谁会去记一串61.135.169.125没人。但www.baidu.com人人都能记。域名就是给IP地址起的一个易读别名。互联网的域名系统是一棵倒挂的树根域 → 顶级域.com、.cn→ 二级域baidu.com→ 子域名www.baidu.com、api.baidu.com。域名本身不承载任何数据传输功能它纯粹是一个人类接口。但正是这个别名机制让网站可以随意换IP而不影响用户访问——用户始终记域名背后的IP换了用户无感知。1.3 DNS把名字翻译成地址的分布式电话簿DNSDomain Name System解决的问题是当用户在浏览器输入example.com时系统怎么知道该连哪个IP答案就是查DNS。它像一个巨大的、全球分布的电话簿里面存着无数条域名 → IP的映射记录。DNS是个被严重低估的环节。很多网页打不开的故障根源根本不在服务器而在DNS解析这一环解析超时、解析到错误IP、本地缓存污染、DNS服务器响应慢……后面我会专门讲排查方法。1.4 CDN在你附近提前开好的货物分仓CDNContent Delivery Network内容分发网络解决的是距离问题。服务器在A城用户在Z城数据包要穿越半个国家延迟和丢包都不可控。CDN的思路是在全国乃至全球部署大量边缘节点把网站的静态资源图片、CSS、JS、视频提前缓存到离用户最近的节点上。用户访问时请求被调度到最近的节点而不是直连源站。一句话总结四者的关系域名是入口DNS是翻译官IP是真实坐标CDN是加速器。没有CDN用户直连IP也能访问有了CDN用户先经过DNS解析到CDN节点再由节点回源站拉取内容。2. 动手验证用命令行把这条链路摸一遍概念讲再多不如敲几条命令。下面这套操作我在排查网络问题时几乎天天用建议你也照着跑一遍。2.1 查看本机IP和网络状态Windows下用ipconfigLinux/macOS用ip addr或ifconfig。我常用的是# Linux 查看本机所有网卡IP ip addr # 查看默认网关 ip route # Windows 下查看IP和网关 ipconfig /all这里注意区分两个IP内网IP比如192.168.1.100和公网IP。服务器上的内网IP是私网地址外部无法直接访问公网IP才是对外服务的地址。很多新手在阿里云、腾讯云买了一台云服务器发现配置了内网IP但外网访问不了——因为云厂商的安全组和公网IP映射没配好。2.2 用nslookup和dig验证DNS解析nslookup是Windows自带的DNS查询工具dig是Linux上更强大的查询工具。# 查询域名的A记录 nslookup www.example.com # 指定DNS服务器查询重点 nslookup www.example.com 8.8.8.8 # Linux下用dig能看完整的解析过程 dig www.example.com跑完你会在输出里看到一行Address: xx.xx.xx.xx这就是该域名当前解析到的IP。当我怀疑是不是DNS解析有问题时会同时用系统默认DNS和公共DNS如223.5.5.5阿里、119.29.29.29腾讯对同一域名做查询。如果两个结果不一致说明要么是不同DNS服务器之间的同步延迟要么是你本地DNS缓存了旧的记录。2.3 用telnet和curl测试端口连通性telnet ip 端口 命令怎么看通不通这类搜索很常见。简单说telnet能连上目标端口说明网络路径通、端口在监听连不上则说明有防火墙拦截或服务没启动。# 测试TCP端口是否可达 telnet 1.2.3.4 80如果黑屏或者显示Connected to 1.2.3.4那就是通的如果提示Unable to connect就是不通。现代Windows系统默认没装telnet客户端可以在启用或关闭Windows功能里勾选Telnet Client或者直接用Test-NetConnection# PowerShell 下更现代的方式 Test-NetConnection 1.2.3.4 -Port 443curl则更进一步能直接测试HTTP服务# 测试HTTP服务是否正常 curl -I http://www.example.com # 指定host测试绕过DNS解析后面排查用得到 curl -H Host: www.example.com http://1.2.3.4第二个命令很实用当你怀疑DNS解析有问题时可以直接把请求打到某个IP并通过Host头告诉服务器你要访问的域名看服务器是否正常响应。2.4 追踪数据包路径tracert和mtr# Windows下看数据包经过哪些节点 tracert www.example.com # Linux/macOS下更推荐mtr能连续探测丢包率 mtr -r www.example.comtracert会展示从你本机到目标IP经过的每一跳路由。哪一跳超时、哪一跳延迟突然飙升一目了然。如果前几跳正常、到了某一跳开始丢包严重问题基本就出在那个节点所在的网络段——可能是运营商骨干网拥塞也可能是对方机房防火墙策略限制ICMP。3. 实战从零配置一个带CDN的网站清楚链路和工作原理之后我们来走一个完整流程域名购买 → 解析配置 → 服务器部署 → 接入CDN。这套组合拳是现在中小站点最常见的部署形态。3.1 域名解析记录怎么选A记录、CNAME、还是NS域名解析记录有很多种日常用得最多的是A记录和CNAME。我做过一个小项目域名挂在阿里云服务器用的也是阿里云ECS当时图省事直接配了A记录主域名和www都指向ECS的公网IP。A记录最直接你把域名解析到IP后DNS查询结果里就是那一串IP没有中间环节。但如果你的域名要通过CDN或者你的服务器IP经常变比如用了弹性IP或者做了高可用切换用CNAME更合适。CNAME是把你的域名别名到另一个域名上比如www.example.comCNAME到www.example.com.cdn.dnsv1.com然后由CDN平台去管理这个域名实际指向哪些边缘节点IP。好处是CDN厂商调整节点、故障转移的时候你的域名解析结果会自动跟着变不用手动改。坏处是CNAME不适用于主域名裸域的某些场景比如你不想因为CDN切换而影响邮箱服务的MX记录解析。还有几个常用记录类型MX记录用于邮箱服务指定邮件服务器TXT记录常用于域名所有权验证和SPF邮件防伪NS记录是把子域名的解析权托管给其他DNS服务器。3.2 解析配置实操以阿里云为例流程很简单控制台 → 云解析DNS → 添加域名 → 添加记录。记录类型A 主机记录www 解析线路默认 记录值1.2.3.4你的服务器公网IP TTL600TTLTime to Live是个容易被忽略的参数。它告诉各地的DNS缓存服务器和本地电脑这条解析记录可以缓存多久秒。开发调试阶段我会把TTL调低到60秒甚至10秒方便改了立刻生效稳定运行后再调回600或3600减轻DNS服务器压力。注意TTL设得再低也要考虑运营商Local DNS的强制缓存策略——有的运营商根本不理会这么短的TTL这就是为什么你改了解析总有人说还是老IP。配置完之后可以用dig 223.5.5.5 www.example.com验证是否生效。注意用公共DNS查询时如果返回的还是旧IP可能是公共DNS的缓存还没过期等几分钟重试即可。3.3 接入CDN以七牛云和常规CDN平台为例接入CDN前必须想清楚一个核心问题哪些内容走CDN哪些必须回源以我经手的一个图片站为例源站在一台2核4G的小ECS上图片量多、体积大带宽经常打满。接入CDN后流程是这样的在CDN控制台添加加速域名比如img.example.com源站配置写你的服务器IP和端口比如1.2.3.4:80CDN平台会给你一个CNAME地址类似img.example.com.w.cdngslb.com回到域名解析控制台把img.example.com的记录类型从A改成CNAME指向第3步的地址在CDN后台配置缓存策略——比如图片缓存30天、HTML不缓存、API接口不缓存等待CNAME生效dig img.example.com能看到结果指向CDN域名就算生效。这里有个最常见的翻车点用户源站是HTTP但网站开启了HTTPSCDN回源协议没配好导致页面加载时浏览器报混合内容错误。我的建议是源站如果支持HTTPS回源协议就选HTTPS如果源站没配证书就选HTTP回源同时CDN节点到用户这段用HTTPS这样用户侧是加密的源站到CDN这段内网传输风险可控——不过涉及登录、支付这类敏感接口强烈建议源站也上HTTPS别图省事。3.4 CDN缓存策略怎么定命中率是命脉CDN接入后的核心指标是缓存命中率。命中率高意味着大部分请求由边缘节点直接响应回源压力小命中率低说明你的缓存策略有问题CDN反而成了中转站速度没快多少还多了一层开销。我踩过的坑是设缓存规则时把动态接口也缓存了。当时有一个/api/user/info接口我图省事给它设了5分钟缓存结果用户修改头像后5分钟内看到的还是老头像排查了大半天才发现是缓存问题。我的经验是分三类处理内容类型典型路径缓存策略静态资源/static/, /images/, *.js, *.css缓存30天带版本号或hash的文件名页面文档/index.html缓存5-10分钟或配置协商缓存动态接口/api/*默认不缓存或极短缓存≤60秒另外云厂商CDN通常支持忽略URL参数开关。如果你的静态资源URL带?v123这样的版本参数开启忽略参数可以大幅提高缓存命中率但如果你的URL参数会影响内容比如图片水印参数?watermark1就绝不能忽略否则会出现所有人看同一张图的事故。4. 高频故障排查从零散的打不开到准确的定位网络和部署类的故障最忌瞎猜。我总结了一套自下而上的排查顺序有效率能提高八成先看链路通不通IP层再看域名解析对不对DNS层最后看应用层HTTP/HTTPS是否正常。每个环节都有对应的验证命令。4.1 DNS解析类故障解析失败、解析慢、解析到错误IP解析失败的典型表现是浏览器报找不到服务器IP地址。先nslookup 域名 223.5.5.5指定公共DNS查询如果公共DNS能解析出来但你本机不行问题大概率出在本地DNS缓存或你配置的DNS服务器上。清缓存的方法# Windows ipconfig /flushdns # macOS sudo killall -HUP mDNSResponder # Linux取决于用的什么DNS服务 sudo systemctl restart systemd-resolved解析慢的排查方向有两个一是你配置的DNS服务器本身响应慢比如某些公共DNS在特定网络环境下时延很高换成运营商默认DNS反而更快二是域名所在的权威DNS服务器响应慢甚至可以dig trace 域名看每一步的耗时能精确到哪一级DNS拖了后腿。解析到错误IP的场景多见于DNS劫持或缓存污染。判断方法是用不同DNS服务器解析同一个域名如果结果差异巨大且其中一个结果是明显异常的IP比如来自境外那基本就是本地网络被污染了这也是很多开发者把内网DNS服务器换成阿里223.5.5.5或腾讯119.29.29.29的原因——这两个在国内公共DNS里相对稳定、抗污染能力强。4.2 域名与端口访问类故障通了IP却打不开域名IP能ping通域名打不开是新手最常问的问题之一。这里要先分清ping通只代表ICMP协议层可达不代表80/443端口可达。我排过很多次这类故障套路基本是先telnet 服务器IP 80确认端口通不通端口通了再curl -H Host: 域名 http://服务器IP绕开DNS直接测应用层如果第二步正常说明服务器和网站都没问题问题出在域名解析或云厂商安全组放行策略上如果端口都不通检查云服务器安全组入方向规则、服务器本机防火墙iptables、firewalld、ufw、以及服务监听地址——重点服务是否只监听了127.0.0.1。比如Nginx配置了listen 127.0.0.1:80外部自然无法访问改成listen 80或者0.0.0.0:80才行。Apache配置域名无法访问是另一个常见问题。新手容易漏掉虚拟主机配置里的ServerName和VirtualHost *:80的匹配逻辑。如果多个虚拟主机配置有冲突Apache会按第一个匹配的默认站点响应你的域名自然指向了错误的站点。排查时先apachectl -S看看虚拟主机的配置概览一眼就能看出哪些域名对应哪个目录。4.3 CDN接入后的独特问题回源失败、缓存不刷新、跨域CDN接入后故障排查多了一层回源逻辑。下面几个是我遇到最多的回源失败用户访问报502/504通常是CDN节点无法从源站拉取内容。原因可能源站防火墙只放行了某个IP但CDN回源用的是节点IP池IP段很多没放行完整段或源站配置了HTTPS而CDN回源协议仍选HTTP导致源站301跳转或源站服务监听端口与CDN回源端口不一致。缓存不刷新网站改版了但用户看到的还是旧页面。这是CDN缓存策略的锅。紧急处理方法在CDN控制台刷新缓存——按URL刷新精确到文件或按目录刷新整目录全站刷新会有些平台不支持或成本很高。根治方法是给静态资源文件名加版本号或hash让新文件名成为新的缓存对象老文件等它自然过期。跨域失败域名接入CDN后Origin头在回源时被CDN改写或透传策略不当导致源站的CORS配置失效。排查时用curl -H Origin: https://你的域名 -I https://域名/资源看响应头里Access-Control-Allow-Origin是否符合预期。CDN平台一般有回源HTTP头和自定义HTTP头配置可以在CDN侧把源站需要的Origin头固定放行。4.4 开发场景里的域名问题在开发阶段域名问题同样烦人。比如uniapp 封装h5如何指向2个域名这类问题本质是环境配置多环境管理的问题。我建议的做法是在config目录下区分dev、test、prod三套环境通过环境变量切换API域名而不是在代码里写死域名。打包时传入--mode参数构建脚本读取对应环境的域名配置这样一套代码可以指向任意多个域名且不会把测试环境的域名误带到生产。还有一个常见的授权场景域名授权系统。很多开源建站程序、PHP系统需要通过域名验证来限制使用范围。这类系统的核心逻辑就是获取访问者的Host头与授权列表比对。这里容易踩的坑是用户通过IP直接访问系统时Host头是IP而不是域名授权校验会误判或者服务器反代以后Host头被改写导致授权不通过。解决方法是让平台支持IP白名单域名白名单双模式反代场景下确保Host头透传或通过X-Forwarded-Host传递原始域名。4.5 一张排查思路速查表症状优先排查环节常用命令/工具域名打不开、ping域名不通DNS解析nslookup、dig、ipconfig /flushdns域名能解析、IP能ping通但网页打不开端口/防火墙/Web服务telnet IP 80、curl -IIP和端口都通但页面响应慢链路质量/回源/Cachetracert、mtr、CDN命中率报表网页能打开但样式图片全破CDN缓存/静态资源路径浏览器F12看资源加载、curl -I改了解析一直不生效本地DNS缓存/运营商缓存换DNS验证、清缓存、检查TTL接了CDN后偶尔报错CDN回源/源站防火墙CDN日志、回源Host配置、源站访问日志5. 一些容易被忽略的经验细节最后分享几个实战中沉淀下来的小经验不算系统知识但关键时刻能救命。第一改DNS和改解析前先备份当前配置。别笑我真见过同事在生产环境把/etc/resolv.conf改坏了导致整个服务器无法解析域名而systemd-resolved和NetworkManager对resolv.conf的托管机制在不同Linux发行版上还不一样。改之前先cp /etc/resolv.conf /etc/resolv.conf.bak改完确认systemd-resolve --status或者直接ping www.baidu.com验证。云上Linux改DNS后重启网络还容易遇到云平台自己重置DNS的情况——因为DHCP获取的DNS会覆盖你手动改的配置需要区分静态配置和DHCP下发的优先级。第二静态资源和动态接口一定要走不同的域名。哪怕你只有一个域名和一个服务器也建议这样划分主域名example.com放业务页面static.example.com走CDN放静态资源api.example.com专门放接口。这样做至少有四个好处浏览器对同一域名的并发连接数有限分域名可以利用并发提升加载速度静态资源可以单独设置更强的缓存策略出现问题时可以独立降级比如只关CDN域名而业务不受影响微信小程序、App的接口授权通常需要单独的域名白名单分开配置更方便。第三测试环境尽量少用局域网IP写死在代码里。NAS IP、Port err(2)这类报错我见得太多都是本地调试时把IP地址写死在代码或连接串里换网络环境后要么不通、要么端口对不上。正确做法是开发环境通过.env文件管理所有连接参数localhost和局域网IP分开配置连接失败时优先检查IP有没有变、端口有没有被占用、服务有没有绑定到非127.0.0.1地址。第四善用CDN回源日志去验证用户到底看到了什么。CDN控制台每天会生成海量的访问日志包含请求URL、状态码、命中缓存还是回源、回源耗时、客户端IP等字段。遇到用户反馈图片很模糊/很旧的问题直接搜对应URL的日志看状态码是不是HIT命中缓存。如果是HIT把缓存刷新策略调整好就解决了如果是MISS说明缓存策略没覆盖到这类请求得去优化缓存规则。说到底IP、域名、DNS、CDN这四个概念并不是什么高深理论它们就是一条为用户最快最稳地获取内容而设计的工程链路。理解它们的最佳方式不是背定义而是亲手部署一次网站、接一次CDN、排查一次故障。把这条链路摸透了以后不管遇到什么奇奇怪怪的网络问题你都能顺着链路一段一段地排查下去而不是靠猜。