企业官网建设流程全解析

刚从同事的电脑前起身，它屏幕上还挂着那条让人血压升高的提示：Docker Desktop failed to start because virtualization support wasn't detected。我太熟悉这行英文了。这几年不管是帮朋友装开发环境，还是处理公司新入职同事的电脑，只要和 Docker 沾边，大概率都能碰见这个 “Virtualization support not detected” 的报错。

说白了，Docker Desktop 在 Windows 上并不是直接跑 Linux 容器的，它需要靠 Windows 虚拟化层托起一个轻量的 Linux 虚拟机，再在虚拟机里运行 Docker 引擎。而虚拟化层要工作，BIOS 里的 CPU 虚拟化开关、Windows 的虚拟化组件、WSL2 的 Linux 内核、Docker Desktop 的后端设置，这四个环节必须全部打通。这条链路里任何一环断了，弹窗就会甩出这一句 “Virtualization support not detected”。

这篇内容我按自己处理过的几十台机器的经验，把从报错原理到每一层修复的具体步骤都整理了一遍。不管你是刚下载完 Docker Desktop 的 Windows 新手，还是已经被这个报错折磨了一下午的老开发，按顺序走一遍，多半能解决。

1. 这个报错到底在报什么：Docker Desktop 的虚拟化依赖链路

1.1 报错信息出现的几个典型场景

很多人以为这个报错只在安装 Docker Desktop 后第一次启动时出现，实际上我遇到的情况要复杂一些。最常见的当然是黑框一闪，然后弹窗提示 “Virtualization support not detected，Docker Desktop failed to start because virtualization support wasn't detected”。但还有几个高频时机容易被忽视：

第一种是 Docker Desktop 大版本升级之后，比如从 4.19 升到 4.27，升级完再点 Launch Docker Desktop，突然就报这个错。这通常不是 Docker 坏了，而是升级过程中重新检测了系统虚拟化状态，原本就没配完整的机器这时候原形毕露。

第二种是 Windows 系统更新之后，尤其是七零八落的大版本更新（比如 Windows 10 升 Windows 11，或者 Windows 11 的 23H2 到 24H2），部分系统的虚拟化组件会被重置或关掉，Docker 就跟着起不来了。

第三种是自己折腾过 Hyper-V 或 WSL 后出现的，可能你之前用 wsl --set-default-version 1 切回过旧版 WSL，或者手动关过 hypervisorlaunchtype，Docker Desktop 启动时检测到虚拟化链路不对，也会甩出同一句话。这三种场景原因各不相同，但弹窗文案一模一样，这就是为什么网上搜到的各种“妙招”时灵时不灵——因为大家断掉的开关根本不是同一个。

1.2 从“Virtualization support”看 Docker 在 Windows 的运行原理

要彻底搞懂这个报错，得先明白 Docker Desktop 在 Windows 上的运行机制。它不像 Linux 里那样直接把 Docker 引擎跑在宿主机上，而是借助一个轻量级虚拟机来跑 Linux 容器。这个虚拟机有两条路线：一条是 WSL2 后端（Docker Desktop 4.x 默认推荐），另一条是老牌 Hyper-V 后端。

无论走哪条路线，底层都要用到 Windows 的虚拟机监控程序（Hypervisor），而 Hypervisor 又必须依赖 CPU 的硬件虚拟化扩展，Intel 平台叫 VT-x，AMD 平台叫 SVM。这套依赖从最底层的硬件 BIOS 设置，到 Windows 功能开关，再到 WSL2 内核，最后到 Docker Desktop 的设置，是一条完整的链。

我用一个生活化的类比：Docker 是坐电梯的乘客，虚拟化层是电梯，BIOS 里的 VT-x 开关相当于电梯电闸，Windows 的虚拟化组件相当于电梯按钮。电闸没合上、按钮坏了、或者电梯被别的住户占用了，乘客都会被困在楼下。“Virtualization support not detected” 是电梯口贴的那张告示，你不查电路，光在这儿撬电梯门，当然没用。

1.3 三个必须同时满足的开关

我习惯把虚拟化支持按层级拆成三个独立开关：

第一层是硬件开关，在 BIOS/UEFI 设置里，Intel 平台叫 “Intel Virtualization Technology” 或 “VT-x”，AMD 平台叫 “SVM Mode”。这一层没开，系统中所有虚拟化相关的软件都会失效。

