企业官网建设流程全解析

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

一、先把"启动了"和"能访问"分成两件事

1.1 三个很常见的场景

场景一：命令回了车，终端看着一切正常，回头打开浏览器，页面打不开。

场景二：刚才那条命令明明跑完了，回头去看容器的列表，却找不到它。

场景三：容器就在列表里，地址也是照着说明抄的，可浏览器还是连不上。

三个场景问的是同一件事，只是答案被拆在了不同地方：从"命令回车"到"浏览器能打开"，中间隔着四段，每一段都有自己独立的失败方式。

1.2 四段链路

本文把这一段路拆成四段：镜像、容器、端口、地址。四段是串联关系——前一段不成立，后面几段无从谈起；反过来，后一段出问题，前面几段看着又都是好好的。

顺序不能跳：初学者最常犯的错，是拿着一个地址在浏览器里反复重试，却始终没确认过前面三段。

Vulhub 官方对自己的定位交代得很直接（逐字引文见附表 A 第 1 行）：

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

"一条命令即可快速启动"说的是启动；启动之后浏览器能不能打开，取决于后面三段。把"启动成功"当成"可以访问"，是这一整类卡点的总开关。

1.3 官方自己列出的前提

先摆出 Vulhub 官方 README 里那份注意事项。它不是排错步骤，而是官方声明的前置条件（逐字引文见附表 A 第 5 行）：

第 ⑤ 条正是本文合规口径的官方背书：环境只在自建、隔离、非生产的前提下使用。

1.4 本文的范围

本文只做一件事：把四段拆开，说清每一段该看什么。不给任何利用步骤、载荷与绕过手法；不给任何具体报错文本——官方文档里没有的，本文不替它补。四段里出现的命令只做"看"的动作，且全部标注待验证。

⚠️代码待验证

# 四段链路的骨架（只读理解用，不执行任何写操作）# 第一段 镜像 ：本机有没有这次要用的镜像# 第二段 容器 ：容器"起来过"还是"还在跑"# 第三段 端口 ：宿主端口与容器端口对不对得上# 第四段 地址 ：写的是主机地址，还是容器内部地址

本章可以带走的一句："启动成功"只覆盖四段里的前两段；浏览器打不开，问题可能落在四段中的任何一段。

二、第一段：镜像那一层——先确认它到底在不在本机

2.1 容器不是凭空出现的

容器是镜像在运行时的实例。所以第二段能不能成立，先取决于第一段：这次要用的镜像，本机有没有。

这里有个特别容易踩的错觉：很多人以为"仓库 clone 下来了、敲了启动命令"，就等于镜像已经就位。仓库里放的是配置与说明；镜像要么本机早有，要么在启动时从远端取——这是两件不同的事。

Vulhub 官方 README 有一句话把边界划得很清楚（逐字引文见附表 A 第 7 行）：

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

也就是说，每个环境的镜像、端口、用法都写在那个环境自己的目录里，而不是写在总 README 里——这就是"具体数字要看环境自己的文件"的由来。

⚠️代码待验证

# 只读动作一：看本机已有的镜像清单，判断"要不要去远端取"dockerimages# 只读动作二：看当前机器的平台架构，与官方支持的架构对一对uname-m# 官方针对平台架构不匹配给出的回退写法（逐字，仅在需要时使用）exportDOCKER_DEFAULT_PLATFORM=linux/amd64

三条都只看不改，不拉取、不删除任何镜像。

2.2 平台架构：第一段里的一个检查点

第一段除了"镜像有没有"，还有一个必须一起看的项：平台架构。官方注意事项写明「部分环境可能不支持 ARM 架构」（逐字引文见附表 A 第 5 行），这意味着同一个环境目录，在不同平台架构的机器上能不能起来并不一致；官方常见问题里针对这种情况给过一条回退写法（逐字引文见附表 A 第 6 行）。它在四段里只是第一段的一个检查点，不是一条独立的排查路径。

本文不展开平台差异，只提醒一句：换了机器、换了平台架构，第一段就要重新看一遍，不能沿用上一台的结论。

2.3 官方常见问题里的三条，都落在第一段

Vulhub 官方 README 的常见问题一共三条，都与"镜像取不取得到、起不起得来"有关（逐字引文见附表 A 第 6 行）：

第 ① 条必须把话说完整：官方只说了"可能无法访问"并给了两条方向；中国大陆的实际可达性、各镜像能否拉取，本文未实测，因此不给任何"某某镜像一定拉得到"的说法。

