企业官网建设流程全解析

1. 先搞清楚Ubuntu下的网络管理架构

1.1 从ifconfig到Netplan，为什么现在配置方式和以前不一样

很多人刚接触Ubuntu时，第一反应还是敲ifconfig，发现报错找不到命令，然后就开始慌。其实这很正常，Ubuntu从17.10版本开始就不再预装net-tools了，取而代之的是ip命令，以及更上层的网络配置工具Netplan。这个变化不是Ubuntu故意折腾人，而是因为老一套的/etc/network/interfaces写法虽然简单直接，但遇到NetworkManager、桌面环境、云服务器这些场景时就显得力不从心。简单理解就是：老的配置文件只管一块网卡，新环境往往要同时管DHCP、多个网卡、虚拟交换机，甚至容器网络，继续用老办法就会出现“改了不生效”“重启就丢配置”这些经典问题。

Netplan本质上是一个“配置翻译层”，你写的YAML文件会被它转换成后端使用的配置格式。默认情况下，桌面版Ubuntu的后端是NetworkManager，服务器版的后端是systemd-networkd。你只需要写一套Netplan配置，它会自动处理后端差异。这一点对新手特别友好，你不用关心底层到底是谁在执行，只要YAML格式没写错，netplan apply一下就能生效。

我见过不少教程让你直接改/etc/network/interfaces，然后service networking restart，这在老版本Ubuntu上确实有效，但放现在容易遇到两个问题：一是文件本身可能根本不会生效，因为新版本系统默认不读取它；二是即便你把它改好了，NetworkManager可能会在你重启后覆盖网卡设置。所以如果你用的是20.04、22.04、24.04这类新版本，老老实实用Netplan才是正路。

1.2 网卡命名规则：eno1、ens33、eth0这些名字到底怎么来的

配置网络之前，第一步永远是找到网卡的真实名字。现在Ubuntu的网卡命名方式继承了systemd的规则，不再沿用以前的eth0这种顺序命名。命名前缀含义大致是这样：en代表以太网（Ethernet），wl代表无线网卡（WLAN），ww代表WWAN无线广域网。后面跟的字母和数字取决于网卡的物理位置和固件信息，比如eno1中的o表示板载（onboard），ens33中的s表示PCIe插槽位置，enp3s0则代表PCI总线3号插槽0号端口。

虚拟机里常见到ens33、ens160、enp0s3这类名字，这跟虚拟网卡的PCI设备分配位置直接相关，所以不同虚拟化平台下名字不一样很正常。比如VMware虚拟机常见ens33，VirtualBox常见enp0s3，某些云服务器上则干脆看不到物理网卡名，而是eth0加一堆虚拟网卡别名。

查看当前系统网卡的方法很简单，执行ip addr或ip link show，就能看到所有网络接口以及MAC地址、IP地址、状态。如果你在虚拟机里装了Ubuntu，却查不到网卡或者只有lo回环接口，多半是虚拟机没启用网卡设备，或者网卡类型选得不对，这个后面会重点说。

1.3 分清两个常见工具：ip命令 vs ifconfig，以及NetworkManager的作用

ifconfig之所以让很多人念念不忘，是因为它输出格式一看就懂，ip addr刚接触时密密麻麻一堆前缀。但ifconfig已经处于维护状态，很多新功能不支持，比如查看路由表要用route -n而不是ip route，操作VLAN、bridge这些高级网络对象时更是力不从心。我的建议很简单：不要纠结，直接转ip命令，花十分钟熟悉ip addr、ip link、ip route三个子命令，以后所有Linux系统都通用。

至于NetworkManager，它在桌面版Ubuntu上负责网络连接的自动管理，图标、设置界面、命令行里的nmcli都是它的前端。桌面版装完系统就能上网，就是它在背后自动用DHCP获取了地址。问题在于，如果你手动改了Netplan配置，NetworkManager可能会“抢回”网卡权限，导致你的静态IP不生效或者时好时坏。出现这种情况，可以检查/etc/Netplan下的YAML文件，看有没有把网卡交给NetworkManager管理，或者直接用nmcli查看连接状态来判断哪个模块在控制网卡。

