引言：一个常见的网络“悖论”

你是否遇到过这样的场景：
在命令行输入 ping www.example.com，返回 Reply from 93.184.216.34，一切正常；但打开浏览器访问 http://www.example.com 时，却提示“无法连接”或超时？
Ping 通 ≠ 网页能打开——这看似矛盾的现象，其实暴露了网络栈中多个关键环节的故障点。今天，我将带你从 DNS 解析 开始，一步步排查到 MTU 设置，用最实用的命令和逻辑，彻底解决这个“网络迷题”。

核心原因：Ping 使用 ICMP 协议（测试底层连通性），而网页依赖 HTTP/HTTPS（基于 TCP 的应用层协议）。两者测试的协议栈层级不同，故障点可能出现在中间环节。

排查思路：从应用层到网络层的逻辑链条

网络问题的排查必须 由上至下、由易到难。以下是经过实战验证的排查顺序（从最常见到最隐蔽）：

✅ 步骤 1：确认 DNS 解析是否正确（应用层）

为什么先查 DNS？
网页地址（如 www.example.com）必须先转换为 IP 地址，否则浏览器连目标服务器都找不到。

排查命令：

# Linux/macOS
nslookup www.example.com
# 或
dig www.example.com

# Windows
nslookup www.example.com

可能的问题：

• DNS 解析错误：返回错误 IP（如 127.0.0.1）→ 本地 DNS 缓存污染或 DNS 服务器故障。
• 无响应：DNS 服务器不可达 → 检查本地 DNS 配置（如 /etc/resolv.conf 或 Windows 网络设置）。
• 解析延迟：DNS 查询耗时过长 → 可能是 DNS 服务器性能差。

解决方案：

• 清除本地 DNS 缓存：ipconfig /flushdns（Windows）或 sudo dscacheutil -flushcache（macOS）。
• 更换 DNS 服务器：尝试 8.8.8.8（Google DNS）或 114.114.114.114（阿里 DNS）。

关键点：如果 ping 用的是域名（如 ping www.example.com），说明 DNS 已解析成功；但网页打不开，问题很可能在 解析后的 IP 是否可用。

✅ 步骤 2：测试 TCP 端口连通性（传输层）

为什么查端口？
网页默认使用 80（HTTP）或 443（HTTPS） 端口。Ping 通只证明 ICMP 通，但 TCP 端口可能被防火墙拦截。

排查命令：

# 测试 HTTP 端口（80）
telnet www.example.com 80
# 或
curl -v http://www.example.com

# 测试 HTTPS 端口（443）
telnet www.example.com 443
# 或
curl -v https://www.example.com

可能的问题：

• 连接被拒绝（Connection refused）：
  → 服务器上未运行 Web 服务（如 Nginx/Apache 未启动）。
• 连接超时（Timeout）：
  → 本地防火墙（如 Windows Defender、iptables）或云服务商安全组（如阿里云安全组）阻断了 80/443 端口。
• TLS 握手失败（HTTPS）：
  → 证书过期、域名不匹配，或客户端 TLS 版本不兼容。

解决方案：

• 检查服务器服务状态：systemctl status nginx（Linux）。
• 检查防火墙规则：

# Linux (iptables)
sudo iptables -L -n | grep 80
# Windows 防火墙：控制面板 > Windows Defender 防火墙 > 高级设置

✅ 步骤 3：验证 HTTP/HTTPS 服务响应（应用层）

为什么这一步？
即使 TCP 端口通，Web 服务器可能返回错误（如 502 Bad Gateway），或浏览器因安全策略（如 HSTS）拒绝访问。

排查命令：

# 用 curl 获取响应头（忽略内容，只看状态码）
curl -I http://www.example.com
# 示例输出：HTTP/1.1 200 OK

curl -I https://www.example.com
# 示例输出：HTTP/2 200

可能的问题：

• HTTP 403/404：路径错误或权限问题。
• HTTP 5xx：服务器内部错误（如 Nginx 配置错误）。
• 证书错误（HTTPS）：域名不匹配（如 example.com 但证书是 www.example.com）。

解决方案：

• 检查服务器日志（如 Nginx 的 /var/log/nginx/error.log）。
• 用 openssl s_client -connect www.example.com:443 测试证书有效性。

✅ 步骤 4：检查 MTU 设置（网络层，终极排查）

为什么最后查 MTU？
MTU（最大传输单元）是网络层的关键参数。当 MTU 设置过小，大包会被分片，但某些设备（如老旧路由器）不处理分片，导致网页加载失败（尤其在 4G/5G 或企业网络中常见）。

排查命令：

# 测试默认 MTU（1500）是否可行
ping -f -l 1472 www.example.com  # 1472 = 1500 - 20(IP) - 8(ICMP)
# 说明：-f 为不分片，-l 设置数据长度（1472+28=1500）

# 如果丢包，逐步减小测试包
ping -f -l 1400 www.example.com
ping -f -l 1300 www.example.com

可能的问题：

• 丢包（Request timed out）：
  → MTU 超出网络路径限制（如 PPPoE 网络 MTU 通常为 1492）。
• 网页加载缓慢/卡顿：
  → 分片导致额外延迟。

解决方案：

• 临时调整 MTU（Windows）：

netsh interface ipv4 set subinterface "以太网" mtu=1492 store=persistent

• 永久修复：
  在路由器或网卡驱动中设置 MTU 为 1492（PPPoE）或 1500（以太网）。

为什么 MTU 问题容易被忽略？
因为 Ping 通（ICMP 小包）和 TCP 连接（小包）可能正常，但 HTTP 请求包较大（如 HTML/CSS） 会被丢弃，导致“网页打不开”。

关键结论

1. Ping 通 ≠ 网络可用：它只测试 ICMP，不涉及 HTTP 服务。
2. 排查优先级：
   DNS → 端口连通性 → HTTP 响应 → MTU（90% 问题出在前3步）。
3. MTU 是“隐形杀手”：尤其在移动网络或企业环境中，需作为最后检查项。

真实案例：某阿里云用户反馈“ping 通但网页打不开”，排查发现：

DNS 解析正确 → 服务器端口被安全组屏蔽 → 修复安全组后问题解决。

（MTU 问题仅占 5% 的案例）

最后提醒：网络问题没有“万能解药”，但 按顺序排查 能让你在 5 分钟内定位 90% 的故障。下次遇到“ping 通但网页打不开”，别慌！从 DNS 开始，一步步走，你也能成为网络排查高手。