Cloudflare/Chrome DNS缓存TTL异常：旧CNAME记录未更新如何解决

当前故障和Cloudflare的DNS TTL配置、CDN缓存清理操作没有直接关联，核心原因是Chrome本地持久化存储的两类缓存未自动失效，Cloudflare的Purge Cache操作仅能清理边缘节点的静态资源缓存，完全无法触达用户端浏览器的本地存储：

• Chrome内置的DNS缓存并不会严格遵循权威DNS返回的TTL值，历史解析记录在部分场景下会做1小时到7天不等的持久化留存，如果之前旧CNAME指向的第三方域名返回过超长TTL的解析结果，缓存留存周期还会进一步拉长
• 占比最高的故障诱因是永久重定向本地缓存：开发阶段旧CNAME指向的第三方站点大概率配置了301 Moved Permanently响应规则，Chrome会将这类重定向直接持久化存储在本地，请求发起时优先读取本地重定向规则，甚至不会发起新的DNS解析请求，这也是用户手动清理浏览器缓存后即可恢复正常访问的核心原因——清理操作同时删掉了本地存的DNS记录和重定向规则。

即时修复方案（无需等待用户缓存自然过期） #

第一时间在旧CNAME指向的第三方开发服务器上配置规则：

• 将所有携带你业务域名Host头的请求，全部反向代理到新站点正式服务器，直接返回新站点的正常业务内容，不要返回任何3xx类跳转响应
• 给所有这类响应加上强制禁用缓存的响应头，配置参考：

Cache-Control: no-store, no-cache, must-revalidate, max-age=0
Pragma: no-cache
Expires: 0

这套配置上线后，即使本地留存旧缓存的用户请求打到旧开发服务器，也能正常拿到新站点内容，不会出现跳转到旧域名的问题，等用户本地缓存自然过期后，请求就会自动切到新的正式服务器地址。

长期兜底配置，规避同类问题复发 #

• 站点正式上线后，非绝对必要不要使用301永久重定向，常规业务跳转优先使用302临时重定向，Chrome不会对302跳转做长期本地缓存
• 新站点服务上线后的前7天，可以在根路径响应中添加Clear-Site-Data: "cache", "storage", "executionContexts"响应头，用户首次访问到新站点时，浏览器会自动清理该域名下存储的所有本地缓存、重定向规则、旧DNS记录，该响应头无需长期保留，等存量用户缓存基本过期后即可移除
• 后续开发阶段如果需要将生产域名CNAME指向测试环境，务必给测试环境的所有响应加上no-store缓存头，避免测试环境的重定向、响应内容被用户浏览器持久化存储。

注意：不要尝试通过缩短DNS记录TTL的方式强制客户端刷新缓存，现代浏览器的本地缓存机制不会对已存在的缓存记录主动做TTL校验，即使把TTL改成1分钟，已经存了旧记录的浏览器也不会主动发起新的解析请求。

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