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

一、先给结论：跑不起来，先确认三件事

1.1 一个很常见的场景

在 M 系列芯片的 Mac 上，把 Vulhub 这样的漏洞靶场环境取到本地，敲下启动命令，终端回了几行输出，然后就没有下文了：有的环境一直起不来，有的起来之后又自己退出了，还有的看起来在跑，浏览器里却什么都没有。

这时候最容易脱口而出的一句判断是——“架构不兼容”。这句话有一半可能是对的，但它没有告诉你下一步该做什么，也没有告诉你什么情况下它是错的。

先交代两件与下文有关的事。第一，本文拿 Vulhub 当例子，它是官方所说的"开源的、即开即用的漏洞靶场环境集合"，不是一个单一靶场，而是一批各自独立的环境（逐字引文见附表 A 第 6 行）。第二，Vulhub 是一个持续在维护的开源项目：截至 2026-10-02，其官方仓库最近一次推送时间为 2026-09-16，处于非归档状态；它归在一个组织账号下，创建于 2017-04-09（见附表 A 第 8 行）。这两点合起来意味着：官方说法是"活"的，读的时候要带上日期，不能拿旧印象当结论。

1.2 三件事，按顺序确认

本文把这个问题拆成三件事，顺序不能颠倒：

第一件回答"两边说的还是不是同一种语言"，第二件回答"官方有没有对这个平台表过态"，第三件回答"这一次的失败该归到哪一类"。三件事都过一遍，再决定要不要动官方给的那条临时写法。

1.3 本文只做什么

本文只做三件事的确认，不给任何攻击步骤、利用载荷与绕过手法，也不给任何具体报错文本——官方文档里没有的，本文不替它补。所有命令只做"看"的动作，不拉取、不删除、不修改任何东西，并且全部标注待验证（写这篇文章的本机没有可用的容器环境，未实际运行）。

⚠️代码待验证

# 三件事的骨架（只读理解用，不执行任何写操作）# 第一件：本机架构 与 镜像目标平台 是不是同一套# 第二件：这个环境的官方 有没有谈过 ARM# 第三件：这次失败 是架构，还是内存等其他原因

本章可以带走的一句："架构不兼容"是一个结论，不是一个排查动作；先按顺序确认三件事，再下这个结论。

二、先弄明白：为什么会有两套指令集

2.1 程序最终要变成机器能直接执行的指令

一段用高级语言写出来的程序，机器并不能直接读。它要先被翻译成一条条最底层的机器指令，CPU 才认识。而"翻译成什么样子"，是由一套约定决定的，这套约定就是指令集。

关键的一点在于：指令集并不只有一套。为某一套指令集翻译好的程序，换到另一套指令集上，CPU 读不懂。这不是"版本高低"的问题，也不是"新旧"的问题——是本来就不是同一种语言。

2.2 arm64 与 amd64 是两套不同的"母语"

日常接触到的机器，很可能说的不是同一种"母语"：

M 系列 Mac 属于 arm64 这一边，而互联网上大量现成的容器镜像、以及很多年前写的教程，是按 amd64 准备的。两边对不上，就是所谓"架构不兼容"的由来。

还要多说一句：同一个软件，可能同时发布两个架构的版本，也可能只发其中一个。“有这个软件"和"有这个软件在你机器上能跑的那一版”，是两件事。

2.3 连第三方工具也会把两种 Mac 分开写

这种区分不只出现在容器里。以第三方 Homebrew tapshivammathur/php为例，它的官方仓库写明自己运行于 Linux x86_64/arm64 与macOS arm64，而macOS Intel 不支持（⚠️ 这是第三方 tap、非 PHP 官方；本文只引用它的支持范围，不展开任何安装步骤）。

一句带过就够了：**同样是"macOS"，在不同芯片下会被当成两个不同的目标平台。**这也正是第一件事要"逐台机器、逐个镜像"去确认的原因——判断依据得从两边各自的信息里去取，不能拿一个笼统的印象去套。

⚠️代码待验证

# 只读动作一：看本机是哪一套架构uname-m# 只读动作二：看容器工具自己报告的架构信息里，"架构"那一项写的是什么dockerversion

两条都只看不改，不安装、不删除任何软件。

本章可以带走的一句：arm64 与 amd64 是两套不同的指令集，不是同一个东西的两个版本；两边对不上，程序就是"读不懂"。

三、第一件事：确认芯片架构与镜像的目标平台