注意：服务器版Ubuntu默认不启动NetworkManager，安装桌面版后才会启用。如果服务器上装了桌面环境，而你又想用Netplan管网络，最好在Netplan配置里明确禁用NetworkManager对网卡的管理，否则会出现各种诡异问题。

2. 用Netplan配置静态IP，最稳妥的官方方式

2.1 Netplan配置文件长什么样，核心字段逐个拆解

Netplan的配置文件统一放在/etc/netplan/目录下，文件名一般是01-network-manager-all.yaml或00-installer-config.yaml。不同版本文件名会有差异，这没关系，关键是目录里那个.yaml文件的内容。配置格式是YAML，对缩进非常敏感，多一个空格或少一个空格都可能导致netplan apply报错。

下面展示一个最典型的静态IP配置，适用于Ubuntu 20.04、22.04、24.04这些主流版本：

network: version: 2 renderer: networkd ethernets: ens33: dhcp4: false addresses: - 192.168.1.100/24 routes: - to: default via: 192.168.1.1 nameservers: addresses: - 223.5.5.5 - 8.8.8.8

字段含义逐个说：

• renderer：指定后端，networkd对应systemd-networkd，NetworkManager对应桌面环境。服务器一般用networkd，桌面版如果不想被NetworkManager干扰也可以用networkd。
• dhcp4：是否启用IPv4的DHCP，配置静态IP时设为false。
• addresses：IP地址列表，注意必须带子网掩码前缀，写成192.168.1.100/24而不是192.168.1.100加netmask 255.255.255.0。
• routes：定义路由，默认网关写成default加via，IPv6下也有对应to: default的写法。
• nameservers：DNS服务器地址，可以配置多个，用空格或数组形式都行。

配置完执行sudo netplan apply，再ip addr确认地址是否生效。如果一切正常，ping一下网关或外部IP，能通就说明配置OK了。

2.2 配完后不生效？三条命令和常见检查顺序

很多新手配置完Netplan，满怀信心执行netplan apply，结果发现IP根本没变，或者直接连不上网络了。我遇到过的情况大概有这么几类：YAML格式写错了但apply没报错、网卡名字写错、DHCP和静态配置冲突、NetworkManager抢走了网卡控制权。

排查顺序建议固定一下，能省不少时间：

1. 执行sudo netplan generate检查配置能否被正确解析，如果这里有报错，后面全是白搭。
2. 执行sudo netplan apply看有没有输出异常信息，成功时通常是静默的。
3. 执行ip addr show查看目标网卡地址有没有变成新配置的IP。
4. 执行ip route show看默认路由是否指向预期网关。
5. 最后cat /etc/resolv.conf确认DNS有没有写入，这个文件通常是指向systemd-resolved的链接文件，内容会显示当前系统的DNS配置。

如果以上步骤都正常，但网络还是不通，那就去排查物理链路了，比如网线有没有插好、虚拟机有没有开网卡、交换机端口是否正常。这个顺序我逐渐养成习惯后，配置网络再也没慌过。

2.3 多网卡场景怎么配：内网外网分开走的思路和踩坑

生产环境里多网卡很常见，比如一台服务器一块网卡连内网，另一块连外网。这种场景下Netplan配置要比单网卡复杂一些，因为你要要明确路由策略，否则数据包会走错网卡。

拿一个典型例子来说：ens33连内网，IP是192.168.10.10/24，网关192.168.10.1；ens35连外网，IP是10.0.0.10/24，网关10.0.0.1。如果只是简单地把两个网卡都配上，系统可能会因为学到两条默认路由而出现“只能通一个网段”的现象。这时就要用routes里的table参数做策略路由，或者把默认路由只分配给其中一张网卡，另一张网卡只走内网段路由。