第二层是系统开关，在 Windows 的“启用或关闭 Windows 功能”里，相关的组件包括 Hyper-V、虚拟机平台（Virtual Machine Platform）、Windows 虚拟机监控程序平台，还有适用于 Linux 的 Windows 子系统。这一层没打开，Docker Desktop 检测不到可用的虚拟化接口。

第三层是应用开关，就是 Docker Desktop 设置里是否勾选了 “Use the WSL 2 based engine”。有些机器系统层完全没问题，但 Docker Desktop 启动时还走的是老式 Hyper-V 后端，或者设置没保存成功，同样会报错。

这三个开关是串联的，任何一个断开，Docker Desktop 报的都是同一个错误。后面所有的排查步骤，本质上就是围绕这三个开关一个一个确认、一层一层修复。

2. 动手前的三分钟体检：先确认虚拟化到底开没开

2.1 任务管理器的“性能”标签页

拿到一台报错的机器，我不会先急着改配置，而是先花三分钟做个快速体检。第一个动作是打开任务管理器，切到“性能”标签页，选左侧的“CPU”，右下角会有一行“虚拟化”的状态。如果显示“已启用”，说明 BIOS 这一层显卡没问题；如果显示“已禁用”，那不用想了，问题基本就锁定在 BIOS/UEFI 层。

这里有个细节需要注意，不同 Windows 版本显示的文字不太一样。Windows 11 的某些新版本在虚拟化那行会写成“虚拟化: 已启用（Hyper-V 在此计算机上运行）”，这说明 Hypervisor 本身已经启动，状态比普通“已启用”更进一步。如果显示的是“已禁用”，别花时间折腾 Windows 功能和 Docker 设置了，直接重启进 BIOS。

另外任务管理器里如果压根看不到“虚拟化”这一项，通常是 CPU 太老，或者主板 BIOS 版本太旧不支持相关指令集。这种情况就算 BIOS 设置里有开关，也建议先更新一下主板 BIOS 再继续。

2.2 命令行体检：systeminfo 与 bcdedit

任务管理器看的是 CPU 层面的虚拟化，但 Windows 能不能真正使用它，还要看系统层面的状态。用管理员身份打开 PowerShell（右键开始菜单，选“终端(管理员)”），输入 systeminfo，拉到输出末尾，会看到一段以“Hyper-V 要求”开头的内容，里面有四行：

• 虚拟机监控程序模式扩展
• 固件中已启用虚拟化
• 二级地址转换
• 数据执行保护

理想情况下四行都应该是“是”。如果第一行“虚拟机监控程序模式扩展”显示“否”，说明 BIOS 里的 VT-x/SVM 没开。如果第二行“固件中已启用虚拟化”显示“否”，同样是 BIOS 问题。但如果是第三行“二级地址转换”或第四行“数据执行保护”显示“否”，那麻烦一点，通常是 CPU 太老不支持 SLAT 或 DEP，这种情况即便虚拟化开着，Hyper-V 和 WSL2 也不好使。

还有一条命令我也经常用：bcdedit /enum {current}，找到名为 hypervisorlaunchtype 的选项。它显示 Auto，表示 Hypervisor 开机自动启动；显示 Off，表示被手动关掉了。如果这里被改过，Docker、WSL2、Hyper-V 全都会受影响。需要恢复时在管理员 PowerShell 里执行 bcdedit /set hypervisorlaunchtype auto，然后重启。

2.3 检查 WSL 的状态

Docker Desktop 4.x 默认依赖 WSL2，所以 WSL 本身的状态是否健康也很关键。管理员 PowerShell 里运行 wsl --status，它会显示默认版本、内核版本等信息。再运行 wsl --version，看 WSL 自身版本号，太旧的话后面可能出问题。

我遇到过很多次，wsl --status 输出里写着“默认版本: 1”，而 Docker Desktop 需要的是版本 2。或者输出直接提示 “WSL 未安装”，但系统里明明有“适用于 Linux 的 Windows 子系统”这个功能。这些情况都会导致 Docker Desktop 启动时报虚拟化支持未检测到。