3.1 先把本机这一头看清楚

第一件事有两头，先看自己这一头：本机是什么架构。在 M 系列 Mac 上，答案通常是 arm64。这一步的意义不在于得到一个新鲜的答案，而在于不让它停留在"我记得好像是"上——换了一台机器、换了一台服务器，这一头就要重新看一遍。

3.2 再看镜像那一头声明的是什么

另一头是镜像。**镜像不是一坨没有属性的文件，它有自己的目标平台。**一个镜像面向的是 arm64 还是 amd64，是它被构建时就带上的信息。

这里有个特别容易踩的错觉：**“我把仓库 clone 下来了、把环境目录打开了”，并不等于"我要用的那个镜像已经就位"。**目录里放的是配置与说明，镜像要么本机早就有，要么在启动时从远端取——这是两件不同的事（Vulhub 官方也写明"每个环境目录下都包含详细的 README"，见附表 A 第 7 行）。

3.3 两边对不上时，该怎么描述

两边对不上，现象是"起不来"或者"起来之后又退出"——本文不给任何具体报错文本，因为官方文档里没有这类文本，照抄别人的报错去对号入座，等于把别人的机器当成自己的机器。

第一件事的正确收尾是这一句：**本机是 arm64，这个镜像声明的目标平台是另一套，所以两者之间需要一层额外的处理，才能在这台机器上跑。**至于这层处理是否存在、由谁提供，就交给第二件事。

⚠️代码待验证

# 只读动作：看本机已有的镜像，以及其中某一个镜像声明的平台信息dockerimages# 把上一步里出现的镜像名填进去，只做查看，不拉取dockerimage inspect<镜像名>

这两条都只看不改；<镜像名>是需要你自己替换的占位符。

本章可以带走的一句：第一件事就是拿"本机的架构"和"镜像声明的目标平台"对一下，两头不一致，才轮到第二件事。

四、第二件事：确认这个环境官方说不说支持 ARM

4.1 官方确实说过"部分环境可能不支持 ARM"

先摆出 Vulhub 官方 README 里那句最常被引用的话（逐字引文见附表 A 第 2 行）：

部分环境可能不支持 ARM 架构

这句话信息量很大：①官方承认ARM 这一类平台在这套环境里存在"跑不起来"的可能；②注意官方用词是"部分环境"，而不是全部；③这句话写在官方注意事项里，是官方主动交代的边界，不是谁的推测。

4.2 官方也说过 M 系列大部分环境可以直接跑

同一份 README 的常见问题里，官方还写了另一句（逐字引文见附表 A 第 3 行）：

Apple Silicon（M 系列）大部分环境可直接运行，失败时可用export DOCKER_DEFAULT_PLATFORM=linux/amd64

这里要注意两个细节。第一，官方说的是"大部分环境可直接运行"——也就是说，M 系列 Mac 并不是"一律跑不起来"；第二，官方紧接着给出了"失败时"的做法，说明官方把失败当成个别情况来处理，而不是整类环境都被判了死刑。

4.3 两句话要并列读，不能只挑一句

这两句话放在一起看，才是官方的完整口径：

**只挑第一句，会把"部分"读成"全部"；只挑第二句，会把"大部分"读成"全部"。**两句合起来才是官方口径：大多数能直接跑，少数失败时官方给了一条临时写法。至于某个具体环境在 arm64 上到底跑不跑得起来，官方没有逐个列举，本文也未实测。

4.4 别的项目，官方口径各不相同

第二件事的关键在于：**“官方说不说支持 ARM”，是逐个项目去看的，没有通用答案。**这一点在同类的 Web 靶场项目上体现得很清楚——它们连"钉在哪个基础镜像上"都不一样：

DVWA 官方 Dockerfile 的基础镜像是FROM docker.io/library/php:8-apache（即 PHP 8，见附表 A 第 10 行）；upload-labs 官方容器的基础镜像则是php:5.5-apache（即 PHP 5.5，见附表 A 第 11 行），而 PHP 5.5 早在2016-07-21就已经结束支持（PHP 官方 EOL 页，末版 5.5.38，见附表 A 第 12 行）。

这里不展开版本对照，只说一句与本文有关的话：这两个项目各自钉在不同的基础镜像上，正说明"支持不支持 ARM"没有一个可以套用的通用答案。某台 Mac 上某个环境到底能不能跑，得回到那个项目自己的官方文档里去看原话，而不是拿另一个项目的结论来推。所以第二件事要读官方原话，不能凭"这个项目应该支持吧"来猜。