第一段还有一条纪律：Vulhub 官方 README 未给出统一端口，也未给出统一的前置版本要求——官方只说安装最新 Docker，没有给任何版本号（逐字引文见附表 A 第 8 行，该行按 2026-09-16 核验）。看到"某某靶场要求某个端口"这类说法时，要回到那个环境自己的目录里去看。

本章可以带走的一句：第一段只问两件事——镜像本机有没有、平台架构对不对得上；两个都没问题，才轮到第二段。

三、第二段：容器那一层——"起来过"和"还在跑"不是一回事

3.1 命令回车之后，先别急着开浏览器

第一段成立之后，才轮到第二段：容器有没有真的在跑。

这里要区分两种状态：“起来过”和“还在跑”。命令回车、终端上出现后续输出——这些都只说明它"起来过"。它是不是仍然开着，要去容器列表里看。先确认容器在列表里、再看状态那一列、最后才去开浏览器，这个顺序不能倒过来。

3.2 官方给的启动与清理命令

Vulhub 官方 README 的"快速开始"给了一串逐字命令，本文照抄，一个字不改（逐字引文见附表 A 第 3、4 行）：

⚠️代码待验证

curl-shttps://get.docker.com/|shsystemctl startdockergitclone--depth1https://github.com/vulhub/vulhubcdvulhub/langflow/CVE-2025-3248dockercompose up-d# 官方同时给出的清理命令（原文照抄，本文不展开它删了什么）dockercompose down-v

这一串命令里有三个细节值得单独拎出来。

第一，cd那一行进的是vulhub/langflow/CVE-2025-3248——官方给出的示例目录，说明 Vulhub 的目录是按"软件名 / CVE 编号"组织的：练的是"某个真实漏洞怎么复现"，而不是"某一类漏洞的第几关"。这与 DVWA、upload-labs 那种"按漏洞类型分关卡"的单一 Web 应用不是一回事，第四章讲端口时还会用到。

第二，up -d里的-d是让它在后台跑。真正决定"容器是不是还在跑"的，是回车之后去看列表，而不是这一行命令本身。

第三，清理命令带了一个-v。本文只把它作为官方命令原文列出，不展开清理流程。

3.3 第二段只看两件事

第二段不复杂，只问两个问题：我要的这个容器，在不在列表里？在的话，它的状态那一列说明它还在跑吗？

如果它不在列表里，说明它根本没起来、或者起来之后又退出了——这时该回头查第一段（镜像有没有、平台架构对不对），而不是去折腾地址。如果它在，第二段就过了，注意力交给第三段。

Vulhub 官方还有一句提醒在同一份 README 里：「请确保 Docker 有权限访问当前目录下所有文件」（逐字引文见附表 A 第 5 行）。这条影响的是容器能不能被正常拉起来，是第二段之前必须过的一道前提。

⚠️代码待验证

# 只读动作：看容器列表，确认目标容器在不在、状态那一列怎么写的dockerps# 只读动作：把已经退出的容器也一并列出来，判断是"没起来"还是"起来后退了"dockerps-a

两条都只看不改，不启动、不停止、不删除任何容器。

本章可以带走的一句：第二段只判断"在不在、还开不开"；容器不在列表里时，该回头查第一段，而不是去改地址。

四、第三段：端口那一层——4280、80、8765 三个数字都从哪来

4.1 宿主端口与容器端口，是两个东西

第三段是四段里最容易混的一段，因为任何一个映射写法里都同时存在两个端口：容器端口是容器内部那个服务自己在监听的端口；宿主端口是你从这台机器外面访问时要写的那个端口。两者不必相同——拿容器端口去拼浏览器地址，是这一段最常见的错。

4.2 三个官方数字的来源

下表是本文的核心对照，三个数字全部来自各自项目的官方 README，一个字的改动都没有（逐字引文见附表 A 第 11、14、15、16 行）：

这张表里有四处必须逐个说清楚。

第一处：DVWA 的 4280。这是本文最想纠正的数字。DVWA 官方 README 原话是（逐字引文见附表 A 第 11 行）：

for running DVWA in containers, the web server is listening on port 4280 instead of the usual port of 80

逐字读：在容器里跑 DVWA 时，Web 服务器监听的是 4280，而不是通常的 80。照着"80"去访问 DVWA 容器，是打不开的。

第二处：upload-labs 的 80。官方容器端口就是 80。这就是本文要反复强调的对照：DVWA 官方容器是 4280，upload-labs 是 80，两个数字不能互相套用。

第三处：Pikachu 的两个宿主端口。官方 README 给了两条并列路线：一条直接用官方镜像、映射到宿主 8765，另一条本地构建后映射到宿主 8080；两条宿主端口不相等，容器端口都是 80。任选一条，不要把两条的宿主端口混用。

