Docker Desktop 在 Windows 上启动时报 “Virtualization support not detected” 的错应该是我这些年处理容器环境问题里最常遇到的一个。折腾过的人都知道这个提示一出Docker Desktop 基本是没法正常用的连右上角的失败提示都带着一股“我检测不到虚拟化你看着办”的味道。而且关键在于这行报错并不会直接告诉你到底是 BIOS 里没开虚拟化、Windows 功能没勾选还是系统组件跟别的虚拟机软件打架。如果你正好不太熟悉 Windows 的虚拟化底层逻辑很容易在原地打转半天甚至一度怀疑是不是电脑太老、CPU 太拉胯。这篇文章就直接把这个报错从根上拆开讲我会按排查顺序把 BIOS 设置、Windows 功能、WSL2 环境、Hyper-V 冲突这几个环节全部过一遍每一步都给到可以直接照做的命令和操作。无论你是刚准备装 Docker Desktop 的新手还是启动某天突然开始报错的老用户这套方案基本都能覆盖。整个流程走完大多数情况下五分钟内就能让 Docker Desktop 重新跑起来。1. 搞清楚报错背后的三件事1.1 报错的完整含义完整报错一般长这样Docker Desktop failed to start because virtualisation support wasnt detected. Sign in to try restoring access to Docker features.翻译过来就是“Docker Desktop 启动失败因为检测不到虚拟化支持”。这行提示的关键词不是“Docker”而是“virtualisation support”。Docker Desktop 在 Windows 上并不是直接跑 Linux 容器的它在底层依赖一个轻量级虚拟机或 Windows 自带的虚拟化组件然后在这个虚拟化环境里运行 Docker 引擎。Windows 上常见的后端有两种老的 Hyper-V 后端和现在默认的 WSL2 后端。不管用哪种底层都必须有可用的硬件虚拟化支持和对应的 Windows 虚拟化功能。Docker Desktop 启动时会通过 Windows 的虚拟化相关 API 去探测当前系统是否具备虚拟化条件。如果探测失败它就把锅扔给你显示这么一句没头没尾的话。所以这行报错本质上是一个“结果”而不是“原因”。我们要找到的是导致探测失败的根源。1.2 为什么报错不直接告诉你具体哪里有问题这个问题我一开始也很困惑。按理说检测不到虚拟化要么是硬件层面没开要么是系统软件层面没开你直接说清楚不就好了但实际情况是Docker Desktop 只负责调用系统能力并没有权限去细化判断每一个开关的状态。它拿到的是 Windows 给它的一个最终结果这个结果可能是由多个环节共同决定的。举个不太恰当但容易理解的例子你打电话给快递公司查包裹客服告诉你“包裹没送到”但没告诉你是因为地址写错了、交通管制了还是仓库漏发了。Docker Desktop 就是那个客服它只知道自己没法干活具体哪个环节出问题得靠我们自己一层层排查。我实际排查下来报错原因基本逃不出这三类硬件虚拟化没开也就是 BIOS/UEFI 里的 Intel VT-x 或 AMD-V 被禁用了。Windows 的虚拟化相关功能和组件没启用比如 Hyper-V、虚拟机平台、Windows 虚拟机监控程序平台、WSL2 功能缺失。系统里其他虚拟化组件或安全软件跟 Docker Desktop 冲突导致检测结果异常。这三类原因对应着不同的解决方向下面我会按“先硬件、再系统、后冲突”的顺序展开。1.3 排查前先分清报错出现的三个常见时机你是在什么时候看到这个报错的也能帮忙缩小范围。我遇到的情况基本是三种第一种刚装完 Docker Desktop第一次启动就报错。这种最常见多半是 Windows 上缺少必要的虚拟化功能或 BIOS 里没开虚拟化也可能是装 Docker Desktop 的时候系统没让你启用 WSL2。第二种原来用得好好的某天突然开始报错。这种往往不是你自己手动改了什么而是 Windows 更新改动了一些设置比如更新后把 hypervisorlaunchtype 改成了 Off或者安全软件升级后开始拦截虚拟化驱动。第三种在虚拟机里跑 Windows再在 Windows 里装 Docker Desktop。比如你用 VMware 或 VirtualBox 装了 Windows 系统然后在里面装 Docker Desktop这时虚拟化支持还要额外做一层“嵌套虚拟化”配置否则 Windows 检测不到硬件虚拟化。不同时机对应不同的排查重点下文会分别覆盖到。2. 第一道关卡BIOS 层面必须把虚拟化打开2.1 Intel 和 AMD 平台设置入口差异很多教程一上来就让你开 Windows 功能但实际上硬件虚拟化如果没开后面做再多软件层面的设置都是白费。所以第一步永远是确认 BIOS/UEFI 里的 CPU 虚拟化开关。Intel 平台一般叫 Intel Virtualization Technology缩写是 VT-x不同主板厂商的叫法略有差异。名称也可能写成“Intel VT”、“Virtualization Technology”、“VT-x”等。AMD 平台则叫 SVM Mode有些主板写的是“AMD SVM”或“Secure Virtual Machine Mode”。进 BIOS 的方法大家应该都知道开机时反复按 Del、F2 或 F10具体看主板型号。进 BIOS 之后虚拟化开关通常藏在 Advanced 或 Overclocking 或 CPU Configuration 这类菜单里。建议直接找关键词 “Virtualization”、“VT-x”、“SVM”。找到之后把它设为 Enabled保存退出重启系统。这一步看起来简单但很多人会在这翻车有些主板默认是关闭的或者因为之前装过精简版系统、用过某些优化工具被顺手关掉了。更隐蔽的是某些“系统优化”软件会直接修改 Windows 的启动配置把 hypervisor 启动类型设成 Off导致即使 BIOS 开了虚拟化Windows 也检测不到。2.2 如何在 Windows 里快速确认 CPU 虚拟化是否生效不想到处找 BIOS 选项的话可以先在 Windows 里确认硬件虚拟化是否已经被系统识别。打开任务管理器切到“性能”选项卡点击“CPU”在右下角能看到“虚拟化”一栏状态是“已启用”或“已禁用”。不过这里有个坑任务管理器显示的“虚拟化: 已启用”只能说明 CPU 硬件层面的虚拟化可用并不能代表 Hyper-V 或 WSL2 已经正常工作。它跟 Docker Desktop 的报错不是完全对等的。更可靠的判断方式是使用命令行systeminfo然后看输出里的“Hyper-V 要求”部分里面有四项已检测到虚拟机监控程序如果显示“是”说明 Hyper-V 正在运行。用于虚拟化的固件显示“是”说明 BIOS 层面的硬件虚拟化已经打开。二级地址转换对应 CPU 的 SLAT 特性显示“是”表示支持。数据执行保护一般显示“是”。如果你在这里看到“用于虚拟化的固件”为“否”那基本可以确定 BIOS 里的虚拟化没开。先去 BIOS 搞定再回来。如果这四项都是“是”但 Docker Desktop 还是报错那就进入下一关卡Windows 功能设置。3. 第二道关卡Windows 功能组件与 WSL2 环境补齐3.1 需要启用的关键功能Docker Desktop 在 Windows 上运行依赖的组件主要是 Hyper-V、虚拟机平台、Windows 虚拟机监控程序平台以及 WSL2。现代 Docker Desktop 默认使用 WSL2 后端但无论用哪种后端“虚拟机平台”和“Windows 虚拟机监控程序平台”这两个功能都必须处于启用状态。具体需要启用哪些 Windows 功能因系统版本而异。如果你是 Windows 10 2004 及以上版本或 Windows 11最少要启用适用于 Linux 的 Windows 子系统WSL虚拟机平台Windows 虚拟机监控程序平台如果是 Windows 10 更旧的版本可能还需要手动启用 Hyper-V但你需要注意的是Windows 10/11 家庭版默认没有 Hyper-V 功能选项。家庭版装 Docker Desktop 的常见做法是启用 WSL2 后端然后依赖“虚拟机平台”和“虚拟机监控程序平台”这两个底层功能。Docker Desktop 新版安装包也会在安装时检查这些依赖。3.2 命令行方式一次搞定绝不漏项我最推荐的方式是在管理员权限的 PowerShell 或 CMD 里执行命令因为图形界面勾选容易漏而且你根本不知道哪些功能现在处于什么状态。直接用命令更干脆。以管理员身份打开 PowerShell执行下面的命令分别启用 WSL、虚拟机平台和 Hyper-Vdism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart dism.exe /online /enable-feature /featurename:Microsoft-Hyper-V-All /all /norestart如果你用的是旧版 Windows 10可能还需要单独启用“Windows 虚拟机监控程序平台”dism.exe /online /enable-feature /featurename:HypervisorPlatform /all /norestart执行完之后系统会提示是否重启直接重启。这里注意一个细节/norestart参数意味着它不会自动重启所以即使提示“操作成功完成”你也一定要手动重启电脑。不重启的话Docker Desktop 还是检测不到新启用的功能。如果你的系统里还没有 WSL2 内核建议顺便更新一下。可以运行wsl --update这个命令会把 WSL 内核升级到最新版本避免因为内核太旧导致 Docker Desktop 不认账。3.3 GUI 方式适合不想记命令的人如果你更习惯图形界面那就走“控制面板 - 程序 - 启用或关闭 Windows 功能”在弹出的窗口里找到并勾选这几项适用于 Linux 的 Windows 子系统虚拟机平台Windows 虚拟机监控程序平台Hyper-V如果系统版本支持把“Hyper-V”整个展开勾选然后点“确定”系统会自动安装对应组件最后按提示重启。但我要提醒一下图形界面方式偶尔会出现“已勾选但实际不生效”的诡异情况。我遇到过一次用户说功能明明勾上了系统信息里却还是显示没有虚拟化平台。后来一查发现是他之前用过某些第三方优化工具把系统组件仓库搞出了点问题图形界面只是写了注册表配置实际文件没装上。这种时候命令行方式反而更能看出问题。3.4 WSL2 相关细节不是装了 WSL1 就万事大吉Docker Desktop 用 WSL2 后端时它需要的是“WSL2”不是老旧的 WSL1。WSL1 和 WSL2 的虚拟化架构完全不同WSL2 才基于真正的轻量级虚拟机。如果你只装过 WSL1或者 WSL 默认版本还是 1Docker Desktop 启动时依然可能报“Virtualization support not detected”。检查 WSL 版本可以用wsl --status wsl --version如果里面的默认版本显示为 1可以手动设置为 2wsl --set-default-version 2另外也要确认当前系统的“虚拟机监控程序启动策略”没有被人为禁用。以管理员身份打开 CMD执行bcdedit /enum看输出里的hypervisorlaunchtype。正常状态应该是Auto。如果显示为Off说明 Windows 的虚拟机监控程序不会随系统启动这样 Docker Desktop 自然检测不到虚拟化支持。修复命令bcdedit /set hypervisorlaunchtype auto再重启系统。这个细节很多人会漏掉尤其是 Windows 更新之后或者用过优化工具的机器上特别容易中招。4. 第三道关卡Hyper-V / 沙盒 / 第三方虚拟机冲突4.1 冲突来源分析如果 BIOS 和 Windows 功能都没问题systeminfo里各项也正常Docker Desktop 还是报错那大概率是系统里存在虚拟化冲突。最常见的冲突来源有几个第一个是 Windows 沙盒。Windows 沙盒本身就是一个轻量虚拟机它会跟 Hyper-V 抢占资源。在某些系统版本上同时开启 Windows 沙盒和 Hyper-V 会导致 Docker Desktop 检测虚拟化状态时出现异常。解决办法是暂时关闭 Windows 沙盒功能看 Docker Desktop 是否恢复。当然如果你的机器配置够好理论上是能共存的但保险起见先关掉试试。第二个是旧版第三方虚拟机软件。VirtualBox 5.x 以及更早版本默认不兼容 Hyper-V。如果你电脑上装了旧版 VirtualBox它可能会禁用了 Hyper-V 相关的 Windows 功能或者干脆在驱动层做了手脚导致 Docker Desktop 启动检测失败。这时候要么升级 VirtualBox 到 6.0 以上版本要么临时卸载或关闭 VirtualBox 的 Hyper-V 兼容选项。第三个是 Credential Guard 或 Device Guard这两个 Windows 安全功能也依赖虚拟化。在某些企业安全策略下它们会把虚拟化资源占住导致 Docker Desktop 无法正常初始化。遇到这种情况只能通过组策略或卸载特定安全软件来调整比较复杂。个人用户遇到较少但如果你是企业电脑建议先找 IT 确认相关策略。4.2 如何快速判断是不是冲突一个比较直观的经验是如果你在“启用或关闭 Windows 功能”里看到 Hyper-V 和 Windows 沙盒同时开着而 Docker Desktop 又报错可以先关掉 Windows 沙盒重启后再试 Docker Desktop。如果恢复正常那就是沙盒冲突。另一个判断技巧是看 Windows 事件查看器。在 Windows 日志 - 系统里搜索关键字 “Hyper-V” 或 “vmcompute” 或 “vmnat”看有没有相关的错误事件。Docker Desktop 启动失败时系统日志往往会留下踪迹。不过说实话在个人电脑上最常见的冲突来源还是“有用过优化工具”或“装过精简系统”。这类系统常常把 Hyper-V 或虚拟机监控程序的相关组件给精简掉了导致功能看起来是启用的但实际上没有一个完整的虚拟化栈。这时候单纯勾选功能不一定好使最省事的办法就是修复系统镜像或重装完整版系统。4.3 家庭版系统没有 Hyper-V 怎么办很多人在 Windows 10/11 家庭版上折腾 Docker Desktop打开“启用或关闭 Windows 功能”发现根本没有 Hyper-V 这个选项心里就慌了以为没法装 Docker。实际上家庭版完全可以跑 Docker Desktop因为它走的是 WSL2 后端底层只需要“虚拟机平台”和“Windows 虚拟机监控程序平台”以及“适用于 Linux 的 Windows 子系统”这三项。家庭版虽然没有 Hyper-V 管理器但这几个底层功能是可以通过命令启用的。如果你在家庭版的“Windows 功能”里看不到这些选项同样可以用命令解决dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart然后再更新 WSL2 内核并重启。这套组合拳在家庭版上依然有效。5. 实操案例从报错到启动成功的完整记录5.1 案例背景与初始状态有位朋友的电脑是 Windows 11 家庭版新装完 Docker Desktop点开图标不到两秒就弹出 “Virtualization support not detected” 的报错。他在网上找了一堆教程好几个人都告诉他要在 BIOS 里开虚拟化他去 BIOS 看了半天发现 CPU 虚拟化明明是 Enabled但 Docker Desktop 依然不领情。后来他又试着重装 Docker Desktop前后折腾了一个多小时问题依旧。我接手后先让他打开任务管理器确认 CPU 的虚拟化状态显示“已启用”。接着让他用管理员身份打开 CMD跑了一句systeminfo结果“Hyper-V 要求”下面的“用于虚拟化的固件”是“是”“二级地址转换”也是“是”数据执行保护也是“是”唯独“已检测到虚拟机监控程序”显示的是“否”。这个问题就很明显了硬件虚拟化没问题但 Windows 的虚拟机监控程序没有运行。继续查发现他的hypervisorlaunchtype是 Off。他回忆了一下之前为了跑某款旧软件按照网上的教程关闭过基于虚拟化的安全性当时顺手执行过bcdedit /set hypervisorlaunchtype off之后就一直没改回来。5.2 解决过程修复操作很简单管理员 CMD 里执行bcdedit /set hypervisorlaunchtype auto重启完再打开 Docker Desktop这次直接进入了初始化流程没有再弹报错。之后他按 Docker Desktop 的提示登录 Docker 账号更新了一下 WSL 内核容器就能正常拉取了。这个案例想说明的是很多“Virtualization support not detected”的报错并不是单纯一个开关没开而是多个环节里某个不起眼的启动参数被改了。尤其是用过系统优化工具、装过精简版系统、或者曾经手动调整过 Hyper-V 相关设置的人特别容易出现hypervisorlaunchtype被改成 Off 的情况。5.3 案例二嵌套虚拟化的坑另一个案例是一个做开发的朋友他在 VMWare Workstation 里装了一个 Windows 10 虚拟机然后在虚拟机里装 Docker Desktop。结果同样报“Virtualization support not detected”。这次的原因不在 Windows 功能上而在 VMWare 的设置里。VMware 默认情况下不会把 CPU 的硬件虚拟化指令透传给虚拟机需要手动在 VMware 的虚拟机设置里打开“虚拟化 Intel VT-x/EPT 或 AMD-V/RVI”这个选项也就是常说的“嵌套虚拟化”。关掉虚拟机修改设置后重新开机Docker Desktop 就能正常启动了。如果你是在虚拟机里跑 Docker Desktop先确认宿主机和虚拟化软件都支持并开启了嵌套虚拟化否则在虚拟机里怎么折腾 Windows 功能都是白搭。6. 常见问题与排查技巧实录6.1 常见问题速查表问题现象可能原因处理方式任务管理器里“虚拟化”显示“已禁用”BIOS/UEFI 未开启 VT-x 或 SVM进 BIOS 找到对应开关设为 Enabledsysteminfo 显示“用于虚拟化的固件”为“否”同上或者老 CPU 不带 SLAT确认 CPU 型号是否支持 SLAT进 BIOS 开启虚拟化开启虚拟化功能后 Docker Desktop 仍旧报错hypervisorlaunchtype 为 Offbcdedit /set hypervisorlaunchtype auto后重启家庭版系统没有 Hyper-V 选项Windows 版本限制用 DISM 命令启用虚拟机平台和 WSL 功能同时装了 VirtualBox 老版本旧版 VirtualBox 与 Hyper-V 冲突升级 VirtualBox 到 6.0或关闭其 Hyper-V 兼容选项装完 Docker Desktop 重启后报错还出现WSL 版本为 1 或 WSL 内核太旧wsl --set-default-version 2然后wsl --update在虚拟机里运行 Docker Desktop未开启嵌套虚拟化在虚拟化软件的虚拟机设置里打开 VT-x/EPT 透传最近 Windows 更新后才开始报错更新后 hypervisorlaunchtype 被重置重新执行bcdedit /set hypervisorlaunchtype auto杀毒软件或安全软件拦截虚拟化驱动安全软件冲突临时退出安全软件测试 Docker Desktop 是否能启动6.2 独家排查技巧从日志里找线索如果上面的步骤都走了一遍还是不解决问题别急着重装系统。Docker Desktop 会在日志目录里留下启动日志路径一般在%LOCALAPPDATA%\Docker\log\host\ %LOCALAPPDATA%\Docker\log\vm\里面有大量启动过程的详细记录包括每一步系统检测的结果。报“Virtualization support not detected”时日志里往往会有关键行提示比如 “hypervisor is not running” 或 “virtualization support is disabled”这些线索能帮你更精准地定位问题。不过对普通用户来说直接看日志确实有点门槛。我的建议是优先把上面提到的排查链路完整走一遍因为绝大多数情况都是 BIOS、Windows 功能、hypervisorlaunchtype、WSL 版本这几个点。如果都排查完还不行再考虑看日志或者直接卸载重装 Docker Desktop。6.3 我总结的一套固定排查路径平时帮人远程排查这个问题我基本严格按以下路径走能省下大量时间先看任务管理器 CPU 的“虚拟化”是否启用没启用就先去 BIOS不用往下走。管理员 CMD 里跑systeminfo确认“虚拟化固件”和“虚拟机监控程序”状态。管理员 CMD 里跑bcdedit /enum确认hypervisorlaunchtype是否为 Auto。PowerShell 里检查 WSL 状态wsl --status、wsl --version确认是 WSL2 且内核较新。到“启用或关闭 Windows 功能”里确认“虚拟机平台”和“Windows 虚拟机监控程序平台”是否勾选。执行完任何修改后务必重启。不要省略这一步很多问题都是“改了但没重启”引起的。这套路径基本能覆盖 95% 以上的“Virtualization support not detected”报错。剩下 5% 的疑难杂症大多是精简系统或安全软件搞的鬼这类问题往往是系统本身被改动过单纯围绕 Docker Desktop 查已经没意义需要先修系统环境。就我目前的实际操作经验来说bcdedit /set hypervisorlaunchtype auto这一步被很多人忽略却是见效最快的一个修复操作。它不涉及硬件也不需要重新安装任何软件改完重启基本上就让 Docker Desktop 起死回生。如果你已经按照其他教程折腾了半天建议优先检查这一项。