DNS 缓存刷新完全指南：Windows、macOS、Linux 与浏览器的 flush dns 命令

更新日期：2026-09-27

"我已经改了解析记录，为什么访问还是旧服务器？"——这是域名迁移和服务器更换后最常被问到的问题。答案几乎总是一样的：你的解析记录已经生效，但链路上某一层的 DNS 缓存还留着旧答案。刷新 DNS 缓存（flush dns / clear dns cache）就是让这一层立刻忘记旧结果、重新查询的动作。

本篇把 DNS 缓存的所有藏身处一次性讲清：操作系统、浏览器、公共递归服务、CDN 边缘节点，每一层给出对应的刷新命令和验证方法，并解释为什么"改完解析要等一会儿"有时确实是唯一的选择。

一、为什么刷了 DNS 还是旧 IP：先理解缓存层级

一次域名解析要经过多层缓存，任何一层没更新，你看到的就还是旧结果：

1. 浏览器缓存：Chrome、Firefox 等为了加速会自己缓存解析结果，生命周期通常在 60 秒上下，但不同浏览器实现不同。
2. 操作系统缓存：Windows 有 DnsClient 缓存，macOS 有 mDNSResponder，Linux 上是否有缓存取决于你运行了什么（systemd-resolved、nscd、dnsmasq 等）。
3. 路由器/局域网缓存：家用路由器往往兼任 DNS 转发并自带缓存。
4. 公共递归 DNS 缓存：你使用 8.8.8.8、1.1.1.1 或运营商 DNS 时，它们各自按 TTL 缓存，刷新你自己电脑对它们毫无影响。
5. CDN 与应用层缓存：严格说这不是 DNS 缓存，但 CDN 边缘节点缓存的旧页面同样会让你"看到旧站"，排查时别和 DNS 缓存混淆。

还有一个最容易被忽略的元凶：hosts 文件。Windows 在 C:\Windows\System32\drivers\etc\hosts，Linux 与 macOS 在 /etc/hosts。hosts 里的记录优先于一切 DNS 查询，而且不会随 TTL 过期——如果你（或某个开发工具）曾为了本地调试把域名指到测试机，忘了删，那么无论怎么刷缓存都不会生效。排查的第一步永远是先看 hosts。

二、TTL：缓存什么时候"自动"过期

DNS 缓存不需要手动刷新也会过期，过期时间由记录的 TTL（Time To Live） 决定。查询当前 TTL：

dig www.mf8.biz +noall +answer

输出中第三列就是 TTL（秒）。注意一个细节：递归服务器返回的 TTL 会随缓存时间递减，而权威服务器返回的是原始 TTL。所以对着 8.8.8.8 查到的 TTL 和对权威 NS 查到的不同是正常现象。

实践建议：如果计划迁移解析，提前 24–48 小时把 TTL 降到 300 秒或更低，迁移完成确认稳定后再调回常规值。这样即使某层缓存没刷，最长等 5 分钟也会自动更新。完整的迁移流程（含 TTL 降级时序与 DNSSEC 注意事项）可以参考我们的零停机 DNS 迁移实战一文。

三、Windows：ipconfig 三板斧

Windows 是"flush dns"搜索量最高的平台，命令也最简单。以管理员身份打开 PowerShell 或命令提示符：

# 刷新 DNS 解析缓存
ipconfig /flushdns

# 查看缓存内容（确认旧记录是否还在）
ipconfig /displaydns

# 刷新缓存并重新注册 DNS（换网络环境后可用）
ipconfig /registerdns

PowerShell 也提供了等价命令：

Clear-DnsClientCache
Get-DnsClientCache          # 查看缓存

如果 /displaydns 里始终有旧记录且无法刷新，可以重启 DnsClient 服务：

Restart-Service Dnscache -Force

注意：较新的 Windows 版本中 Dnscache 服务被锁定为系统管理，Restart-Service 可能提示无法停止，此时 ipconfig /flushdns 本身就足够了。

四、macOS：一句话刷新

macOS（10.15 Catalina 及之后的版本）统一用这条命令：

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