第四处：Vulhub 没有统一端口。Vulhub 是"漏洞环境集合"，官方 README 未给统一端口，端口由每个环境自己的 compose 文件决定（逐字引文见附表 A 第 8 行）。所以"Vulhub 默认端口是多少"这个问法本身不成立，要看的是你进的那个环境目录。

三个项目各自的官方命令并排列在下面，照抄其中一组即可：

⚠️代码待验证

# DVWA（官方 README「Docker」）：clone → 进入 DVWA 目录 →dockercompose up-d# 访问写法（官方）：http://localhost:4280# upload-labs（官方 README「2.3 Linux快速搭建」）：cdupload-labs/dockerdockerbuild-tupload-labs.dockerpull c0ny1/upload-labsdockerrun-d-p80:80 upload-labs:latest# 官方容器端口：80# Pikachu（官方 README「Docker」，以下两条路线二选一）：dockerrun-d-p8765:808023/pikachu-expect:latest# 或者：dockerbuild-t"pikachu".dockerrun-d-p8080:80 pikachu# 两条路线的容器端口均为 80，宿主端口分别是 8765 与 8080

4.3 顺带交代一条时效事实

提到 Pikachu，就绕不开它当前的维护状态：官方 README 自标status-asleep，作者在 README 中建议改用其新项目 MadRabbit（逐字引文见附表 A 第 16 行）。写清这个状态，是因为它直接影响"要不要用它来练"这个判断；本文不做推荐，只把官方标注原样交代。

本章可以带走的一句：第三段永远在比两个端口——容器里监听的那个、你浏览器里要写的那个；4280 是 DVWA 的，80 是 upload-labs 的，8765 与 8080 是 Pikachu 两条路线各自给的，四者不能互相套用。

五、第四段：地址那一层——your-ip指的不是容器内部 IP

5.1 官方逐字解释了your-ip

前三段都过了之后，才轮到第四段：地址写对没有。这一段官方有一句非常关键的话（逐字引文见附表 A 第 5 行）：

文档中的your-ip指你的主机/VPS IP，不是 Docker 容器内部 IP

逐字读：凡出现your-ip这个占位符，指的是你运行 Docker 的那台主机（或 VPS）的地址，而不是容器的内部地址。这就解释了第四段最常见的那类困惑：为什么"容器里的地址"看着更"真实"，浏览器却打不开——容器内部地址只有容器网络内部才认识，宿主上的浏览器并不按那条路走。

5.2 命令行看到的，与浏览器要写的，不是同一个

把第四段收成一句判断：容器内部看到的地址，和你在浏览器里要写的地址，是两套不同视角下的东西。容器内看到的是"我在这个网络里是谁"，浏览器里要写的是"从那台跑着 Docker 的主机外面，怎么找到映射出来的那个端口"。两者对不上是正常的，对上才是巧合。

⚠️代码待验证

# 只读动作：看本机的地址有哪些，人工判断该用哪一个# 注意：容器内部的地址不在这个清单里，它属于容器自己的网络hostname-I

这条只看不改，也不据此改动任何网络配置。

5.3 第三段与第四段最容易互相冒充

四段里，第三段和第四段最容易互相冒充：现象都是"浏览器打不开"，但根因一个在端口、一个在地址。一个简单的分开办法：

• 地址里的端口号与官方给的对不上——那是第三段的问题；
• 端口号是对的，但这个地址是从容器内部看到的——那是第四段的问题。

本文不给任何"连不上怎么办"的排查命令清单，也不给修改配置的做法——四段链路到此只做定位，不做修复。

完整版环境对照表：这一章的"该用主机地址还是容器内部地址"判断法，加上第四章的三靶场官方端口对照、第一章的四段链路表，一起收进资料包，扫码即可获取：

本章可以带走的一句：your-ip指的是主机（或 VPS）的地址，不是容器的内部地址；地址这一层的错，长得和端口那一段一模一样。

六、命令写法这一层：docker compose与docker-compose差在哪

6.1 官方逐字：“不再需要安装独立的 docker-compose”

把四段讲完之后，还有一层横跨四段的东西要先说清楚：命令本身怎么写。Vulhub 官方 README 有一段非常明确的表述（逐字引文见附表 A 第 2 行）：

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

这段话有两层意思：Vulhub 环境依然基于 compose 制作，机制没变；但启动它用的是Docker 自带的 compose 命令，不需要再单独装一个docker-compose。这不是版本号问题，是"命令从哪来"的问题。

6.2 两种写法并排看

⚠️代码待验证

