Vulhub 不是靶场，是漏洞环境集合：初学者该怎么用

授权与合规声明
本文全部操作对象均为自建隔离靶场（本机容器或隔离虚拟机），涉及安全测试的环节必须以取得合法授权为前提。未经授权的渗透测试违反《中华人民共和国网络安全法》与《刑法》相关条款，须承担相应法律责任。本文只讲环境配置、版本对照与靶场隔离，不含任何攻击步骤、利用载荷与绕过手法，请勿将文中环境指向任何非自有系统。

一、先把定位纠正过来：它是"集合"，不是"靶场"

第一次听说 Vulhub 的人，多半会先把它当成"又一个靶场"：clone 下来，找一个登录页或者关卡列表，然后发现——没有。没有统一的入口页面，没有按关卡排列的目录，也没有"通关"这回事。于是很容易得出一个错误结论：我是不是 clone 错了？是不是我的环境有问题？

问题不在你，也不在你的机器，而在"靶场"这个词带来的预期。Vulhub 在自己的 README 里这样描述自己：

「Vulhub 是一个开源的、即开即用的漏洞靶场环境集合。无需 Docker 基础，只需一条命令即可快速启动用于安全研究、学习或演示的漏洞环境。」

英文版用的词是 collection（集合）。把这两个字看清楚，后面所有的使用方式才成立。

1.1 "集合"说的是组织方式

DVWA、upload-labs 这类靶场，是一个应用：一个网站程序，里面装了很多种漏洞，按漏洞类型分成一个个模块或关卡，你登录进去，一关一关练。它们是"一个应用内部的多个练习点"。

Vulhub 不是这样。它是一个目录库：里面的每一个目录，对应一个互相独立的环境，每个环境自己带一套 Docker 配置，自己起、自己停、自己清理。官方 README 的快速开始示例里，cd 进去的是一个"软件名 / 漏洞编号"的两级目录——环境是按软件和漏洞编号摆放的，而不是按"第一关、第二关"排列的。

这就解释了为什么它没有"进度"这个概念：你不是在一条线上往上爬，而是在一个库里挑一个环境、把它起起来、观察它、然后关掉它。没有通关，只有取用。

1.2 每个环境目录自带 README

官方 README 里还有一句很关键的话：

「每个环境目录下都包含详细的 README，请参阅以了解复现步骤和使用说明。」

意思是：某一个环境具体怎么用，答案在那个目录自己的 README 里，不在总 README 里。这直接决定了你的使用姿势——你不需要背一份"总攻略"，而要养成"进目录先读 README"的习惯。

这里先把边界说清楚：本文只讲怎么把环境起起来、起不来时该往哪个方向排查、以及怎么从一堆环境里挑出一个来练，不涉及任何一个环境启动之后的操作，也不给任何具体环境的使用步骤。

1.3 它是一个仍在更新的活跃项目

对初学者来说，"这个项目还活着吗"是个很现实的问题：一个停更的项目，意味着你踩到的坑大概率没人修，也意味着教程与现状会越来越对不上。

Vulhub 的情况比较好。按它 GitHub 仓库的元数据：仓库由组织账号 vulhub 维护，创建于 2017-04-09，最近一次 push 是 2026-09-16，仓库处于未归档状态。许可为 MIT License，可以自行取用。

至于内容规模，官方站点提供了一个动态统计接口，本文写作时读到的是：截至 2026-09-18，官方统计为 332 个漏洞环境。

这里必须强调一句：332 是会变的。它是官方接口实时返回的值，不是写死在文档里的常量。所以本文给它标了日期，你以后看到任何不带日期的"Vulhub 有 XXX 个环境"，都应该留个心眼——包括本文这个数字，也请以官方接口当时的返回为准。

二、和 DVWA / upload-labs 差在哪：两种不同的练法

搞清楚"集合 vs 单一应用"之后，还有一个问题值得展开：这两类东西，练到的能力其实不一样。很多人把它们放进同一个"靶场清单"里横向比，比着比着就糊涂了——因为它们本来就不是同一类东西。

