为何DNS已不再指向CloudFront时，部分用户流量仍被路由到CloudFront？

为什么浏览器DNS缓存没有遵守记录的TTL设置 #

出现这个现象是多层缓存覆写导致的，没有遵守你设置的5分钟TTL属于行业普遍情况：

• 浏览器本身有硬编码的最小DNS缓存时长限制，大部分主流PC浏览器的最小缓存是1分钟，部分移动浏览器、运营商定制浏览器的最小缓存会被设置为1小时甚至更久，会直接忽略DNS返回的短TTL
• 运营商递归DNS服务器会强制覆写TTL，很多中小运营商为了降低跨网查询成本，会把所有DNS记录的返回TTL强制修改为至少1小时，无论你在Route53设置的TTL多短都不会生效
• 用户侧的系统级DNS缓存、家用路由器的DNS缓存也普遍存在强制兜底TTL的逻辑，部分老旧系统甚至会把DNS记录缓存24小时以上才主动过期

有没有方法可以强制所有用户的DNS缓存刷新 #

不存在可以覆盖所有用户的强制DNS缓存刷新方法。
DNS协议本身没有设计远端缓存主动刷新的标准机制，你只能控制你侧的权威DNS记录，无法干预用户端浏览器、系统、运营商递归节点的已缓存内容。少数云服务商提供的DNS缓存刷新服务，也只能清理他们自身网络内的递归节点缓存，无法覆盖全网所有用户的设备和运营商节点。

有没有更优的方案来实现流量是否走CloudFront的切换 #

有几个成熟的方案可以完全规避DNS缓存的影响，切换速度和可控性都远高于直接修改DNS记录：

• 方案1：固定走CloudFront，仅切换回源配置
  不需要修改DNS，让域名的DNS记录一直指向CloudFront分发。需要流量跳转到源站时，直接修改CloudFront的源站配置为你的源站IP，同时把CloudFront的缓存TTL设置为0，此时CloudFront相当于透明七层转发，所有流量会直接透传给源站，配置修改后全球生效时间仅需要1-2分钟，完全没有DNS缓存问题。要切回CloudFront缓存模式时，改回原源站配置和缓存规则即可。
• 方案2：使用Route53加权路由切换
  不要直接在A记录和CNAME之间切换，而是为域名配置两条加权路由记录：一条指向CloudFront分发，一条指向源站IP。需要走CloudFront时将CloudFront记录的权重设为100%、源站权重设为0，需要切源站时调整权重即可，相比直接改记录的生效速度更快，也可以逐步调整权重观察流量变化，避免一次性切流出现故障。
• 方案3：应用层开关切流
  如果是Web业务，可以在前端代码里内置切流开关，定期拉取开关配置。需要切源站时，打开开关让前端直接把请求发到源站的独立域名（比如origin.yourdomain.com），这种方案可以做到秒级生效，不受任何DNS缓存影响，还支持按用户比例灰度切流，可控性最高。

内容的提问来源于stack exchange，提问作者Daniel