一个比较实用的写法是这样的：

network: version: 2 ethernets: ens33: dhcp4: false addresses: - 192.168.10.10/24 routes: - to: 192.168.10.0/24 via: 192.168.10.1 nameservers: addresses: - 223.5.5.5 ens35: dhcp4: false addresses: - 10.0.0.10/24 routes: - to: default via: 10.0.0.1 nameservers: addresses: - 223.5.5.5

这段配置里，ens33只添加了去往内网网段的路由，没有写入默认路由；ens35则承担默认路由，所有外部流量都从它走。这么做的好处是内网访问不会绕道，外网访问也不会因为默认路由冲突而随机选网关。

实际踩坑提示：如果两张网卡都配置了默认网关，且使用了相同的metric值，Linux可能会在两者间负载均衡或随机选择，导致外网连接时断时续。排查时用ip route show table main看当前生效的默认路由，如果有多条，就要么删掉多余的一条，要么给不同路由设置不同的metric值。

3. 虚拟机里跑Ubuntu，网络模式选错了等于白配

3.1 VMware三种网络模式的本质区别

在VMware Workstation里创建虚拟机时，网络适配器默认会选NAT模式，安装Ubuntu后通常能直接上网。但如果你后来想改成静态IP、想让宿主机的其他电脑访问虚拟机，就必须要理解VMware那三种网络模式到底是干嘛的。

• 桥接模式（Bridged）：虚拟机直接接入宿主机所在的物理局域网，效果就像局域网里多出了一台独立电脑，IP需要和宿主机在同一网段，并且由路由器分配或手动指定。
• NAT模式：虚拟机通过宿主机“借用”IP地址访问外部网络，外部网络看到的访问来源是宿主机的IP。虚拟机之间和宿主机之间可以互通，但局域网其他设备无法直接访问虚拟机。
• 仅主机模式（Host-Only）：相当于创建了一个完全隔离的虚拟网络，只有宿主机和虚拟机在这个网络里，虚拟机可以访问宿主机，但默认不能访问外部网络（除非宿主机开启IP转发）。

三种模式没有绝对的好坏，取决于你的需求。只是大多数教程安装时默认NAT很方便，但后面做SSH、挂载目录、联调时就发现不对劲了。所以装之前想清楚自己要用虚拟机来干什么，网络模式的选择会直接影响后面的体验。

3.2 桥接模式下怎么设置才能让虚拟机正常上网

很多人把VMware网络模式改成桥接后，虚拟机突然上不了网，就开始怀疑系统配置有问题。其实大部分情况是物理机的网卡支持了多个网络接口，而无线网卡桥接起来特别容易出问题。

在VMware里切换桥接模式时，需要选择具体桥接到哪张物理网卡。如果你的电脑同时有有线和无线网卡，虚拟机桥接到了有线网卡，但电脑实际用的是Wi-Fi，那虚拟机当然上不了网。解决办法是在VMware的“虚拟网络编辑器”里，把桥接模式关联的网卡改成实际在用的那张网卡，或者干脆选择“自动”。

桥接模式下，虚拟机里的Ubuntu最好也配置成静态IP，和宿主机在同一个网段，网关指向路由器的IP，DNS设置为公共DNS或路由器IP。比如宿主机是192.168.31.100，路由器网关是192.168.31.1，那虚拟机可以设置成192.168.31.200/24，网关192.168.31.1。配置方式就是用第二节提到的Netplan写法，把网卡名改成虚拟机里的实际网卡名。

这样做完之后，不仅虚拟机本身可以上网，局域网里其他设备也能直接通过192.168.31.200访问虚拟机，做SSH、Web服务、数据库联调都很方便。

3.3 宿主机和虚拟机互通的几种方式