4.5 顺带交代一条常被忽略的事实

Vulhub 官方还有一句常被忽略的话（逐字引文见附表 A 第 4 行）：

你不再需要安装独立的 docker-compose，而是使用Docker 自带的 compose 命令来启动 Vulhub 环境。

这句话与"支持不支持 ARM"没有直接关系，但它常常和架构问题搅在一起：**命令本身没被识别，和容器起不来，是两种完全不同的失败。**如果连启动命令都没跑对，就不要急着把结论下成"架构不兼容"。站内老教程里常见的连字符写法docker-compose，截至 2026-10-02，官方已明确不再需要。

本章可以带走的一句：同一个平台，有的项目官方明确表过态、有的没表态；读官方原话，别读想象。

五、第三件事：确认失败到底是架构，还是别的

5.1 官方列的前提里，第一条是内存

三件事里最容易被跳过的是第三件：这次失败，凭什么算到架构头上？

先把官方列的前提摆出来。Vulhub 官方注意事项的第一条是（逐字引文见附表 A 第 1 行）：

推荐使用至少1GB 内存的 VPS 或虚拟机

注意这里的关键词是"推荐"和"至少"。它是一条资源前提，和架构没有关系。本地机器内存紧张、同时开着别的东西、或者分配出去的空间不够，都可能让一个环境起不来——这类失败看起来和架构问题一样，都是"起不来"。

5.2 同样是"起不来"，原因可能完全不同

把常见的几种情况并排放一放：

这张表想说的是：**“起不来"是一个现象，不是一个原因。**把现象直接翻译成"架构不兼容”，跳过的恰恰是最该确认的第三件事。

5.3 怎么把"架构"和"别的"分开

一个朴素的顺序是：先确认第一件事（两边架构对不对得上），再确认第三件事（资源等前提够不够），最后才看官方给的那条临时写法。

理由很简单：**官方给的那条临时写法，是为了解决"两边架构对不上"这一类失败的。**如果这次失败根本是内存不够，那么用它也只是换一种方式失败。先归类，再动手。

⚠️代码待验证

# 只读动作：看本机给容器环境分配了多少内存、当前还剩多少# 这一步的目的只是排除"资源不足"这一类原因，不修改任何设置dockerinfo

这条只看不改，也不据此调整任何分配。

完整版环境对照表：这一章的"同样是起不来、原因可能完全不同"对照表，加上第二章的 arm64 / amd64 架构说明、第四章的各项目官方口径，一并收进资料包，扫码即可获取：

本章可以带走的一句：先把失败归类，再动手；内存等前提没过关时，架构那一条临时写法帮不上忙。

六、官方给的临时处理动作，以及它的边界

6.1 官方那条写法长什么样

三件事确认完，如果结论确实落在"架构"这一头，官方给的临时写法是这一条（逐字引文见附表 A 第 3 行）：

⚠️代码待验证

# 官方针对 Apple Silicon（M 系列）失败时给出的写法（逐字）# 仅在确认失败属于"架构对不上"时使用exportDOCKER_DEFAULT_PLATFORM=linux/amd64

逐字读这条命令：它把默认的目标平台设置成了linux/amd64。也就是说，在它生效之后，取镜像与运行容器时，会按 amd64 这个目标平台来做，而不是按本机原生的 arm64。

6.2 它做了什么，为什么不是"变通了"

这里要解释清楚一层：本机还是 arm64，机器并没有变成 amd64。这条写法的作用是让流程改按另一套目标平台去准备，两边之间因此需要一层额外的转换工作。

这也解释了它的两个使用特征：

本文不展开它的实现细节，也不给"加了之后一定成功"的说法——官方只说"失败时可以这样写"，并没有说这样写之后每个环境都能跑起来。

6.3 它的边界在哪

把这条写法的边界说清楚，比把它当成万能钥匙更重要：

第一，**它只针对"架构对不上"这一类失败。**内存不够、命令写法不对、环境目录里那一步没做对，这些都不在它的覆盖范围内（第五章已经说过这一层）。

第二，**它不改变"部分环境可能不支持 ARM"这个官方前提。**官方写下这句注意事项时，这条临时写法也已经存在了——两者是同一位作者在同一份文档里给出的，这一点本身就说明：临时写法并不等于"所有环境都被支持了"。