# 官方现行写法：空格（Docker 自带的 compose 子命令）dockercompose up-d# 站内老教程里常见的写法：连字符（独立的 compose 二进制）# 官方 README 已明确：不再需要安装独立的 docker-composedocker-composeup-d

DVWA 官方 README 给的用法同样是空格写法：clone → 进入DVWA目录 →docker compose up -d（逐字引文见附表 A 第 10 行）。两个项目在这一点上是一致的。

6.3 这一层为什么会搅乱四段排查

命令写法看着只是"少一个连字符"，却会实实在在影响排查：如果命令根本没被识别，第二段压根没开始，你却可能以为自己在查第三段；而老教程的连字符写法与官方现行写法混着抄，会让"下一步该看哪一段"失去参照。

还有一条相关口径放在这里（逐字引文见附表 A 第 12 行）：

We provide support for the latest Docker release as shown above.

逐字读：DVWA 官方只支持其 README 中列出的最新 Docker 版本（核验日 2026-09-16）——官方支持范围有限，这点只影响最前面的运行环境本身。

本章可以带走的一句：官方现行写法是空格的docker compose，独立安装的docker-compose官方已说明不再需要；这一层影响的是第二段能不能开始，而不是第三、四段怎么判断。

七、收束：四段链路排查清单

7.1 把四段压成一句

"起来了"和"能访问"之间隔着四段：镜像在不在、容器还开不开、端口对不对、地址是不是主机的。

这个形状是官方文档自己摆出来的：官方说"每个环境目录下都包含详细的 README"，说明镜像与端口要看环境自己；官方给的是一条后台启动命令，说明起来之后还要去看列表；官方给 DVWA 的是 4280、upload-labs 是 80、Pikachu 是 8765 或 8080，三个数字各不相同；官方还专门写了一行your-ip是主机/VPS IP，不是容器内部 IP。

7.2 常见卡点对照

7.3 四段排查清单

⚠️代码待验证

# 【四段排查清单 · 只看不改】# 第一段 镜像# 1. 本机已有镜像里，有这次要用的那个吗？# 2. 当前平台架构，被这个环境支持吗？# 第二段 容器# 3. 容器在列表里吗？状态那一列说明它还在跑吗？# 4. 若不在，先回到第一段，不要跳到第四段去改地址# 第三段 端口# 5. 这个项目官方给的端口是多少？# DVWA 4280 / upload-labs 80 / Pikachu 80（宿主 8765 或 8080）# 6. 我地址里写的端口，和官方给的对得上吗？# 第四段 地址# 7. 地址写的是主机（或 VPS）的吗？# 8. 端口对、地址不对 -> 第四段；地址对、端口不对 -> 第三段

7.4 这份清单不覆盖什么

第一，不覆盖中国大陆的实际可达性——官方只说 Docker Hub 在中国大陆可能有访问问题；本文未实测，不给任何"能不能拉到"的结论。

第二，不覆盖各环境的具体端口清单——Vulhub 官方未给统一端口，端口由每个环境自己的 compose 文件决定；本文未逐个打开核验。

第三，不覆盖任何版本号门槛——Vulhub 官方只说安装最新 Docker，未给任何版本号（该条按 2026-09-16 核验）。

第四，不覆盖修复动作——四段链路只负责定位，本文不给改配置、给权限、调网络的做法。

第五，本层不碰任何量级数字，也不给任何具体报错文本、载荷与利用步骤。

完整版环境对照表：这份"四段排查清单"，加上第一章的四段链路表、第四章的三靶场官方端口对照表、第六章的命令写法对照表，一并收进资料包，扫码即可获取：

本章可以带走的一句：卡住的时候，按"镜像 → 容器 → 端口 → 地址"四段走一遍，比在浏览器里反复重试快得多。

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

附表 B：术语速查表

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

写这篇时我把 Vulhub 官方 README 的快速开始、NOTE 块和常见问题逐字读了一遍，又回头对 DVWA、upload-labs、Pikachu 三份 README 里的端口写法，才确认"4280 和 80 不是一回事"值得单独写一篇——顺手整理了几份配套的东西：

• 容器靶场四段排查清单：镜像 / 容器 / 端口 / 地址 四段各看什么、常见现象该落在哪一段
• 靶场环境对照表：DVWA、upload-labs 在 Windows / macOS / Linux 三平台的可行性与推荐路径
• Web 安全学习路线图：从基础打牢到安全管理，四个阶段各学什么
• 常用靶场清单：每个靶场练什么、适合哪个阶段

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

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

拿到之后建议先看容器靶场四段排查清单那一份，先把"启动了"和"能访问"分开，再回头查卡住的那一段。