直接把 Vulhub 拉下来跑，靶场比想象中省事。搭建这玩意儿就是靶场个漏洞靶场集合，每个漏洞一个目录，搭建配好 docker-compose 文件，靶场你只需要敲一条命令就能把整个环境拉起来。搭建我第一次用的靶场时候，从 git clone 到浏览器里弹出那个熟悉的搭建 Tomcat 页面，前后不到三分钟。靶场

环境准备没什么特别的搭建。装好 Docker 和 Docker Compose，靶场这是搭建硬性前提。Ubuntu 22.04 上直接 apt 装就行，靶场Windows 和 macOS 用 Docker Desktop 也完全没问题。搭建内存建议给到 4GB 以上，靶场有些靶场比如 Struts2 系列跑起来挺吃资源，2GB 的虚拟机偶尔会卡在容器启动那一步。

拉取仓库这一步，网络状况决定体验。GitHub 直连慢的话，用 gitee 的镜像源也行，但更新可能滞后几天。我一般习惯直接 clone 官方仓库：

git clone https://github.com/vulhub/vulhub.git cd vulhub

目录结构很直白。比如想复现 Log4j2 那个核弹级漏洞，就进 log4j/CVE-2021-44228 目录。里面通常有一个 docker-compose.yml，偶尔附带 README.md 说明利用步骤。别急着 docker-compose up -d，先扫一眼 README，有些靶场需要额外编译或者调整端口映射。

启动命令就一条：

docker-compose up -d

等镜像拉完，容器跑起来，用 docker ps 看一眼端口映射。比如 8080 映射到宿主机的 8080，浏览器直接访问 http://127.0.0.1:8080 就能看到漏洞应用。我遇到过端口冲突的情况，本机 Nginx 占了 80，靶场起不来。改 docker-compose.yml 里的端口映射就行，左边宿主机端口随便换，右边容器端口别动。

用完记得关。不是 docker-compose down 就完事，有些容器会留下 volume 和网络。我习惯加 --volumes 参数：

docker-compose down --volumes

有次偷懒没加，结果磁盘里堆了十几个 G 的残留数据，清理起来挺烦。

实际用的时候有个坑：Vulhub 的靶场默认监听 0.0.0.0，如果你在云服务器上跑，安全组没限制，等于把漏洞环境直接暴露公网。我见过有人拿这个挖矿，容器里跑满 CPU。本地虚拟机玩最稳妥，或者 iptables 限制来源 IP。

另一个细节是镜像版本。Vulhub 仓库更新不算频繁，但有些老漏洞的镜像 tag 可能被 Docker Hub 删了。拉取失败的话，去 GitHub issues 里搜一下，通常有人贴了替代方案。我就碰到过 struts2 某个版本的镜像 404，最后手动改了 Dockerfile 里的基础镜像地址才跑起来。

对于想批量测试的人，Vulhub 提供了 docker-compose 的并行启动能力。写个脚本遍历目录，每个靶场单独起一个 compose 项目名，端口错开，能同时跑十几个环境。但别贪多，内存撑不住，而且漏洞之间可能互相干扰——比如两个靶场都往 /tmp 写文件，权限冲突了排查起来很费劲。

最后说个个人习惯：每复现完一个漏洞，我会在 README 旁边建个 notes.md，记下请求包、payload 和回显特征。Vulhub 本身不带 writeup，但它的价值就在于让你亲手把 exp 打进去，看服务端到底返回什么。光看文章不动手，过两天就忘干净了。