第一句清空目录服务缓存，第二句让 mDNSResponder 守护进程重载（这才是真正清掉 DNS 缓存的动作）。命令执行成功没有任何输出——没报错就是成功了。验证方式见下文第七节。

五、Linux：取决于你跑了什么

Linux 没有统一的系统级 DNS 缓存，有没有缓存取决于发行版和配置。先确认你的解析路径：

# 看 /etc/resolv.conf 由谁管理
cat /etc/resolv.conf
# 如果指向 127.0.0.53，说明在用 systemd-resolved

systemd-resolved（Ubuntu 18.04+、多数现代发行版的默认）：

# 新版命令（推荐）
resolvectl flush-caches
# 旧版兼容命令
systemd-resolve --flush-caches

# 查看缓存统计，确认 Cache Size 归零
resolvectl statistics

nscd（较老的发行版常见）：

sudo nscd -i hosts
# 或者干脆重启服务
sudo systemctl restart nscd

dnsmasq（常用于路由器、虚拟化和自建网关）：

sudo systemctl restart dnsmasq
# 或向进程发送 SIGHUP，仅清缓存不重启服务
sudo kill -HUP $(pgrep dnsmasq)

BIND（named，自建权威/递归服务器）：

sudo rndc flush                # 清空全部缓存
sudo rndc flushname mf8.biz    # 只清某个域名

重要提醒：如果你的 /etc/resolv.conf 直接指向 8.8.8.8 这类外部地址，且本机没有运行任何缓存服务，那么 Linux 本机并没有可刷的 DNS 缓存——旧记录在递归服务器那一层，只能等 TTL 过期（见第七节）。

六、浏览器缓存：别漏了这一层

Chrome / Edge： 地址栏打开 chrome://net-internals/#dns，点击 "Clear host cache"；再打开 chrome://net-internals/#sockets 点击 "Flush socket pools"——DNS 刷了但连接池还复用旧连接时，页面依然打不开，这一步经常被漏掉。

Firefox： 地址栏打开 about:networking#dns 查看缓存；刷新可以在 about:config 里把 network.dnsCacheExpiration 临时设为 0 后再恢复，或者直接重启浏览器。

Safari： 没有公开的缓存管理页，退出重开浏览器即可；顽固时 sudo killall -HUP mDNSResponder 连系统缓存一起刷。

七、公共递归层与权威层：你能做的和只能等的

刷掉自己电脑的缓存后，如果验证发现某些地区仍然解析到旧 IP，说明旧记录还留在公共递归 DNS 的缓存里。这一层你无法直接清除，有两个选择：

等 TTL 过期。 这是唯一保证对所有递归服务器生效的方式。这就是为什么迁移前要降 TTL——它决定了"最坏情况要等多久"。

用厂商提供的刷新工具。 Google Public DNS 提供了公开的缓存刷新页面，输入域名和记录类型即可发起清除：https://developers.google.com/speed/public-dns/cache 。Cloudflare 1.1.1.1 的缓存清理可以通过其支持渠道提交。此外，很多在线"多地点 DNS 检测"服务（如 https://whatsmydns.net ）能直观看到全球各节点的解析结果分布，用来判断缓存衰减进度非常方便。

发起刷新前，先确认权威记录确实已经改对——否则刷得越勤，旧错误传播得越快：

# 直接问权威 NS，绕过所有缓存
dig @ns1.your-dns-provider.com www.mf8.biz +noall +answer

还有一个冷门坑：负面缓存。如果迁移期间某域名短暂返回过 NXDOMAIN（域名不存在），这个"不存在"的答案也会被缓存，表现为解析完全失败而非指向旧 IP。修复权威记录后，同样要等这段负面 TTL 过期，或用上面的刷新工具加速。

八、完整排查决策表

把上面的内容收敛成一张表，按现象对号入座：

九、迁移场景的标准动作顺序

结合以上所有内容，给出服务器更换/迁移时的推荐顺序（细节展开见我们的 DNS 迁移实战文章）：

