Linux 无法 Telnet 是运维工作中常见的网络故障，其核心原因通常归结为服务端服务未启动、防火墙策略拦截、端口监听异常或网络层连接问题，解决这一问题需要遵循从系统层到网络层的排查逻辑，首先确认服务状态，其次检查安全策略，最后验证网络连通性，在排查过程中，必须注意 Telnet 协议本身的安全性缺陷，建议在问题解决后评估是否迁移至 SSH 协议。
服务端 Telnet 服务状态检查
排查的第一步是确认目标 Linux 主机是否已经安装并启动了 Telnet 服务，Telnet 在 Linux 中通常由 xinetd 管理，或者作为独立的 systemd 服务运行，如果服务未启动，客户端的连接请求将被直接拒绝。
检查是否已安装 Telnet 服务端软件包，对于基于 RPM 的系统（如 CentOS、RHEL），可以使用 rpm -qa | grep telnet-server 进行查询；对于基于 Debian 的系统（如 Ubuntu），则使用 dpkg -l | grep telnetd，如果未安装，需使用 yum 或 apt 进行安装，安装完成后，必须启动服务，对于较新的系统版本，通常使用 systemctl start telnet.socket 启动服务，并使用 systemctl enable telnet.socket 设置开机自启，对于依赖 xinetd 的旧系统，则需要修改 /etc/xinetd.d/telnet 配置文件，将 disable 的值改为 no，随后重启 xinetd 服务。
Telnet 服务默认监听的是 23 号端口，如果服务启动失败，可能是配置文件中的端口设置被修改，或者该端口已被其他进程占用，使用 netstat -tunlp | grep :23 或 ss -tunlp | grep :23 可以确认端口是否处于正常的 LISTEN 状态，如果端口未监听，任何防火墙层面的放行都是徒劳的。
防火墙与 SELinux 策略排查
在确认服务正常运行且端口处于监听状态后,防火墙拦截是导致无法 Telnet 的最常见原因，现代 Linux 发行版默认使用 firewalld 或 iptables 作为防火墙管理工具。
如果系统运行的是 firewalld，必须检查 public 区域（或其他活动区域）是否允许 TCP 23 端口的流量，可以使用 firewall-cmd --list-ports 查看放行的端口列表，23 端口不在列表中，需执行 firewall-cmd --zone=public --add-port=23/tcp --permanent 添加规则，并执行 firewall-cmd --reload 使配置生效，对于使用 iptables 的系统，需检查规则链中是否有 REJECT 或 DROP 针对 23 端口的策略，并添加相应的 ACCEPT 规则。
除了防火墙,SELinux（Security-Enhanced Linux） 的强制访问控制机制也经常被忽视，当 SELinux 处于 Enforcing 模式时，它可能会阻止 Telnet 服务监听网络端口或阻止用户登录，可以使用 getsebool 命令查看 Telnet 相关的布尔值，执行 setsebool -P telnet_disable_trans 1 可以尝试禁用 Telnet 的域转换，或者根据安全策略调整 telnet_enabled 等参数，在排查过程中，临时将 SELinux 模式设置为 Permissive（使用 setenforce 0）有助于快速判断是否为 SELinux 导致的问题。
网络连通性与端口监听验证
当服务端配置无误时,问题可能出在网络层面，此时需要使用 ping 命令测试基础的网络连通性，如果无法 Ping 通目标主机，说明存在物理链路中断、路由配置错误或网关问题，这与 Telnet 服务本身无关，属于底层网络故障。
在基础连通性正常的情况下,Telnet 连接超时 通常意味着防火墙丢弃了数据包，而连接被拒绝（Connection refused） 则通常指目标端口未监听，为了更精准地定位问题，可以使用 nc（Netcat）或 telnet 命令自身进行端口探测，执行 telnet <目标IP> 23，如果屏幕显示 Trying... 随后长时间无响应，即为超时，大概率是防火墙问题；如果立即显示 Connection refused，则应回到服务端检查服务状态和端口监听。
网络中间设备（如硬件防火墙、云安全组、路由器 ACL）也可能拦截 23 端口流量，在云服务器环境中，务必登录云控制台检查安全组入站规则，确保 TCP 23 端口已对源 IP 地址放行，这是运维人员容易遗漏的外部防线。
客户端环境与配置验证
虽然大多数问题出在服务端,但客户端的配置异常也可能导致连接失败，确认客户端机器上安装了 Telnet 客户端软件，在最小化安装的 Linux 系统中，可能需要运行 yum install telnet 或 apt install telnet 进行安装。
检查客户端本地是否有防火墙限制出站连接,或者本地 hosts 文件是否有错误的 IP 地址映射，如果是在 Windows 客户端进行测试，需确保 Windows Defender 防火墙或其他杀毒软件没有阻止 Telnet 客户端的运行。
安全建议与替代方案
在解决 Linux 无法 Telnet 的故障后，必须从安全角度进行专业评估。Telnet 协议采用明文传输数据，这意味着账号、密码及传输内容在网络中极易被嗅探软件截获，存在严重的安全隐患，根据 E-E-A-T 原则中的安全最佳实践，强烈建议在生产环境中禁用 Telnet，全面迁移至 SSH（Secure Shell）协议。
SSH 通过加密技术保护所有传输数据，有效防止了中间人攻击和数据窃听，如果必须使用 Telnet（例如某些老旧硬件设备的配置需求），应将其限制在受信任的内网环境中，并配合 TCP Wrappers（/etc/hosts.allow 和 /etc/hosts.deny）严格限制允许访问的源 IP 地址，最大程度降低安全风险。
相关问答
Q1：为什么 Telnet 连接时显示 “Escape character is ‘^]'” 但无法登录？
A1：看到 “Escape character is ‘^]'” 提示符，说明 TCP 三次握手已经成功建立，客户端与服务端的 23 端口网络连通性正常，防火墙和服务监听均无问题，此时无法登录通常是由于服务端的认证配置问题、PAM 模块配置错误、或者用户 Shell 设置异常，建议检查 /etc/pam.d/login 配置文件以及 /etc/passwd 中用户的登录 Shell 是否有效。
Q2：如何在不重启服务的情况下实时查看 Telnet 的连接日志？
A2：Telnet 的日志通常记录在 /var/log/messages 或 /var/log/secure 文件中（取决于 Linux 发行版和 syslog 配置），可以使用 tail -f /var/log/secure 命令实时追踪日志，如果日志中没有相关信息，可能需要修改 rsyslog 配置以增加日志详细级别，或者在测试时使用 tcpdump -i any port 23 -w telnet.pcap 抓包分析数据流交互细节，从而定位断开连接的具体环节。
希望以上排查思路能帮助您快速解决 Linux 无法 Telnet 的问题，如果您在操作过程中遇到其他特殊情况，欢迎在评论区分享具体的报错信息或配置细节，我们将共同探讨解决方案。
