虚拟机报connection refused，核心原因就两个：目标端口没在监听，或者防火墙把连接拦了，按“查端口监听→查防火墙→查虚拟网络”这个顺序排查，绝大多数情况都能定位并解决。
先说一个被很多人忽略的事实：connection refused并不是“连不上”的统一症状，它就相当于对方听到了敲门声，但开门后看了一眼说“我不认识你”，然后把门关上了，相比超时那种“敲了门但没人应答”，refused反而更好定位，因为至少说明网络是通的。
别把connection refused和超时混为一谈，这是两种完全不同的故障
圈里有个不成文的经验：凡是报refused，优先查服务端口和防火墙；凡是报timeout，优先查路由和网络链路，如果你把两者搞反了，排查方向会彻底跑偏。
| 报错类型 | 实际含义 | 大概率原因 |
|---|---|---|
| connection refused | 网络可达，但端口无人响应或主动拒绝 | 服务未启动、端口绑定错误、防火墙REJECT规则 |
| connection timed out | 请求发出后石沉大海，无人应答 | 网络不通、IP错误、防火墙DROP规则 |
| network unreachable | 路由层面就不可达 | 网段配置错误、虚拟网卡未启用或未配置IP |
业内专家指出,在虚拟化环境里，相当一部分refused问题并非网络不通，而是服务绑定地址太“内向”，比如你在虚拟机里起了一个Web服务，它默认只监听了127.0.0.1，宿主机自然连接不上这不是网络问题，是服务配置问题。
区分“本机能连”和“外部不能连”是判断的第一步
在虚拟机里执行curl http://localhost:8080，如果返回正常，再用虚拟机自己的IP去访问一次：
- 本机IP也正常 → 问题出在宿主机的路由或防火墙
- 本机IP就refused → 服务只绑定了127.0.0.1，需要修改服务配置绑定0.0.0.0
这两步做完,基本能划清责任边界，剩下的事就是顺着“服务配置→防火墙→虚拟网络”往下钻。
一步步排查虚拟机connection refused怎么解决？按这四步走就够
以下是实操路径,每完成一步就验证一次，不要一口气全做完再去试。
第一步：确认端口到底有没有人在监听
登录虚拟机终端,执行：
ss -tlnp | grep 8080 # 或者老一点的环境用 netstat -tlnp | grep 8080
看输出的监听地址那一栏：
- 0.0.1:8080 → 服务只开了本地回环地址，外部连不进来，修改服务配置绑定
0.0.0或对应网卡IP - 0.0.0:8080 或 [::]:8080 → 服务监听全网卡，跳到第二步
- 没有任何输出 → 服务根本没启动，去查服务日志
现实场景中,开发型服务（比如Python的Flask/Django、Node.js开发服务器）默认绑定localhost的情况非常多，这也是“容器里跑的服务宿主机连不上的典型原因”。
第二步：检查防火墙是不是半路拦截
服务没问题,连接还是refused，那就轮到防火墙了，Linux环境主要看两套东西：iptables和firewalld，很多人分不清谁优先级高实际上它们是共存的，firewalld只是iptables的前端管理工具。
# 看firewalld是否在运行 systemctl status firewalld # 直接看iptables规则链 iptables -L -n --line-numbers
重点是找REJECT规则，防火墙拒绝方式有两种：REJECT（回RST包，表现就是refused）和DROP（静默丢弃，表现是timeout），如果你看到REJECT落在目标端口上，就是它干的。
# firewalld放行端口 firewall-cmd --permanent --add-port=8080/tcp firewall-cmd --reload # iptables放行端口 iptables -I INPUT -p tcp --dport 8080 -j ACCEPT
改完立刻重试连接。
第三步：检查虚拟网络模式和端口转发
服务在监听、防火墙也放行了，但refused还存在，这时候要看虚拟网络这一层。
以最常见的NAT模式为例：虚拟机用的是私有网段，宿主机可以访问虚拟机，但外部设备访问虚拟机需要在虚拟网络编辑器里配置端口转发，很多人会忽略一件事在某些虚拟化软件里，宿主机访问NAT模式虚拟机时，走的路径和外部设备访问是两条路，导致宿主机能连、外部设备连不上，或者反过来。
建议在虚拟网络编辑器里检查：
- NAT网段是否和你预想的一致
- 端口转发规则是否指向了虚拟机的正确IP和端口
- 虚拟机是否启用了静态IP但和NAT网段冲突
第四步：看虚拟网卡和路由表
ip addr ip route
确认默认路由走的是哪张网卡。多网卡虚拟机经常出现“服务监听了网卡A的IP，但外部访问的是网卡B的IP”这种情况，看起来像网络故障，实际是网卡配置混乱。
vmware虚拟机无法远程连接时，重点查网络适配器模式
VMware的三种网络模式对应三种不同的访问场景,模式选错了，refused和timeout都可能出现：
| 模式 | 宿主机访问虚拟机 | 外部设备访问虚拟机 |
|---|---|---|
| 桥接模式 | 直接访问VM的局域网IP | 同网段设备可直接访问 |
| NAT模式 | 直接访问VM的私有IP | 需要端口转发才能访问 |
| 仅主机模式 | 可通过VMnet网卡访问 | 外部设备完全不可达 |
很多人的场景是“宿主机访问VMware虚拟机里的MySQL或Redis时报refused”，排查时先确认虚拟机IP在哪个网段，再回到VMware的虚拟网络编辑器核对，别直接一上来就去虚拟机里面改配置。
VMware虚拟机配置了静态IP却连不上的常见坑
给虚拟机配静态IP时,网关和DNS容易配错，尤其是NAT模式下，默认网关应该是VMnet8的网段地址（通常是192.168.x.2），而不是虚拟机的IP或者路由器的网关，哪怕你查iptables查了半天，最后发现是IP配错了，这种案例不在少数。
centos虚拟机ssh连接拒绝时，多半是这四个细节在作祟
CentOS在服务器场景里使用率很高,它的SSH服务默认只监听22端口，但实际出问题时，原因往往藏在不起眼的地方：
- SSH服务没启动：
systemctl status sshd看一下，很多精简安装的CentOS默认不装OpenSSH-Server - SELinux拦截：CentOS默认开启SELinux，它可能拦截非标准端口的SSH连接，临时验证可执行
setenforce 0
，问题消失再调整SELinux策略
- sshd配置里ListenAddress写死了：
/etc/ssh/sshd_config里的ListenAddress如果只写了127.0.0.1，外部连接必然refused - 云平台安全组或虚拟化平台规则：如果这台虚拟机跑在私有云或OpenStack环境里，控制台安全组也可能拦住了入站连接
行业共识认为,多数SSH connection refused问题集中在服务未启动和端口监听地址配置错误这两项，防火墙反而排第三。
虚拟机connection refused和timeout的区别到底在哪？
这个问题值得单独说,因为很多人一直没拎清。
- refused：目标主机收到了请求，但端口关闭或主动拒绝连接，证明主机在线、网络链路通、但应用层没有服务在听
- timeout：请求发出后目标主机没有任何回应，可能是包丢了、路由错了、或者防火墙静默丢弃了包
用大白话讲：refused是“人不在家但门开着，你知道家里没人”timeout是“你根本不确定这个地址存不存在，敲门也没有任何声音”。
虚拟机connection refused问题速查
问：重启虚拟机，connection refused问题能自动恢复吗？
不一定,重启确实能解决服务未启动这类临时问题，如果iptables规则被手动改乱了，重启也能重置，但如果根本原因是服务配置绑定了127.0.0.1或SELinux策略问题，重启后依然会报refused。
问：为什么从宿主机访问虚拟机报refused，但虚拟机访问宿主机一切正常？
宿主机访问虚拟机相当于“外部入站连接”，虚拟机访问宿主机是“出站连接”，两个方向走的防火墙规则完全不同，入站被拦是常见情况，优先检查虚拟机的防火墙规则和服务监听地址，这两个方向排查完再查虚拟网络模式。
问：手机上能正常连接虚拟机里的服务，但电脑上不行，这是什么原因？
手机和电脑如果走的是不同的网络路径（比如手机用4G访问公网IP，电脑走局域网），问题大概率出在宿主机或路由器的回程路由上，如果两者都在同一局域网但结果不同，检查电脑防火墙是否拦截了出站连接或目标端口。