第三，**它是否有效，要看具体是哪个环境。**官方没有逐个环境列举结果，本文也未实测，因此不给任何"某某环境加上就一定跑得起来"的结论。

6.4 两条容易被混进来的东西

顺带把两条容易和"架构"混为一谈的东西分开。

一是镜像拉不下来。那是"取不到"，不是"取到了但平台不对"，两者是不同的一段；这类问题另见本号相关篇目，本文一句带过。

二是容器内监听的端口。这一点和架构没有关系，但常被一起提起：DVWA 官方容器内的 Web 服务器监听的是4280，不是通常的 80（官方原文 “instead of the usual port of 80”）；upload-labs 官方容器内则是80（见附表 A 第 13、14 行）。本文只作为事实引用，冒号左右的含义不在这里展开。

⚠️代码待验证

# 官方现行写法：空格的 docker compose（Docker 自带的子命令）dockercompose up-d# 若确认失败属于"架构对不上"，再按官方常见问题加上平台变量exportDOCKER_DEFAULT_PLATFORM=linux/amd64# 官方给出的清理命令（原文照抄，本文不展开它删了什么）dockercompose down-v

本章可以带走的一句：这条临时写法解决的是"两边架构对不上"，它不改变官方"部分环境可能不支持 ARM"的前提，也不是加了就一定能跑起来。

七、把三件事串成一条确认顺序

7.1 压成一句话

在 M 系列 Mac 上跑靶场环境，先确认三件事：两边架构对不对得上、官方有没有表态支持 ARM、这次失败到底是架构还是别的——三件都过一遍，再看官方那条临时写法。

这个顺序是官方文档自己摆出来的：官方注意事项里既写了"部分环境可能不支持 ARM"，也写了"推荐至少 1GB 内存"，一条讲平台、一条讲资源，说明这两类本来就是分开的；官方常见问题里又单独给了一条针对 M 系列的失败处理，说明"大部分能跑"和"少数要处理"是并存的两件事。

7.2 常见现象对照

7.3 三件事确认清单

⚠️代码待验证

# 【三件事确认清单 · 只看不改】# 第一件 架构# 1. 本机是什么架构？ uname -m# 2. 要用的镜像声明的目标平台是什么？# 3. 两头对得上吗？对不上 -> 记下来，进第二件# 第二件 官方口径# 4. 这个项目的官方文档怎么谈 ARM？逐字读一遍# 5. 有没有把"部分环境"读成了"全部"？# 第三件 失败归类# 6. 这次失败是"起不来"还是"起来了又退"？# 7. 资源等前提过了吗？（官方注意事项第一条讲内存）# 8. 确认属于架构 -> 再看官方那条临时写法

7.4 本文不覆盖什么

第一，不覆盖某个具体环境在 arm64 上的实际运行结果——官方只说"大部分可直接运行"，本文未实测，不给任何逐环境结论。

第二，不覆盖镜像的实际取用情况——镜像能否取到、取到的架构变体是哪一个，属环境实测，本文未实测；这类问题另见本号相关篇目。

第三，不覆盖任何修复动作——本文只做三件事的确认与归类，不给改配置、给权限、调资源的具体做法。

第四，不给任何具体报错文本、量级数字、利用步骤与绕过手法；也不给"这样设置就一定能跑起来"的说法。

完整版环境对照表：这份"三件事确认清单"，加上第三章的架构对照、第五章的失败归类表、第六章官方临时写法的边界，一并收进资料包，扫码即可获取：

本章可以带走的一句：先在纸上把三件事走一遍，比在终端里反复重试快得多；确认属于架构，再动那条临时写法。

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

附表 B：术语速查表

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

写这篇时我把 Vulhub 官方 README 的 NOTE 块、常见问题与前置条件逐字读了一遍，又回头看了两个 Web 靶场各自的基础镜像，才确认"部分环境可能不支持 ARM"和"M 系列大部分可直接运行"这两句话必须并列着读——顺手整理了几份配套的东西：

• M 系列 Mac 跑靶场三件事确认清单：架构怎么看、官方口径怎么读、失败怎么归类
• 靶场环境对照表：DVWA、upload-labs 在 Windows / macOS / Linux 三平台的可行性与推荐路径
• Web 安全学习路线图：从基础打牢到安全管理，四个阶段各学什么
• 常用靶场清单：每个靶场练什么、适合哪个阶段

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

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

拿到之后建议先看三件事确认清单那一份，先把"架构不兼容"从结论变回一个需要确认的问题，再回头查卡住的那一头。