DNS 是互联网中不可或缺的基础服务，而用户在访问网站时看到的加载速度、解析正确率、甚至是 CDN 调度效果，都与 DNS 缓存机制密切相关。很多站长会遇到解析修改后全网迟迟没有生效，或用户仍然访问到旧 IP 的问题，这背后正是 DNS 缓存刷新和 TTL 设置在发挥作用。理解缓存的产生、传播路径以及 TTL 的规则，才能在部署网站、调整服务器地址或进行迁移时，做到可控、稳定、低延迟。

　　DNS 解析的过程看似简单，输入域名、解析为 IP，但真正的幕后流程涉及根域名服务器、顶级域服务器、权威 DNS 服务器、本地递归 DNS 服务器以及浏览器、系统层级缓存。缓存存在于多个节点，任何一级没有更新都会导致解析结果不同步，因此刷新缓存并不是单一动作，而必须理解整体链路。

　　当用户访问某个域名时，首先会检查浏览器缓存，如果缓存未过期，直接返回，无需再去请求外部 DNS 服务器。其次是操作系统本地缓存，例如 Windows 中的 DNS Client Service，Linux 的 nscd 或 systemd-resolved，如果本级缓存已过期或不存在，才会向递归 DNS 服务器发送请求。递归服务器再逐级查找权威 DNS，获取结果后按 TTL 存储缓存，这样后续更多用户访问时速度更快。整个过程设计的核心就是减少重复查询，提高解析效率，降低权威 DNS 的查询压力。

　　缓存的存在意味着解析速度更快，但也带来同步延迟。当网站更换服务器或修改解析记录时，各层缓存可能仍保存旧 IP，导致部分用户访问异常。因此刷新 DNS 缓存，实际上是让不同层级尽快丢弃旧缓存，重新请求权威服务器。

　　TTL是 DNS 缓存有效期的关键参数，每条记录都有自己的 TTL 值，以秒为单位。TTL 越长，缓存生效时间越久，但解析更新越慢;TTL 越短，解析更新及时，但递归服务器请求次数增加，访问延迟略微上升，因此 TTL 的设定需要平衡“稳定”与“灵活”。默认 TTL 常见值为 3600 秒(1 小时)、14400 秒(4 小时)、86400 秒(1 天)等。如果网站不会频繁变更解析，设置较长 TTL 可以减少解析负载，提升访问效率。而在网站计划迁移或切换 CDN 时，建议提前数小时将 TTL 调小至 300 秒甚至 60 秒，确保切换期间用户解析能实时更新。

　　TTL 并不是立即生效的参数，它只影响从修改之后的新缓存周期，而不会让旧缓存立即失效。因此很多人以为调整 TTL 就能“立刻刷新全网解析”，这是误解。真正想要快速更新，需要提前降低 TTL，并等待旧缓存自然过期后再进行变更，否则依旧存在延迟传播现象。

　　当发现 DNS 解析未更新时，可以从多个层面进行缓存刷新。浏览器缓存可以通过清除浏览记录、隐身模式或快捷键触发刷新。操作系统层面的 DNS 缓存可通过命令清除，例如 Windows 使用 ipconfig /flushdns，MacOS 使用 sudo dscacheutil -flushcache 或结合 sudo killall -HUP mDNSResponder，Linux 则根据服务不同执行 systemd-resolve 或 nscd 重启。网络运营商 DNS 缓存无法主动清除，只能等待 TTL 超时。权威 DNS 服务器本身并不会缓存，因此修改配置后即时生效，但其他节点的缓存会有传播延迟。

　　导致缓存刷新无效或解析冲突的原因，通常与多个 DNS 服务并存相关。例如用户使用本地 hosts 文件修改解析，但浏览器仍使用 DNS over HTTPS 进行解析，导致返回结果不一致。或者站长修改 A 记录，却忘记删除旧的 AAAA 记录，导致 IPv6 用户仍访问旧服务器。同样，部分 CDN 平台有独立缓存策略，节点未同步也会出现目标 IP 不一致的情况。因此排查缓存不更新时，不能只盯着本地系统，还需确认递归 DNS 与 CDN 缓存状态。

