Kali Linux网络故障排查：从虚拟机网卡到DNS的完整解决思路

装好Kali Linux之后第一件事是什么？不是打开终端敲命令，不是找渗透测试工具，而是先确认能不能上网。这个问题听起来简单，但群里几乎每天都有新手卡在这一步：刚装完系统，浏览器怎么都打不开网页，apt update报错一大片，重启几次依然没用，最后只能重装系统，结果重装完还是老样子。

说实话，Kali连不上网这个问题，大部分情况下根本不用重装。网络连接是一条完整的链路，从物理网卡到IP地址分配、DNS解析、再到应用层访问，任何一环出问题都会表现为“连不上网”，但不同环节的故障表现不同，排查方式也完全不同。这篇文章我就按自己日常排查的实际顺序，把Kali从虚拟机到物理机、从有线到无线、从系统服务到软件源配置的各种断网场景拆开讲清楚。

1. 别急着重装系统：先弄清断网发生在哪一层

1.1 新手最常见的三个无效操作

在社区里回答Kali网络问题多了之后，我发现新手遇到断网时最爱做三件事：第一，反复重启虚拟机和宿主机；第二，直接重装Kali；第三，把虚拟机软件删了重新装。这三个操作有一个共同特点——它们都是在赌运气，而不是在排查问题。

网络请求发出后要经过完整的链路才能到达对端服务器：物理网卡或者虚拟网卡负责收发信号，网卡拿到IP地址之后才能参与路由寻址，DNS把域名解析成IP之后应用层才能建立连接。任何一个环节断了，表现都是“上不了网”，但你不知道断在哪。

所以我反复跟人强调：排查网络故障，第一原则是逐层定位，第二原则是不要跳过基础检查直接怀疑玄学原因。先把断网的位置确定下来，后面的一切操作才有针对性。

1.2 三条命令确定故障层次

打开终端，按顺序执行下面三条命令，基本上能把问题范围缩小到一个很小的区间。

ping 8.8.8.8

这里用8.8.8.8做探测目标，是因为它是直接以IP形式访问外部服务器，不涉及域名解析。如果这条命令通了，说明网卡驱动、IP地址分配、路由表、物理链路全都是正常的，问题一定出在DNS或者其他上层配置上。如果这条命令不通，说明问题出在更底层的网卡或网络配置层面。需要注意的是，某些网络环境禁ping8.8.8.8，可以先换成ping 114.114.114.114，这个国内公共DNS服务器的可达性通常更好。

ping www.baidu.com

0. 如果上一条命令通了但这一条不通，那就非常典型：IP层没问题，纯粹是DNS解析挂了。

再看下网卡当前的地址状态：

ip addr show

这个命令的输出里，重点关注有线网卡（一般是eth0、ens33、enp0s3之类的名字）和无线网卡（wlan0）。如果看不到类似inet 192.168.x.x这样的IP地址段，说明网卡没有成功获取IP，问题出在DHCP或者网卡本身。

拿到这三条命令的输出后，你就能把故障分成几类：底层网络完全不通、DNS解析故障、网卡没拿到IP、无线网卡不识别。下面各节就按这些场景分别拆解。

2. 虚拟机里的Kali：VMware和VirtualBox最容易忽略的网卡设置

2.1 NAT、桥接和仅主机：三种网络模式搞错了就是断网

绝大多数人是从虚拟机开始接触Kali的，而虚拟机里的网络问题，有一半以上出在网络模式选择错误上。

VMware和VirtualBox默认给虚拟机提供三种网络模式：

• NAT（网络地址转换）：宿主机扮演路由器的角色，虚拟机通过宿主机的IP地址访问外网。这个模式下虚拟机可以上网，而且不需要占用物理局域网的IP。
• 桥接（Bridged）：虚拟机直接接入宿主机所在的物理局域网，像一台独立的设备一样，占用一个局域网IP。
• 仅主机（Host-only）：虚拟机只能和宿主机通信，出不了这台物理机，自然上不了外网。

新手最容易踩的坑是什么？安装系统的时候选错了模式，或者在虚拟机设置里把网卡手动移除了，结果进入Kali之后发现系统里压根没有可用的网络接口。

