明明后台已经改了 IP，为什么用户访问还是旧站点？因为缓存不止一层——TTL 没到期之前，谁都不会去权威服务器拿新答案。
DNS 缓存分浏览器、操作系统、路由器、递归解析器四层，每一层都会把查到的结果暂存一段时间，时长由记录的 TTL（生存时间，RFC 1035 定义的秒数字段）决定。你在权威后台改了 IP 之后，旧值仍会沿着这四层缓存继续被使用，直到各层缓存按旧 TTL 自然过期——所以"全球生效"最坏要等满一个 TTL（常见 600–86400 秒）。想立刻看到新值，清本机缓存（ipconfig /flushdns）+ 无痕窗口测试即可；但要让所有用户都切到新值，只能等缓存过期，或提前把 TTL 调小。
从浏览器到递归解析器，每一层都可能"自作主张"地记住旧结果
| 缓存层 | 谁在存 | 缓存内容 | 如何主动清掉 |
|---|---|---|---|
| ① 浏览器缓存 | Chrome / Firefox / Edge | 近期访问过的域名解析结果，配合 HOST 解析缓存 | 清浏览器缓存，或用无痕/隐私窗口测试 |
| ② 操作系统缓存 | Windows DNS Client、nscd、systemd-resolved、mDNSResponder | 本机最近解析结果，TTL 内重复使用 | Windows ipconfig /flushdns；macOS sudo dscacheutil -flushcache |
| ③ 路由器缓存 | 家里/公司的路由器（dnsmasq 等） | 全屋设备共享的解析结果 | 重启路由器，或登录后台手动刷新 |
| ④ 递归解析器缓存 | 运营商 DNS、公共 DNS（8.8.8.8 等）、自建解析器 | 大量用户共享的权威记录缓存，按 TTL 过期 | 普通用户无法清，只能等 TTL 到期；自建解析器可手动 flush |
关键认知：越靠上层（浏览器、系统），你越容易控制；越靠下层（公共递归解析器），你越无能为力。前两层你一条命令就能清，但全国/全球用户正在用的那台递归解析器，它缓存的旧结果你动不了——这就是为什么"我自己这边已经新了，别人还在访问旧站"。
TTL 由权威域名服务器写在每条记录里，所有下游缓存共同遵守
TTL（Time To Live，生存时间）是 DNS 响应报文中的一个字段，单位是秒，定义见 RFC 1035。它的含义非常直接：这条记录从权威服务器发出那一刻起，下游任何缓存——操作系统、递归解析器——最多可以把它缓存这么久；到期后缓存条目失效，下一次查询必须重新向权威服务器获取。
用 dig example.com 看输出，每条答案前都标着这个数字：
60–300 秒：临时值，用于即将做迁移/切流的场景，方便快速生效。600 秒（10 分钟）：很多 CDN/云解析的默认值，兼顾缓存与生效速度。3600 秒（1 小时）：常规网站常用，缓存命中率不错。86400 秒（24 小时）：稳定不变的记录（如 MX、NS）常用，最大化缓存收益。TTL 的取值范围是 0 到 2³¹−1 秒，但实践中很少用超过一天的值做业务解析；另外 RFC 2308 还规定了"否定缓存"（查不到的域名也按较短 TTL 缓存，避免权威服务器被反复查询打爆）。
因为"旧 TTL"是按旧值算的，你改记录这个动作本身不通知任何缓存
很多人误以为"我在后台点了保存，全世界立刻生效"。事实是：DNS 是拉取式系统——权威服务器不会主动告诉任何人"记录变了"。各级缓存只在自己的 TTL 到期后，才会重新来问。于是：
86400（24 小时）。更麻烦的是：TTL 是由当时的旧记录带下去的。你把 TTL 从 86400 改成 60，这个"新 TTL"只对"改完之后新查出来的记录"生效——在改之前就已被缓存的旧值，依然按它当初拿到的 86400 走完。这就是为什么老手都在迁移前提前 1–2 天先把 TTL 调小，等旧的大 TTL 缓存过期得差不多了，再去改记录值。
一个实用估算：最坏生效时间 ≈ 你改动前那一条记录的 TTL。举例：改之前 TTL 是 3600 秒，那么从你改记录算起，绝大多数用户在 1 小时内陆续切到新值；如果改之前 TTL 是 86400，就要预留 24 小时。想更准，就多等一个 TTL 再对外宣布"已切换完成"。
只影响你自己这台机器，但调试时立竿见影
操作顺序建议：①改完权威记录 → ②在自己机器上 flush 系统缓存 → ③浏览器用无痕窗口访问（绕过浏览器层缓存）→ ④若仍不对，用 dig @权威服务器域名 你的域名 直接向权威服务器查，绕开所有中间缓存，确认权威侧本身已改对。注意：这一整套只解决"你自己看到旧值"，其他用户与公共递归解析器的缓存仍按旧 TTL 走，急不得。
没有完美 TTL，只有当前阶段合适的 TTL
| 维度 | TTL 小（60–300 秒） | TTL 大（3600–86400 秒） |
|---|---|---|
| 改记录后生效速度 | 快，几分钟内全球陆续生效 | 慢，要等几小时到一天 |
| 缓存命中率 | 低，缓存很快过期，重复查询多 | 高，一次缓存用很久 |
| 权威服务器压力 | 大，更多请求落到权威侧 | 小，被缓存挡掉大部分查询 |
| 解析延迟 | 缓存未命中更多，体感略慢 | 命中多，体感更快 |
| 适合场景 | 即将迁移、切流、临时变更 | 稳定运行期、不常变的记录（MX/NS） |
标准工作流：平时 TTL 调大（享受缓存红利）→ 变更前 1–2 天先把 TTL 调小 → 等旧大 TTL 缓存过期得差不多 → 再改记录值 → 切换完成稳定后，再把 TTL 调回大值。这样既不牺牲平时的性能，又把切换窗口期压到最短。具体操作可参考 Cloudflare 关于 DNS 记录 TTL 的官方说明。
ipconfig /flushdns，Linux 用 systemd-resolved --flush-caches，macOS 用 sudo dscacheutil -flushcache。再强制浏览器刷新（Ctrl+F5）或开无痕窗口测试。注意：这只清你自己机器，递归解析器和其他用户的缓存仍然按旧 TTL 走。