如果只是想让宿主机和虚拟机互相访问，NAT模式其实最简单。NAT模式下，虚拟机通常有个类似192.168.x.x的地址，宿主机可以直接ping通虚拟机，虚拟机也能通过NAT地址访问宿主机。但反过来，如果虚拟机改了静态IP，可能会丢失NAT网段下的地址，导致宿主机无法访问。

一个稳妥的做法是在VMware的NAT设置里，记住虚拟网络的网段，比如192.168.88.0/24，然后把虚拟机的静态IP设置成这个网段内的地址，比如192.168.88.10。宿主机通常在这个网段里占用一个地址，比如192.168.88.1或192.168.88.2（不同版本有差异），这样两者就能互访。

还有人喜欢用Host-Only模式做隔离环境，这时候虚拟机只能和宿主机通信，没有外部网络。如果需要外网，可以在宿主机上开启Internet连接共享，或者额外加一块NAT网卡做“双网卡”方案：一块网卡走Host-Only供内部通信，另一块网卡走NAT供外部上网。这种玩法在搭建实验环境时非常实用，配置起来也不复杂，就是多一张网卡、多一点Netplan配置的事。

3.4 VirtualBox下的类似场景补充

VirtualBox的网络模式和VMware大同小异，对应关系分别是“桥接”、“网络地址转换（NAT）”、“仅主机网络（Host-Only）”。有个显著区别是VirtualBox的NAT模式默认没有提供宿主机到虚拟机的端口转发，如果你要在NAT模式下SSH进虚拟机，需要手动在“端口转发”规则里配置，比如把宿主机的2222端口转发到虚拟机的22端口。

另外，VirtualBox默认会创建一块虚拟网卡，网段通常固定为10.0.2.0/24，虚拟机的原始NAT地址一般是10.0.2.15，网关10.0.2.2。如果你在VirtualBox里使用Ubuntu后网络不通，先检查虚拟机的网络适配器是不是选成了“未连接”，这个错误我在初学者环境里见过太多次了。

实操心得：不管VMware还是VirtualBox，安装Ubuntu时如果网络连不上，系统安装向导里后续下载更新、安装第三方驱动这些步骤会卡很久，很多人误以为是系统卡死了。建议在安装界面先跳过“下载更新”，装完系统进入桌面再慢慢调网络，这样能省下大量等待时间。

4. SSH远程连接：配置完成后第一个要验证的能力

4.1 Ubuntu默认没开SSH？几步把它打开

Minimal版Ubuntu安装完后连SSH服务都没有，桌面版即使装了OpenSSH Server也很少默认开启。很多人直接用Xshell连接Ubuntu失败，第一反应是IP配错了，其实很可能只是服务没装、没启动，或者防火墙拦住了。

安装和启动过程其实就三条命令：

sudo apt update sudo apt install -y openssh-server sudo systemctl enable --now ssh

装完以后用sudo systemctl status ssh确认状态是active (running)，再用ip addr查到IP地址，Xshell里填主机IP，端口默认22，用户名填你登录系统时的用户名，就能连上了。

如果你习惯用root直接登录，需要额外修改/etc/ssh/sshd_config，把PermitRootLogin prohibit-password改成PermitRootLogin yes，然后重启SSH服务。不过我个人建议创建普通用户加sudo权限，然后配置密钥登录，安全性和便捷性都会更好。

4.2 连不上的时候按这个顺序排查

SSH连不上是网络配置里最高频的故障之一。我总结了一套排查顺序，按部就班走一遍，基本都能定位问题。

1. 先ping目标主机IP，如果ping不通，说明网络层就有问题，SSH肯定也连不上。这时回到基础网络配置，检查IP、网关、网段。
2. 如果ping得通但SSH连不上，检查SSH服务状态，systemctl status ssh是否正常。
3. 再确认端口有没有被监听，ss -lntp | grep 22，如果没输出，说明SSH服务没起来或端口不对。
4. 如果服务正常，检查防火墙，sudo ufw status，看到22/tcp被拦截时放行：sudo ufw allow 22/tcp。
5. 最后确认虚拟机网络模式。NAT模式下宿主机访问虚拟机一般没问题，但局域网其他设备要访问虚拟机，必须改成桥接模式，否则肯定失败。