在VMware里检查的方式是：右键虚拟机 → 设置 → 网络适配器 → 选择“NAT模式”，并勾选“启动时连接”。在VirtualBox里则是：设置 → 网络 → 连接方式选“网络地址转换（NAT）”，下面的“接入网线”选项必须勾上。这一项很多人会漏掉，没勾选就相当于物理网线没插，系统无论如何都连不上。

2.2 VMware网卡类型选错：VMXNET 3与e1000e之争

VMware有一个很多新手完全没注意到的问题——虚拟网卡的类型。VMware在创建虚拟机时，默认可能选择“VMXNET 3”这种高性能虚拟网卡，但在部分Kali版本下，系统内核里没有对应的驱动模块，表现为网卡完全不被识别，ip addr里只有lo回环接口。

解决办法有两个，我建议直接走第一个：编辑虚拟机设置 → 网络适配器 → 在“设备类型”里从VMXNET 3改成“e1000e”（Intel PRO/1000千兆网卡模拟）。e1000e是模拟Intel经典的千兆网卡，Linux内核的支持非常成熟，几乎不存在识别不了的情况。

第二个办法是保留VMXNET 3，在Kali里安装对应驱动。但这个方案有个死循环：如果系统识别不了网卡，你连不上网，怎么下载驱动？除非你有其他临时网络手段，否则别折腾。

2.3 VirtualBox的网卡控制器选择也有讲究

VirtualBox用户如果遇到“网卡明明添加了但Kali里就是看不到”的情况，进虚拟机设置 → 网络 → 高级 → 控制器类型，Windows下默认可能是“Intel PRO/1000 MT Desktop”，虽然兼容性不错，但个别Kali版本和这个网卡模拟有兼容问题。我的经验是可以尝试换成“PCnet-FAST III”这个老型号，它反而在一些冷门版本的Linux系统里被识别得更顺利。

为什么会出现这种问题？VirtualBox每次更新都会调整它的网卡模拟实现，而Kali的内核更新也很快，两边不是总能配合得好。遇到识别不了的时候，就把控制器类型逐个试一遍，这是最快的方法。

2.4 虚拟机里能上网但时断时续：检查虚拟网络编辑器

还有一种情况是虚拟机刚开机能上网，过几分钟就断了，然后重启虚拟机又好。这个我遇到过很多次，尤其多发于VMware上。原因是VMware的NAT模式依赖宿主机的VMnet8虚拟网卡和vmnetdhcp服务，Windows宿主机上的VMware相关服务有时候启动不完整。

排查方式：编辑 → 虚拟网络编辑器 → 选VMnet8（NAT模式） → 点击“更改设置” → 看一下子网IP和DHCP设置是否正常，然后点“还原默认设置”让VMware重建虚拟网络。这个操作会清零你自定义的网络配置，但通常能修复各种奇怪问题。注意一定要用管理员权限打开VMware才能改这些设置。

3. NetworkManager服务状态异常：最常见的软件断网元凶

3.1 NetworkManager is not running 是怎么发生的

Kali的网络管理架构里，NetworkManager占据核心位置。它负责自动检测网络连接、通过DHCP获取IP地址、管理Wi-Fi连接、处理网络切换。Kali的默认桌面环境Xfce依赖NetworkManager来实现图形化网络管理，如果它挂了，就算网卡驱动完全正常，系统也拿不到IP地址，表现为有线网络不通、Wi-Fi扫描不到任何信号。

在终端里执行网络管理命令时，经常会遇到NetworkManager is not running的提示，或者systemctl status NetworkManager显示inactive (dead)。

为什么它会停止运行？我在实际使用中遇到过几种情况：

1. 安装某些工具的过程中，自动把NetworkManager依赖的服务停掉了。
2. 手动修改过/etc/network/interfaces文件，里面的配置和NetworkManager发生冲突，导致服务启动失败。
3. 有些精简版的Kali Live磁盘镜像里NetworkManager默认不启动。
4. 系统异常关机后，服务状态没有正确恢复。

3.2 启动和设置开机自启的标准操作

检查并启动NetworkManager：

systemctl status NetworkManager systemctl start NetworkManager systemctl enable NetworkManager

enable这步很重要。它会把NetworkManager注册为开机自启服务，否则你这次手动启动了，下次开机又断网。很多人只执行了start，重启后又来问为什么断网，原因就是漏了这一步。

