解决Final Shell连接CentOS7时java.net.ConnectException: Connection refused的实战指南

1. 问题现象与初步排查

最近重装Windows10系统后，很多开发者都遇到了一个典型问题：使用Final Shell连接CentOS7虚拟机时，突然出现"java.net.ConnectException: Connection refused"错误。这个错误表面看是连接被拒绝，但背后可能隐藏着多种原因。我自己在帮团队排查这个问题时，发现重装系统后整个网络环境都变了，导致虚拟机和主机之间的通信完全中断。

首先我们需要明确几个关键现象：主机ping不通虚拟机、Final Shell连接超时、最终报错变成Connection refused。这三个症状其实代表了问题发展的不同阶段。最开始是完全不通，后来能ping通但SSH连接被拒绝，这说明网络层已经通了，但应用层的SSH服务出了问题。我建议先用"故障树"的排查思路，从下往上逐层检查：物理连接→网络层→传输层→应用层。

2. 基础环境检查

2.1 虚拟机网络连接状态

打开VMware Workstation，首先要确认虚拟机是否使用了正确的网络适配器。我遇到过很多次因为重装系统后，虚拟机的网络适配器被重置为NAT模式，而实际需要的是桥接模式。右键虚拟机→设置→网络适配器，检查是否选择了"桥接模式（自动）"。这里有个细节：如果你的主机有多块网卡（比如同时有有线和无线），需要在"桥接到"下拉菜单中手动选择当前正在使用的物理网卡。

2.2 主机与虚拟机IP配置

在CentOS7终端输入ifconfig（如果没有这个命令可以安装net-tools包），查看ens33网卡的IP地址。同时在Windows主机上打开cmd执行ipconfig，对比两者的IP地址是否在同一网段。比如主机是192.168.1.10，虚拟机是192.168.1.11，这就是正常的。但如果像我的情况，主机变成192.168.65.x而虚拟机是192.168.235.x，那肯定无法通信。

修改虚拟机IP的方法：

nmcli connection modify ens33 ipv4.addresses 192.168.1.100/24 nmcli connection modify ens33 ipv4.gateway 192.168.1.1 nmcli connection modify ens33 ipv4.dns 8.8.8.8 nmcli connection modify ens33 ipv4.method manual nmcli connection up ens33

这几条命令比直接改配置文件更安全，不会因为语法错误导致网络中断。

3. SSH服务深度配置

3.1 检查SSH服务状态

在虚拟机上执行：

systemctl status sshd

如果服务没运行，先用yum install openssh-server -y安装（CentOS7默认可能没装）。我遇到过重装系统后sshd_config配置文件被重置的情况，这时候需要重点检查几个参数：

vi /etc/ssh/sshd_config

确保以下配置正确：

Port 22 ListenAddress 0.0.0.0 PermitRootLogin yes PasswordAuthentication yes

特别注意：修改配置后必须重启服务systemctl restart sshd，建议再加个systemctl enable sshd设置开机自启。

3.2 防火墙与SELinux设置

CentOS7的防火墙规则可能在系统更新后被重置，执行以下命令开放22端口：

firewall-cmd --permanent --add-service=ssh firewall-cmd --reload

如果还不行，可能是SELinux在作祟。临时关闭测试：

setenforce 0

如果这样能连上，说明需要调整SELinux策略而不是直接禁用它：

semanage port -a -t ssh_port_t -p tcp 22

4. 高级网络调试技巧

4.1 使用telnet测试端口连通性

在Windows主机上打开cmd，运行：

telnet 虚拟机IP 22

如果看到黑屏只显示一个光标，说明端口是通的；如果提示连接失败，则证明防火墙或路由有问题。注意：Win10默认没有telnet客户端，需要在"启用或关闭Windows功能"里勾选"Telnet客户端"。

4.2 网络流量抓包分析

当常规方法都无效时，可以在虚拟机上用tcpdump抓包：

tcpdump -i ens33 port 22 -w ssh.pcap

然后在主机尝试SSH连接，结束后分析抓包文件。如果能看到TCP SYN包到达虚拟机但没有响应，很可能是防火墙拦截；如果根本看不到SYN包，则是路由问题。

5. 虚拟机网络配置重置

如果所有方法都试过了还是不行，可以尝试重置虚拟网络配置。在VMware菜单选择"编辑→虚拟网络编辑器"，点击"还原默认设置"按钮。这个操作会重建所有虚拟网卡，但不会影响已有虚拟机的网络配置。我帮同事处理问题时，发现重装系统后VMware的NAT服务有时会异常，这时需要手动重启：

1. 打开services.msc
2. 找到"VMware NAT Service"
3. 右键选择"重启"

6. 预防措施与最佳实践

经过这次折腾，我总结了几条经验：第一，重装系统前一定要导出虚拟机的网络配置，可以用nmcli connection show ens33 > network_backup.txt备份；第二，给虚拟机创建快照是个好习惯，特别是修改网络配置前；第三，建议在主机和虚拟机上都配置静态IP，避免DHCP分配导致IP变动。

最后分享一个排查流程图：先ping测试基础连通性→检查SSH服务状态→验证防火墙设置→分析网络配置。按照这个顺序一步步排查，大部分连接问题都能解决。记住，网络问题往往出在最简单的地方，耐心检查每个环节才能找到真正的原因。