这里有个容易误解的地方：很多人以为装完 Docker Desktop 就万事俱备了，其实 Docker Desktop 安装包只负责把主程序拷进去，WSL2 的 Linux 内核更新包是独立的，系统得单独装或者靠 wsl --update 拉取。我见过太多人卡在这一步，总是去重装 Docker，结果重装十遍也没用，问题根本不在 Docker 身上。

3. 从上到下逐层修复：BIOS、Windows 功能、WSL2 内核

3.1 第一步：进 BIOS/UEFI 打开 CPU 虚拟化

如果体检发现任务管理器或 systeminfo 显示 BIOS 层没开虚拟化，就得重启进 BIOS 了。各品牌主板进 BIOS 的快捷键不一样，台式机主板大多是 DEL，笔记本常见的是 F2，也有些是 F10、F12。开机时连续按对应键就行，不建议一个个试，直接看你主板或笔记本的品牌，搜索“品牌名 + 进BIOS键”更快。

进入 BIOS 后，界面风格看厂商。Intel 平台找 “Intel Virtualization Technology”，有些新主板写的是 “VT-x”，还有的藏在 “Advanced” 或 “Processor Configuration” 子菜单里。AMD 平台找 “SVM Mode” 或 “Secure Virtual Machine Mode”。把状态从 Disabled 改成 Enabled，保存退出（通常 F10）。

这里提醒一句：改完 BIOS 里虚拟化选项后，如果系统还是显示未启用，别急着怀疑改错了。部分主板，尤其是笔记本，改了 BIOS 后需要彻底断电一次才生效。办法是关机、拔掉电源线、如果是笔记本再抠出电池（现在很多内置电池，那就长按电源键十几秒放电），然后再开机进系统。这个问题我踩过坑，当时一台 ThinkPad 开了 VT-x 却没生效，折腾半天才发现是没断电。

3.2 第二步：通过“Windows 功能”打开虚拟化支撑组件

BIOS 层面没问题后，下一步确认 Windows 功能。按下 Win + R，输入 optionalfeatures 回车，打开“启用或关闭 Windows 功能”。这里需要重点确认以下几项：

• Hyper-V（如果系统是专业版、企业版、教育版，可以勾选整个 Hyper-V 目录）
• 虚拟机平台（Virtual Machine Platform，这个非常关键）
• Windows 虚拟机监控程序平台（Windows Hypervisor Platform，WSL2 和 Hyper-V 兼容性相关）
• 适用于 Linux 的 Windows 子系统（Windows Subsystem for Linux）

有些版本里 “Hyper-V” 和 “虚拟机平台” 是独立的两项，有些版本里勾选“虚拟机平台”后会自动关联。保守做法是把上面提到的几项都勾上。如果你用的是 Windows 家庭版，列表里可能看不到“Hyper-V”这一项，这是正常的，家庭版本身不带完整 Hyper-V，但“虚拟机平台”和“适用于 Linux 的 Windows 子系统”这两项必须有。Docker Desktop 在家庭版上走 WSL2 后端，跑 Linux 容器没有任何问题。

勾选完成后系统会提示重启，这里我建议一定重启，不要点“稍后”。重启后先用第2部分的方法再确认一下 systeminfo 的输出，看看四行要求是不是都变成了“是”。

如果图形界面操作不方便，也可以用管理员 PowerShell 执行命令，效果一样：

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

执行后依次输入 Y 并重启。如果命令报错 0x80070005，那是权限不够，确认 PowerShell 是否以管理员身份运行。如果报 0x800F0950，多半是系统镜像文件有损坏，需要先执行 DISM 修复：

DISM.exe /Online /Cleanup-Image /RestoreHealth

修复完再执行 Enable-WindowsOptionalFeature。

3.3 第三步：安装/更新 WSL2 Linux 内核

Windows 功能开完后，下一步是确认 WSL2 内核。管理员 PowerShell 里先运行 wsl --status，如果输出里有 “内核版本” 或者提示 WSL 版本太旧，就直接更新。

最简单的方式是从微软官方更新包安装。你可以在浏览器里搜索 “wsl_update_x64.msi 微软官方下载”，下载后双击安装。安装完成后，管理员 PowerShell 里再设置默认版本：

wsl --set-default-version 2