如果执行start提示服务不存在，说明NetworkManager被卸载了，需要重新安装：

apt update && apt install network-manager -y

这里有个逻辑上的尴尬：NetworkManager挂了可能意味着你当前根本没有网络，那apt update自然跑不了。这时候建议直接跳到后面第6节，先用临时手段恢复网络，再回来装。

3.3 /etc/network/interfaces 与NetworkManager的配置冲突

这是Kali网络问题里隐藏得最深的一个坑。

Debian系列系统里，传统的有线网络配置方式是编辑/etc/network/interfaces文件，在里面写静态IP或者DHCP设置。这个方法在Ubuntu Server、Debian Server这些没有桌面环境的系统上完全适用，但在Kali这种带桌面环境、默认由NetworkManager接管网络管理的发行版上，两边就会打架。

冲突的典型表现是：你按照网上的教程在/etc/network/interfaces里配置了静态IP，重启之后发现网络管理器界面一片空白，或者连接状态一直在转圈，最终上不了网。

排查方法：

cat /etc/network/interfaces

正常状态下，这个文件应该只有loopback配置，类似：

auto lo iface lo inet loopback

如果你发现里面多了auto eth0、iface eth0 inet static、address之类的内容，说明造成冲突的根源就在这。把这些内容注释掉或者直接清空，只保留loopback部分，然后重启NetworkManager：

systemctl restart NetworkManager

如果这个文件被你改坏了，又不知道原本该是什么样，直接用一行命令重置：

echo -e "auto lo\niface lo inet loopback" | sudo tee /etc/network/interfaces

之后重启NetworkManager即可。

4. 无线网卡不被识别：从驱动加载到rfkill封锁的完整排查链路

4.1 笔记本跑Kali，Wi-Fi消失的第一道坎：硬件识别

笔记本物理机安装Kali的无线网络问题，和虚拟机完全是两个世界。虚拟机里只要网卡模式正确基本都能上网，物理机上则要看无线网卡的硬件型号是否被Kali内核支持。

如果你发现自己笔记本电脑上的Kali里只有有线网卡接口，wlan0完全不存在，首先要确认无线网卡的硬件型号。查看PCI设备列表：

lspci | grep -i network lspci | grep -i wireless

输出里如果能看到Broadcom、Realtek、Intel、Atheros等厂商的无线网卡型号，说明硬件本身在PCI总线上是存在的，只是驱动没加载。

4.2 博通网卡驱动：broadcom-sta 和 b43 的选择问题

在所有无线网卡厂商里，博通（Broadcom）在Linux下的驱动兼容性是最折腾的。博通网卡在Linux下对应两套驱动方案：broadcom-sta（提供wl模块）和b43（开源驱动）。选哪个取决于具体的芯片型号，选错就加载不上。

例如，BCM4313一般用broadcom-sta，而BCM4311/4312/4318这些老芯片适合b43。如果自己不确定，先查一下芯片型号再决定。另外，如果是Intel的无线网卡，绝大多数型号的内核自带驱动，通常不用额外操心。

4.3 没网络怎么装驱动的死循环：手机USB网络共享最好用

物理机上遇到“网卡不被识别 → 上不了网 → 下载不了驱动”的死循环，最好的破局方案不是折腾U盘拷贝deb包，而是用手机USB网络共享。

安卓手机开启“USB网络共享”后，通过数据线连接电脑，Kali会自动把手机识别为一个有线网络接口（通常是enp0s20u2这样的名字），并能通过DHCP拿到IP。这相当于你的电脑临时多了一个USB有线网卡，而且这个网卡不需要装任何额外驱动，兼容性极好。

只要有了网络，接下来不管是apt install broadcom-sta-dkms还是从软件源下载任何驱动包都不成问题。

4.4 网卡存在但连不上：rfkill 软封锁和硬封锁的区分

还有一种很容易被忽略的情况：wlan0接口存在，信号列表也能看到，但怎么都连不上Wi-Fi。这时候优先检查是不是被rfkill锁定了。

rfkill list

输出结果里，如果某个无线设备后面带有Soft blocked: yes或者Hard blocked: yes，问题就出在这。软封锁是系统层面的锁定，可以用命令解除：

rfkill unblock all

