简介针对Ubuntu 20.04无法连接WiFi或无线图标消失的常见问题这份PDF资料整理了两种行之有效的修复方案尤其适合刚接触Ubuntu、对驱动安装和Netplan配置不熟悉的入门用户。方案一通过安装bcmwl-kernel-source驱动解决Broadcom无线网卡驱动缺失导致的识别失败方案二则从Netplan配置文件入手手动添加WiFi接入点与密码适用于驱动完好但无线连接不生效的场景。资源为单个PDF文档包体仅36KB内容精炼、步骤清晰便于随时查阅对照。该资料发布以来已有超过2万人浏览学习实践参考价值较高。读者可从中获得完整的命令操作序列、配置文件修改示例以及重启验证等排错思路即使缺少图形界面操作经验也能按步骤完成WiFi连接设置。1. 装好 Ubuntu 20.04 却找不到 WiFi 图标先定位驱动还是配置层装完 Ubuntu 20.04 后右上角没有 WiFi 图标这是笔记本用户最常见的开局问题。很多人第一反应是系统坏了其实拆开看只有两种根因要么无线网卡的驱动模块没有加载系统压根没认出硬件要么网卡认出来了但 netplan 的默认配置里只写了 ethernets没给 wifis 留位置。这两种原因的处理方式完全不同装 bcmwl-kernel-source 还是改 YAML取决于你在lspci里看到的是 Broadcom 芯片还是 Intel/Realtek 芯片。这篇文章把两条路线完整展开中间会穿插 VMware 虚拟机、双系统共用无线网卡这类高频场景最后给一套可执行的验证命令让你在重启之后能立刻知道问题出在哪一层。2. 用 lspci 与 dmesg 确认无线网卡芯片和驱动占用状态2.1 先看硬件lspci 输出里藏着网卡的真实身份不要急着敲安装命令先确认无线网卡的芯片厂商。lspci是 PCI 设备枚举工具无线网卡绝大多数挂在 PCIe 总线上少数 USB 网卡用lsusb查。我一般这样操作lspci -nnk | grep -iA3 network-nnk会同时显示设备 ID 和已绑定的内核驱动模块-A3把 network 条目后面三行打出来。输出大致是02:00.0 Network controller [0280]: Broadcom Inc. and subsidiaries BCM4331 [14e4:4331] (rev 02) Subsystem: Hewlett-Packard Company BCM4331 Kernel driver in use: wl Kernel modules: bcma, wl看到Broadcom四个字母就走 bcmwl 路线看到Intel Corporation或Realtek一般是 iwlwifi 或 rtl8xxxu 这类内核自带驱动属于配置问题而非驱动缺失改 netplan 或装 NetworkManager 更靠谱。14e4:4331是 vendor:device 编号如果你需要去社区搜特定型号的坑这串编号比BCM4331这个商品名准确得多。2.2 再查状态驱动加载没加载dmesg 说了算lspci只告诉你有这块卡不告诉驱动到底起来没有。接着跑lshw -C network在*-network条目下重点关注configuration行里的driver字段和logical name是不是空的。如果driverwl且logical namewlp2s0说明驱动在工作问题在配置层如果driverUNCLAIMED说明硬件被识别但没人接客这就是驱动缺失的典型标识。dmesg 里也会留下线索dmesg | grep -iE brcm|wl|firmware | tail -20常见的三类日志Firmware not found意味着固件文件缺失Unsupported device说明驱动不支持该型号timeout waiting for hardware多半是模块加载顺序或电源管理问题。先记下这三行关键词后面装完驱动回来对比就能确认问题是否真正被解决。2.3 别忘了 rfkill 和 NetworkManager 状态驱动正常但 WiFi 还是灰的八成是 rfkill 把无线开关锁死了。这个坑在笔记本上尤其常见尤其是用过rfkill block或者 Windows 那边有飞行模式残留的机器rfkill list输出里看到Soft blocked: yes或Hard blocked: yes就执行rfkill unblock all。同时用nmcli device status看一眼网卡是被 NetworkManager 管理还是显示unmanaged——unmanaged意味着 netplan 或 cloud-init 抢走了控制权这是第四章的主战场。3. 方法一bcmwl-kernel-source 修复 Broadcom 无线网卡驱动加载3.1 为什么偏偏是 bcmwl-kernel-sourceBroadcom 的无线网卡在 Linux 下的驱动生态很混乱内核自带b43、ssb、bcma三个开源驱动但 BCM4331、BCM4313 这一代芯片的开源驱动支持并不完整要么 5GHz 频段缺失要么频繁断流。bcmwl-kernel-source本质上是 Broadcom 官方闭源驱动的 DKMS 打包版里面包含wl内核模块对 14e4:43xx 系列的兼容性最好。DKMS 的意义在于Ubuntu 内核升级后wl模块会自动重新编译。如果没有 DKMS每次apt upgrade内核之后 WiFi 就会再挂一次逼你手动重装——这是 20.04 时代很多人被反复折磨的根源。装这个包不复杂但前提是有线网络能通否则你没法把包拉下来。# 先确保 multiverse 软件源是开启的 sudo add-apt-repository multiverse # 刷新索引 sudo apt update # 安装驱动 sudo apt-get install bcmwl-kernel-source # 卸载可能冲突的开源驱动模块 sudo modprobe -r b43 ssb bcma wl # 加载闭源模块 sudo modprobe wl命令执行完用dmesg | grep -i wl确认模块加载日志再ip a看无线网卡是否拿到 IP。正常情况会看到wlp2s0出现在列表里此时再到 GNOME 右上角点 WiFi 图标AP 列表就能扫出来了。3.2 安全启动Secure Boot才是真正的拦路虎很多人在apt install之后再重启发现 WiFi 还是没了dkms status显示installed但modprobe wl报错Operation not permitted。这是 Secure Boot 在作怪内核只会加载有合法签名的模块wl是第三方编译的没进 UEFI 签名库于是被静默拒绝。解决路径有两条。最简单的做法是进 BIOS 关掉 Secure Boot但如果你不想动 BIOS可以用 mokutil 给模块签名# 生成签名用的密钥对 openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj /CNWiFi Driver/ # 导入到 MOK 管理 sudo mokutil --import MOK.der # 重启后会进入蓝色 MokManager 界面按提示 Enroll key重启后进入蓝色的 MokManager选Enroll key from disk指定刚才生成的 MOK.der输入密码确认再重启一次。完成签名后dkms status会显示installedmodprobe wl不再报错。这条路第一次走要重启三遍别嫌烦它就是 UEFI 的既定流程。3.3 常见失败对照表现象根因处理apt install报 Package not foundmultiverse 源没开sudo add-apt-repository multiverse后重试装完仍UNCLAIMED内核 headers 缺失DKMS 编译失败sudo apt install linux-headers-generic后重装包modprobe wl报密钥拒绝Secure Boot 拦截关闭 Secure Boot 或走 MOK 签名流程装完能连但重启失效dkms 构建残留旧模块sudo dkms remove bcmwl/版本号 --all后重装5GHz 频段消失wl固件与天线增益不匹配sudo iw reg set CN后重启 NetworkManager最后一行iw reg set是射频区域设置中国区 5GHz 信道默认可能被限制设置成CN后扫到的 AP 数量会明显变化——这个细节在装完驱动后值得立刻验证一次。4. 方法二Netplan YAML 里补 wifis 段并让配置原子生效4.1 Netplan 的工作机制YAML 只是渲染入口Ubuntu 20.04 用 netplan 统一管理网络配置它在开机时读取/etc/netplan/*.yaml渲染成 systemd-networkd 或 NetworkManager 能识别的下发配置。默认的50-cloud-init.yaml只声明了ethernets没有wifis段所以哪怕驱动是好的系统也不知道该拿无线网卡怎么办。理解这层之后修法就清晰了在 YAML 里声明 wifis 段把 SSID 和密码写进去。注意接口名必须以ip a输出为准——20.04 使用可预测命名规则绝大多数是wlp2s0而非老旧的wlan0写错名字 netplan apply 会直接报Cannot find device正解析到一半就中断。4.2 可复制的 YAML 配置模板先用ip a找到无线网卡的准确接口名。假如是wlp2s0编辑/etc/netplan/50-cloud-init.yamlsudo nano /etc/netplan/50-cloud-init.yaml写入以下内容network: version: 2 renderer: NetworkManager ethernets: eth0: dhcp4: true dhcp4-overrides: route-metric: 200 optional: true wifis: wlp2s0: dhcp4: true dhcp4-overrides: route-metric: 100 access-points: HomeWiFi-5G: password: 你的WiFi密码 optional: true然后把配置下发# 校验 YAML 合法性渲染成后端配置 sudo netplan generate # 试应用60 秒内按回车确认超时自动回滚 sudo netplan try # 确认无误后永久生效 sudo netplan apply这里几个参数值得解释。renderer: NetworkManager表示交给 NetworkManager 管理对应 GNOME 右上角的 WiFi 菜单如果你装的是 server 版没有桌面可以去掉这行改用默认的 systemd-networkd。route-metric是关键有线网卡 metric 200WiFi 100内核路由表会优先走 WiFi这样同时插着网线也能确保流量不冲突。optional: true的作用是避免网卡未连接时系统等待 2 分钟才进桌面——不写这个参数开机速度会被拖慢。4.3 netplan try 的原子回滚机制netplan try是 Ubuntu 18.04 之后引入的安全机制配置先临时生效如果 60 秒内不确认自动回滚到上一版。对于通过 SSH 远程改配置的场景这个机制能救命——改错 YAML 导致断网至少还有自动还原的退路。# 远程操作时把超时时间调长一点给自己留足确认窗口 sudo netplan try --timeout120如果netplan try时报错ERROR: conf ... is not a YAML object多半是缩进问题。netplan 的语法比 Python 还严格wifis下的wlp2s0必须与ethernets对齐access-points后面必须换行缩进。拿不准时先sudo netplan generate做静态检查它会在渲染阶段就暴露语法错误不会真正改动网络状态。4.4 和 NetworkManager 打架时怎么办这个场景非常常见YAML 里没有renderer字段默认走 systemd-networkd但桌面的 NetworkManager 也想管无线网卡两边抢控制权最终谁都不干活。现象是nmcli device status显示unmanagedWiFi 菜单一直转圈。我一般直接让 NetworkManager 全权接管 WiFi# 查看当前网络服务状态 systemctl status NetworkManager # 确认 netplan 渲染目标是 NetworkManager cat /run/netplan/*.yaml | grep renderer如果renderer不是 NetworkManager修改/etc/netplan/50-cloud-init.yaml显式声明。改完执行sudo netplan generate sudo netplan apply然后nmcli radio wifi on兜底打开无线开关。这套组合拳处理完右上角图标会立刻恢复。5. VMware 与双系统场景为什么在 Ubuntu 里连 WiFi可能是伪命题5.1 VMware 里根本没有 WiFi 设备在 VMware Workstation 里装 Ubuntu 20.04 后发现lspci查不到无线网卡这是正常的。VMware 默认创建的虚拟网卡是 e1000e 或 VMXNET3它们模拟的是有线网卡WiFi 功能在虚拟化层被省略了——虚拟机里的 Ubuntu 压根没有无线网卡这个硬件。这种情况下要做的是让虚拟机通过宿主机的网络上网而不是在虚拟机里配 WiFi# VMware 里选择 VM Settings Network Adapter # 桥接模式BridgedVM 直接走宿主机物理网卡IP 由路由器分配 # NAT 模式VM 走宿主机 NATIP 由宿主机分配桥接模式最接近Ubuntu 直接连 WiFi的体验。宿主机连的是哪个 WiFi虚拟机里的 Ubuntu 就拥有那条网络的同等访问权延迟和带宽几乎无损。NAT 模式则多一层转发但好处是宿主机切 WiFi 时虚拟机不受影响。如果你的目的是在 Ubuntu 里跑apt update或下载包NAT 模式反而是最稳的——它不依赖 WiFi 信号强度只要宿主机有网就行。5.2 双系统场景Windows 能上网不代表 Ubuntu 能双系统用户最常见的困惑是Windows 下 WiFi 好好的切到 Ubuntu 就搜不到信号。这是因为 Windows 侧用的驱动和 Ubuntu 侧完全不同Windows 会自动装厂商驱动Ubuntu 只认内核模块。如果你在第二台机器上测试过 bcmwl 或 netplan 的方法但无效先确认是不是这个因素# 检查无线网卡是否被 BIOS 的快速启动机制锁住 sudo ethtool -i wlp2s0 # 查看网卡的电源管理状态 iwconfig wlp2s0 | grep Power Management很多笔记本的 WiFi 网卡在 Windows 快速启动后进入了一种省电状态Ubuntu 唤醒时拿不到完整硬件状态。解决方案是双重保险Windows 里关掉快速启动然后在 Ubuntu 里执行sudo sed -i s/3/2/ /etc/modprobe.d/*.conf把所有驱动电源管理禁用。还有一个更隐蔽的坑Broadcom 网卡在 Windows 下被更新过固件Ubuntu 侧固件版本不匹配这种情况用 bcmwl 装上后dmesg会报unknown firmware version——先回滚 Windows 固件或直接换一版驱动。5.3 树莓派 4B 装 20.04WiFi 配置走 netplan不走 bcmwl树莓派 4B 的无线网卡是博通 BCM43455但别装 bcmwl-kernel-source——树莓派社区维护的固件包是firmware-brcm80211bcmwl 反而会和内核自带的 brcmfmac 冲突。树莓派场景下直接改 netplan 即可接口名是wlan0树莓派不启用可预测命名规则配置第四章的 wifis 段就能工作。注意树莓派官方 Ubuntu Server 镜像默认启用 cloud-init它会覆盖 netplan 配置需要先sudo touch /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg阻止 cloud-init 干预网络再改 YAML 才有意义。6. 驱动与链路的验证清单dkms、iw、ip route 三层排查6.1 一套命令判断问题所在层重启后仍然连不上不要盲目重装按下面这个顺序逐层定位# 第 1 层驱动是否加载 lspci -nnk | grep -iA3 network dkms status # 第 2 层接口是否识别 ip link show iw dev # 第 3 层是否扫描到 AP sudo iw dev wlp2s0 scan | grep -i ssid # 第 4 层IP 和路由 ip addr show wlp2s0 ip route show default驱动层看Kernel driver in use是否等于wl或brcmfmac接口层看wlp2s0是否存在且state UP扫描层能列出 SSID 说明驱动和射频都没问题路由层有default via说明 DHCP 拿到了网关。卡在哪一层就去修哪一层不要从头再来。6.2iw是验证无线链路质量的冷门利器iw命令比iwconfig信息密度高得多而且 20.04 自带。连上 WiFi 后执行# 查看当前连接的 AP 信息、信号强度和频宽 iw dev wlp2s0 link # 查看该 AP 的协商速率判断是 802.11n 还是 ac sudo iw dev wlp2s0 station dump | grep -E signal|tx bitrate|rx bitratesignal值在 -50 dBm 到 -60 dBm 属于优秀-80 dBm 以下基本不可用。如果你发现tx bitrate停在 72.2 Mb/s 以下说明协商到了 2.4GHz 的 20MHz 频宽可以到路由器管理页把 5GHz 频段带宽调成 80MHz反过来如果rx bitrate跳来跳去说明周围干扰严重优先切到 5GHz。6.3 驱动回滚的正确姿势新驱动反而让 WiFi 更不稳定时回滚要干净利落。以 bcmwl 为例# 查看当前安装的驱动版本 dkms status # 卸载并移除该模块在 DKMS 中的注册 sudo dkms remove bcmwl/6.30.223.271bdcom --all # 彻底清理驱动包 sudo apt purge bcmwl-kernel-source # 重新加载内核自带模块 sudo modprobe brcmfmac sudo systemctl restart NetworkManager注意dkms remove的版本号必须以dkms status输出为准直接照抄这里会报错。回滚后用dmesg | grep brcm确认内核模块正常接管再走一遍 6.1 的检查清单。如果问题依旧就要怀疑是网卡固件而非驱动的问题——此时看dmesg | grep firmware是否有Direct firmware load failed的提示有的话去 linux-firmware 仓库拉对应型号的.bin文件放到/lib/firmware/brcm/下权限改成 644重启加载。6.4 一个值得记住的提示提示每次改完驱动或 netplan 配置重启后先跑dmesg | grep -iE wl|brcm|firmware | tail -5把结果和第二章留的日志对比。新的日志里如果不出现Firmware not found或timeout说明驱动层已经通过问题一定在配置层——这时直接nmcli device wifi connect SSID password 密码手动连一次能把路由和 DHCP 的问题单独暴露出来。nmcli这条命令绕过 netplan 直接发起连接如果它能连通就反向修改 netplan 配置的 SSID 或密码拼写即可。建议把 6.1 的检查命令存成脚本装好系统后第一次配 WiFi 前先跑一遍记录驱动层和接口层的基线输出后续任何网络异常都能快速对照。本文还有配套的精品资源点击获取