如果你的 Windows 10 版本较新，或者你用的 Windows 11，其实可以不用手动下载更新包，直接运行 wsl --update 让系统自动安装。这个命令在联网状态下会自动下载最新内核，比手动找安装包省心。执行完后再看 wsl --version，输出应该是一个比较新的版本号。

还有一个小细节：如果你之前装的是旧版 WSL，系统里可能有“旧版 WSL 组件”和“新版 WSL”同时存在的混乱状态。稳妥的做法是先把已注册的发行版全部处理掉（备份好数据），然后在 Windows 功能里取消勾选旧版“适用于 Linux 的 Windows 子系统”，重启后重新勾选，再执行 wsl --install 或 wsl --update。这样做看起来麻烦，但能避开很多非常奇怪的问题。

3.4 第四步：排查“内核隔离/内存完整性”的干扰

前三步做完，大部分机器就正常了。但还有一类机器，虚拟化状态全开、WSL 也正常，却依然报 “Virtualization support not detected”。这种情况我优先怀疑 Windows 内核隔离里的“内存完整性”。

Windows 安全中心里有个“设备安全性”页面，点进去能看到“内核隔离”，再展开是“内存完整性”。它是 Windows 基于虚拟化安全的机制，本质上是在虚拟化层之上再开一个安全区域。问题就在于，当这个安全区域活跃时，部分 Windows 版本上会和 WSL2 的虚拟化资源产生冲突，Docker Desktop 动不动就检测不到虚拟化支持。

如果其他排查都没问题，可以试试把“内存完整性”关掉，重启后启动 Docker Desktop 看看。关闭路径：Windows 安全中心 → 设备安全性 → 内核隔离 → 内存完整性开关拨到关。

如果你想用注册表方式，路径是：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity

找到 Enabled 键，双击改成 0，重启机器。改回来就是改成 1。

这里要说明：我不建议为了跑 Docker 一上来就关安全功能，如果前面 BIOS、Windows 功能、WSL 内核都没问题，Docker 仍然报错，再考虑关内存完整性。毕竟安全性和开发环境哪个优先，得自己权衡。不过从实际经验看，很多 Windows 11 机器关掉内存完整性后 Docker 立刻恢复正常，值得一试。

4. Docker Desktop 自身配置与后端切换的细节

4.1 确认 Docker Desktop 使用的是 WSL2 后端

系统层折腾完，还得看 Docker Desktop 自己的设置对不对。打开 Docker Desktop，进 Settings（齿轮图标），切到 General 标签页，找到 “Use the WSL 2 based engine” 这个勾选项。

如果没勾选，说明 Docker Desktop 打算用 Hyper-V 后端运行。问题在于很多人的 Windows 版本是家庭版，根本没有完整的 Hyper-V 组件，或者虽然开了 Hyper-V 但配置不完整，这时候 Docker Desktop 就会报虚拟化支持未检测到。解决办法就是把勾打上，改用 WSL2 后端。

切换后端之后，不要直接点 Docker Desktop 窗口的关闭按钮就完事了。右下角系统托盘里有鲸鱼图标，右键选 “Quit Docker Desktop” 完全退出，然后再重新打开。这样后端才真正切换过来，否则有些配置不会立即生效。

这里也顺便提醒一句，Docker Desktop 设置里的配置，改完后如果发现有提示需要重启 Docker，一定要照做。很多人改完设置后直接继续操作，结果发现 Docker 还是起不来，其实是没有把配置真正刷进去。

4.2 WSL Integration 与发行版挂载

WSL2 后端跑起来之后，还有个 Settings → Resources → WSL Integration 页面，里面会列出当前系统里安装的所有 WSL Linux 发行版。把你需要用到的发行版开关打开。

这个配置和 “Virtualization support not detected” 的报错没有直接关系。报错解决后，如果你发现 WSL 里的 Ubuntu 等发行版访问不了 Docker，或者 docker 命令在发行版里没反应，基本都是这个 WSL Integration 开关没打开。

还有一点要提醒，Docker Desktop 在使用 WSL2 后端时，会自动在 WSL 发行版里注册 docker 相关环境变量和 socket。因此正常情况下，你不需要在 WSL 的 Ubuntu 里额外安装 docker-ce，也不需要手动启动 docker 服务。如果你之前在 WSL 里手动装过 docker，那反而容易和 Docker Desktop 的 docker 命令冲突，遇到过几例这种奇怪折腾，最后手动卸掉 WSL 里的 docker-ce 才正常。