硬封锁则对应笔记本的物理Wi-Fi开关或者键盘上的飞行模式快捷键，系统层面解除不了，必须手动打开。有的笔记本Wi-Fi开关藏得很隐蔽，在机身侧面一个物理拨杆，或者在键盘上和F1-F12功能键放在一起，需要配合Fn键使用。

4.5 驱动就绪后用nmcli连接Wi-Fi

确认驱动正常、rfkill没有封锁后，用NetworkManager的命令行工具连接Wi-Fi：

nmcli radio wifi on nmcli device wifi list nmcli device wifi connect "WiFi名称" password "WiFi密码"

nmcli device wifi list如果列出了周围的无线网络，说明整条无线链路已经通了，连接后就有网络。如果这条命令提示找不到设备，那就返回去检查驱动加载和rfkill状态。

5. 能ping通IP却上不了网：DNS解析与软件源配置的双重陷阱

5.1 DNS配置错误制造的“伪断网”

有一种情况在群里的提问频率非常高：“我ping 8.8.8.8通了，但ping www.baidu.com不通，浏览器打不开任何网页，这是怎么回事？”这就是典型的DNS解析故障。IP层的网络完全正常，只是域名解析这一步挂了。

查看当前系统的DNS配置：

cat /etc/resolv.conf

正常情况下应该有一两行nameserver配置，比如nameserver 223.5.5.5。如果文件里全是注释，或者指向了一个不可达的地址，域名就解析不了。

用NetworkManager来修改DNS设置，而不是直接编辑文件：

nmcli connection show nmcli connection modify "Wired connection 1" ipv4.dns "223.5.5.5 114.114.114.114" nmcli connection up "Wired connection 1"

第一行先查看当前活动的连接名称，第二行把DNS设置为阿里公共DNS（223.5.5.5）和114DNS（114.114.114.114）的组合，第三行让修改生效。这里不用8.8.8.8是因为在很多网络环境下，它作为DNS服务器时访问速度慢甚至超时，而国内这两个公共DNS服务器响应速度更快更稳。

5.2 手动编辑 /etc/resolv.conf 为什么总是被覆盖

有的同学习惯直接编辑/etc/resolv.conf来改DNS，却遇到一个怪现象：改完保存，几秒之后文件内容又恢复原样了。

原因在于Kali的systemd-resolved服务会接管/etc/resolv.conf，它会把文件强制改为指向127.0.0.53这样本地回环地址的软链接，你手动改的内容毫无意义。这样做的本意是把DNS缓存统一管理起来，但对不熟悉这个机制的人来说反而添乱。

想直接编辑resolv.conf的话，需要先停掉systemd-resolved：

systemctl stop systemd-resolved systemctl disable systemd-resolved

之后才能手动编辑。不过我个人的建议是，日常使用就乖乖用NetworkManager管理DNS，它和桌面环境的图形化设置是联动的，不容易出问题。

5.3 apt update连不上：这不是网络断了，是软件源的问题

最后一种“伪断网”很有迷惑性：浏览器能打开网页，ping外网IP也通，偏偏执行apt update的时候报一堆连接错误。这通常是软件源配置的问题。

Kali官方默认的软件源是http://http.kali.org/kali，从国内访问这个源的速度很不稳定，而且经常会连接超时。对策是换成国内镜像源。

备份原始配置不解释，直接改：

cp /etc/apt/sources.list /etc/apt/sources.list.bak

编辑/etc/apt/sources.list，写入阿里云Kali源的配置：

deb https://mirrors.aliyun.com/kali kali-rolling main non-free contrib deb-src https://mirrors.aliyun.com/kali kali-rolling main non-free contrib

保存后执行apt update。如果提示缺少apt-transport-https无法访问HTTPS源，先安装：

apt install apt-transport-https ca-certificates

这里建议HTTPS源，是因为HTTPS能避免ISP劫持软件包内容的问题。如果你连HTTP源都访问不通，那就要回到前面的网络底层排查了。

6. 物理机有线网卡驱动缺失：没有网络时的离线救急方案

6.1 装完系统发现没有有线网卡

物理机安装Kali后，发现网线插着但系统里完全看不到有线网卡接口，这种情况多见于新款笔记本或部分使用冷门网卡芯片的主板。Kali虽然后出，但内核也不可能覆盖市面上所有网卡芯片的驱动。

