我见过太多跑在Windows Server上的禁用站点，明明配置不低，核缓访问量一大就卡死。存降排查到最后，低漏洞影十有八九是禁用IIS内核缓存惹的祸。这东西默认开着，核缓本意是存降好的——把频繁请求的动态页面输出暂存在内核态，省得每次都得跑一遍ASP.NET或PHP。低漏洞影但问题在于，禁用它缓存的核缓不只是正常响应，还有HTTP错误码和重定向结果。存降

去年帮一家电商公司处理过一回故障。低漏洞影他们的禁用登录接口突然被刷，攻击者用不同的核缓User-Agent反复试探弱口令。IIS内核缓存把那些401、存降403响应全存了下来，后续的合法用户请求居然直接命中了被缓存的拒绝页面。结果就是，正常用户明明输对了密码，却被服务器当成攻击者挡在门外。更麻烦的是，清缓存得重启W3SVC服务，业务中断好几分钟。

内核缓存的另一个坑在于它绕过了应用层的安全过滤。你的WAF或自定义中间件可能已经识别出某个请求是恶意的，返回了拦截页面。但内核缓存不关心这些，它只认URL和查询字符串。同一个恶意URL第二次访问时，请求根本到不了应用层，直接在内核态就返回了缓存的拦截结果。攻击者可以利用这一点做缓存投毒——先发一个带恶意参数的请求骗过WAF，让内核缓存记下响应，然后诱导其他用户访问同一个URL，拿到被污染的内容。

禁用这东西的步骤不复杂。打开IIS管理器，选中站点，进入“输出缓存”功能，把默认的“内核缓存”勾选项去掉。或者更彻底一点，在applicationHost.config里把serverRuntime节的appConcurrentRequestLimit和frequentHitThreshold调低，让内核缓存几乎不生效。但光改设置不够，得记得重启IIS服务，不然旧缓存还在内存里待着。

有人担心禁用后性能下降。说实话，对绝大多数中小型站点来说，那点性能损耗根本感知不到。现代应用框架本身就有自己的缓存机制，比如ASP.NET Core的ResponseCaching中间件，或者Redis分布式缓存，它们能更智能地判断哪些内容值得缓存，哪些必须实时生成。内核缓存这种一刀切的粗暴方案，早该退场了。

我自己的服务器从2019年起就禁用了IIS内核缓存，换来的是更稳定的安全日志——每个恶意请求都能在应用层被完整记录，不会因为命中缓存而丢失攻击痕迹。做安全分析的时候，数据完整比那零点几毫秒的响应时间重要得多。

别等到被刷了才想起来改配置。打开你的IIS管理器，花两分钟把内核缓存关掉，然后观察一周日志。你会发现，那些之前莫名其妙的间歇性访问故障，多半就跟着消失了。