　　理解 DNS 缓存的传播路径，可以让解析变更做到可控。例如网站需在凌晨切换服务器，可提前 24 小时将 TTL 调至 300 秒，并确认权威 DNS 修改后等待旧缓存自然过期。切换操作完成后，再将 TTL 调回 3600 秒或更高，保证稳定性。这样能避免访客访问旧 IP 导致“无法连接服务器”“证书错误”等问题，也避免了数据写入到旧机器造成业务分裂。

　　另外，TTL 并不是越短越好，尤其是高访问量网站，TTL 过低会让递归 DNS 频繁查询权威 DNS，若配置不当甚至可能导致 DNS 放大攻击或带宽浪费。一般业务推荐值如下：静态内容网站 24 小时，动态内容或偶尔变更业务 1 小时，跨机房调度类业务如 GSLB 10～300 秒。电商活动、业务大迁移等特殊时期再临时调整。

　　除了 TTL 之外，现代 DNS 还支持 CDN 分线路解析、区域自治 DNS、权威集群同步等机制，因此缓存更新也会涉及 DNS 服务商的刷新机制。有些 DNS 平台提供手动刷新全网缓存功能，用于覆盖递归节点缓存，但其原理大多是模拟大量递归请求触发覆盖，而非真正控制 ISP 缓存，因此并不绝对可靠。

　　如果用户访问仍然拿到旧 IP，也可能是运营商 DNS 劫持或递归服务器异常缓存，此时更换 DNS 解析服务器，例如切换至 8.8.8.8、1.1.1.1 或 223.5.5.5 等公共 DNS，可快速验证是否为 DNS 缓存问题。

　　对于跨境网站，还需注意国际与国内解析缓存差异，有时中国运营商 DNS 和海外递归服务器缓存更新速度不同，导致访问行为不一致，必要时可使用全球 DNS 查询工具确认传播情况，例如 dig +trace、nslookup、或使用在线解析检测平台。

　　当明确理解缓存生效逻辑后，站长不仅可以正确安排解析变更，也能避免因为 TTL 设置错误导致业务故障，提升全局网络可控性。在实际运维中，DNS 不只是配置域名解析那么简单，而是一项需要策略规划、理解传播周期、并结合网络架构长期维护的基础服务。

　　常见问答：

　　问1：为什么修改 DNS 解析后，有些用户立刻生效，有些用户仍访问旧 IP?

　　答1：因为缓存存在于不同层级，每个节点的 TTL 剩余时间不同，部分用户本地、浏览器或运营商 DNS 仍在使用旧缓存，需要等待 TTL 超时后才会刷新。

　　问2：TTL 设为 0 是不是表示不缓存?

　　答2：不是所有节点都严格遵守 TTL=0，有些递归 DNS 会强制设置最短缓存周期，例如 60 秒，因此 TTL=0 不能保证全国立即同步，但确实能大幅缩短缓存时间。

　　问3：提前降低 TTL 后多久可以安全修改解析?

　　答3：至少等待旧 TTL 时间完全过期，例如原 TTL 为 86400 秒(1 天)，改成 300 秒也必须等待 24 小时后再修改解析，否则仍有用户持有旧缓存。

　　问4：如何判断 DNS 缓存是否真的刷新?

　　答4：可以使用 dig domain.com @dns_ip 指定不同 DNS 服务器查询，例如测试 8.8.8.8、1.1.1.1、本机 DNS、运营商 DNS，若返回 IP 一致，则缓存同步成功。

　　问5：浏览器和系统都清缓存了，但仍访问旧 IP 怎么办?

　　答5：可能是运营商 DNS 未更新，可尝试切换公共 DNS 或使用海外节点进行验证，也可能是 CDN 缓存导致，而非 DNS 缓存问题。

　　问6：网站迁移时 TTL 应该怎么设置?

　　答6：推荐流程：迁移前 24 小时降低 TTL -> 等待旧缓存过期 -> 执行迁移修改解析 -> 验证全网生效 -> 将 TTL 调回正常值。