先用这两个命令确认硬件和驱动状态：

lspci | grep -i ethernet dmesg | grep -i ethernet

第一条命令检查PCI总线上是否能识别到以太网控制器，第二条命令查看内核启动日志里网卡相关的报错信息。如果lspci能看到网卡型号但dmesg有报错，那就基本确定是驱动问题。

6.2 离线安装驱动的四步走

没有网络的情况下安装驱动，只能走离线路线：

1. 找一台有网络的电脑，访问Kali的软件包仓库，搜索对应网卡驱动相关的deb包，比如Realtek网卡就找firmware-realtek和r8168-dkms这样的包。
2. 把下载的deb包拷贝到U盘。
3. 在Kali物理机上执行离线安装：

dpkg -i 包名.deb

如果提示缺少依赖包，需要把依赖的deb包也一并下载拷贝过来，再执行一次apt -f install补装依赖。需要注意的是，apt -f install本身也是要联网的，所以从网上一次性把所有依赖都下载齐全比什么都重要。

4. 安装完成后加载驱动模块：

modprobe 模块名

5. 用dmesg | tail确认驱动有没有报错。

6.3 备用网卡和Live镜像的思路

如果你被驱动问题折腾了一晚上还没搞定，我的建议是不要再死磕了。花几十块钱买一张主流的USB有线网卡或者PCIe网卡，Realtek RTL8111/8168系列和Intel I219系列在Linux下的驱动支持非常完善，插上即用。这种“用钱换时间”的做法，在项目赶进度的时候性价比很高。

另一个思路是用Kali Live USB启动，看看Live模式下网卡能不能识别。Kali的Live镜像会尝试加载更全面的驱动候选集，有时候安装版系统识别不了的网卡，在Live模式下反而能工作。如果Live模式下能上网，至少能确认你的网卡硬件没坏，只是安装版的驱动组不够全。

7. 减少断网概率的日常习惯与自查清单

7.1 更新内核后先准备后路

Kali是滚动更新发行版，内核更新很频繁，而每次内核大版本更新后，第三方驱动的兼容性问题就可能冒出来。如果某个网卡驱动是后装的DKMS模块，内核更新后模块需要重新编译加载，这个过程中断网属于常见现象。

所以我更新内核后有个习惯：不急着关机，先执行uname -r确认当前内核版本，同时测试一下网络是否正常。如果重启后发现网卡找不到了，先检查内核头文件是否就位：

apt install linux-headers-$(uname -r)

然后重新编译安装对应的驱动程序。

7.2 关键服务的例行体检

我平时每隔一段时间会执行下面两条命令，看看系统的网络核心服务是否健康：

systemctl status NetworkManager systemctl status systemd-resolved

这两条命令按两下Tab就能补全，花费不到十秒钟，但能提前发现很多隐患。比如NetworkManager处于半死状态但没完全死掉的时候，图形界面可能还能显示，但网络已经时好时坏，这时候看一眼服务状态就能发现问题。

7.3 建立自己的网络故障速查表

排查网络问题多了之后，我建了一个速查表，每次踩坑就更新一行。这里分享给你参考：

7.4 一个很少人知道的恢复技巧：nmcli general reload

最后分享一个冷门但很实用的命令。如果你觉得网络配置被改乱了，但又不确定改了什么，可以执行：

nmcli general reload

这个命令会让NetworkManager重新扫描并加载系统里的网络配置文件，相当于让网络管理器自己重新整理一遍。它不是万能的，但很多时候能恢复一些莫名其妙的状态，而且完全不需要重启系统。

我在实际使用Kali的过程中，踩过最多的坑其实就是两个：虚拟机的网卡选型选错了，以及手贱改了/etc/network/interfaces导致和NetworkManager打架。这两类问题占了Kali断网案例的很大比例，其次才是无线网卡驱动这些硬件问题。希望这篇文章能帮你把排查思路理清楚，下次遇到Kali连不上网，先从命令的结果判断故障层次，再对症下药，别一上来就重装系统，那是在浪费自己的时间。如果你试完整套流程还是查不出原因，把你执行ip addr show、ping 8.8.8.8、systemctl status NetworkManager这三条命令的输出放到评论区，我们按具体输出来分析。