1. 迁移前 48 小时：把相关记录 TTL 降到 300 秒；
2. 新服务器就绪并自测后，修改权威解析记录；
3. dig @权威NS 确认权威已生效；
4. 本机刷缓存 + 浏览器刷缓存，验证新 IP 可访问；
5. 用多地点检测观察全球生效进度，等待旧 TTL 自然衰减；
6. 稳定 48 小时后，把 TTL 调回常规值。

六点五、容易翻车的进阶坑：浏览器 DoH 会绕过系统缓存

较新版本的 Chrome、Edge、Firefox 默认启用了 DNS over HTTPS（安全 DNS）：浏览器不再把解析请求交给操作系统，而是直接加密发往 Cloudflare 或 Google 的 DoH 服务。这意味着两件事：

1. 你刷系统缓存可能没用——浏览器根本没走系统解析，它有自己的缓存和自己的上游；
2. 关闭 DoH 才能复现某些问题——排查"我这正常、用户不正常"时，先确认浏览器是否开了安全 DNS，它可能拿到和你系统解析完全不同的结果。

验证与处理：Chrome 在 chrome://settings/security 的"使用安全 DNS"开关；Firefox 在 about:config 的 network.trr.mode（0 为关闭）。排查 DNS 问题时建议临时关闭，用 curl 做基准对照——curl 走系统解析，行为最"干净"。

六点六、手机端与自建递归的处理

iOS / iPadOS：没有公开的 DNS 缓存刷新命令，最快的方式是开合一次飞行模式（重建网络连接，通常连带清掉解析缓存）；顽固时重启设备。如果设备设置了"配置 DNS"为加密 DNS（设置 → WLAN → 配置 DNS），它会绕过系统常规解析，排查时先切回"自动"。

Android：同样没有直接的 flush 命令，飞行模式或重启；开启"私人 DNS"（加密 DNS）的设备注意它会绕过运营商与系统缓存直连上游，排查时同样先关闭。浏览器 App 的缓存与桌面版逻辑一致，Chrome 的 chrome://net-internals/#dns 在 Android 版也可用。

自建递归 unbound：

# 清全缓存
unbound-control flush_zone .
# 只清某域名（含子域）
unbound-control flush_zone mf8.biz

unbound-control 需要在配置里启用 remote-control 才可用。运行 AdGuard Home 或 Pi-hole 的家庭网络，直接在管理界面里清缓存或重启服务即可。

七、路由器与网关设备

家用路由器：多数路由器运行 dnsmasq 或类似服务，缓存不受你电脑控制。最省事的处理是重启路由器；OpenWrt 用户可以精准操作：

# OpenWrt：重启 dnsmasq 或仅清缓存
/etc/init.d/dnsmasq restart
kill -HUP $(pidof dnsmasq)

云上内网 DNS：阿里云、腾讯云等 VPC 内网 DNS（100.64.0.0/10 段的 resolver）同样有缓存，云控制台的内网 DNS 解析文档通常提供刷新方式或说明缓存时长。自建 Kubernetes 集群里，CoreDNS 的缓存策略由 Corefile 控制，调试解析问题时可以临时调低 cache TTL。

八、验证工具对比：dig、nslookup、Resolve-DnsName

验证解析是否生效，三个平台的工具各有差异：

一个常用组合：dig 域名 +short 看结果，dig 域名 @权威NS +short 核对权威，dig +trace 域名 从根服务器追一遍完整解析链路（迁移疑难杂症的最后手段）。

注意 Windows 的 nslookup 有个经典坑：它默认用本机配置的 DNS 服务器做反向查询提示，超时的警告信息（"Default servers are not available"）不代表解析失败，看最后的 Answer 段才是结果。

九、一个真实场景：三层缓存叠加的解析残留

用一个典型案例把全篇串起来。某站点从服务器 A 迁到 B，TTL 300 秒，改完记录 10 分钟后：

1. 站长自己电脑还看到旧站——hosts 文件里躺着三天前调试时加的一条 旧域名 → 服务器A，删掉并刷新系统缓存后解决；
2. 同事 Chrome 仍打不开新站——hosts 没问题、系统缓存已刷，但 Chrome 开了安全 DNS 且自带缓存，chrome://net-internals/#dns 清缓存加 flush socket pools 后解决；
3. 部分外地用户几小时后仍解析到 A——公共递归缓存还没衰减，权威记录已核对无误，等 TTL 自然过期；其中个别用户是运营商 DNS 无视 TTL 长缓存（国内部分运营商 DNS 的老问题），只能等或建议用户改用公共 DNS。