4.3 重装/重置 Docker Desktop 的正确姿势

如果以上步骤都确认过，Docker Desktop 还是报同样的错，再考虑彻底重置。这里的操作顺序有讲究，别上来就卸载。

第一步，右键托盘鲸鱼图标退出 Docker Desktop。 第二步，管理员 PowerShell 里执行 wsl --shutdown，把 WSL 虚拟机关掉，避免打日志时文件被占用。 第三步，备份数据目录。重点备份 C:\Users\你的用户名\AppData\Local\Docker 和 C:\Users\你的用户名\AppData\Roaming\Docker。 第四步，控制面板里卸载 Docker Desktop。 第五步，重启电脑，重新安装最新版 Docker Desktop。 第六步，启动 Docker Desktop，看是否恢复正常。

重置过程中不要慌。Docker Desktop 卸载时可能提示 Hyper-V 未启用之类的信息，Docker Desktop 4.x 默认走 WSL2 后端，不一定真的需要完整 Hyper-V。只要 WSL2 的组件都在，卸载重装就能把败坏的配置清干净。

这里我特别提醒一件事：%LocalAppData%\Docker 目录里有个 wsl\data\ext4.vhdx 文件，是 Docker Desktop 在 WSL2 里的虚拟磁盘，里面存的是镜像、容器、卷的数据。重装时别手贱去删这个文件，删了就是 Docker 所有数据全丢。我见过同事急眼了直接把整个 Docker 目录删掉，结果本地几十个镜像全没了，只能重新拉。

5. 特殊环境的坑：家庭版、虚拟机、残留组件与内核隔离

5.1 Windows 家庭版到底怎么处理

Windows 家庭版是 Docker Desktop 报错的重灾区，因为网上大量教程一上来就说“勾选 Hyper-V”，家庭版根本找不到这一项，很多人到这一步就卡住了。

事实是，Docker Desktop 官方对 Windows 家庭版的支持方案就是用 WSL2 后端，不需要完整 Hyper-V。家庭版需要做的只有两件事：第一，在 Windows 功能里开启“虚拟机平台”和“适用于 Linux 的 Windows 子系统”；第二，安装 WSL2 内核更新包，并把默认版本设置为 2。做完这些，Docker Desktop 在家庭版上就能正常运行 Linux 容器。

需要注意，家庭版开不了 Hyper-V，所以跑不了 Windows 容器。如果你的工作场景必须用 Windows 容器（比如开发 .NET Framework 应用），那家庭版是真不行，得升级到专业版或企业版。但如果只是日常跑 Linux 容器做开发测试，家庭版加 WSL2 完全够用，不用被网上那些“必须升级系统”的言论吓到。

5.2 虚拟机里跑 Docker Desktop：嵌套虚拟化

有一种场景特别容易把人逼疯：你的 Windows 本身是跑在虚拟机里的，比如用 VMware Workstation 或 VirtualBox 装了 Windows，再在 Windows 里装 Docker Desktop。

这种情况下，除了要保证虚拟机里的 Windows 虚拟化功能开好，还要让虚拟机软件把物理机的虚拟化指令透传进去。VMware Workstation 的设置方法是：虚拟机设置 → 处理器 → 勾选“虚拟化 Intel VT-x/EPT 或 AMD-V/RVI”。VirtualBox 的设置方法是：系统设置 → 加速 → 勾选“启用嵌套分页”和“硬件虚拟化”。

如果虚拟机软件里没有这个透传选项，或者勾选了也不生效，那 Docker Desktop 无论怎么配都会报 “Virtualization support not detected”。这里的原因不在 Windows 里，而在虚拟机软件或者宿主机的 BIOS 层。做这一步之前，建议先确认物理机 BIOS 的虚拟化开关是开着的，否则虚拟机软件也没办法透传。

个人经验：在虚拟机里跑 Docker Desktop 的体验其实一般，就算嵌套虚拟化配置成功，性能也有损耗。如果只是学习 Docker，推荐直接上物理机；如果必须在虚拟机里跑，优先用 VMware Workstation，兼容性比 VirtualBox 稳一些。

5.3 残留组件和旧版 Docker 清理

