虚拟机rc=104错误，本质上是被连接方主动重置了连接，绝大多数时候与SSH服务、网络链路或安全策略相关，而不是虚拟机本身“罢工”了。 这个报错在云主机、OpenStack环境和本地虚拟机里都经常出现，排查思路可以遵循从外到内、从网络到服务的顺序。
虚拟机rc=104错误怎么解决：先分清“谁拒绝了谁”
rc=104对应的底层含义是Connection reset by peer，在虚拟化场景里，这就好比你去敲邻居家的门，邻居开门看了一眼又砰地关上了，虚拟机本身可能活着，但它所在的环境或它内部的服务“拒绝”了你的接入请求。
业内专家指出,大约七成以上的rc=104问题都出在网络路径或安全组规则上，真正需要登录虚拟机内部修复的情况反而占少数，所以拿到这个报错，先别急着重启虚拟机，而是按下面的层次逐层排查。
第一层：安全组与防火墙规则是否为“隐形杀手”
云平台的安全组规则有时候比虚拟机内部的防火墙更严格,比如你在简米云、酷番云或自建OpenStack环境里，安全组默认只放行了22端口，但如果你是从一个非标准IP段发起连接，一旦被安全组策略拦下，部分云平台的表现就是直接重置连接，也就是rc=104。
- 检查安全组是否放行了你的来源IP和端口
- 确认VPC内的网络ACL没有阻断流量
- 试着重置安全组规则,或者临时放行所有来源IP做测试
常见的误区是只检查了入方向规则,忽略了出方向的限制，比如虚拟机所在的子网出方向只允许特定目的地址，那么即使入方向通透，SSH的回包也可能被拦截，造成连接被重置。
第二层：目标端口是否在监听，还是被“半路拦截”
有时候rc=104不一定是防火墙干的，而是目标服务根本没起来，或者端口被别的东西占用了，你可以尝试用telnet或nc从宿主机或同网段的其他机器去探测端口。
telnet 192.168.1.100 22 nc -vz 192.168.1.100 22
如果探测结果显示端口关闭或连接超时,说明问题出在虚拟机网络栈或服务监听上，如果探测结果是“Connection refused”，那通常是SSH服务没启动；如果是“Connection reset”，那有可能是负载均衡、iptables规则或者云平台的代理层动了手脚。
在OpenStack环境里,如果虚拟机使用了浮动IP，还需要检查浮动IP是否绑定成功，以及neutron router的状态是否正常。浮动IP漂移或者router down是导致rc=104的高频原因之一。
openstack虚拟机启动失败rc=104的常见场景剖析
在OpenStack中,rc=104有时候不单指SSH连接，它也可能出现在实例启动过程中的控制台日志里，或者是nova-compute与rabbitmq通信时抛出的异常，这里需要区分两种场景：一种是用户通过SSH连不上，另一种是实例本身启动卡住或失败。
实例处于“运行中”但SSH连接重置
这种情况下,OpenStack面板显示虚拟机ACTIVE，但你用密钥或密码SSH登录时，输完密码或密钥校验阶段就断了，常见原因有几个：
- cloud-init未完成初始化：镜像第一次启动时，cloud-init需要设置主机名、注入密钥、配置网络，如果初始化脚本出错，sshd可能只监听了一半就退出了。
- 内核与sshd版本不匹配：偶尔出现在旧镜像里，SSH握手阶段的算法协商失败，看起来像连接被重置。
- CPU架构或虚拟化模式不对：比如在ARM宿主机上跑x86镜像，或者CPU模式配置为
host-passthrough导致指令集不兼容，虽然能启动，但网络栈和进程调度异常。
建议操作：通过OpenStack控制台（VNC或SPICE）登录虚拟机，查看systemctl status sshd和journalctl -u cloud-init的日志，如果控制台也没法用，那就需要从nova-compute的日志或libvirt的domain XML里找线索了。
实例创建后立即报错，根本进不去
如果你的实例创建失败,或者创建后马上进入ERROR状态，而错误信息里有rc=104字样，那就是另一套排查逻辑了，这通常会与nova-compute节点上的网络设备创建失败、安全组规则下发失败有关。
| 现象 | 可能原因 | 排查路径 |
|---|---|---|
| 创建后秒进ERROR | neutron OVS agent异常 | 检查openstack network agent list |
| 控制台黑屏但状态ACTIVE | 镜像缺virtio驱动 | 用QEMU模拟IDE模式测试 |
| 挂载数据卷后报错 | 卷设备attach超时 | 查看cinder-volume日志 |
这种情况下,存储设备或网络设备的底层错误会向上传递成“连接重置”的假象，需要登录到nova-compute节点上，用virsh list查看实例是否真实存在，再用virsh console尝试接入。
虚拟机rc=104的终极排查清单：按步骤操作
如果你不想漫无目的地试,可以按照下面这套流程，一步步定位问题，这套方法在云主机和自建虚拟化平台上都适用。
检查宿主机到虚拟机的连通性
先跳过云平台的管理层,直接从宿主机层面去访问虚拟机，如果你用的是KVM或Xen，通常宿主机可以直接通过virbr0网桥或tap设备访问虚拟机。
ping <虚拟机内网IP> arp -n | grep <虚拟机IP>
如果ping不通,说明虚拟机的虚拟网卡没有正常接入网桥，或者IP地址配置错误，如果ping通但SSH仍然rc=104，那问题大概率在虚拟机内部，需要进一步看端口。
检查sshd服务的具体错误日志
登录虚拟机控制台,执行以下命令：
tail -100 /var/log/secure grep sshd /var/log/messages ss -tnlp | grep :22
如果日志里出现“fatal: Timeout before authentication”或“Connection reset by peer”的字眼，说明有外部流量触发了sshd的错误，这时候要检查/etc/hosts.deny和/etc/ssh/sshd_config里的MaxStartups和AllowUsers配置。
对比测试：换端口和换协议
为了区分是端口问题还是服务问题,可以做个小实验，把sshd临时改到2222端口：
sed -i 's/#Port 22/Port 2222/' /etc/ssh/sshd_config systemctl restart sshd
如果改成2222端口后能正常连接,那说明22端口被某个安全软件或iptables规则动了手脚，如果新端口同样报rc=104，那问题在于更深层的网络栈，比如TCP Segmentation Offload（TSO）功能异常。
某些虚拟化环境下,开启TSO会导致数据包被网卡驱动错误地切分，造成连接被重置，可以尝试关闭虚拟网卡的offload功能：
ethtool -K eth0 tso off gso off gro off
重新连接后如果恢复正常,那问题就锁定在网卡驱动的兼容性上，解决办法是更新virtio-net驱动，或者在虚拟机XML配置里加上<driver name='vhost'/>相关的参数。
Q&A：虚拟机rc=104相关高频疑问
Q：虚拟机重启后rc=104错误消失了，但过一段时间又出现，是什么原因？
A：这种间歇性报错通常指向资源竞争或定时任务，sshd在并发连接数超过MaxStartups阈值时会随机丢弃新连接，表现为连接被重置，系统日志轮转或auditd定时检查也可能短暂锁住socket，建议将MaxStartups从默认的10:30:100改为30:30:100，并检查crontab里是否有网络扫描类脚本。
Q：rc=104和connection refused有什么区别？
A：Connection refused意味着目标端口没有任何服务在监听，数据包到达了主机但被内核直接拒绝，是一个“确定性”的反馈，rc=104则代表连接在建立过程中被主动重置，比如防火墙发了RST包，或者SSH服务在握手阶段崩溃，前者是没人在家，后者是开门看了一眼又关了，排查方向完全不同，前者直奔端口监听状态，后者需要关注安全策略和应用层报错日志。
Q：虚拟机迁移后出现rc=104，如何快速恢复？
A：先确认迁移后实例的IP和MAC地址是否保留，冷迁移通常会重新分配虚拟网卡，如果新网卡的MAC与云平台数据库里记录的不一致，安全组策略就无法正确匹配，导致连接被重置，操作上先在控制台查询实例的OS-EXT-SRV-ATTR:host，然后登录新宿主机执行virsh dumpxml核对网卡配置，手动修正为原MAC地址后重启网络服务即可。