DNS TTL 到期为何仍是旧地址？分清权威记录与本地缓存
DNS 记录已经改成新地址，电脑却仍访问旧入口，很多人会把它归因于机场节点或“DNS 污染”。实际上，TTL 只规定递归解析器可以缓存记录多久，浏览器、操作系统、家庭路由器和代理客户端还可能各自保留缓存。先确认答案来自哪一层，再决定是否需要清理。
TTL 控制的是哪段缓存
Cloudflare 的文档说明，TTL 是 DNS 记录上的字段，用来控制记录被缓存的时间；TTL 越长，缓存命中通常越多，但记录更新传到用户侧也会更慢。文档还提醒，即使某类记录的 TTL 是五分钟，本地 DNS 缓存也可能让实际体验变化得更晚。
这意味着“权威服务器已更新”和“你的应用已经看到新地址”是两个不同状态。旧答案可能来自递归解析器、系统缓存、浏览器安全 DNS 缓存、路由器转发缓存，或代理客户端的 DNS 模块。
用分层查询找出旧答案
先查询系统当前使用的 DNS，记录返回地址与 TTL。再向一个明确的递归解析器查询，最后查询权威服务器。Windows 可用 Resolve-DnsName，常见系统也可用 nslookup 或 dig。
示例思路：
dig example.com A
dig @1.1.1.1 example.com A
dig @权威服务器 example.com A
不要只比较 IP，还要记录查询时间、记录类型和响应中的 TTL。A 与 AAAA 是两套记录；看到 IPv4 已更新，不代表 IPv6 也更新。
什么时候该清缓存
如果权威答案已是新地址，而系统查询仍返回旧地址，等待原 TTL 到期通常最稳妥。确需立即验证时，可以只清理当前设备的 DNS 缓存，重启相关浏览器或代理客户端，然后复测。不要把反复修改权威记录当作“刷新”方法，这会制造更多变量。
若系统和公共递归解析器都返回新地址，但应用仍连接旧 IP，检查应用是否使用独立 DoH、内置 DNS、连接池或固定映射。机场客户端开启 Fake-IP、远程 DNS 或规则覆盖时，也可能让应用查询路径与系统命令不同。
验收更新是否完成
合格的验收至少包含：权威查询返回预期记录；常用递归解析器在合理时间后返回相同答案；系统查询一致；浏览器或客户端实际连接的远端地址也已变化。证书主机名与 HTTPS 验证必须继续通过。
做机场网络测试时，不要仅凭一次旧 IP 就判断节点故障。把 TTL、解析层次和实际连接地址放在一起，才能区分 DNS 更新延迟、应用缓存与代理路径问题。
评论