Windows 缓存域名容量这件事，听起来像个偏门需求，但真到用的时候特别急人。最近半年，我身边好几个同事都在折腾这个：有人是内网域名一多，访问内部系统老出现“DNS 解析慢”甚至超时；有人是跑 Docker、自建服务、本地开发环境，同一堆域名反复重建缓存，性能白白浪费；还有人是做网络排查，发现ipconfig /displaydns里缓存条目留存时间太短，根本起不到缓存作用。Windows 默认的 DNS 客户端缓存策略，放在轻量办公环境问题不大，可一旦域名量上来，或者你对解析速度有要求，就必须自己动手调一调缓存域名容量。这篇文章我会把改法、参数原理、验证手段和我踩过的坑，一次讲清楚。
1. 先搞懂：Windows DNS 缓存到底是什么，容量限制在哪
1.1 一次域名解析背后做了什么
为了说清楚缓存容量，我们得先回到最基础的问题：一次域名解析到底是怎么发生的。
你在浏览器里输入一个域名，比如www.example.com，系统会先查本地 DNS 缓存，这个缓存存在于内存中，由DNS Client服务（服务名Dnscache）统一管理。如果缓存里有这条记录，直接返回 IP，整个过程可能在毫秒级。如果缓存没有，Windows 会按网络接口配置的 DNS 服务器列表，发出递归查询请求，从运营商 DNS 或内网 DNS 服务器拿到结果，然后把结果存进本地缓存，再返回给调用方。
这个“先查缓存、没命中再走网络”的机制，就是系统性能优化里相当基础的“缓存第一”思想。类比一下：你去一家常去的餐厅，服务员如果已经记住你常点的菜，一开口就能报出来；如果记不住，每次都要翻菜单、问后厨、等出餐。DNS 缓存就是记住域名解析结果的“服务员”，缓存容量就是这个服务员能记住多少桌客人的点单。
这里有一个容易忽略的细节：DNS 响应中是带 TTL（Time To Live）字段的，由权威 DNS 服务器指定，告诉客户端“这条记录可以缓存多久”。Windows 会把这条 TTL 和本地策略做一次比较，取两者中的较小值作为实际缓存时间。也就是说，就算 DNS 服务器告诉你“这条记录可以缓存 10 天”，Windows 如果默认只允许缓存 1 天，它也只会留 1 天，到期后照样重新发起解析请求。
1.2 默认缓存容量与“不够用”的真实表现
Windows 的默认缓存容量，并不是一个简单的“最多存 1000 条”这样的固定数字。现代 Windows 的 DNS 缓存更像是一个动态内存结构，没有一条文档上写的“缓存最大条目数”硬性上限。真正拉低缓存效率的，主要是下面几个参数在起作用：
MaxCacheEntryTtlLimit：默认86400秒，也就是 1 天。它限制的是“单条缓存记录能存活的最大 TTL”。MaxNegativeCacheTtl：默认300秒，也就是 5 分钟。它限制的是“解析失败的记录”在缓存里保留多久。- 缓存哈希表（Cache Hash Table）大小：这组参数主要影响同时缓存大量域名时的查找效率。
看到这里你就明白了，Windows DNS 缓存默认不会让你无限缓存，更不会让一条记录无限期留存在内存里。TTL 上限 1 天，意味着哪怕上游服务器给了很长的 TTL，超过 1 天的也只会缓存 1 天。这样做的好处是避免 DNS 记录变更后客户端迟迟拿不到新 IP；坏处是如果你们公司内网有不少“短域名但长 TTL”的记录，本地缓存命中率就上不去。
“缓存容量不够用”最常见的表现有这么几类：
- 访问同一域名时，第一次慢、第二次也慢，明明刚访问过，好像完全没有缓存生效一样。
- 内网系统多、域名量大，
Get-DnsClientCache看到的缓存条目总在几千条上下波动，刷新频率很高。 - 做了 DNS 监控的人会发现
DNS Client\Cache Misses/Sec计数器长期偏大，说明大量请求打到了上游 DNS 服务器。
如果你遇到了这些情况，说明默认缓存策略已经不太适合当前环境了。
1.3 我为什么建议你先别急着加大容量
模块式的第一段，我想先泼一盆冷水：别一上来就把缓存容量往死里加，因为不是所有场景都需要改。
先看一个关键问题——你改缓存容量，到底想解决什么？如果是想减少 DNS 查询延迟，那么把 TTL 上限调高、让记录留得更久，效果立竿见影。但如果是缓存条目数量已经大到内存吃紧，或者内网域名数量极多、哈希冲突严重，那么单纯调 TTL 是解决不了问题的，你得考虑另外一套思路。
我在实际中见过最经典的误操作，是有人为了“加速”，把MaxCacheEntryTtlLimit直接调到604800（7 天），结果部署某个服务时改了 DNS 解析，新旧 IP 交替了好几天都不稳定。原因很简单，DNS 记录不是永远不变的，缓存时间越长，记录更新滞后的风险就越高。域名解析到旧 IP 的客户端会一直走旧链路，直到缓存过期或者手动刷缓存。
所以正确的步骤一定是：先理解默认参数为什么要这么设，再结合自己的场景做小幅调整，最后做好验证和回滚预案。下面几节我把参数讲透，你再看自己该不该动、怎么动。
2. 动手改之前：看懂这几个注册表参数再下手
2.1 注册表路径与核心参数解读
Windows 的 DNS 客户端缓存参数，集中在以下注册表路径：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters我把常用的几个参数整理成了表格，实际修改时建议对照着看：
| 参数名 | 类型 | 默认值 | 作用 | 调整建议 |
|---|---|---|---|---|
MaxCacheEntryTtlLimit | DWORD | 86400（秒） | 限制单条正向缓存记录最多保留的时间 | 内网环境可适当调大到172800或604800，视记录变更频率而定 |
MaxNegativeCacheTtl | DWORD | 300（秒） | 限制解析失败（如域名不存在）记录的缓存时间 | 内网可适当调大到1800或3600，减少对不存在域名的重复查询 |
CacheHashTableSize | DWORD | 系统自动 | 控制缓存哈希表大小，间接影响可缓存记录数量与查找速度 | 除非域名量极大，否则一般不用动 |
CacheHashTableBucketSize | DWORD | 系统自动 | 控制哈希桶大小 | 同上，一般不用动 |
NegativeCacheTime | DWORD | 与MaxNegativeCacheTtl相关 | 某些 Windows 版本上的负缓存时间参数 | 保持默认即可，优先调整MaxNegativeCacheTtl |
这里有一个常见误解要澄清：很多人认为调MaxCacheEntryTtlLimit就是“扩大缓存容量”，严格来说，它调整的是“单条记录的有效存活时间”。容量这个事，有一个时间维度和一个空间维度。时间维度由 TTL 参数控制，就是一条记录在缓存里能活多久；空间维度由缓存哈希表规模和系统内存决定，就是同一时刻能装下多少条记录。对绝大多数场景，调时间维度就够了，因为即使哈希表默认，日常几千条甚至几万条记录也完全装得下。
2.2 TTL、负缓存与哈希表之间的关系
这三个概念之间不是孤立的，它们共同决定缓存的整体表现。
TTL 决定的是正向记录的生命周期。DNS 服务器返回记录时带的 TTL，和本机设置的MaxCacheEntryTtlLimit，取最小值。举个例子：上游 DNS 返回 TTL 是 7200 秒（2 小时），本机上限是 86400 秒，那这条记录实际就缓存 2 小时；上游返回 TTL 是 604800 秒（7 天），本机上限是 86400 秒，那它最多也只会缓存 1 天。所以你调大本机上限，是有价值的，但前提是上游给的 TTL 本身也得够大。
负缓存指的是“解析结果为空”的记录。比如你查询nonexistent.example.com，DNS 服务器返回“这个域名不存在”，这个失败结果也会被缓存下来。默认的 300 秒叫负极缓存 TTL，目的是防止同一个不存在的域名反复去骚扰 DNS 服务器。内网环境里，如果你的客户端经常会拼错域名，或者有大量恶意扫描请求，适当调大负缓存时间可以明显降低 DNS 服务器负载。但要注意，调太大也会有问题——万一这个域名以后真的被创建了，客户端可能还记着“它不存在”。
哈希表大小影响的则是缓存查找阶段的性能。想象一个巨大的书架，书很多，如果书架格子设计合理、标签清晰，找一本书很快；如果格子太少、冲突太多，找一本书可能要翻好几排。哈希表就是管理这些“缓存条目”的格子系统。日常环境不用动它，只有当Get-DnsClientCache里已经有几万条记录时，才值得研究这个方向。
2.3 容量到底该调多大：场景化估算办法
改参数没有标准答案，我给一个我常用的估算路径，你可以照着套进自己的环境。
先统计一下当前缓存里的记录量。用 PowerShell 跑一下：
Get-DnsClientCache | Measure-Object再看缓存命中和未命中的情况。用性能监视器（perfmon）添加DNS Client性能对象，观察Cache Hits/Sec和Cache Misses/Sec这两个计数器。如果Misses占比长期在 20% 以上，并且很多域名是重复查询的，那就有优化空间。
然后估算目标域名规模。假设你的内网有 2000 个业务域名，每个域名平均有 3 到 5 条解析记录，加上外围 CDN、对象存储、第三方 API 域名，总量大概在 1 万到 2 万条左右。每条缓存记录占用的内存并不大，通常按 100 到 200 字节估算，2 万条也不过 2 到 4 MB。这时候你会发现，单纯说“内存不够装下缓存”在绝大多数客户端上是不成立的，真正的瓶颈往往是 TTL 太短——记录没活多久就过期了。
所以我建议的调整思路是：先把MaxCacheEntryTtlLimit从默认的 1 天调到 2 天到 3 天（172800到259200），观察一周再说。如果缓存命中率上来了、重复查询明显减少，说明这个方向是对的；如果还不够，再往 7 天调，但一定要同步考虑 DNS 记录变更的及时性。
3. 修改缓存容量的两种实操方法
3.1 方法一：regedit 可视化修改（适合单机、怕出错的用户）
如果你的电脑就一两台，而且你对注册表编辑不熟悉，那用图形界面是最稳妥的。
按Win + R，输入regedit，回车，打开注册表编辑器。定位到：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters如果Parameters这个键不存在，就右键Dnscache，新建一个“项”，命名为Parameters。然后在右侧空白处右键，新建两个 DWORD（32 位）值：
- 名称：
MaxCacheEntryTtlLimit，数值：172800，基数选“十进制”。 - 名称：
MaxNegativeCacheTtl，数值：1800，基数选“十进制”。
注意，这里一定要选“十进制”，不然你填进去的172800会按十六进制解析，结果会变成一个特别离谱的大数。
改完以后，不要急着激动，注册表参数通常不会立刻全局生效。最简单的方法是按Win + R，运行：
ipconfig /flushdns把当前缓存清空，下次解析时就会按新参数重新缓存。如果需要更彻底地让服务重新加载配置，可以重启DNS Client服务。
3.2 方法二：PowerShell 脚本批量分发（适合多台机器）
如果你是运维，需要给公司几十上百台机器统一调整，手动一个个点注册表编辑器肯定不现实。这时候建议用 PowerShell 脚本批量推。
先在本机验证一遍脚本。把下面的内容保存为Set-DnsCacheSize.ps1：
$params = "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" if (-not (Test-Path $params)) { New-Item -Path $params -Force | Out-Null } # 设置正向缓存 TTL 上限，单位：秒。172800 为 2 天，604800 为 7 天。 New-ItemProperty -Path $params -Name "MaxCacheEntryTtlLimit" -Value 172800 -PropertyType DWord -Force | Out-Null # 设置负缓存时间，单位：秒。1800 为 30 分钟。 New-ItemProperty -Path $params -Name "MaxNegativeCacheTtl" -Value 1800 -PropertyType DWord -Force | Out-Null # 重置 DNS 缓存，让新配置尽快生效 ipconfig /flushdns | Out-Null # 输出当前配置确认 Get-ItemProperty -Path $params | Select-Object MaxCacheEntryTtlLimit, MaxNegativeCacheTtl在管理员 PowerShell 窗口运行：
Set-ExecutionPolicy -Scope Process Bypass .\Set-DnsCacheSize.ps1如果你有 AD 域环境，可以用组策略的“首选项”把注册表项推下去；如果机器不在域里，也可以用Invoke-Command远程执行。我的经验是，域环境下用组策略最省心，因为重启后配置还在，而且回滚也方便。
3.3 让配置生效的三种方式
改完注册表之后，很多人会问一个问题：要不要重启电脑？答案分三种情况。
第一种，只清空缓存重新构建。运行ipconfig /flushdns，当前缓存清空，后续查询按新参数走。这种方式最温和，适用于日常调优，不需要中断正在运行的服务。
第二种，重启 DNS Client 服务。在管理员命令行执行：
net stop dnscache && net start dnscache或者用 PowerShell：
Restart-Service Dnscache -Force重启服务会重新读取注册表配置，同时把内存里的缓存全部清掉。效果比flushdns更彻底，适合改了哈希表这类和缓存结构相关的参数。要注意，重启 DNS Client 服务的瞬间，会有一小段无法解析域名的时间，生产环境操作前记得先评估影响。
第三种，重启系统。说实话，大部分情况下没必要。只有当你改了CacheHashTableSize这类底层结构参数，重启服务后仍然看不到预期效果时，才值得重启一次系统让内核重新初始化。
3.4 验证改没改成功：查看缓存命中与条目数量
改完之后，验证是必须的。很多人改完就完事了，结果实际参数是否生效都不知道。
第一条命令，看注册表里的当前值：
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters"确认MaxCacheEntryTtlLimit和MaxNegativeCacheTtl已经变成你设置的值。
第二条命令，看缓存中的实际条目：
Get-DnsClientCache | Select-Object -First 20注意观察输出的TimeToLive列。如果MaxCacheEntryTtlLimit设置为 172800，而某条记录的 TTL 是上游返回的 3600，那它显示 3600 是正常的。缓存的实际时间永远是“上游 TTL 和本机上限取小”，不要看到 TTL 不是 172800 就以为设置失败了。
第三条命令，统计当前缓存条目数量和按域名分组的数量：
Get-DnsClientCache | Measure-Object Get-DnsClientCache | Group-Object Entry | Sort-Object Count -Descending | Select-Object -First 10这样你能直观看到缓存里到底装着哪些域名。如果内网业务域名大量存活在缓存里，说明设置开始起效了。
4. 一个真实优化案例：办公网络 DNS 缓存容量调整全记录
4.1 问题背景：内网域名解析频繁超时
去年我帮一个朋友公司做过一次类似的优化。他们的现状是：办公网络有 400 多台 Windows 客户端，内部系统有十几个，域名分布在好几个二级域名下面，比如oa.corp.example、files.corp.example、erp.corp.example。问题反馈很集中：每天上午上班高峰，大家同时打开内部系统，总有人反映页面卡顿、加载超时，有时候要刷新好几遍才能打开。
排查了一圈，网络层没问题，内网 DNS 服务器负载也不算高，问题就出在本地缓存的命中率上。我登到一台问题严重的机器上，先看缓存：
(Get-DnsClientCache | Measure-Object).Count结果只有几百条，对于一个每天要访问几十个域名的办公环境来说，这个数字太少了。再看某个核心系统的缓存记录：
Get-DnsClientCache | Where-Object { $_.Entry -like "*erp.corp.example*" }发现这些记录要么不存在，要么 TTL 已经所剩无几。也就是说，它们每次访问都要重新走一遍完整解析流程，非常慢。
原因基本锁定了：内网 DNS 服务器返回的 TTL 很短，加上本机默认MaxCacheEntryTtlLimit是 1 天，两者取小，导致缓存实际存活时间很短。办公楼里几百台机器在同一时间反复发起解析请求，内网 DNS 服务器即使性能不差，在瞬时高峰也会丢包、响应变慢。
4.2 参数设定与实施过程
我们的调整目标很明确：让常用内网域名尽量留在本地缓存里，同时避免外部公网域名长时间缓存影响准确性。
由于客户端数量多，我们没有采用手动方式，而是用 PowerShell 脚本先在一台测试机上跑通，再通过域组策略批量下发。参数设定如下：
| 参数 | 设定值 | 设定理由 |
|---|---|---|
MaxCacheEntryTtlLimit | 259200（3 天） | 内网系统域名很少变更，且业务记录大多由内网 DNS 统一管理，3 天是一个比较稳妥的平衡点 |
MaxNegativeCacheTtl | 1800（30 分钟） | 减少对不存在域名的重复查询，又不至于压太久 |
CacheHashTableSize | 不调整 | 400 台客户端环境下，缓存条目总量不会太大，哈希表默认够用 |
部署脚本时我加了一个保护逻辑：先备份当前注册表值，方便回滚。下面是一个简化版：
$params = "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" $backupFile = "D:\backup\dns_cache_params_$(Get-Date -Format yyyyMMdd_HHmmss).reg" reg export "HKLM\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" $backupFile /y顺便说一句，备份注册表这个习惯非常值得养成。改 TTL 不比改普通配置，出了问题往往是慢性的，你不会第一时间发现是这里导致的，有备份就能快速排除变量。
4.3 修改前后对比
调整完成后，我们观察了两周。
第一周的效果就很明显。缓存条目数从原来的几百条上升到了几千条，核心内网域名如erp.corp.example的解析记录基本维持在缓存里很少消失。性能监视器里DNS Client\Cache Hits/Sec明显提高，Cache Misses/Sec下降了一半以上。
最直观的变化是用户反馈：上午高峰期的系统卡顿现象基本消失，页面加载速度恢复到了内网该有的水平。后来我查了一下内网 DNS 服务器的日志，峰值时段的查询量下降了大约 40%，这就是本地缓存发挥作用的最有力证据。
不过我们也发现了一个小问题：某天运维在erp.corp.example上切换了新的服务器 IP，结果有少部分客户端在半小时内还是访问旧 IP，导致页面短暂报错。原因就是缓存还在生效期，TTL 没到，系统不会主动去更新。遇到这种情况，最快的处理方式是通知这些客户端执行：
ipconfig /flushdns所以我的建议是：缓存参数调大后，一定要把“清缓存”这个操作教会给相关人员。这不是可有可无的细节，而是调大 TTL 后必然会带来的操作变化。
4.4 后续监控与回滚预案
这次调整并没有一劳永逸。我们在两周后复查了一次，确认缓存命中率稳定后，把初始的 3 天 TTL 保留了。同时设置了回滚预案：如果后续某个内网系统域名需要频繁切换 IP，优先考虑单独处理，而不是全局把 TTL 调回默认。
回滚本身很简单，备份文件还在，双击导入注册表，重启 DNS Client 服务即可。但我建议回滚后也观察两天，确认症状确实和缓存配置相关，再下结论。
5. 常见问题与排查技巧实录
5.1 改完注册表后缓存看起来没变大
有人会遇到这种情况：注册表值已经改成604800了，但ipconfig /displaydns里看到的 TTL 还是很小，或者缓存条目数没有明显增长。
我的排查步骤一般是这样的：
先确认上游 TTL。用nslookup -type=A example.com看一下返回的 TTL 是多少。如果服务器返回的 TTL 本身就很小，比如 60 秒，那本机上限设得再大也没用，缓存活不了几分钟。这种情况要调整的是 DNS 服务器上的 TTL 配置，而不是客户端注册表。
再确认你查看的缓存对象是同一个域名。很多人测试时用了一个随机访问的公共网站，这个网站的 TTL 可能只有几百秒，和预期不匹配，于是误以为设置失效。实际测试应该用你们自己的内网域名，或者 TTL 比较长的稳定域名。
最后检查注册表值有没有写错。DWORD 的数值类型选成十六进制了没有？路径是不是HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters？有没有拼写错误？这些问题我见过太多次。
5.2 TTL 设得过大反而引来一堆麻烦
把MaxCacheEntryTtlLimit调到 7 天甚至 30 天，听起来会让缓存命中率变得很漂亮，但麻烦也随之而来。
最典型的麻烦就是“缓存延迟”。新版本的 DNS 记录发布后，老记录不会立刻消失，客户端继续访问旧 IP，服务切换总会慢半拍。这在 CDN 切换、机房迁移、A/B 发布这些场景下尤其致命。你本来是想优化性能，结果把自己坑进了“为什么我改了 A 记录却不生效”的经典排查陷阱里。
我的经验值是：内网稳定域名 2 到 3 天，公网域名最多 1 天，动态性强的域名不要超过 5 分钟。缓存不是越大越好，而是越贴切越好。
5.3 清缓存还是重启服务，到底该用哪个
日常遇到域名解析异常时，大家最常用的命令是：
ipconfig /flushdns这条命令只清空 DNS 客户端缓存，不影响其他网络连接，是目前最温和、最推荐的清理方式。如果清完缓存后问题依旧，再考虑重启 DNS Client 服务。
但要注意，重启服务会造成短时间内无法解析域名，正在进行的网络请求可能会出现短暂中断。所以我一般只会在确认是解析服务本身异常时才重启服务。
还有个冷知识：在某些 Windows 版本上，DNS Client 服务会缓存一部分“由系统其他组件发起的解析结果”，这些记录即使flushdns也不一定会完全清掉。如果你遇到怎么刷都刷不干净的记录，重启服务通常能解决。
5.4 恢复默认值的方法
如果你想恢复默认，把之前新增的注册表值删掉就行。删除后系统会按内置默认值运行。
Remove-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" -Name "MaxCacheEntryTtlLimit" -ErrorAction SilentlyContinue Remove-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" -Name "MaxNegativeCacheTtl" -ErrorAction SilentlyContinue然后用ipconfig /flushdns清空已有缓存，让系统回到默认状态。如果机器上配置过组策略，那就需要先解除组策略的下发值，因为策略值优先于本地注册表值。
5.5 别忘了检查 DNS 服务器侧策略
最后提醒一个很多人忽略的点：你改了客户端缓存容量，不代表内网 DNS 服务器也这么认为。
有些内网 DNS 服务器会强制执行较短的 TTL，甚至支持“忽略客户端请求的 TTL”这种策略性覆盖。这种情况下，你在 Windows 本机再怎么调 TTL 上限，也架不住服务器返回的 TTL 就是 60 秒。
所以做这套优化时，尽量两边一起看。客户端改缓存策略，服务器侧调 TTL 分发策略，两边配合才能达到最好的效果。我曾经见过一个项目，客户端优化做了半天，最后发现 DNS 服务器上某个“安全加固”选项把 TTL 全压到了 30 秒，这就不是客户端能解决的问题了。
我个人的习惯是，每次调完客户端参数，都会在服务器侧用nslookup -type=A -nosearch对着几个关键域名查一下实际返回的 TTL，再对比客户端缓存里的 TTL，两边对得上才说明整个链路真的在按预期工作。这套优化做完后，也别急着删备份，观察一两周再收尾，你会发现收获的不仅是速度提升，还有对整个内网域名解析链路的重新认知。
