故障现象：看似正常的网络连接突然“罢工”
在某中型制造企业IT支持中心，周一上午突然接到多起投诉：财务部的同事反映ERP系统登录界面一直转圈，最终提示“服务器连接超时”；同时，部分研发人员的内网Wiki页面也无法加载。然而，IT工程师在尝试远程连接故障电脑时，发现一个简单的现象：执行 ping 192.168.1.100（ERP服务器IP）能够收到回复，延迟稳定在1ms以内。这意味着物理链路和网络层通信完全正常。
既然Ping测试通过，为什么基于TCP/IP的应用层服务却无法连接？经过初步排查，工程师排除了防火墙策略变更和服务器宕机的可能性。问题最终锁定在一个隐蔽的网络环节——DNS解析异常。这就是典型的“DNS缓存污染”或“DNS解析劫持”故障场景。
故障复盘：从Ping通到应用断连的逻辑断裂
要理解这个故障，需要理清计算机访问网络资源的流程：
- DNS查询：用户输入域名（如
erp.company.com）。 - 本地缓存查找：操作系统首先在本地DNS缓存中查找是否有该域名对应的IP映射。
- 向DNS服务器请求：若本地没有，则向配置的DNS服务器发起查询。
- 建立连接：获取正确的IP地址后，客户端向该IP发起TCP连接。
在本案例中，Ping IP地址成功，说明第4步的路由是通的。但应用层无法访问，极大概率发生在第2或第3步。当本地DNS缓存中被注入了错误的IP记录（例如指向了一个错误的内部测试服务器，或者被恶意软件篡改指向钓鱼网站），即使底层网络畅通，应用程序也会连接到错误的目标，从而导致“连接超时”或“拒绝访问”。
核心排查步骤与解决方案
针对此类“Ping通但服务不可用”的故障，建议按照以下步骤进行标准化排查：
第一步：验证DNS解析结果
首先确认客户端获取到的IP地址是否正确。在故障电脑上打开命令提示符（CMD），执行以下命令：
nslookup erp.company.com
分析： - 如果返回的IP地址与实际服务器IP不一致，则确认为DNS解析错误。 - 如果返回IP正确，但仍无法连接，需检查该IP是否对应多个端口或服务，或存在其他中间件拦截。
第二步：清除本地DNS缓存
这是解决DNS缓存污染最直接有效的方法。Windows系统会缓存DNS查询结果以提高效率，但这也可能导致旧错误或被污染的记录长期驻留。
操作：
1. 以管理员身份运行“命令提示符”。
2. 输入命令：ipconfig /flushdns
3. 看到“已成功刷新DNS解析缓存”提示后，再次尝试访问服务。
注意：清除缓存仅对当前会话生效。如果问题是路由器或上游DNS服务器导致的，清除本地缓存后，再次查询仍可能得到错误结果。
第三步：检查Hosts文件配置
有时，恶意软件或不当的系统维护会在本地Hosts文件中添加静态映射规则，强制覆盖DNS查询结果。
操作：
1. 打开路径：C:\Windows\System32\drivers\etc\hosts。
2. 使用记事本打开该文件。
3. 检查是否有针对故障域名（如 erp.company.com）的行。
示例异常条目：
127.0.0.1 erp.company.com （这将导致访问被重定向到本机，从而无法连接远程服务器）
如果发现可疑条目，将其删除或注释掉（在行首加 #），保存文件后重试。
第四步：排查路由器DHCP分配的DNS地址
如果大量用户同时出现类似问题，且清除本地缓存无效，问题很可能出在网络出口设备。检查故障电脑获取到的DNS服务器地址。
操作：
1. 在CMD中输入 ipconfig /all。
2. 查看“DNS服务器”字段，确认其是否为预期的企业内网DNS地址（如 192.168.1.10）。
风险点：
- 如果DHCP分配的是公共DNS（如 114.114.114.114 或 8.8.8.8），而企业内网资源需要通过内网DNS解析私有IP，那么外网DNS将无法解析内网域名，导致“Ping通IP但域名解析失败”。
- 某些劣质路由器或遭受劫持的光猫，可能会将DNS请求重定向到其内置的广告解析服务器，导致部分域名解析为错误IP。
第五步：更换备用DNS进行测试
为了快速定位是本地DNS服务器故障还是网络劫持，可以手动临时更改DNS设置。
操作：
1. 进入“网络和共享中心” -> “更改适配器设置”。
2. 右键网卡 -> “属性” -> 双击“Internet 协议版本 4 (TCP/IPv4)”。
3. 手动指定首选DNS为 223.5.5.5（阿里DNS）或 119.29.29.29（腾讯DNS）。
如果更换后恢复正常，说明原企业内部DNS服务器存在配置错误或遭受攻击，需进一步联系网络管理员检查DNS服务日志。
预防与维护建议
为了避免此类故障频发，建议采取以下措施：
- 实施DNS监控：在ITSM系统中配置对关键业务域名解析结果的定期轮询监控，一旦发现解析IP异常，立即告警。
- 规范DHCP配置：确保企业内网终端优先使用内部权威DNS服务器，仅在内网DNS失效时才回退至公共DNS。
- 加强Endpoint防护：部署EDR或防病毒软件，监控
hosts文件的变更行为，防止恶意软件篡改本地解析配置。
通过网络故障的案例复盘，我们可以看到，Ping通并不等于全链路可用。作为IT专业人员，在面对应用层故障时，必须结合OSI模型逐层排查，特别是容易被忽视的DNS解析环节，才能高效定位并解决“幽灵”般的网络问题。