把代理入口从旧节点切到新节点，后台明明显示"已生效"，业务请求却还是打到老IP——这是做数据采集、多账号运营的团队最容易踩的坑之一。问题多半不在切换操作本身，而在DNS解析链路上层层叠叠的缓存。这篇文章把整条解析链路拆开讲清楚：缓存到底藏在哪几层、怎么逐层刷新，以及如何让入口切换在分钟级内真正生效。
一、先看懂解析链路：你的请求经过了多少层"记忆"
很多人以为"改了解析就立刻生效"，实际上一次域名解析要经过好几层缓存，任何一层没更新，你看到的就还是旧结果：
1. 浏览器缓存：浏览器自己会缓存DNS记录，通常几十秒到几分钟，目的是减少重复解析的开销。
2. 操作系统缓存：Windows、macOS、Linux都有系统级DNS缓存。另外要注意，hosts文件里的记录优先级最高，一旦写死，DNS怎么改都没用。
3. 递归DNS缓存：你本机配置的DNS服务器（运营商默认的，或114.114.114.114、223.5.5.5这类公共DNS）会按TTL缓存解析结果。这一层你本机的刷新命令管不到。
4. 权威DNS：域名记录真正的所在地，你改解析改的就是这里。它是源头，改完即新。
代理场景还有个特殊之处：走代理时，业务域名的解析往往发生在代理服务端，你本地解析的其实是"代理入口域名"本身。所以入口切换后要排查的是两条线：入口域名的解析有没有更新、代理端拿到的业务解析是不是新的。两条线都通，切换才算真正完成。
二、老解析为什么"赖着不走"？四个常见元凶
元凶一：TTL还没到期。TTL是解析结果的"保质期"，单位是秒。假设TTL是3600，那么切完入口后一小时内，各层缓存都可能继续返回旧IP。这不是故障，是机制——TTL存在的意义就是让各层缓存安心复用结果。
元凶二：负缓存。之前某次解析失败或"域名不存在"的结果，同样会被缓存一段时间。如果入口刚上线你就测试，很可能拿到的是"解析失败"这个旧结论，白白误判成切换出问题。
元凶三：长连接复用。浏览器和程序里的socket还挂在老IP上，只要连接不断开，就不会触发重新解析。这就是为什么"明明刷新了缓存，请求还是走老节点"——连接压根没断过。
元凶四：程序级缓存。Java等运行时自带DNS缓存，某些配置下默认长期缓存甚至永久缓存，不重启进程就永远不更新。这类缓存最隐蔽，也最容易被忽略。
三、缓存刷新实操：从本机到链路逐层清理
按下面的顺序逐层处理，基本能覆盖所有缓存点。
第一步：刷新本机DNS缓存。
Windows：
ipconfig /displaydns # 先查看当前缓存了什么
ipconfig /flushdns # 清空本机DNS缓存macOS：
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponderLinux（systemd系）：
resolvectl flush-caches
# 旧版本系统使用：
systemd-resolve --flush-caches第二步：清浏览器缓存并断开旧连接。Chrome在地址栏输入 chrome://net-internals/#dns，点击 Clear host cache；再到 chrome://net-internals/#sockets，点击 Flush socket pools，把挂在旧IP上的连接一并断掉。Firefox在 about:networking#dns 页面点 Clear DNS Cache。
第三步：检查hosts残留。Windows看 C:\Windows\System32\drivers\etc\hosts，Linux和macOS看 /etc/hosts，删掉与入口域名相关的旧记录。hosts优先级高于DNS，留着它，后面全白做。
第四步：处理程序级缓存。Java进程可以在启动参数里限制缓存时间，例如 -Dnetworkaddress.cache.ttl=30（单位秒）；其他语言的服务，最直接的办法是切换后重启一次进程。
第五步：验证解析结果。
nslookup 你的入口域名
nslookup 你的入口域名 223.5.5.5
nslookup 你的入口域名 119.29.29.29第一条看本机当前解析，后两条直接问公共DNS，绕开运营商递归缓存。如果公共DNS已经返回新IP而本机还是旧IP，问题就在你本机或程序缓存；如果公共DNS也还是旧IP，那就耐心等TTL过期，或者联系解析服务方确认记录是否真的改对了。
各层缓存的保留时间和清理方式，对照下表一目了然：
| 缓存层级 | 典型保留时间 | 清理方式 |
|---|---|---|
| 浏览器缓存 | 几十秒到几分钟 | 内部页面一键清理 |
| 操作系统缓存 | 遵循TTL | flushdns等命令 |
| 递归DNS | 遵循TTL，负缓存另算 | 换公共DNS或等待 |
| 程序级缓存 | 看配置，可能长期 | 重启进程或调参数 |
四、让入口切换分钟级生效的四个工程习惯
习惯一：切换前先降TTL。计划切换前10-30分钟，把入口域名的TTL临时调到60秒左右，切完观察稳定后再调回正常值。这是让切换"快"的最关键一步，TTL越短，各层缓存过期越快。
习惯二：新入口先预热。全量切换前，先用新入口跑一小部分验证请求，确认解析、连通性、响应速度都正常，再放量。别拿全量业务当测试工具。
习惯三：灰度切换。把业务机器分成几批，一批一批切，每切一批观察几分钟。这样即使新入口有问题，影响面也被控制在最小。
习惯四：解析监控留痕。用定时任务每隔一分钟跑一次 nslookup 并记录结果，切换后一眼就能看出各层缓存什么时候更新完毕，而不是靠猜。长期留存这些记录，还能帮你在下次切换前估算生效时间。
五、入口切换频繁？选对服务商能省一半心
如果你的业务需要频繁切换入口——比如多账号运营、数据采集轮换IP——那么除了自己做好缓存管理，选一家切换顺畅的服务商同样重要。
这里推荐天启HTTP。它是国内IP代理服务商，节点覆盖国内多个城市，提供API批量提取方式，IP轮换和入口切换都可以通过接口自动化完成，不用手工逐台改配置。它支持HTTP/HTTPS/SOCKS5常用协议，接入现有的采集框架、多账号管理工具改造成本很低。遇到解析类或连通性问题，也可以直接找他们的技术支持协助排查，比自己闷头猜缓存快得多。
需要提醒的是，天启HTTP是纯国内IP代理服务商，适合数据采集、电商多账号运营、舆情监测这类国内业务场景；如果你的业务需要海外IP，它并不适用。
常见问题
Q: 刷新了缓存，解析出来还是老IP怎么办？
按顺序排查三件事：一是浏览器或程序的旧连接还没断开，去清socket池或重启进程；二是程序级DNS缓存没失效，调TTL参数或重启服务；三是hosts文件里还有旧记录，hosts优先级高于DNS，删掉再试。如果公共DNS也返回旧IP，那是递归缓存还没过期，等TTL即可。
Q: TTL设置成多少比较合适？
需要频繁切换的入口域名，平时可以设300-600秒，计划切换前提前降到60秒左右，切换稳定后再恢复。TTL不是越短越好，太短会增加解析请求量、抬高解析失败的概率，按业务的切换频率权衡即可。
Q: 把本机DNS换成公共DNS（如223.5.5.5、119.29.29.29）有用吗？
对"让你本机更快看到新解析"有用，因为绕开了运营商递归服务器的缓存；但它只改变你本机问谁，管不了其他机器的缓存，全网生效速度还是由TTL决定。
Q: 走代理时，域名到底在哪一步被解析？
取决于代理的工作方式：常见的HTTP代理场景下，目标业务域名由代理服务端负责解析，本地只解析代理入口域名。所以排查时要先分清缓存问题出在"入口域名"还是"业务域名"这条线上，别刷错地方。
Q: 使用天启HTTP时，入口切换有什么注意事项？
通过API拿到新的入口信息后，先小流量验证连通性和解析结果，再全量切换；切换后按本文方法清理本机与程序缓存，并用nslookup对比新旧解析，确认请求已经落到新入口上。养成"降TTL—预热—灰度—监控"的固定流程，切换就不再是玄学。
