Vulhub 漏洞环境起不来？10 分钟定位原因，把容器拉起来

Vulhub 漏洞环境起不来？10 分钟定位原因，把容器拉起来

【免费下载链接】vulhubPre-Built Vulnerable Environments Based on Docker-Compose项目地址: https://gitcode.com/GitHub_Trending/vu/vulhub

启动 Vulhub 漏洞环境时，你敲进struts2/s2-045，跑完docker compose up -d，等回来的却是一行红色的context deadline exceeded；或者容器在docker compose ps里明明亮着，三秒后状态变成Exit 1；又或者环境起来了，浏览器打开 8080，页面却是白的。这三种现象覆盖了 Vulhub 启动故障的大头，难就难在大多数人的第一反应是反复down再up，结果一次比一次绝望。

这篇文章不讲原理，只讲怎么查。读完之后，你遇到任何一个报错，都能按"现象 → 定位 → 处置 → 验证"的路径自己对号入座，独立处理掉绝大部分启动类故障，不用再怀疑是自己操作错了。

📋 开工前的 4 道硬门槛

动手之前先把这 4 项过完，任何一项不过，后面的步骤都会白跑：

本地还没有仓库的话，先把它拉下来：

git clone --depth 1 https://gitcode.com/GitHub_Trending/vu/vulhub # 浅克隆，省时间 cd vulhub ls struts2/s2-045/docker-compose.yml # 确认目录结构完整，能列出文件即通过

镜像拉不下来，卡死在 context deadline exceeded

现象：进环境目录后的第一条命令，卡了几分钟后报错退出：

Error: request ID xxx: pull access denied for vulhub/struts2, repository does not exist or may require 'docker login': context deadline exceeded

定位：绝大多数情况不是镜像不存在，而是这台机器到 Docker Hub 的链路被墙或被限速，拉取一直等响应直到超时。先排除手滑写错镜像名的可能：

grep image struts2/s2-045/docker-compose.yml # 确认镜像名是 vulhub/struts2:2.3.30

处置：给 Docker 配上镜像源，再重启服务。编辑/etc/docker/daemon.json（不存在就新建）：

sudo tee /etc/docker/daemon.json <<-'EOF' { "registry-mirrors": ["https://docker.mirrors.ustc.edu.cn"] } EOF sudo systemctl restart docker # 让新配置生效，预期无输出

然后回到环境目录重新拉：

cd struts2/s2-045 docker compose pull # 这次应该能看到 layer 逐层下载

验证：

docker images | grep struts2 # 列表里出现 vulhub/struts2:2.3.30 即拉取成功 docker compose up -d # 启动不再卡在拉取阶段

🔧 端口被占住：Bind for 0.0.0.0:8080 failed

现象：镜像拉下来了，容器也创建了，但冒出一条红色报错：

Error response from daemon: driver failed programming external connectivity on endpoint ... : Bind for 0.0.0.0:8080 failed: port is already allocated

定位：字面意思就是 8080 被别的进程占着。Vulhub 里 8080、3306 这类常用端口很密集，本机如果开着 Tomcat 或 MySQL，撞上很正常。先找到是谁在占：

ss -lntp | grep 8080 # 会打印出占用进程名和 PID

处置：占用的进程可以停就停掉；不方便动的话，改宿主侧映射端口。在本地副本的 docker-compose.yml 里把映射改成：

ports: - "8081:8080" # 只改冒号左边（宿主机端口），容器内的 8080 保持不变

验证：

docker compose up -d curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:8081/ # 返回 200/302 即映射生效

容器秒退：状态 Exit 1

现象：docker compose up -d没有任何报错，可几秒后再看：

docker compose ps # NAME STATUS # struts2 Exit 1

容器没了。这时候十有八九是容器内部自己退了，看日志是最快的路径：

docker compose logs --tail 50 # 只看最后 50 行，足够定位原因

日志里两个高频报错，对应的根因都很典型：

1. exec format error，架构不匹配：M 系列芯片的 Mac 上最常见，镜像只有 amd64 构建，ARM 直接跑不动。README.zh-cn.md 给了标准解法：

export DOCKER_DEFAULT_PLATFORM=linux/amd64 docker compose up -d # 强制按 amd64 模拟运行，慢一点但能跑通

2. 启动即崩，提示Too many open files：Kali Linux 的ulimit nofile默认偏低，部分环境吃不消，需要先调高文件句柄上限再启动，项目"常见问题"一节有对应的修复说明。

⚠️ 改完ulimit后建议新开终端再跑up，旧终端里环境变量不生效。

验证：

docker compose ps # ✅ STATUS 稳定保持 Up 不退出 curl -I http://127.0.0.1:8080/ # 返回 HTTP/1.1 200 即服务就绪

环境起来了，但 PoC 打不通：镜像版本没对上

这是最磨人的一种：容器 Up、页面能访问，可照着 README 走复现步骤就是 403/404。根因通常一句话——容器里跑的镜像 tag 和该环境要求的漏洞版本不一致。

每个环境要求哪个镜像是锁死的，environments.toml 和目录内的 docker-compose.yml 都写得很清楚，比如 s2-045 对应vulhub/struts2:2.3.30，Ghostcat（CVE-2020-1938）对应vulhub/tomcat:9.0.30。先查你实际跑的是什么：

docker compose config | grep image # 看 compose 解析出来的 tag docker ps --format '{{.Names}} {{.Image}}' # 看实际运行中的镜像

对不上就彻底清掉再拉，让 compose 按配置拉回正确版本：

docker compose down -v # 连数据卷一起清，避免旧数据干扰新环境 docker compose pull && docker compose up -d

起来之后先做最简单的连通性验证，再按 README 逐步打 PoC。以 Cacti 环境为例，请求发出后响应里能看到敏感字段，说明环境已可用：

Tomcat Ghostcat 环境也可以借助检测页确认服务确实带漏洞，看到 "Ghostcat exists" 即环境就绪：

故障对照卡

主线没展开的边角问题，直接查表：

收尾：三个长效习惯

• 测完就清场。每复现完一个环境立刻docker compose down -v，否则端口和磁盘会越堆越满，下一次"端口被占"就是自己造成的。
• 先看日志再改配置。九成问题的原因日志里直接写明了，反复重启容器只会让故障拖得更久。
• 别动镜像 tag。镜像版本是 README 里锁死的，手痒换了 tag，"PoC 打不通"这种玄学问题就出现了。

如果你手上正卡着某个环境，先对着上面对号入座跑一遍，再把卡住的报错原文留言发出来——原文越具体，定位越快。

免责声明：本文所有漏洞环境仅供合法授权环境下的安全学习与研究使用，严禁将文中命令与 PoC 用于任何未授权系统。

【免费下载链接】vulhubPre-Built Vulnerable Environments Based on Docker-Compose项目地址: https://gitcode.com/GitHub_Trending/vu/vulhub