重启虚拟机后，绝大多数业务异常都源于网络配置丢失、服务未自启和系统环境漂移这三大类原因。别急着重装系统，按下面顺序排查,大部分问题都能在十分钟内解决。
重启虚拟机后IP地址变了怎么办
重启虚拟机后IP地址变了，是云服务器和本地虚拟机最常遇到的现象，这个问题的根源，在于虚拟机默认开启了DHCP动态获取IP，每次重启，租约重新申请，地址可能就会跟着变，业务系统如果绑定旧IP，自然就“失联”了。
先确认IP变化是偶然还是必然
打开终端登录虚拟机，用 ip addr 查看当前IP，然后对比之前的地址，如果IP变了,先检查虚拟机的网络模式：
- NAT模式：宿主机分配的IP段固定，但DHCP租期较短,重启后容易变化。
- 桥接模式：直接从局域网获取IP，如果路由器DHCP池大,变化几率较低。
- 仅主机模式：一般通过虚拟网卡的DHCP分配,重启也可能变动。
场景代入：你之前用Xshell连的是192.168.1.10，重启虚拟机后变成192.168.1.15,这时盲目的扫描整个网段不如直接进虚拟机看IP来得快。
永久固定IP的实操步骤
既然要解决“重启虚拟机后IP地址变了”这个痛点,最干净的方式就是改成静态IP。
第一步：定位网络配置文件。 在CentOS/RHEL 7+系统中,执行：
ls /etc/sysconfig/network-scripts/ifcfg-
通常会出现 ifcfg-ens33 或 ifcfg-eth0 这类文件。
第二步：修改配置。 用 vi 或 nano 编辑该文件,需要确保以下参数正确：
BOOTPROTO=static（从dhcp改为static）IPADDR=192.168.1.10（你想要的固定IP）NETMASK=255.255.255.0GATEWAY=192.168.1.1（宿主机或路由器网关）DNS1=114.114.114.114
第三步：重启网络服务。
systemctl restart network
对Ubuntu系统，则推荐直接修改 /etc/netplan/ 下的YAML文件，把 dhcp4: no 并写死 addresses 和 gateway4，修改后执行 netplan apply。
业内专家指出，静态IP配置中最容易忽略的是网关和子网掩码的匹配，一旦填错，重启后虽然IP没变,但对外网络完全不通。
验证IP是否真的固定
修改完配置后，执行 reboot 重启虚拟机，开机后用
ip addr 检查地址，如果还是老样子，看看宿主机是否开启了MAC地址漂移部分虚拟化平台会随机生成新MAC，导致静态IP绑定失效,此时需要把虚拟机的MAC地址也固定下来。
重启虚拟机后SSH连接不上怎么排查
重启虚拟机后SSH连不上的概率仅次于IP变化，而且多数情况下，服务端SSH其实是正常启动的,问题出在网卡或防火墙。
先从宿主机控制台入手
虚拟机重启后，如果没法通过SSH远程登录，首先打开虚拟机的控制台界面（VMware的Console，或云平台的VNC登录）,在控制台里执行：
systemctl status sshd
- 如果状态是
active (running),说明SSH服务没毛病。 - 如果状态是
inactive或failed，执行systemctl start sshd拉起来。
检查网卡是否成功启动
有时候网卡没有随系统启动,控制台登录后执行：
ip a
如果只见 lo 回环地址，而网卡（如ens33）没有IP,那就是网卡没起来。
常见原因和修复：
- 网卡配置文件中
ONBOOT=no，改为yes并重启网络。 - 网卡服务未生效，执行
systemctl restart network。 - 虚拟化平台限制网卡启动，检查VMware或KVM的虚拟机设备是否勾选了“连接”选项。
防火墙和SELinux作祟
重启后防火墙策略可能被还原或者加载了新规则,依次排查：
iptables -L -n firewall-cmd --list-all
如果SSH端口被DROP,临时放行：
firewall-cmd --permanent --add-service=ssh firewall-cmd --reload
SELinux方面，执行 getenforce 看是否Enforcing，临时关闭用 setenforce 0，但永久修改要编辑 /etc/selinux/config。
重启虚拟机后服务没有自动运行
很多业务崩溃是“重启虚拟机后服务没有自动运行”造成的，数据库没起来、Nginx没起来,网站自然打不开。
为什么服务没有设为开机自启
最容易忽视的原因：安装服务时用的是默认设置，或者使用源码编译安装,没有注册成systemd服务。
以MySQL为例，手动启动没问题，但一重启虚拟机，MySQL就消失,正确的自启配置：
systemctl enable mysqld systemctl daemon-reload
对于自定义的脚本或应用，优先写一个systemd unit文件，放在 /etc/systemd/system/myapp.service 中，内容大致涉及 ExecStart
和 Restart=always,写好后执行：
systemctl daemon-reload systemctl enable --now myapp
检查服务启动顺序和依赖
如果服务自启了但启动失败，可能是依赖的服务还没起来，比如应用依赖数据库，数据库依赖网络，此时可以调整systemd的 After= 和 Requires= 参数,或者在应用启动脚本里增加等待连接的逻辑。
场景对比：多数情况下，Nginx通过 systemctl enable nginx 即可正常自启，而像Redis这类服务，如果配置了持久化，还要注意权限,防止重启后无法写RDB文件。
重启虚拟机后磁盘空间出现异常
重启后 df -h 发现磁盘快满了，或者原本扩容的硬盘在系统里看不到,这也是常见问题。
区分“真实占用”和“文件系统视图”
一个典型场景是，重启后删除大文件的进程已经终止，但空间没有释放,这时需要执行：
lsof | grep deleted
找到占用文件句柄的进程，重启该进程就能释放空间，如果不想重启服务，用 > /proc/进程号/fd/文件描述符 清空文件。
磁盘扩容后重启不生效
云平台或虚拟机管理器中扩容了磁盘，但虚拟机内部没有识别,重启虚拟机后可以执行：
lsblk
查看块设备大小，如果部分设备（如vda）显示了新大小，但分区和文件系统还是旧的,需要执行：
growpart /dev/vda 1 resize2fs /dev/vda1
这个操作在Ubuntu上对应 resize2fs，在XFS文件系统上用 xfs_growfs /。
临时文件在重启时自动清理
/tmp 目录在重启时通常会被清空，如果业务依赖 /tmp 下的文件，重启后就会报错，这类问题本质上不是磁盘异常，而是临时文件生命周期管理不当，合理的做法是把持久化数据迁移到 /var 或其独立的数据盘中。
重启虚拟机后网络服务启动缓慢的优化
有些时候，能够连上SSH，但执行命令响应很慢，等待时间长达十几秒，这通常和DNS解析有关，SSH登录时会做反向DNS查询，如果DNS配置错误，就会卡很久，优化方式是在 /etc/ssh/sshd_config 中设置：
UseDNS no GSSAPIAuthentication no
然后重启sshd。
如果虚拟机使用DHCP，但重启后网卡等待DHCP超时，也会拖慢启动，建议将网卡配置改为静态IP，同时把systemd的 network-online.target 服务依赖调整到网络完全就绪后再启动关键服务。
适用不同虚拟化平台的注意事项
- VMware Workstation：拖拽或复制虚拟机导致MAC地址改变,需要在虚拟机设置里重新生成或固定网络适配器。
- VirtualBox：桥接网卡在重启后可能没有自动绑定宿主机的真实网卡位，到“设置-网络”里确认“高级-混杂模式”没有异常。
- 云服务器（简米云、酷番云等）：控制台执行重启不等于硬件重启，云主机的系统盘和网络配置本身是持久化的，如果出现固定IP丢失,检查是否设置了辅助网卡或弹性网卡的自动挂载。
重启虚拟机后常见问题集中解答
重启虚拟机后ip地址变了但没改配置，能找回原来的IP吗
可以，在虚拟机的DHCP租约文件里查找旧IP，Linux下查看 /var/lib/dhclient/dhclient.leases 或 /var/lib/NetworkManager 中记录，找到后直接手动指定该IP为静态IP，就能恢复业务访问，如果记录已经丢失，只能通过宿主机检查虚拟机的ARP缓存,或者在控制台操作期间把新IP记录下来并更新本地SSH配置。
重启虚拟机后网卡启动失败，提示“Job for network.service failed”怎么办
最常见的原因有四种：配置文件错误、设备名不匹配、NetworkManager与network脚本冲突、内核驱动未加载,按顺序执行：
systemctl status network journalctl -u network
看具体的报错，如果是设备名不匹配，重命名 /etc/sysconfig/network-scripts/ifcfg- 里的 NAME 和 DEVICE 与 ip link 显示的一致，若出现 RTNETLINK answers: File exists，通常是重复配置了IP地址,检查是否存在多余的ifcfg文件。
重启虚拟机后数据库自动断电，如何防止数据损坏
MySQL和PostgreSQL在强制重启下可能导致数据文件不一致，定期执行 flush tables with read lock 并做物理备份，或者使用云存储快照，更关键的是，在系统层面不要执行 kill -9 来关闭数据库进程，应该使用 systemctl stop mysqld 优雅停止，在配置文件里增加 innodb_flush_log_at_trx_commit=1 和 sync_binlog=1,降低重启后崩溃恢复时丢数据的风险。
重启虚拟机不是简单的反复开关机，它更像一次对系统健壮性的体检，IP漂移、服务失联、磁盘视图错乱，这些问题只要提前把静态网络、自启服务、持久化存储三件事做扎实，大概率就能平稳关机，安心开机，你的虚拟机哪天再重启，照着上面的顺序过一遍,至少不会手忙脚乱。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/672991.html
