打开一个网站时，浏览器并不会每次都向DNS服务器询问这个域名对应的IP地址，而是先在本地查一遍缓存，命中就直接使用，未命中才会逐级向外发起解析请求。这份被临时保存下来的域名与IP映射记录，就是DNS缓存。它的好处很直观：省掉一次可能耗时几十毫秒甚至更久的解析过程，让页面打开更快；副作用同样明显：当网站的真实IP发生变化，缓存里的旧记录不会自动消失，于是网站明明已经完成迁移，你的电脑却还在固执地访问旧地址，表现为打不开或者访问到错误内容。
DNS缓存到底存放在哪些地方
很多人以为DNS缓存只有一个，实际上从你敲下回车到页面呈现，解析结果会经过至少四层缓存。第一层在浏览器内部，Chrome、Edge、Firefox都会维护自己的DNS缓存，与操作系统互不干扰；第二层在操作系统里，Windows由DNS Client服务负责，Linux上则可能是systemd-resolved、nscd或dnsmasq这类组件；第三层在家庭路由器或公司网关上，前提是它开启了DNS代理功能；第四层在运营商或公共DNS的递归服务器上，例如8.8.8.8这类地址背后的服务器集群。
理解这个层级非常关键，因为它直接决定了排查思路。你清空了本机缓存，但如果运营商递归服务器上还留着旧记录，解析结果依然不会变。每条DNS记录都带有一个TTL值，单位是秒，它规定了这条记录可以被缓存多久。比如TTL为600，意味着缓存方最多保存10分钟，超时后必须重新向权威服务器发起查询。TTL是域名持有方在解析记录里设置的，缓存方无权修改，只能遵守。
另外别忘了hosts文件这个特殊的存在。Windows下位于C:\Windows\System32\drivers\etc\hosts，Linux和macOS下是/etc/hosts，它的优先级高于DNS查询，属于本地静态解析。如果排查半天发现解析结果诡异，先检查这个文件里有没有人手动写过测试条目，很多莫名其妙的解析问题，根源就藏在这里。
各平台清除DNS缓存的命令整理
清除缓存的操作本身不难，难点在于不同系统、不同服务组件对应的命令完全不同。下面按平台逐一整理，建议对照自己的实际环境选用。
Windows系统
Windows提供了最简洁的命令，直接在命令提示符或PowerShell中执行即可，普通权限通常就能成功，遇到个别组策略限制时改用管理员身份运行。
:: 查看当前系统缓存的所有DNS条目 ipconfig /displaydns :: 清除本机DNS缓存 ipconfig /flushdns :: 执行成功后会返回提示：已成功刷新DNS解析缓存
ipconfig /displaydns输出的列表里能看到每条记录的域名、记录类型、TTL剩余时间，排查时非常有用。如果你修改了hosts文件后发现没生效，执行一次ipconfig /flushdns通常就能解决，因为hosts条目同样会被Windows缓存起来。
Linux系统
Linux发行版差异较大，缓存由哪个组件管理，命令就跟着变。Ubuntu及多数新发行版默认使用systemd-resolved，老一些的系统可能是nscd，自己搭软路由或做本地缓存的则常用dnsmasq。
# systemd-resolved 管理缓存的发行版，例如 Ubuntu sudo systemd-resolve --flush-caches # 查看缓存命中统计，确认缓存已被清空 sudo systemd-resolve --statistics # 使用 nscd 的旧系统，直接重启服务即可 sudo systemctl restart nscd # 使用 dnsmasq 做本地缓存的场景 sudo systemctl restart dnsmasq
新版systemd-resolved还提供了resolvectl flush-caches命令，效果与上面第一条相同，属于新旧命令的更替。遇到其中一个报命令不存在时，换另一个试试即可。
macOS系统
苹果系统的缓存由mDNSResponder守护进程管理，清除操作需要两条命令配合执行，并且要求sudo权限。
# 清除目录服务缓存 sudo dscacheutil -flushcache # 通知 mDNSResponder 重新加载，使DNS缓存立即失效 sudo killall -HUP mDNSResponder
网上流传的旧教程里常出现lookupd -flushcache，那是十多年前老版本Mac OS X的命令，现在的macOS早已不支持，照抄会直接报命令找不到。
浏览器缓存
由于Chrome系浏览器内置独立的DNS缓存，有时系统缓存清了，浏览器里还是旧记录。以Chrome或Edge为例，在地址栏输入chrome://net-internals/#dns，进入DNS页面后点击清除主机缓存按钮即可。Firefox则可以通过清除浏览器全部缓存数据来顺带处理，或在about:config中把network.dnsCacheExpiration临时设为0后重启浏览器。
清除之后如何验证解析已经生效
清完缓存不代表问题解决，还得确认新的解析结果符合预期。验证工具同样分平台，Windows自带nslookup，Linux和macOS建议使用dig，输出的信息更完整。
# Windows 下查询域名解析结果 nslookup www.ipipp.com # Linux/macOS 下查询，显示完整解析过程 dig www.ipipp.com # 只输出最终IP，适合脚本使用 dig +short www.ipipp.com # 指定用某个公共DNS查询，绕过本地默认配置 dig @8.8.8.8 www.ipipp.com
dig输出中有一段ANSWER SECTION，里面的数字就是该记录当前的TTL。多执行几次会发现这个数字在逐渐变小，这正是缓存倒计时的直观体现。如果你连续查询同一域名，TTL一直不下降，说明命中了本机缓存；想看外部最新答案，就用dig @8.8.8.8这种指定外部DNS的方式，对比两边结果是否一致，就能判断旧记录残留在哪一层。
常见问题与注意事项
围绕DNS缓存的实际故障大致可以归为四类，下面逐条说明处理思路。
第一类是刷新了本机缓存仍然解析到旧IP。这时候旧记录大概率卡在路由器或运营商递归服务器上，本机已经无能为力。临时办法是把本机DNS改成8.8.8.8或223.5.5.5，换一条递归路径，或者直接修改hosts文件做临时指向；根本办法是等TTL自然过期。这也解释了为什么网站迁移前，运维通常会提前一两天把域名TTL调低到60秒甚至30秒，让全网缓存快速失效，切换完成后再调回正常值。
第二类是负缓存带来的困扰。DNS不仅缓存解析成功的记录，也缓存解析失败的答案，比如域名不存在这类NXDOMAIN响应同样会被缓存一小段时间。刚注册的域名、刚添加的解析记录，配置明明正确却查不到，很可能就是负缓存在起作用，等几分钟再试往往就恢复正常了。
第三类是缓存投毒的安全风险。攻击者如果向缓存中注入伪造的解析记录，会把用户引导到假冒的钓鱼站点。防范上，一方面可以选择支持DNSSEC验证的公共DNS，另一方面重要业务尽量开启HTTPS，让证书校验成为第二道防线，即使解析被劫持，假站点也拿不出合法证书。
最后一点提醒：清缓存不是万能钥匙，更不是日常保健操作。解析一切正常时频繁执行清空命令，只会让每次访问都重新走完整解析流程，反而拖慢速度。把它当成域名迁移、修改解析记录、排查连通性问题时的针对性手段就好，平时不必刻意去清。