一、 故障背景与现象还原
场景描述：某中型制造企业近期反馈，部分研发部门的员工在使用Chrome浏览器访问外部技术论坛和下载开源代码库时，出现页面加载极慢、视频卡顿甚至图片无法显示的问题。然而，同一时间段内，财务部门和使用同一出口路由器的其他员工则无此异常。初步判断为局部网络配置或特定协议兼容性问题。
用户反馈细节：
- 访问百度、Google等国内主流搜索引擎正常。
- 访问GitHub、Stack Overflow等海外资源时，DNS解析迅速（通常 “网络和共享中心” > “更改适配器设置”。右键点击当前使用的以太网/Wi-Fi适配器，选择 “属性”。双击 “Internet 协议版本 4 (TCP/IPv4)”，点击 “高级”，取消勾选 “自动Metric”，在底部找到 “接口 MTU”，手动输入 1450，保存退出。
- 通过命令行修改（更精准）：
以管理员身份运行 CMD，输入以下命令：
netsh interface ipv4 set subinterface "本地连接" mtu=1450 store=persistent
（注：“本地连接”需替换为实际的适配器名称，可通过netsh interface ip show config查看）。使用store=persistent确保重启后设置依然生效。 - Ping测试：再次运行
ping github.com -f -l 1472，若能成功，说明调整有效（若仍失败，可将MTU进一步降至1400重试）。 - 实际浏览测试：清除浏览器缓存，重新访问之前卡顿的网站，观察加载速度和图片渲染情况。
- 抓包确认：使用Wireshark过滤TCP流，确认不再有重传率过高的TCP段。
方案二：启用路径MTU发现（PMTUD）的强制响应
如果在Windows Server环境或特定应用场景下，可以修改注册表以忽略ICMP不可达消息的影响，但这通常不是最佳实践，因为可能导致更大的数据包持续被丢弃，浪费带宽。
方案三：网络设备侧优化（长期根治）
联系网络团队，检查出口防火墙的策略。确保防火墙允许 ICMP Type 3 Code 4 (Fragmentation Needed) 报文通过，或者在防火墙上为出向流量配置适当的 MSS Clamping（MSS钳制）策略，强制将TCP包的MSS值减小，从而避免大包产生。
四、 验证与复盘
完成上述调整后，执行以下验证步骤：
最终结果：将网卡MTU调整为1450后，研发人员的网页加载速度恢复正常，GitHub代码拉取流畅。同时，建议网络团队在出口防火墙上开启MSS Clamping，以解决所有通过该链路设备的通用性问题，并清理了内部DNS服务器的一周前残留的错误缓存记录，确保了整体网络的健壮性。
五、 总结与建议
企业内网访问外网缓慢是一个多因素导致的问题。在排查时，切忌盲目重启或重装驱动。应遵循 “应用层(DNS/Cache) -> 传输层(TCP/MSS) -> 网络层(IP/MTU) -> 物理层” 的自顶向下排查逻辑。对于经常访问不同网络环境的用户，保持合理的MTU配置至关重要。此外，定期监控DNS查询延迟和网络丢包率，也是预防此类性能隐患的有效手段。