在Ubuntu中重置网络，不能只盯着某一个环节做简单修补，而是要按网络层级逐步排查和清理：先确认网卡接口状态，再处理DHCP租约（这里一定要指定接口名称，比如ens33），接着检查netplan配置（renderer必须与当前实际启用的网络服务保持一致），然后再处理DNS缓存（正确方式是通过netplan配置nameservers，而不是直接手动修改resolv.conf），最后还要检查宿主机上的虚拟网卡设置。这几个步骤缺少任何一项，Ubuntu网络故障都有可能反复出现。

在 Ubuntu 里，重置网络设置并不是执行一条命令就能“恢复默认”，更准确地说，它是一套分层排查与恢复流程：接口状态需要理顺，DHCP 租约需要释放，配置文件需要核对，DNS 缓存需要刷新，相关网络服务状态也要一并检查。任何一个环节遗漏，都可能让网络问题持续存在。很多用户会直接执行 sudo systemctl restart NetworkManager，但实际效果往往不理想，原因也很明确——旧的 DHCP 租约、错误的 netplan 配置或 DNS 解析异常不会因为服务重启而自动消失，服务一旦重新加载，这些问题通常又会再次出现。

dhclient -r 后必须指定接口名，否则可能失效

执行 sudo dhclient -r 时，如果系统中存在多个活动网络接口（例如 ens33、wlan0），该命令通常只会释放主接口的租约，其他接口对应的 /var/lib/dhcp/dhclient.leases 仍可能保留旧 IP 地址信息，导致后续执行 sudo dhclient 重新获取地址时表现不一致，影响 Ubuntu 网络重置效果。

• 先使用 ip -br a 确认当前活跃的接口名称（如 ens33）
• 强制释放指定接口的 DHCP 租约：sudo dhclient -r ens33
• 再手动请求新的 IP 地址：sudo dhclient -v ens33（加 -v 可以查看 DHCP DISCOVER/OFFER/REQUEST 的完整过程）
• 注意：dhclient 不会影响由 NetworkManager 管理的连接，在纯手动网络管理模式下才更可靠

netplan 配置必须 renderer 匹配实际服务

Ubuntu 18.04 及以上版本默认通过 NetworkManager 或 systemd-networkd 渲染 netplan 配置，但如果配置文件中的 renderer 写错，就可能导致 sudo netplan apply 表面执行成功、实际没有生效——看起来没有报错，但网络配置并未真正应用。

• 检查当前 renderer：sudo cat /etc/netplan/*.yaml | grep renderer
• Ubuntu 桌面版通常使用 NetworkManager，服务器版则更常见 systemd-networkd
• 如果配置中写的是 renderer: NetworkManager，但 systemctl is-active NetworkManager 返回 inactive，就要先执行 sudo systemctl start NetworkManager
• 不要混合使用多个 netplan 配置来源：删掉 /etc/netplan/50-cloud-init.yaml（Cloud-Init 自动生成）后再新建 01-custom.yaml，可减少配置冲突

/etc/resolv.conf 是软链接，硬改会被覆盖

很多人在 Ubuntu 中会手动执行 echo "nameserver 8.8.8.8" | sudo tee /etc/resolv.conf 来修改 DNS，但重启系统或执行 netplan apply 后又发现配置被还原。这是因为 Ubuntu 默认将 /etc/resolv.conf 指向 /run/systemd/resolve/stub-resolv.conf 或 /run/NetworkManager/resolv.conf，本质上它是一个软链接，直接修改通常不会长期生效。

• 正确做法是：在 netplan 配置中加入 nameservers 配置块，然后执行 sudo netplan apply
• 临时调试时可绕过当前解析路径：sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf，再执行 sudo systemd-resolve --flush-caches
• 验证 DNS 是否真正生效：resolvectl query www.baidu.com（相比 nslookup 更准确，能够反映当前 resolver 的实际解析路径）

虚拟机环境要同步重置宿主机虚拟网卡

如果 VMware 或 VirtualBox 虚拟机中的 Ubuntu 网络无法连接，很多时候问题并不在 Ubuntu 客户机本身，而是宿主机一侧的虚拟网络出了故障。例如 VMware 的 VMnet8 NAT 服务异常，或 VirtualBox 的 VBoxNetDHCP 进程卡死，此时即使在 guest 内反复执行 dhclient，通常也无法获取到正确的 IP 地址。

• VMware：关机后打开 Virtual Network Editor → Restore Defaults，再确认 Windows 服务 VMware DHCP Service 和 VMware NAT Service 处于运行状态
• VirtualBox：命令行执行 VBoxManage dhcpserver remove --netname HostInterfaceNetworking-VirtualBox Host-Only Ethernet-Adapter，然后重新启用 DHCP 服务
• 在 guest 内操作前，先执行 sudo ip link set ens33 down && sudo ip link set ens33 up，确保网卡接口底层状态被重新初始化

真正麻烦的从来不是记不住 Ubuntu 网络重置命令，而是不清楚到底是哪一层出了故障——接口已经 up 但没有 IP？拿到了 IP 但无法 ping 通网关？能 ping 通网关却不能解析域名？每一步都应该使用对应的网络排查工具逐项验证，而不是单纯依赖“重启网络服务”来碰运气解决问题。