2.1 一张定位对照表

2.2 练的是两种能力

把这张表翻译成"我在练什么"，差别会更清楚：

• DVWA / upload-labs 练的是"某一类漏洞的原理与手法"。它把同一个类型的漏洞做成多个难度递进的练习点，让你先理解这一类问题的成因，再体会不同防护强度下的差别。
• Vulhub 练的是"某个具体漏洞环境的搭建与观察"。它是把某个软件在某个漏洞上对应的环境打包好，让你能把它起起来、自己去看这个环境长什么样。

一个是"横向把一类漏洞吃透"，一个是"纵向把某个具体环境跑起来"。两者不替代，是接力关系：先用单一应用把一类漏洞的原理摸清，再走到环境集合里去看真实的软件与版本形态。

2.3 一个最常见的错位

正因为形态不同，最常见的错误就是拿 Vulhub 去找"关卡列表"。找不到是正常的，因为它压根没打算提供这个东西。

判断自己有没有用错，只要问一句：我现在是想练"某一类漏洞"，还是想看"某一个具体环境"？ 前者去找单一应用靶场，后者才轮到 Vulhub。这个判断，比记住任何命令都重要。

三、前置只有 Docker：官方说不再需要独立安装 docker-compose

Vulhub 官方对前置条件的描述相当克制：它只要求 Docker。但它顺带纠正了一个站内老教程里传得很广的写法，这个点值得单独拿出来讲。

3.1 官方原话：不再需要独立的 docker-compose

官方 README 的原文是：

「虽然所有 Vulhub 环境都基于 Docker compose 制作，但你不再需要安装独立的 docker-compose，而是使用 Docker 自带的 compose 命令来启动 Vulhub 环境。」

这句话有两个信息点：

老教程里普遍写的 docker-compose（带连字符）指的是早期需要单独安装的那个独立二进制。而官方现在的写法是 docker compose（中间是空格）——它是 Docker 的一个子命令，随 Docker 一起装好，不用另外折腾。

3.2 一字之差：docker compose 与 docker-compose

这两个写法长得很像，但来源不同：

⚠️ 代码待验证

docker –version # 先确认 Docker 本体装好了
docker compose version # 官方现行写法：Docker 自带的 compose 子命令（空格）
docker-compose version # 老教程的写法：早期独立安装的二进制（连字符）

按官方口径，你只需要确认第一种可用。第二种如果本机没有，不影响你用 Vulhub——这正是官方那句"不再需要安装独立的 docker-compose"的意思。

所以，如果你照着两三年前的教程敲 docker-compose 命令发现命令不存在，大概率不是你的环境坏了，而是那篇教程的写法过时了。换成空格写法即可。

3.3 官方给的安装与启动流程

官方 README 的「快速开始」给出的流程如下（命令保持官方原样，其中"进入某个环境目录"这一步官方给的是一个具体示例目录，这里用占位符表示）：

⚠️ 代码待验证

curl -s https://get.docker.com/ | sh # 官方给的 Docker 安装方式
systemctl start docker # 启动 Docker

git clone –depth 1 https://github.com/vulhub/vulhub
cd vulhub/<你要练的那个环境目录> # 进入一个环境目录（官方示例给的是具体目录）
docker compose up -d # 启动这个环境
docker compose down -v # 用完清理

最后两条命令要成对记：up -d 起环境，down -v 收环境。因为一个"集合"里环境很多，用完不清理，本机就会一层层堆容器和镜像——这是初学者最容易忽略的一点。

3.4 最小前置自查

官方在 README 的注意事项里列了几条，都是"起环境之前"该确认的：

这四条里，初学者最容易踩的是第一条和第三条：内存太小会导致起不来的现象，而把项目放在 Docker 没有权限访问的目录下，也会让启动过程中断。

四、起不来时的三类归因（按官方说法）

环境起不来，是初学者用 Vulhub 时最集中的挫败来源。好消息是：官方 FAQ 已经把最常见的几类原因写出来了。这一章把它们整理成"分类归因"，目的是让你先判断自己属于哪一类，而不是漫无目的地重装。

