CDN和A记录：解析到底听谁的

解析记录里，A记录和CDN不是二选一的关系，也不是谁压谁一头。真正决定用户连到哪的，是DNS最后返回的那个地址。很多人把「加了CDN」当成开关，以为后台一开，全国访问就自动走边缘节点；可域名系统不看这个，它只认记录。你填A记录，它就把用户往那个IP送；你填CNAME，它才可能把请求交给CDN调度。cdn和a记录搅在一起的时候，先别急着骂CDN慢，先看解析到底回了什么。

cdn和a记录到底谁生效，得看DNS返回了哪个

DNS解析器是个很死板的东西。它不关心你买了多大的CDN套餐，也不认识「加速」俩字。用户输入域名，递归服务器查到哪条记录，就返回哪个地址。A记录是直接给IP，CNAME是把域名指到另一个域名上，让下一层继续查。CDN接入通常给你一个CNAME地址，你把域名解析到那个CNAME，CDN的调度系统才能按访问者的位置分配边缘节点。如果A记录还留着，而且记录集没清干净，某些请求就可能绕过CDN，直愣愣打到源站。不同DNS服务商对A记录和CNAME并存的限制不一样，有的直接报冲突，有的允许但行为要看控制台提示，以服务商页面说明为准。

A记录是门牌号，CDN是门口的前台

这么理解吧。A记录像门牌号，写死了你家在哪；CDN像小区门口的前台，先帮你收快递、分流、挡一部分闲杂人等。用户来找你，先到前台，前台再决定让他去哪个值班室，最后还是得回你家拿东西。回源那一步，CDN还是要通过源站IP或者源站域名找上门。所以不是有了CDN，A记录就彻底没用了；源站那边通常还需要一个能解析的地址，或者至少让CDN知道回哪去。只不过这个A记录最好藏在CDN后面，不要直接暴露给全网。

两个同时存在，最容易出什么乱象

常见的情况是网站一会儿走CDN，一会儿直连源站。用户感觉时快时慢，你在后台看日志，发现有些请求根本没经过CDN。还有更隐蔽的：源站换了IP，A记录改了，CDN那边的回源配置没跟着动，页面就开始报错。这时候你查CDN节点，节点是好的；查源站，源站也活着；问题卡在中间那层地址对不上。我见过有人把域名同时解析到CDN的CNAME和旧服务器的A记录，觉得「双保险」，结果一部分用户拿到旧IP，看到的是旧页面，缓存和数据库对不上，排查半天还以为中邪了。别这么干，解析记录不是买保险，多填一条不保平安，只会多一个出口。

切CDN那一步，顺序别弄反

比较稳妥的顺序是先把源站准备好，确认源站能正常访问、回源端口放行，再去CDN控制台添加域名、拿CNAME地址，最后去DNS里改解析。改的时候把原来的A记录停掉或者删掉，别留着当备胎。TTL别设太长，切换期间留一点缓冲。改完不是立刻全网生效，各地递归缓存不一样，有的快有的慢，这段时间看到两种结果很正常。要是切完发现CDN没流量，先查DNS返回的是CNAME还是A记录，别一头扎进CDN日志里。这个顺序听起来啰嗦，但能少踩很多坑。

源站IP露不露，跟A记录关系很大

A记录直接写源站IP，等于把门牌号贴在公网上。CDN本来能帮你挡一部分直接攻击和扫描，结果源站IP一暴露，对方绕开CDN打源站，清洗压力全回到你身上。所以接CDN之后，公网解析尽量走CNAME，源站IP只留在CDN回源配置和内部记录里。有人会问，那源站不要A记录怎么活？源站可以只对CDN的回源网段开放，或者用内网、专用线路回源，具体看服务商支持到什么程度。别为了图省事把源站IP挂在A记录上，还安慰自己「反正有CDN」。

出问题先查这三样

第一，看DNS解析结果，用dig或者nslookup查，最好多查几个地方，别只看本机。第二，看CDN控制台的回源地址和源站健康状态，确认它回源时找的是不是你现在的源站。第三，看源站防火墙和安全组，CDN回源过来的请求有没有被拦。顺序别乱，先解析后回源再源站，一层层往下排。很多时候不是CDN不行，也不是A记录坏了，是两层之间的地址没对齐。

真要记一句话：域名解析听DNS记录的，CDN调度听CNAME的，源站回源听CDN配置的。三件事各管各的，硬把它们拧成一股，出事就互相甩锅。改解析之前先把旧记录抄下来，改完过一阵再回头看，别刚切完就下结论。网站这玩意儿，稳不稳定往往就差在这种小地方。