三层问题、三种修法，全在这篇的射程内——按"本机 hosts → 本机缓存 → 浏览器（含 DoH）→ 公共递归"的顺序过一遍，几乎不存在第五种可能。

十、常见误区清单

1. 只刷电脑不查 hosts：hosts 优先于一切 DNS 查询，且永不过期，永远第一个查。
2. 刷新公共 DNS 的错觉：刷自己电脑对 8.8.8.8 的缓存没有任何影响，递归层只能等 TTL 或用厂商刷新工具。
3. 把 CDN 缓存当 DNS 缓存：解析已经是新 IP、页面还是旧的，是 CDN 边缘缓存在起作用，去刷 CDN。
4. 忘了浏览器连接池：DNS 刷了但 TCP 连接池复用旧连接，页面依旧打不开，flush socket pools 那一步别省。
5. 迁移前不降 TTL：等出问题才想起 TTL 还是 3600，全场要等一小时。TTL 降级是迁移前的动作，不是事后的补救。
6. 负面缓存被忽略："域名不存在"也会被缓存，解析彻底失败时要想到 NXDOMAIN 负缓存。

十一、关于"DNS 传播要 48 小时"的迷思

最后澄清一个流传最广的说法。"DNS 需要 24–48 小时全球生效"这句话误导了太多人——它描述的是最坏情况的缓存衰减，而不是一个固定等待时间：

解析生效的过程是逐层、可预测的：权威记录修改后立即生效；各递归缓存的旧记录按各自的 TTL 倒计时过期，TTL 是 300 就是最多 5 分钟。所谓"48 小时"，通常是迁移前 TTL 设了 86400（一天）且跨了两轮过期的结果——不是协议要求，是运维惯性。

正确的认知是：生效时间 = 你之前设的 TTL。这也是本篇反复强调迁移前降 TTL 的原因：把等待时间从"一天"压缩到"几分钟"，剩下的验证工作（第七节的多地点检测）才有意义。反过来说，看到"某个用户还在旧站"时，先用 dig 查那条记录当前的 TTL 剩余值，就能准确回答"还要等多久"，而不是报出一个模糊的"24 小时"。

顺带一个迁移时的高发疏漏：IPv6 的 AAAA 记录。改解析时把 A 记录指向新服务器，却忘了 AAAA 还指着旧机器——支持 IPv6 的用户（如今多数移动网络）会继续访问旧站，而测试机恰好不开 IPv6 时你还复现不出来。核对解析时用 dig 域名 AAAA +short 把 A 与 AAAA 一起过一遍。

十二、命令速查表

# ── Windows（管理员 PowerShell）────────────
ipconfig /flushdns            # 刷新缓存
Clear-DnsClientCache          # 等效 PowerShell 命令

# ── macOS ─────────────────────────────────
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# ── Linux（按实际运行的缓存服务选用）───────
resolvectl flush-caches       # systemd-resolved（Ubuntu 18.04+ 常见）
sudo nscd -i hosts            # nscd
sudo systemctl restart dnsmasq  # dnsmasq
sudo rndc flush               # BIND

# ── 验证 ──────────────────────────────────
dig 域名 +short               # 看当前解析结果
dig 域名 @权威NS +short       # 核对权威记录
dig 域名 +noall +answer       # 看剩余 TTL

官方资料与继续阅读

• systemd-resolved 与 resolvectl 官方手册：https://www.freedesktop.org/software/systemd/man/resolvectl.html
• Google Public DNS 缓存刷新工具：https://developers.google.com/speed/public-dns/cache
• Microsoft ipconfig 命令参考：https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ipconfig
• 站内相关文章：零停机 DNS 迁移实战：TTL 策略、DNSSEC 与邮件记录切换检查表、CDN 缓存命中率从 60% 到 95%、503 Service Unavailable 排障实战