原因只有一个判断原则："起不来"不是一个问题，而是好几类不同的问题。

4.1 第一类：镜像拉不下来

官方 FAQ 的第一条就是它：

「Docker Hub 在中国大陆可能无法访问，可以使用镜像站加速，或使用境外 VPS」

也就是说，官方明确承认了镜像可达性这个变量，并且给了两个方向：镜像加速，或者换一台境外 VPS。

这里必须说清一件事：官方只描述了这个问题和这两个方向，没有给"一定能拉下来"的保证，也没有指定任何具体的镜像站。网络上流传的各种加速地址会变、会失效，本文不做推荐。你只需要知道：如果失败发生在"拉取镜像"这个阶段，那它属于网络可达性问题，不用怀疑自己的命令行写错了。

4.2 第二类：CPU 架构不匹配

Apple Silicon（M 系列芯片）的 Mac 用的是 ARM 架构。官方 FAQ 的说法是：大部分环境可以直接运行，失败时可以设置平台变量再试：

⚠️ 代码待验证

export DOCKER_DEFAULT_PLATFORM=linux/amd64

这条与第 3 章表格里那句"部分环境可能不支持 ARM 架构"是同一件事的两种表述：官方既在注意事项里提示了架构风险，也在 FAQ 里给了应对方式。

判断方法很简单：如果失败发生在"启动"阶段、且你的机器是 ARM 平台，先按这一类排查。

4.3 第三类：本机资源限制（Kali 用户尤其要看）

官方 FAQ 还专门提到一条：在 Kali Linux 下，部分环境会因为 ulimit nofile 过低而失败。

ulimit nofile 指的是"系统允许单个进程打开的文件数量上限"。这个值偏低时，某些环境在启动阶段就会失败。可以先看一眼自己机器上的当前值：

⚠️ 代码待验证

ulimit -n # 查看当前的文件描述符上限

这类问题的特征是：它与你的命令写法无关，也与网络无关，而是本机资源限制。很多人的 Kali 是直接装好的默认配置，更容易撞上这一条。

4.4 归因对照表（含前置项）

这张表的用法是：先定位失败发生在哪一步，再对上归类。归类对了，方向就明确了；归类不对，重装多少次都还是在原地打转。

五、从 332 个环境里怎么挑练习对象

定位讲清了、前置备齐了、失败会归因了，最后就剩下一个实际问题：332 个环境，我该起哪一个？

这一章不给"推荐清单"——因为清单会过期，判断方法不会。

5.1 别按目录顺序刷

最容易走错的一条路，是把 Vulhub 当成"关卡列表"从第一个目录开始往下刷。原因有两个：

• 它是集合，不是课程。目录之间没有难易递进关系，先起哪个都行；
• 它的目录是按软件名与编号摆放的，顺序本身不携带学习意义。

正确的起点是反过来的：从"你正在学的那一类漏洞"出发，去库里反查对应的环境。

5.2 三个筛选动作

具体可以这样操作：

落到第 2 步，进了项目根目录之后，你看到的东西长这样：

⚠️ 代码待验证

cd vulhub # 进入项目根目录
ls # 这里列出的是一个个环境目录，不是一个网站程序的目录

这三个动作里，第 3 步最容易被跳过，也最不该跳过。因为它正是"集合型项目"与"分关卡应用"在使用方式上的分水岭：前者要靠读文档自己定位，后者靠界面引导。

5.3 挑完之后，先别急着"往里走"

这一节要说的是一句提醒，而不是一个步骤。

因为 Vulhub 的环境大多是"某个软件在某个漏洞上的形态"，所以它天然会让人产生"赶紧看看里面能做什么"的冲动。但对初学者来说，这一步不该由本文、也不该由任何一篇教程来带你走。本文能提供的是：让你知道该起哪一个、起不来时属于哪一类原因。至于起起来之后要做什么，属于你自己在合法授权范围内、按官方文档学习的事。

一个简单原则：挑环境的判据是"我正在学什么"，不是"哪个看起来有意思"。 前者让你补上知识，后者容易让你停在"能跑起来"的兴奋感里。

