admin管理员组

文章数量:1130349

文章目录

  • 一、问题场景
  • 二、ping命令的工作过程
  • 三、五个常见盲区
    • 1. ping 通 ≠ 应用通，是两回事！
    • 2. 防火墙策略拦了 TCP，但 ICMP 没管
    • 3. 服务监听了 127.0.0.1，没有监听实际 IP
    • 4. 路由表正常但回程不通，流量回来走错了
    • 5. MTU/丢包/ACL：最后的“看不见的问题”
  • 结尾

一、问题场景

你是不是也遇到过这种情况：

  • 明明 ping 能通目标服务器
  • 但 telnet、curl、网页死活连不上
  • 有时候甚至能打开首页，点个功能就断了
  • 客户问你是不是网络不通，你看着 ping 一脸懵逼

二、ping命令的工作过程

我们先了解一下「ping」命令的工作过程：
假设有两个主机，主机A（192.168.0.1）和主机B（192.168.0.2），现在我们要监测主机A和主机B之间网络是否可达，

在主机A上输入命令：ping 192.168.0.2

能 ping 不代表服务能正常访问，这个问题根本不是“网络通不通”这么简单，而是牵涉了五个常见盲区。

三、五个常见盲区

1. ping 通 ≠ 应用通，是两回事！

首先把一件事讲清楚：

  • ping 用的是 ICMP 协议
  • 网页访问、API 调用、数据库连接，用的是 TCP 或 UDP

    很多网络设备（尤其是防火墙、云主机）对这两类协议的处理逻辑是完全不同的。

所以出现这种情况其实非常常见：

  • ICMP 放行了，ping 没问题
  • TCP/UDP 被策略拦了，服务访问挂了

所以第一件事不是继续 ping，而是换工具测试目标端口，比如：

telnet 192.168.1.10 80
curl http://192.168.1.10
nc -zv 192.168.1.10 80

这才是“服务是否可达”的基本测试手段。

2. 防火墙策略拦了 TCP，但 ICMP 没管

这个是最常见的根源。

很多防火墙策略长这样：

allow icmp any any
deny tcp any any

特别是在云上（阿里云、华为云、腾讯云）或企业用堡垒机出口的环境中，一大堆默认规则允许 ping，却默认拦掉了 80/443/3306 这些服务端口。

怎么排查？

  • 看 安全组 / 防火墙策略 是否只允许 ICMP，其他都被 Drop
  • 在服务端看监听状态，用 netstat -ntlp、ss -ntlp 看是否在监听
  • 配合 tcpdump 抓包，看包是不是到了但没回应

3. 服务监听了 127.0.0.1，没有监听实际 IP

这个坑新手容易踩，比如部署 Nginx、MySQL、Redis 时：

你启动服务了，它确实也在跑，但你访问不了。

为啥？

看监听地址：

ss -ntlp

输出是这样：

LISTEN 0 128 127.0.0.1:6379 ...

那你从外部访问 192.168.1.10:6379 肯定不通啊，因为服务只监听了 localhost，根本没绑定在你实际的网卡 IP 上。

改服务配置，把监听地址从 127.0.0.1 改成 0.0.0.0 或实际网卡 IP，就好了。

4. 路由表正常但回程不通，流量回来走错了

这个问题在双网卡、双出口的机器上特别常见。

表现就是：

  • ping 没问题（因为 ICMP 是对等的）
  • telnet、HTTP 连接超时（尤其是三次握手不成功）

原因在于：

  • 请求是从网卡 eth0 发出去的
  • 返回却走 eth1，结果对端收不到回包
  • 表现就是 ping 通，服务死

怎么查？

  • 用 traceroute 和 tcpdump 同时看入站和出站接口
  • 把服务器的路由表 ip route 输出看清楚
  • 尝试只绑定一个网卡、关闭第二个默认路由试试

这种问题看着像网络问题，其实是服务器自身的问题，很多时候和网络设备毫无关系。

5. MTU/丢包/ACL：最后的“看不见的问题”

有时候你以为是“访问不了”，其实是大包被截断了。

比如：

  • ping 默认包 56 字节，可以通
  • 业务发的 TCP 包是 1460 字节，被中间设备丢掉了

常见的场景是：

  • IPSEC/VPN 通道、GRE 隧道里走了应用
  • 没调 MTU，或者中间丢包严重

解决办法：

  • 用 ping -s 1500 -M do 检查最大传输单元
  • 用 iperf 测一下通道质量
  • 用 tcpdump 看看是否三次握手卡在 SYN-ACK

结尾

一眼就能定位的排查思路，送你一张表

能 ping 通telnet 不通常见原因
是是1. 防火墙策略拦 TCP
2. 服务监听错地址
3. 路由/回程异常
4. 端口未监听
是页面能开一半MTU 问题 / 中间设备丢包 / CDN 异常
是不通，但服务本地能连上网络 ACL/云安全组/回程路由问题

所以，“ping 通却访问不了服务”并不稀奇，这个问题基本三两眼就能定位，因为他们心里有这张排查逻辑图：
第一步：协议是否一致（ICMP vs TCP）
第二步：服务监听没问题（IP、端口）
第三步：路径是否通（ACL、防火墙、策略路由）
第四步：抓包分析是否有回包（排查 MTU、NAT、回程问题）

