先说一个我自己踩过几次的坑很多人照着网上早年的Ubuntu教程去配置静态IP改完/etc/network/interfaces然后重启网络服务结果发现配置完全没生效或者干脆SSH直接断掉连不上机器。这不是你操作失误而是Ubuntu从18.04开始底层网络配置工具已经从ifupdown切换成了netplan。你还在用上一代语法系统根本不认。这篇文章就把Ubuntu 18.04、20.04、22.04这几代系统里配置静态IP的方法完整梳理一遍。核心会放在netplan上因为它是目前Ubuntu Server和Desktop默认使用的配置栈同时也会讲nmcli命令行方式、传统interfaces文件的适用场景、虚拟机环境下的特殊问题以及配置完之后的验证和自救手段。无论你是刚接触Linux的新手还是要给服务器或虚拟机换固定IP的老手这篇应该都能帮上忙。1. 为什么Ubuntu 18.04之后静态IP配置突然变难了1.1 从ifupdown到netplan的配置栈变迁Ubuntu 18.04 LTS发布时做了一个影响深远的改动用netplan替换ifupdown作为默认的网络配置前端。netplan本身不直接管理网络它只是一个配置渲染器把你写好的YAML配置转化成后端程序能识别的规则然后交给systemd-networkd或NetworkManager去执行。这个设计改变了配置入口。以前你只需要编辑/etc/network/interfaces然后运行ifup或者systemctl restart networking配置就生效了。现在你需要在/etc/netplan/目录下维护YAML文件然后执行netplan apply让配置生效。注意/etc/network/interfaces文件在18.04以上版本里默认还在但已经被边缘化你改它基本不会影响系统实际网络。很多人配置失败根本原因就是不知道这个变化。尤其是从14.04、16.04时代迁移过来的老用户惯性思维太重。网上一搜关键词搜出一堆老文章照着操作当然配不通。1.2 先确认你的系统走的是哪套网络栈拿到一台Ubuntu机器先别急着改配置。你得先判断当前系统实际由谁管理网络。我一般用一个命令ls /etc/netplan/如果这个目录存在并且里面有.yaml文件说明系统默认走netplan。这个目录在18.04、20.04、22.04里都是标配。再看一眼NetworkManager的接管状态systemctl status systemd-networkd systemctl status NetworkManager如果是桌面版UbuntuNetworkManager大概率在运行如果是Server版systemd-networkd可能是主力或者两者交替使用。netplan通过YAML里的renderer:字段决定把配置交给谁。默认情况下Server版通常使用networkd作为renderer桌面版使用NetworkManager。还有一个很容易忽略的判断点执行ip addr看网卡状态信息和你在修改前抓到的IP对不对得上。如果IP地址是由NetworkManager拉的DHCP你去改netplan文件但renderer还是NetworkManager就会发生配置不生效的诡异现象。下文会具体讲。总之先确认配置栈再动手。这一步省掉后面全是坑。2. 配置静态IP前必须先想清楚的三个参数2.1 网卡接口名ens33、enp0s3还是eth0很多教程第一步就让你把eth0改成静态IP但你实际机器上可能根本没有eth0这个接口。Ubuntu 18.04以上使用systemd的链路命名规则网卡名取决于硬件拓扑和固件信息常见的有这些ens33PCIe总线上的网卡常见于VMware虚拟机。enp0s3PCI总线0插槽3上的网卡常见于VirtualBox虚拟机。eno1板载网卡。enp2s0PCIe扩展槽网卡。wlan0或类似的wl...开头无线网卡。查看当前系统里有哪些网卡用ip addr show或ip link你会看到类似2: ens33: BROADCAST,MULTICAST,UP,LOWER_UP这样的输出。第一列的数字是接口索引冒号前的ens33就是接口名。后面的状态里UP代表已启用DOWN代表未启用。如果你配置的时候写错接口名比如把ens33写成eth0netplan apply不会报错但它只会把配置应用到一个不存在的接口上你现有的网络完全不动。这种“无声失败”是最坑的。2.2 网关地址怎么查、怎么选网关错了或者漏写了最常见的表现是内网能通外网不通。因为跨网段的数据包不知道该发给谁。查看当前网关的快捷方式ip route show输出里default via 192.168.1.1 dev ens33就是默认网关。192.168.1.1就是当前DHCP分配给你的网关地址。如果你要配置静态IP正常情况下网关就沿用这个地址除非你所在的网络规划里静态IP段的网关确实不是它。需要注意DHCP获取的网关不一定等于真正的路由器地址。有些复杂网络里网关可能是内网里某台三层交换机或防火墙的接口地址。你直接沿用ip route显示的地址通常没问题但如果你发现持续丢包或延迟异常检查一下网关MAC地址是不是和路由器对得上。在虚拟机环境下网关的选择更要谨慎。NAT模式下VMware的虚拟网关通常是192.168.x.1VirtualBox的NAT网关通常是10.0.2.2。桥接模式下网关则是你物理路由器的IP。这个区别要记清楚不然虚拟机配了静态IP依然上不了网。2.3 DNS配置静态IP后域名解析不通的根源静态IP配置里DNS是仅次于网关的第二大翻车点。很多人配完静态IPIP地址确实固定了但用浏览器打开网页一直转圈ping 8.8.8.8能通ping baidu.com却报未知主机名。这基本就是DNS没配好。查看当前DNS信息可以用resolvectl status或者看/etc/resolv.conf的内容。不过在Ubuntu 18.04以上这个文件通常是指向/run/systemd/resolve/stub-resolv.conf的软链接内容是127.0.0.53。不要被这个地址吓到这是systemd-resolved的本地缓存地址最终上游DNS还是来自netplan或NetworkManager下发的配置。配置静态IP时我建议至少填两个DNS地址一个主一个备。国内网络环境就用223.5.5.5和119.29.29.29或者114.114.114.114国外服务器可以用8.8.8.8和1.1.1.1。具体看你的使用场景目标是保证一个挂了还能有备用。3. netplan配置静态IP全过程含最容易翻车的细节3.1 找配置文件/etc/netplan下到底是什么在Ubuntu 18.04及以上版本里进入/etc/netplan/通常能看到一个或多个文件01-network-manager-all.yaml桌面版常见。50-cloud-init.yaml云镜像或自动安装版常见。99_config.yaml你自己新建的配置文件。命名规则是数字前缀名称.yaml。netplan会按字典序读取这些文件后面文件里的同类配置会覆盖前面的。这个特性可以拿来用不直接动默认文件而是新建一个名称排序靠后的文件把静态IP配置写进去优先级更高还能保留原始配置做参考。先看下默认文件内容比如50-cloud-init.yaml通常长这样network: ethernets: ens33: dhcp4: true version: 2这就清楚了网卡ens33当前由DHCP获取IPv4地址。3.2 手把手编辑YAML修改或新建netplan配置文件推荐用vim或nano。我习惯先备份再改sudo cp /etc/netplan/50-cloud-init.yaml /etc/netplan/50-cloud-init.yaml.bak然后编辑改成network: version: 2 ethernets: ens33: dhcp4: no dhcp6: no addresses: - 192.168.1.100/24 routes: - to: default via: 192.168.1.1 nameservers: addresses: - 223.5.5.5 - 119.29.29.29逐项说明dhcp4: no关闭IPv4的DHCP这个是静态IP的第一步。不关掉的话DHCP可能继续覆盖你的静态配置。addresses:接口IP地址和子网前缀长度。/24就是子网掩码255.255.255.0的CIDR写法。写的时候必须带前缀长度不能只写IP地址。地址使用列表格式可以写多个IP比如同时配IPv4和IPv6。routes:路由表配置。to: default表示默认路由via:后面跟网关地址。nameservers:DNS服务器列表。注意缩进addresses:是nameservers:的子项。很多新手卡在YAML格式过不了netplan generate报错。最常见的原因是用了Tab缩进。YAML对缩进敏感而且netplan的配置明确要求使用空格不能用Tab。编辑器设置里把Tab自动替换成两个空格或者干脆手工用空格缩进。3.3 应用配置netplan apply和netplan try的区别配置写好后先运行sudo netplan generate这个命令只做语法检查和生成后端配置文件不改动当前网络。如果这里报错先修格式问题别急着apply。确认无报错后sudo netplan apply这个命令会真正应用配置。但我强烈建议使用另一个更安全的命令sudo netplan trynetplan try会自动应用配置然后等待你确认。如果配置有问题导致网络断开系统会在等待超时后自动回滚到之前的可用配置。这相当于给自己留了一条退路。执行后终端会提示“Do you want to keep these settings?”按回车确认保留超时则自动恢复。如果是远程SSH操作我特别建议用netplan try因为你配置错了导致断网时netplan apply可不会自动帮你恢复。你只能跑到物理控制台或者用IPMI硬恢复非常狼狈。而netplan try在等待期间如果检测到连接中断你直接不理会超时后它自己就回滚回去了。3.4 配置后SSH断连、无法上线的自救方法远程服务器配置静态IP最经典的翻车现场就是apply之后SSH直接断开再也连不上只能让机房重启或者本人去现场。避免这种现场的最好办法有几个原则用netplan try而不是netplan apply。这是第一道保险。别改默认路由和当前SSH连接所在的IP段。如果你SSH用的IP是192.168.1.10现在要把IP改成192.168.1.100改的时候要确认192.168.1.100不在其他设备上占用而且你改完后要马上用新IP去连。保留一个临时救急配置。有些老手会在服务器上额外写一个备用网络配置比如在/etc/netplan/里放一个带DHCP的备用文件需要时通过物理控制台切换。这个做法比较高级不推荐新手一上来就搞但心里要知道有这条退路。如果已经断连而且你人在控制台前操作顺序是sudo netplan try不行的话直接恢复备份sudo cp /etc/netplan/50-cloud-init.yaml.bak /etc/netplan/50-cloud-init.yaml sudo netplan apply再检查一下ip addr确认网络回来没有。整个过程不需要重启系统。很多人习惯配完网络就重启机器其实没必要netplan apply足够。4. 不想碰YAML用nmcli和传统interfaces补齐方案4.1 nmcli命令行配置静态IP如果你觉得YAML格式容易出错或者你更喜欢命令行操作可以用nmcli。它是NetworkManager的命令行工具。前提是你的系统装了NetworkManager并且相关接口由它管理。查看当前连接名nmcli connection show输出类似NAME UUID TYPE DEVICE Wired connection 1 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ethernet ens33NAME那列的Wired connection 1就是连接名注意空格命令里要加引号。然后修改连接sudo nmcli connection modify Wired connection 1 \ ipv4.method manual \ ipv4.addresses 192.168.1.100/24 \ ipv4.gateway 192.168.1.1 \ ipv4.dns 223.5.5.5 119.29.29.29这条命令把连接改为手动manual模式设置静态地址、网关和DNS。执行后重启连接sudo nmcli connection down Wired connection 1 sudo nmcli connection up Wired connection 1nmcli对新手更友好因为它有补全提示而且语法比较直白。缺点是它只管理NetworkManager范围内的连接如果你的服务器用的是systemd-networkd纯后端nmcli可能无法真正接管。顺带说一句有些方法在网上流传是把/etc/network/interfaces文件改回auto eth0、iface eth0 inet static这类写法这是针对旧版Ubuntu或者改用了ifupdown的系统。手工安装ifupdown包并切换也是可以的但如果你不想折腾底层服务还是老实用netplan或nmcli。4.2 什么时候你会需要回到/etc/network/interfaces写法有一类特殊场景需要传统写法你在跑一个精简版Ubuntu或者一个从旧版本滚动升级上来的系统netplan没装或者没接管所有网卡再比如你在做系统裁剪希望最小化依赖不想引入systemd-networkd。这种情况下可以手动启用ifupdownsudo apt update sudo apt install ifupdown然后在/etc/network/interfaces里写auto ens33 iface ens33 inet static address 192.168.1.100 netmask 255.255.255.0 gateway 192.168.1.1 dns-nameservers 223.5.5.5 119.29.29.29注意dns-nameservers依赖resolvconf包。如果没装这行配置不会生效你需要手动处理/etc/resolv.conf。启用配置sudo systemctl enable networking sudo systemctl restart networking但我要明确说除非你确实在维护一个比较特殊的系统否则不建议走这条路。netplan在18.04以上版本里已经非常稳定没必要逆着系统默认设计去折腾。5. 虚拟机里配静态IP和物理机有什么本质区别5.1 NAT、桥接、仅主机模式对IP规划的影响虚拟机上配静态IP比物理机多一层变量虚拟网卡的工作模式。VMware和VirtualBox都提供了几种常见的虚拟网络模式不同模式下你的静态IP地址段、网关、DNS策略完全不同。NAT模式虚拟机通过宿主机访问外部网络。虚拟机的流量经过宿主机转发出NAT外部设备无法主动访问虚拟机。VMware下默认网关通常是192.168.x.1VirtualBox下通常是10.0.2.2。在NAT模式下静态IP必须配置在虚拟网卡的网段内网关必须是虚拟网卡提供的网关不能随手填一个。桥接模式虚拟机直接接入物理局域网和宿主机在同一网段拥有独立IP。这是最接近物理机的模式。静态IP就按你局域网的真实规划填网关和DNS都是真实路由器的。这种模式下如果局域网开启了DHCP你要注意避免IP冲突如果局域网没有DHCP桥接模式下虚拟机可能完全无法自动获取IP这也是很多新手在宾馆、公司网络里配不通虚拟机的关键原因。仅主机模式虚拟机和宿主机之间有一个私有网络虚拟机无法直接访问外部网络。这种模式一般用来做本地实验静态IP填在仅主机网卡的私有网段里即可。5.2 VMware/VirtualBox常见静态IP问题在虚拟机上配静态IP真实踩坑频率最高的几个问题我列一下网卡类型导致接口名不固定。VMware里把网卡类型从e1000换成vmxnet3或者VirtualBox里改网卡类型接口名可能从ens33变成enp0s3之类。你原来的netplan配置里写死了接口名改完网卡类型后配置对不上网络就废了。虚拟机硬件变动前记得先看ip link确认接口名。主机快照回滚导致配置丢失。很多人给虚拟机做完快照才去折腾网络配完静态IP后测试不通直接回滚快照结果网络配置也跟着回滚了。这倒不是配置问题是操作习惯问题。建议配静态IP前先确认系统里没有未保存的快照状态配完确认稳定后再打新快照。复制虚拟机导致MAC地址和连接绑定异常。在VMware里克隆虚拟机时如果选择“复制物理网络地址”两台机器用同一个MAC地址接入同一网络会冲突网络时通时断。克隆后建议重新生成MAC地址然后用ip link确认接口名再检查netplan配置。专用工具的坑。标题里提到的vm kylin v11 静态ip能上网这类场景本质上还是需要正确处理网关和DNS链路。我之前使用银河麒麟和统信UOS这类基于Ubuntu衍生的系统时遇到不少情况是系统自带的网络管理工具把配置写进了它自己的配置文件里然后netplan没接管导致配置完成但网络不通。遇到这种衍生系统先检查/etc/netplan/是否存在以及系统systemctl status NetworkManager里的状态不要盲目套用主版本Ubuntu的步骤。6. 验证、回滚与故障排查顺序6.1 检查网络生效的完整命令链路配置应用之后不能只看一眼IP就完事。我按顺序操作ip addr show ens33确认接口上的IP是否为指定的静态地址。同时看状态state UP才是正常。如果发现接口状态是DOWN说明接口被手动关了或者驱动没加载。ip route show确认默认路由存在default via 192.168.1.1 dev ens33这一行不能少。少了说明网关配置没生效。ping 192.168.1.1先ping网关这一步通了说明二层链路和IP设置基本OK。不通的话检查IP和子网掩码以及网线、交换机端口这些物理层。ping 223.5.5.5这一步通说明出网的路由链路没问题。如果上一步通而这一步不通问题出在网关和公网之间的路由或者防火墙配置。ping baidu.com这一步通说明DNS解析和域名访问都正常。到这一步才算是真正的配置成功。还有一条容易被忽略的检查systemctl status systemd-networkd如果你用netplannetworkd这个服务状态要确认是active。如果服务没起来配置再对也没用。顺手看一眼journalctl -u systemd-networkd的日志有报错信息就直接对症排查。6.2 网络不通时按什么顺序排查网络出问题的时候切忌乱试。我一般按这个顺序排查检查接口状态和IPip addr。如果接口是DOWN先ip link set ens33 up把它拉起来再确认IP是否还在。检查路由表ip route。缺默认路由是外网不通的常见原因。出现多条默认路由时也要注意可能互相打架。检查物理链路在虚拟化环境里看虚拟交换机、物理交换机端口状态在物理机上检查网线、光模块。检查防火墙Ubuntu默认装了ufw。sudo ufw status看看是不是挡住了出站或入站流量。很多“配好了但连不上”的问题其实是别人的防火墙或你的防火墙在起作用。检查DNS链路resolvectl status和cat /etc/resolv.conf。确认DNS配置确实生效而不是停留在默认生成的本地回环地址。检查ARP表ip neigh。如果网关的ARP条目显示FAILED或INCOMPLETE说明二层都到不了网关。这个步骤在看“虚拟机里ping不通物理机”这类问题尤其好用。每一步都确认无误再往上层查。用排除法把问题缩小到一个环节是最快的手段。6.3 被cloud-init覆盖配置的情况最后一个平时很容易踩中的坑cloud-init。Ubuntu官方云镜像、或者你用自动安装镜像装出来的Ubuntu默认会在启动时通过cloud-init配置网络。cloud-init会在启动早期读取/etc/netplan/里的50-cloud-init.yaml并可能修改它。这意味着你在系统运行中手动改了50-cloud-init.yaml重启后配置可能被覆盖回原来的DHCP模式。解决办法有两个路径路径一是直接停用cloud-init对网络的接管sudo touch /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg写入一行配置network: {config: disabled}然后清理cloud-init已生成的状态sudo cloud-init clean --logs再重启或者至少重启netplansudo netplan apply路径二是手动编辑50-cloud-init.yaml后同时禁用cloud-init的配置覆盖。我实际使用中推荐直接禁用cloud-init对网络的管理因为你要配置静态IP说明网络是固定的没必要让cloud-init每次启动动态生成。另外提醒一句在阿里云、腾讯云这类云平台上如果你的Ubuntu镜像是云市场版网络配置通常由云平台的agent和cloud-init合作管理。手动改netplan虽然能生效但可能会和云平台的网络配置机制冲突。这类环境我建议使用云平台控制台的弹性网卡IP管理功能而不是下到系统里去改netplan文件。说回标题这件事。Ubuntu 18.04以上配置静态IP核心就一句话找对配置文件写对YAMLSafe apply。把这三点做好哪里都能配通。静态IP配置本身不是难点真正难的是配置之后各种环境变量导致的问题叠加。多花两分钟做信息收集和备份配完多执行几步验证基本不会翻车。我自己的习惯是配完静态IP之后顺手把/etc/netplan下的所有配置目录打一个整体备份包下次再改任何网络相关的配置先还原到这份基准再动手省得越调越乱。这个做法推荐给所有需要长期维护服务器网络的同行。