还有一类情况是系统里残留了老旧的 Docker 相关组件。尤其装过 Docker Toolbox 的机器，Docker Toolbox 是基于 VirtualBox 的老工具，它会在系统里装上 VirtualBox 驱动和 com.docker.service 相关服务。这些残留组件和 Docker Desktop 的虚拟化检测逻辑会起冲突。

排查方法是：Win + R 输入 services.msc，看服务列表里有没有 Docker Desktop Service、com.docker.service 等 Docker 相关服务。再看看程序和功能里有没有遗留的 Docker Toolbox、老版 Docker Desktop。如果有，先卸载干净，再用我前面讲的重装姿势装新版本。

另外系统里残留的 Hyper-V 组件也可能出问题。比如你之前创建过 Hyper-V 虚拟机，后来删了虚拟机但没删 Hyper-V 功能，或者反过来之前关掉过 Hyper-V，但没重启，这种情况下 Docker Desktop 检测到的虚拟化状态是混乱的。稳妥做法是：确认需要哪些功能后，统一在 Windows 功能面板里一次性勾选或取消，然后重启机器，避免开着半套组件。

5.4 内核隔离与 VBS 深挖

前面提过内存完整性，这里把 VBS（基于虚拟化的安全性）再说深一点。VBS 是 Windows 利用硬件虚拟化在下层创建一个安全环境，用来保护内核和敏感数据。它和 Docker Desktop 争抢的是同一套硬件虚拟化能力。

判断 VBS 是否在运行：打开“设置 → 系统 → 系统信息”，拉到“基于虚拟化的安全性”，如果显示“正在运行”，就说明 VBS 已经启用了。这种情况下，就算 BIOS 虚拟化显示已启用，Docker Desktop 偶尔也会报虚拟化支持未检测到。

处理方法是关闭“内核隔离”里的“内存完整性”，这是 VBS 的主要用户态入口。如果关闭内存完整性还不够，可以再考虑查看注册表：

HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity

把 Enabled 设为 0，重启。

不过我提醒一句：不要轻易使用 bcdedit /set hypervisorlaunchtype off 来关闭整个 Hypervisor。虽然这能暂时释放虚拟化资源，但 WSL2 同样需要 Hypervisor，关了之后 Docker Desktop 照样起不来。这种“杀敌一千自损八百”的操作，只有在你完全确认只用 Hyper-V 后端、不用 WSL2 的时候才考虑。

6. 问题速查表与个人排查顺序

6.1 问题速查表

把前面所有排查点整理成一张速查表，方便后续照着做：

6.2 我推荐的排查顺序

最后说下我自己的排查习惯。遇到 “Virtualization support not detected”，我从来不直接重装 Docker Desktop，而是按下面的顺序来：

第一步，任务管理器性能页看虚拟化状态，显示“已禁用”就直接进 BIOS，其他都不用看。 第二步，虚拟化已启用但还报错，跑 systeminfo，看四行 Hyper-V 要求是否全是“是”，有“否”就去 Windows 功能里补勾。 第三步，确认 Windows 功能都开了，再执行 wsl --status 和 wsl --update，把 WSL 版本拉新，设成默认版本 2。 第四步，启动 Docker Desktop，如果还失败，检查内核隔离和内存完整性，关掉再试。 第五步，检查是否虚拟机环境，确认嵌套虚拟化透传开了。 第六步，最后才考虑重装 Docker Desktop。

这个顺序看起来慢，实际上一台机器走完前三步最多十分钟。大多数人卡住，是因为跳过了前面的基础设施排查，直接去重装 Docker，结果装完发现还是原来的报错，白白浪费时间。你按我上面这个顺序来，每改一处就对照速查表看一眼，问题基本能定位到具体某一层。

说个这次最深的体会：Virtualization support not detected 这行字，表面上属于 Docker Desktop，深挖下去其实是 Windows 虚拟化链路的体检报告。链路哪层断了，它就报哪层断。把这套链路摸透了，以后别人再遇到这个错，你看一眼电脑就能猜个大概方向。我自己现在处理这种问题，平均不到五分钟就能定位，大部分是 BIOS 被更新重置了，剩下的是内核隔离开着在捣乱。先看硬件，再看系统，最后动 Docker 本身，这顺序不会错的。