文章目录

  • 一、问题场景
  • 二、ping命令的工作过程
  • 三、五个常见盲区
    • 1. ping 通 ≠ 应用通，是两回事！
    • 2. 防火墙策略拦了 TCP，但 ICMP 没管
    • 3. 服务监听了 127.0.0.1，没有监听实际 IP
    • 4. 路由表正常但回程不通，流量回来走错了
    • 5. MTU/丢包/ACL：最后的“看不见的问题”
  • 结尾

一、问题场景

你是不是也遇到过这种情况：

  • 明明 ping 能通目标服务器
  • 但 telnet、curl、网页死活连不上
  • 有时候甚至能打开首页，点个功能就断了
  • 客户问你是不是网络不通，你看着 ping 一脸懵逼

二、ping命令的工作过程

我们先了解一下「ping」命令的工作过程：
假设有两个主机，主机A（192.168.0.1）和主机B（192.168.0.2），现在我们要监测主机A和主机B之间网络是否可达，

在主机A上输入命令：ping 192.168.0.2

能 ping 不代表服务能正常访问，这个问题根本不是“网络通不通”这么简单，而是牵涉了五个常见盲区。

三、五个常见盲区

1. ping 通 ≠ 应用通，是两回事！

首先把一件事讲清楚：

  • ping 用的是 ICMP 协议
  • 网页访问、API 调用、数据库连接，用的是 TCP 或 UDP

    很多网络设备（尤其是防火墙、云主机）对这两类协议的处理逻辑是完全不同的。

所以出现这种情况其实非常常见：

  • ICMP 放行了，ping 没问题
  • TCP/UDP 被策略拦了，服务访问挂了

所以第一件事不是继续 ping，而是换工具测试目标端口，比如：

telnet 192.168.1.10 80
curl http://192.168.1.10
nc -zv 192.168.1.10 80

这才是“服务是否可达”的基本测试手段。

2. 防火墙策略拦了 TCP，但 ICMP 没管

这个是最常见的根源。

很多防火墙策略长这样：

allow icmp any any
deny tcp any any

特别是在云上（阿里云、华为云、腾讯云）或企业用堡垒机出口的环境中，一大堆默认规则允许 ping，却默认拦掉了 80/443/3306 这些服务端口。

怎么排查？

  • 看 安全组 / 防火墙策略 是否只允许 ICMP，其他都被 Drop
  • 在服务端看监听状态，用 netstat -ntlp、ss -ntlp 看是否在监听
  • 配合 tcpdump 抓包，看包是不是到了但没回应

3. 服务监听了 127.0.0.1，没有监听实际 IP

这个坑新手容易踩，比如部署 Nginx、MySQL、Redis 时：

你启动服务了，它确实也在跑，但你访问不了。

为啥？

看监听地址：

ss -ntlp

输出是这样：

LISTEN 0 128 127.0.0.1:6379 ...

那你从外部访问 192.168.1.10:6379 肯定不通啊，因为服务只监听了 localhost，根本没绑定在你实际的网卡 IP 上。

改服务配置，把监听地址从 127.0.0.1 改成 0.0.0.0 或实际网卡 IP，就好了。

4. 路由表正常但回程不通，流量回来走错了

这个问题在双网卡、双出口的机器上特别常见。

表现就是：

  • ping 没问题（因为 ICMP 是对等的）
  • telnet、HTTP 连接超时（尤其是三次握手不成功）

原因在于：

  • 请求是从网卡 eth0 发出去的
  • 返回却走 eth1，结果对端收不到回包
  • 表现就是 ping 通，服务死

怎么查？

  • 用 traceroute 和 tcpdump 同时看入站和出站接口
  • 把服务器的路由表 ip route 输出看清楚
  • 尝试只绑定一个网卡、关闭第二个默认路由试试

这种问题看着像网络问题，其实是服务器自身的问题，很多时候和网络设备毫无关系。

5. MTU/丢包/ACL：最后的“看不见的问题”

有时候你以为是“访问不了”，其实是大包被截断了。

比如：

  • ping 默认包 56 字节，可以通
  • 业务发的 TCP 包是 1460 字节，被中间设备丢掉了

常见的场景是：

  • IPSEC/VPN 通道、GRE 隧道里走了应用
  • 没调 MTU，或者中间丢包严重

解决办法：

  • 用 ping -s 1500 -M do 检查最大传输单元
  • 用 iperf 测一下通道质量
  • 用 tcpdump 看看是否三次握手卡在 SYN-ACK

结尾

一眼就能定位的排查思路，送你一张表

能 ping 通telnet 不通常见原因
是是1. 防火墙策略拦 TCP
2. 服务监听错地址
3. 路由/回程异常
4. 端口未监听
是页面能开一半MTU 问题 / 中间设备丢包 / CDN 异常
是不通，但服务本地能连上网络 ACL/云安全组/回程路由问题

所以，“ping 通却访问不了服务”并不稀奇，这个问题基本三两眼就能定位，因为他们心里有这张排查逻辑图：
第一步：协议是否一致（ICMP vs TCP）
第二步：服务监听没问题（IP、端口）
第三步：路径是否通（ACL、防火墙、策略路由）
第四步：抓包分析是否有回包（排查 MTU、NAT、回程问题）

本文标签： 解决方案ping

版权声明：本文标题：ping 得通却访问不了服务的问题解决方案 内容由热心网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：https://it.en369.cn/jiaocheng/1763394546a2928466.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。