Vulhub 前置自查清单：把本文第 3 章的前置四条、第 4 章的三类归因、第 5 章的挑选判据合成一页，起环境前逐条打勾。放在资料包里，扫码即可获取：

六、三条硬边界

前面五章都在讲"怎么用"，这一章讲"用它的边界在哪"。这三条不是本文自己加的，第一条就是官方原文。

6.1 官方逐字：严禁用于生产环境

官方 README 的注意事项里，最后一条用的是感叹号：

「所有环境仅供测试与学习，严禁用于生产环境！」

这条值得被单独抄一遍，因为它的意思很直接：这些环境本身就是故意做成有问题的，它们的价值只存在于"你自己的隔离环境里"，出了这个范围没有任何正面用途。对初学者来说，把这句话当成一条硬规矩记住就够了。

6.2 它是一个学习环境，不是一个"练手的真实目标"

第二层边界不太需要官方提醒，但更重要：它不能成为你对着非自有系统动手的跳板。

把 Vulhub 起在自己机器上、在自己的隔离环境里观察，是本文讲的用法；把同样的环境信息搬去对着别人的系统试，是另一回事。这条线不在环境里，在你自己身上——起一个环境是动作，对谁起、拿它做什么，才是决定行为性质的部分。本文全篇只覆盖前一半。

6.3 本文没有覆盖什么（以及官方也没说的）

为了不让读者拿本文当"万能说明书"，这里把没写和官方没说的部分一并列清：

上面几条里，中间三条尤其要留意："Vulhub 需要 XX 版本 / 用 XX 端口"这类说法，在官方层面就是不成立的。你如果看到某篇文章给了这类统一数字，那多半是作者自己推的。

七、带走物：把这篇压缩成一页

一篇讲定位的文章，最好的结尾是把结论压到能直接用的程度。

7.1 一页自查清单

下次准备用 Vulhub 时，按顺序问自己四句话：

四句话全部能答上来，这篇就没白读。

7.2 它与本地靶场的关系

最后用一张最简的关系图收束全文：

它们不是"选一个"，而是先后接力。单一应用帮你建立一类漏洞的判断力，环境集合让你把这个判断力用到一个具体的、真实软件形态的环境上。

而无论走到哪一步，第 3 章的前置、第 4 章的归因、第 6 章的边界，都还是要一起带上。

靶场环境对照表：把本文第 2 章的"集合 vs 单一应用"展开成一张完整的对照表，含 DVWA、upload-labs 与 Vulhub 三者的形态、组织方式、前置要求与适用阶段。放在资料包里，扫码即可获取：

附表 A：本文引用事实与官方出处对照表

说明：第 10 行对应的是本文与站内老教程的一处写法差异——站内老教程普遍写连字符 docker-compose（早期独立二进制），官方现行口径为空格写法 docker compose（Docker 自带子命令）。本文按官方口径写，并把差异本身作为纠错点保留。
第 3 行的 332 为官方动态统计值，已于 2026-09-18 复检（复检前值为 330，当日返回 332）。该值会随接口变化，请以官方接口当时的返回为准。

附表 B：术语速查表

写在最后：这篇用到的资料

写这篇文章时，我把 Vulhub 官方 README（中英文两版）与它的官方统计接口对着读了一遍，发现站内老教程里"把它当靶场"和"用连字符命令"这两处写法，和官方现行口径都已经对不上了，于是顺手也整理了几份配套的东西：

• Vulhub 前置自查清单：把本文的前置四条、三类归因、挑选判据压成一页，起环境前逐条打勾
• 靶场环境对照表：集合型环境与单一应用靶场的形态、组织方式、前置要求、适用阶段对照
• Web 安全学习路线图：从基础打牢到安全管理，四个阶段各学什么

资料是我自己整理的，放在下面这个码上，扫码即可获取：

添加时备注「靶场」，优先通过。

拿到之后建议先看前置自查清单那一份，对照着把 Docker 与 compose 命令这一层确认好，再进第 5 章挑你要练的那个环境。