这里有个容易忽略的细节：云服务器或安装了桌面发行版的电脑，可能会有多个网卡，SSH绑定的IP可能不匹配。查看ss -lntp时分清楚是监听了0.0.0.0:22还是只监听了某个IP，如果只监听内网IP，外网连接自然失败。

4.3 修改端口、密钥登录和防火墙放行的细节

为了提高安全性，很多人喜欢把SSH默认端口从22改成其他端口，比如2222。改完后必须记得重启SSH服务，并且把防火墙里旧端口规则删掉、新端口加进去，否则自己把自己关在门外。

密钥登录配置也不复杂，本地生成一对密钥，把公钥内容追加到远程主机的~/.ssh/authorized_keys文件里，权限设对就行。记住两点：~/.ssh目录权限最好是700，authorized_keys文件权限最好是600，权限太宽松SSH会拒绝加载。

防火墙方面，Ubuntu默认装了ufw，如果之前开启过ufw enable，那所有端口默认都会被拦。常用命令有sudo ufw status verbose查看状态，sudo ufw allow 22/tcp放行端口，sudo ufw reload重载规则。不建议直接systemctl stop ufw图省事，生产环境还是要保持防火墙开启的。

注意：在云服务器上修改SSH端口或防火墙前，先确保云控制台的安全组规则也放行了新端口，否则改了以后会直接失联，这种坑踩一次就长记性了。

5. 网络配置常见问题与排查技巧实录

5.1 DNS解析问题：能ping通IP但上不了网，多半是这里

有时候静态IP配好了，能ping通192.168.1.1网关，也能ping通223.5.5.5这种公网IP，但输入www.baidu.com却提示无法解析域名。这个现象基本确定是DNS配置有问题。

查看当前DNS配置用resolvectl status，或者直接看cat /etc/resolv.conf。Ubuntu新版通常由systemd-resolved管理这个文件，所以直接改resolv.conf是无意义的，重启后就回滚了。正确做法是在Netplan配置里写nameservers段，或者在NetworkManager连接设置里修改DNS。

如果确认Netplan已经配置了DNS但ping www.baidu.com还是不行，可以试试临时指定DNS来验证网络本身是否通畅：

resolvectl query www.baidu.com

这个命令会显示解析结果和使用的DNS服务器，能快速定位是系统DNS配置问题，还是上游DNS服务器本身有问题。实际经验里，联通、电信家庭路由器自带的DNS解析有时候很慢，换成223.5.5.5（阿里DNS）或119.29.29.29（腾讯DNS）通常能立刻改善。

5.2 重启后配置丢失，大概率是改错了文件

“重启后IP又变回去了”这个问题几乎每周都能在社区看到。原因无非几种：第一，改的是运行时配置，比如直接用ip addr add这种命令添加的IP，没写入配置文件；第二，改了Netplan配置文件但没执行netplan apply，重启后配置还在但没生效，这情况相对少；第三，改错文件了，比如编辑了/etc/network/interfaces，但系统实际用的是NetworkManager或Netplan。

正确做法是把修改落实到/etc/netplan/下的YAML文件里，然后执行sudo netplan apply。如果你用的是NetworkManager，也可以在图形界面里修改连接配置，或者在nmcli里改，注意方式统一，别混着用。

另外提醒一个细节：如果你是克隆虚拟机后去改静态IP，原始克隆源里的配置可能带有多余网卡规则，导致新机器分配不到IP。遇到这种情况，先netplan config看当前配置，必要时把YAML里残留的网卡信息删掉，再重新配置。

