故障背景与现象还原
在近期的一次企业IT运维巡检中，某中型制造企业反馈内部网络出现异常：员工反映早晨上班后打开网页速度极慢，尤其是访问非企业内部网站（如百度、知乎、GitHub等）时，加载时间长达数十秒甚至超时，而局域网内的文件共享、ERP系统访问完全正常。
初步观察发现，该问题并非发生在所有终端上，而是呈现“间歇性”和“局部性”。部分使用有线网络的部门受影响严重，而连接公司备用无线AP的区域影响较轻。网络管理员重启路由器或修改单个电脑IP后问题暂时消失，但几小时后再次复现。
初步排查与逻辑分析
面对此类“网速慢但连接通”的现象，我们排除了带宽不足和物理链路故障的可能性。通过以下步骤进行逻辑推导：
- 排查带宽瓶颈：使用网络流量监控软件查看核心交换机带宽利用率，发现出口带宽占用率仅在30%左右，排除拥堵。
- 排查物理链路：对故障频发的PC进行Ping网关和Ping外网公共DNS（如8.8.8.8）测试，结果显示TTL值正常，丢包率为0，说明物理链路和数据链路层稳定。
- 定位应用层故障：当Ping通外网IP但打开URL网页极慢时，问题高度集中在域名解析环节（DNS）。
深入诊断：DNS缓存污染
为了验证上述假设，我们在受影响的终端上执行了具体的诊断命令。首先，使用 nslookup www.example.com 命令查询某个常用网站。
关键发现：在执行查询时，观察到返回的IP地址并非该网站官方提供的最新CDN节点IP，而是一个指向不明海外服务器的IP，且响应时间（Time）显著高于正常值（超过500ms）。
进一步检查本地DNS缓存，发现系统中存在大量错误的解析记录。这种现象通常被称为“DNS缓存污染”或“DNS劫持”。在企业环境中，这往往由以下原因引起：
- 上游DNS服务器污染：企业默认使用的运营商DNS或公共DNS被恶意篡改或发生故障，返回了错误的IP地址。
- 本地设备缓存残留：Windows系统或路由器长期缓存了错误的解析结果，即使上游修复，本地设备仍读取旧缓存。
- NAT网关会话老化：部分老旧路由器在处理DNS请求时，未能正确刷新NAT映射表，导致解析响应返回错误的源IP或端口。
实战修复步骤
针对上述诊断结果，我们采取了以下三步走的修复方案，迅速恢复了网络的正常访问速度。
第一步：清除本地DNS缓存
这是最直接的应急措施。在受影响的Windows工作站上，以管理员身份运行命令提示符（CMD），输入以下命令并回车：
ipconfig /flushdns系统提示“已成功刷新DNS解析缓存”后，立即尝试访问之前缓慢的网站，速度恢复正常。此步骤解决了“客户端侧”的缓存残留问题。
第二步：更换可靠的公共DNS服务器
为了彻底根治上游DNS污染问题，我们将企业的核心路由器和接入交换机的DNS设置从默认的运营商自动获取，更改为国内外稳定、抗污染的公共DNS服务器。推荐配置如下：
- 阿里云DNS：223.5.5.5 / 223.6.6.6
- 腾讯云DNSPod：119.29.29.29
- Google DNS：8.8.8.8 / 8.8.4.4（视合规要求选用）
修改完成后，在客户端再次执行 ipconfig /flushdns 并重启浏览器，观察 nslookup 的响应IP是否指向正确的CDN节点。
第三步：配置DNS转发与过滤策略
对于企业级环境，仅修改DNS服务器可能不够。我们在核心防火墙上配置了DNS转发策略，并确保启用DNSSEC验证（如果硬件支持），以防止中间人攻击和缓存投毒。同时，关闭了客户端不必要的IPv6 DNS解析，减少解析路径的复杂性。
预防与维护建议
为避免类似故障再次发生，建议IT管理人员建立以下常态化维护机制：
- 定期监控DNS解析质量：利用自动化脚本定期检测关键业务域名的解析耗时和结果一致性，一旦发现异常立即告警。
- 双DNS冗余配置：在企业网络设备中配置主备DNS，确保其中一个不可用时能自动切换至另一个健康节点。
- 限制终端直接访问公网DNS：通过ACL（访问控制列表）禁止内部终端直接向非企业指定的DNS服务器发起请求，防止个别电脑绕过企业DNS策略导致的不一致。
总结
DNS缓存污染是造成“能Ping通但打不开网页”类故障的主要原因之一。通过清晰的逻辑排查——从物理层到应用层，从全局流量到单点解析，可以高效定位问题根源。采取“清缓存+换DNS+配策略”的组合拳，不仅能快速恢复业务，更能提升企业内网的整体稳定性和安全性。