Ping 通代表网络层可达，Telnet 不通通常是传输层被拦或服务没监听，优先查防火墙规则和服务绑定地址。
先说结论：这是典型的 ICMP 通但 TCP 不通，问题多半出在防火墙策略或服务监听配置上，而非物理网络中断。
- 先确认：服务是否真正监听在 0.0.0.0 而非 127.0.0.1
- 先处理：检查本地防火墙及云平台安全组是否放行 TCP 端口
- 再验证：使用 telnet 或 nc 命令测试端口连通性是否恢复
常用命令速查
# 检查端口监听状态 (推荐 ss 命令)
ss -tlnp | grep :端口号# 检查防火墙状态 (CentOS/RHEL)
firewall-cmd `--list-all`# 检查防火墙状态 (Ubuntu)
ufw status# 放行特定端口 (CentOS/RHEL 安全方式)
firewall-cmd `--add-port`=端口/tcp `--permanent` && firewall-cmd `--reload`# 测试端口连通性
telnet IP 端口
# 或使用 nc
nc -zv IP 端口故障原理
Ping 命令基于 ICMP 协议，只要网络层路由可达且未被禁 ping，就能通。而 Telnet 基于 TCP 协议，需要三次握手成功。如果防火墙只放行了 ICMP 但拦截了特定 TCP 端口，或者服务只监听了本地回环地址（127.0.0.1），就会出现 Ping 通但 Telnet 不通的现象。这通常不是网线断了，而是策略或服务配置在某一层拦下了业务流量。
分步排查与修复
第一步：确认服务监听状态
在目标服务器上执行ss -tlnp | grep :端口号。查看 Local Address 列，如果显示127.0.0.1:端口，说明服务只允许本机访问。需修改服务配置为监听0.0.0.0或具体公网 IP，并重启服务。
第二步：检查本地防火墙
Linux 发行版自带防火墙可能默认丢弃入站 TCP 请求。CentOS/RHEL 使用firewall-cmd `--list-ports`查看是否开放端口，未开放则执行firewall-cmd `--add-port`=端口/tcp `--permanent`后重载。Ubuntu 可使用ufw status查看，必要时ufw allow 端口。注意：生产环境严禁直接关闭防火墙，应通过放行特定端口测试。
第三步：检查云平台安全组
如果服务器在云上（如阿里云、腾讯云、AWS），实例内部的防火墙放行后，还需检查控制台的安全组规则。确保入方向允许对应端口及源 IP 段，云平台安全组优先级通常高于系统内部防火墙。提示：安全组规则修改后可能有 1-5 分钟延迟，若未生效请稍后重试。
第四步：排查中间设备
若上述均正常，可能是中间网络设备（如企业网关、运营商设备）做了 TCP 限速或深度包检测。可尝试更换网络环境（如手机热点）对比测试，或联系网络管理员确认是否存在 TCP 层策略。
验证与回滚方案
完成配置后，在客户端再次执行telnet IP 端口。若显示Connected to...则成功。若仍超时，可使用nc -zv IP 端口进行更详细的连接测试。对于 Web 服务，也可尝试curl -v http://IP:端口查看是否有 HTTP 响应头返回。
故障回滚：若放行端口后出现安全风险或无需该端口，请及时移除规则。CentOS/RHEL 回滚命令：firewall-cmd `--remove-port`=端口/tcp `--permanent` && firewall-cmd `--reload`。Ubuntu 回滚命令：ufw delete allow 端口。
常见坑点
1. 绑定地址错误：服务启动但只绑定了 127.0.0.1，外部无法访问，需检查 Nginx、Redis 等配置文件中的 listen 或 bind 参数。
2. 安全组未生效：云平台修改安全组规则后有时需要几分钟生效，或规则顺序错误导致被前一条拒绝规则拦截。
3. IPv6 干扰：部分服务默认监听 IPv6，而测试使用的是 IPv4 地址，需确认协议栈匹配。
4. 服务假死：进程存在但端口未真正监听，需结合ss或netstat确认端口状态而非仅看进程名。
原文链接：https://www.zjcp.cc/ask/10884.html