5.3 DHCP和静态IP来回切换的管理技巧

在开发和测试环境里，今天用DHCP自动获取，明天又要静态IP，来回手改Netplan配置很麻烦。这里有个小技巧：在同一份Netplan配置里同时保留DHCP和静态两种方式，注释掉其中一种即可。比如：

network: version: 2 ethernets: ens33: dhcp4: true # addresses: # - 192.168.1.100/24 # routes: # - to: default # via: 192.168.1.1

需要静态时把注释打开、dhcp4设为false；需要自动获取时反过来。YAML里用#注释很统一，切换起来只需编辑+apply两步，比重新写文件快得多。

如果你更习惯用NetworkManager，nmcli提供了灵活的profile管理方式，用nmcli connection modify可以随时调整IPv4方法，设置为auto或manual，还不用动文件。桌面版用户推荐优先熟悉nmcli，服务器无图形界面时用Netplan就好。

5.4 双系统时间错乱与网络配置的关联问题

装双系统的用户经常遇到日历时间不准，八小时偏差，这跟网络配置没有直接关系，但很多人排查网络时总会顺手把时间也检查一遍，所以我放进来提醒一下。Windows和Linux对硬件时钟的处理方式不一样，Windows认为硬件时钟是本地时间，Linux认为硬件时钟是UTC时间，安装双系统时容易把硬件时钟写乱。

解决办法是在Ubuntu里把硬件时钟改为本地时间：

sudo timedatectl set-local-rtc 1 --adjust-system-clock

这个设置不会影响网络配置，但能让双系统切换时少一个莫名其妙的问题。

5.5 嵌入式开发板挂载Ubuntu目录的网络问题

嵌入式和硬件开发的朋友经常要把开发板挂载Ubuntu主机上的NFS目录，或者反过来用虚拟机里的Ubuntu作为交叉编译环境，给板子传文件。这类场景依赖网络配置正确，尤其是要保证虚拟机桥接或NAT模式下能和开发板在同一个网段里通信。

我见过的最常见坑是防火墙拦截NFS相关端口，比如2049、111等。在Ubuntu上配好NFS服务后，如果开发板mount -t nfs总是超时，可以先在Ubuntu上执行sudo ufw allow from 开发板IP来放行整个主机访问，或者干脆先临时sudo ufw disable，验证通了以后再精确配置规则。还有种情况是虚拟机网络模式选择了NAT，但开发板在局域网里，NAT模式下虚拟机无法被板子主动访问，这时把网卡改成桥接模式基本能解决。

实操提醒：做嵌入式联调时，尽量让Ubuntu、开发板、宿主机三者处于同一物理局域网网段，并都把IP设置成静态。频繁使用DHCP会导致每次重启地址变动，然后调试到一半又连不上了，整个体验非常折磨。

6. 网络配置思路的进阶建议

聊了这么多，其实都是从“不通”到“通”的过程。但我越来越觉得，真正高质量的网络配置不是三下五除二让网通就算完事，而是把整个过程理得明明白白：明确设备角色、规划好IP、管理好网关和DNS、做好防火墙规则，平时还得留好排查路径。无论是虚拟机、云服务器还是物理机，这套思路都通用。

遇到网络问题别急着在网上搜“Ubuntu 网络配置”然后照抄一堆代码，先坐下来理一理自己的网络拓扑：宿主机、虚拟机、路由器、开发板各自在哪个网段，谁依赖谁，谁应该走哪条网卡。想清楚了再动手改配置，通常几分钟就能解决问题。否则今天改这个、明天试那个，很容易把系统配置搞混乱，到时候想回滚都不知道从哪开始。

根据我个人经验，最值得养成的习惯是每次配置完静态IP后，顺手把网关、DNS、网卡名、网段这些关键信息写进一个备忘文件，放到/etc/netplan/README或者自己的笔记里。等过了一个月、半年再回来看，这份记录比任何教程都有用。