ping通但curl或telnet连不上，说明ICMP通而TCP不通，常见原因有6种：1.服务绑定127.0.0.1；2.防火墙/安全组拦截端口；3.NAT或回程路由异常；4.ECMP路径不一致；5.Docker MTU不匹配；6.中间设备静默丢包。
ping 通但 curl 或 telnet 连不上，说明 ICMP 层通了，TCP 层却卡住了。这不是“网络断了”，而是协议、配置或策略在某一层悄悄拦下了业务流量。下面6种情况最常见，按排查优先级和发生频率排序，每种都附关键判断方法和验证动作。
1. 目标服务未监听外部地址（绑定地址错误）
服务只绑定了 127.0.0.1，能本地 curl，但外部连不上。ping 通是因为 ICMP 不受绑定限制。
- 执行 ss -tlnp | grep :端口号，看 Local Address 列：若显示 127.0.0.1:80，就是问题所在
- 应改为 *:80 或 0.0.0.0:80（具体看服务配置，如 Nginx 的 listen、Redis 的 bind）
- 改完重启服务，并用 ss -tlnp 确认输出已变
2. 防火墙/安全组拦截 TCP 流量
ICMP 放行，但 80/443/3306 等端口被显式 DROP —— 云平台和企业防火墙的默认策略常如此。
- 服务端检查：firewall-cmd --list-ports（CentOS/RHEL）或 ufw status（Ubuntu）
- 确认是否开放目标端口，没开就加规则，例如：firewall-cmd --add-port=80/tcp --permanent
- 别忘了检查云厂商控制台的安全组规则，确保入方向允许对应端口+源 IP 段
3. NAT 映射不完整或回包路径异常
公网设备做了静态 NAT，但只映射了 ICMP，或映射了端口却没配好回程路由，导致请求能到、响应发不回来。
- 在目标服务器上抓包：tcpdump -i any port 端口号 and host 客户端IP
- 如果看到 SYN 包进来，但没发 SYN+ACK 出去 → 服务没响应或内核丢弃
- 如果 SYN 进来、SYN+ACK 也发出去了，但客户端收不到 → 回程路径问题（如多出口、策略路由错配）
4. 多路径/ECMP 导致请求与响应走不同链路
ping 走的是“好”路径，HTTP 请求走主链路，回包却误入备链路，而备链路缺 NAT 或 ACL 规则，导致连接失败。
- 对比两次 traceroute：traceroute -T -p 80 目标IP 和 traceroute 目标IP
- 若路径明显不一致，尤其回程跳数异常，需检查出口设备的会话保持、源地址转换或策略路由配置
- 临时测试可关闭备用路由或强制绑定单网卡测试
5. Docker 或容器网络 MTU 不匹配
主机网卡 MTU 是 1500，Docker 默认桥接网卡是 1500，但某些云环境（如阿里云 VPC）底层 MTU 实际为 1450，导致 TCP 分片被丢，curl 卡在三次握手。
- 查主机网卡 MTU：ip link show eth0 | grep mtu
- 查 docker0：ip link show docker0 | grep mtu
- 不一致时，编辑 /etc/docker/daemon.json，加入 "mtu": 1450，再重启 docker
6. 应用层连接被中间设备静默丢弃
代理、WAF、负载均衡器等设备未返回 RST，也不转发 SYN，而是直接丢包——表现为 telnet/curl 卡在 “Trying…” 后超时。
- 用 timeout 3 nc -zv 目标IP 端口 快速验证是否 TCP 层就断了
- 换用不同客户端（如从另一台机器、手机热点）直连测试，排除本机出口设备问题
- 若仅特定域名不通，但同 IP 其他端口或 IP 直连正常，重点查 DNS 解析结果是否被劫持或指向了错误节点
