企业官网建设流程全解析

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

一、先分清："页面出不来"其实是三类不同的现象

刚把 PHP 靶场跑起来，浏览器里出现的不是页面，而是一整段代码文本——这个现象在新手环境里出现的频率很高。但它只是"页面出不来"里的第一类。三类的排查方向完全不同，混在一起查会绕远路。

C 类要专门说明一句：这类现象里有一部分其实是靶场本身的设计意图，不是环境问题，所以本文不碰它。

本文的落点只有一个：A 类。因为 A 类最容易被误判——很多人一看到代码文本，第一反应是"PHP 版本不对"，于是去换版本，换了半天还是老样子。

先把这一层的问法定死。浏览器拿到什么，由服务器决定；服务器要不要把这段文件当成 PHP 来处理，取决于三件事：

1. 服务器上有没有真的装上 PHP，并且这个 PHP 有没有被启用；
2. 中间件有没有被告知：这个后缀的文件要交给 PHP 处理；
3. 这段代码要用到的扩展，装了没有。

这三件事的顺序不能颠倒：没有第一条，第二、三条无从谈起；有了第一条但第二条没配，页面依然是源码；前两条都对、第三条不对，表现就从 A 类变成了 B 类。

这里还要说明一个容易走偏的地方：网上讲这个现象的教程，很多会直接给出一张版本对照表，让人照着挨个换。版本确实和这件事有关，但它不在上面这三件事里——三件事没查完就去调版本，等于跳过了更可能的原因。所以本文把它单独放到第五章去讲。

⚠️代码待验证

# 先确认自己看到的到底是哪一类：看服务端声明的类型 + 看返回内容本身curl-s-Ihttp://127.0.0.1:4280/|grep-i'^content-type'curl-shttp://127.0.0.1:4280/|head-n5

第一行的意义是看服务端自己说这个响应是什么类型；第二行的意义是直接看返回体到底是页面还是源码文本。两者都对不上"页面"，再往下走三件事。

本章可以带走的一句：看到源码文本，先别急着换版本——它落在"有没有被当成 PHP 处理"这一层，而这一层由三件事决定。

二、第一件事：PHP 有没有真的装上并启用

这一条听起来像废话，但它恰恰是有官方答复可引的一条。

DVWA 官方仓库里有一个 issue（编号#573），标题里带着 php8.1 字样。它的实际现象是"页面把 PHP 源码原样输出"。维护者digininja 本人的答复是逐字的：

You haven’t got php installed or enabled. Follow the README for instructions

提问者随后重装 PHP 后解决。也就是说，这个 issue 的真因是 PHP 没被安装或没被启用，不是版本不兼容。（出处与核验日见附表 A。）

这条答复的价值在于：它把"看到源码文本"的默认排查顺序摆了出来——先看 PHP 本身在不在、有没有启用，而不是先怀疑版本。

那具体怎么确认？分两种情况看。

情况一：打包环境（XAMPP 这类）。DVWA 官方推荐的运行方式之一，就是虚拟机加 NAT、在 guest 内装 XAMPP。这类集成环境的问题通常不是"没装"，而是"装了但服务没起"或者"模块没被加载"。

情况二：自己装的 PHP 加 Apache。这时要分开确认两件事：命令行里的 PHP 在不在，以及 Web 服务器有没有加载 PHP 模块。这两件事是分开的——命令行里有php，不等于 Apache 会用它。

⚠️代码待验证

# 1) 命令行层面：PHP 到底装没装、是哪个版本php-v# 2) Web 服务器层面：Apache 有没有加载 PHP 模块apachectl-M2>/dev/null|grep-iphp# 或者（Debian / Ubuntu 系）apache2ctl-M2>/dev/null|grep-iphp

第一条有输出、第二条查不到，就是典型的"装了但没启用"。这时候该做的是把模块启用起来并重启服务，而不是去降 PHP 版本。

还有一种情况值得单列：PHP 装了、模块也加载了，但 Web 端用的其实是另一个 PHP。一台机器上装了多个 PHP 版本时，命令行里的php与 Apache 实际加载的模块，可能来自不同的安装路径。这时候php -v显示的结果，和页面上真正在跑的那一个并不一致。判断方法是回到页面本身，看 Web 端实际输出的那一份，而不是只看命令行。

本章可以带走的一句：看到源码文本，第一条要问的是"PHP 在不在、有没有启用"；官方维护者对同类现象给出的第一句答复，正是这一条。

三、第二件事：中间件有没有把它当 PHP 处理

PHP 装上了、也启用了，页面还是源码，问题就落到中间件这一层：Apache 有没有被配置成"把.php交给 PHP 处理"。

upload-labs 官方 README 的"环境要求"表里，中间件那一行的原文是逐字的：

设置Apache以moudel方式连接

（原文中module拼作moudel，这里照抄，不做任何修正。）

"以 module 方式连接"说的是 Apache 加载 PHP 的方式。官方把这一行单独列进环境要求表，说明在官方看来它是环境要求的一部分，而不是可选项。

这一层还有第二种表现，我单独拎出来讲：后缀映射。upload-labs 官方容器的docker/docker-php.conf，提交说明写的是"添加php3 phtml解析"。这句话说明：官方在自己的容器里，专门为.php3、.phtml这两种后缀加了"交给 PHP 解析"的配置。

这里必须划一条线：本文只写这条配置事实本身，不写它对应哪一关，更不写任何用法。.php3/.phtml被映射为 PHP 解析，是官方容器里的一条配置记录；它为什么被加上、加上之后影响什么，超出本文范围。

这一层还有反向的一种情况：如果中间件配置里没有覆盖.php，那么无论 PHP 装得多完整，.php文件都会以源码形式返回。所以这一层的自查，是去看配置文件里的解析规则，而不是去猜版本。

这一层的漏配，在打包环境里尤其常见：集成环境通常自带一套已经写好的解析规则，一旦换了站点目录、换了站点配置，或者手动改过配置文件，规则就可能没跟过去。所以自查时看的不是"当初装的时候配没配"，而是当前生效的配置里到底有没有这条规则。

⚠️代码待验证

# 看 Apache 当前生效的解析相关配置（路径随发行版不同，按自己环境替换）apachectl-t-DDUMP_RUN_CFG2>/dev/nullgrep-ri'php'/etc/apache2/mods-enabled/2>/dev/null|head-n20grep-ri'php'/etc/httpd/conf.d/2>/dev/null|head-n20# 只读查看官方容器里那条配置本身（不启动任何东西）# 仓库路径：upload-labs/docker/docker-php.conf

最后一行值得单独说明：upload-labs 官方 Docker 的配置文件路径，以及那条"添加php3 phtml解析"的提交说明，都是在官方仓库里能直接看到的只读事实，可以放心核对。

本章可以带走的一句：PHP 装了不等于 Apache 会用；这一层看的是中间件里的解析规则，其中最容易被人忽略的是后缀映射这一项。

四、第三件事：要用的扩展装了没有

前两件事决定"页面能不能出来"，第三件事决定"出来之后能不能用"。这一层的表现不再是源码文本，而是前面说的 B 类：页面框架在，某个模块不对。

upload-labs 官方 README 里对扩展的原文，是一行表格：

PHP组件 |php_gd2, php_exif| 部分Pass依赖这两个组件

也就是官方明说了：部分关卡依赖这两个组件。对应到具体关卡，官方 README 给到的关系是：

这两行的写法要留神：官方 README 给的表述是"部分 Pass 依赖这两个组件"，而"哪一关依赖哪一个"是把 README 的组件行与关卡说明对应起来的结果。按关卡列出来没问题，但不要说成"官方逐关标注了扩展依赖"。

再看官方容器里实际装了什么：upload-labs 官方容器的 Dockerfile 里，另外装了gd、exif两个扩展。也就是说，官方容器不是"基础镜像里有什么就用什么"，而是专门补装了这两个。

这一层的自查方式很直接：列出当前 PHP 已加载的扩展，再对着上表核一遍。

⚠️代码待验证

# 列出当前 PHP 已加载的扩展，再按关键词过滤php-mphp-m|grep-i-E'gd|exif'

有一个很容易搞混的点：命令行里的php -m，与 Web 服务器实际使用的那套 PHP，可能不是同一套扩展。打包环境和自己装的 PHP 加 Apache，这两个清单可能是分开的。所以遇到"命令行里能看到 gd、页面上却还是不对"这种情况，要先确认 Web 端加载的究竟是哪一个 PHP。

另一点：扩展装上之后，通常需要重启 Web 服务才会生效；只把扩展放进去、不重启，页面上看到的还是老样子。这类"改了没重启"和"根本没装"在现象上很像，但排查方向完全不同——前者先看服务重启了没有，后者先看扩展在不在。

本章可以带走的一句：前两件事决定页面能不能出来，扩展这一条决定出来之后能不能用；官方 README 已经把依赖的组件写成明确的一行。

五、版本这一层：为什么最容易被误判

三件事都查完，如果还是不对，才会轮到版本。但这一层的网上说法最乱，得先把口径校准。

DVWA 官方 README 的「PHP Versions」部分，关于 PHP 版本一共是三句话，逐字如下：

Support will not be given for anyone trying to use PHP 5.x.

Versions less than 7.3 have known issues that will cause problems, most of the app will work, but random things may not… support will not be given.

Ideally you should be using the latest stable version of PHP

三句话的意思是：拒绝支持 PHP 5.x；低于 7.3 有已知问题且不给支持；建议使用最新稳定版。

为什么这一层最容易误判？因为它看起来最像问题所在——版本号是一个能一眼看到的数字，而"模块有没有启用""解析规则有没有配"是看不见的配置。看得见的东西先被怀疑，看不见的东西最后才被想起，这是这类现象里最常见的偏差。

⚠️ 这里有一条必须校准的表述：官方原文没有出现"≥7.3"或"minimum 7.3"。所以"DVWA 要求 PHP ≥7.3"这种写法属于口径失真——官方给的是"低于 7.3 有已知问题且不给支持"与"建议用最新稳定版"，不是一条硬性的最低版本线。

第二处误传更值得说。站内流传着"DVWA 不支持 PHP 8"，但按官方一手事实去核，是三条并存：

三条里最硬的是第二条：官方自己交付的容器，基础镜像就是 PHP 8。这比"README 没提到 8.x"更能说明问题。

社区里还流传过"官方标注 Tested on PHP 5.4–7.4""PHP 8 有三处硬性不兼容"这类说法，没有任何官方出处。可以写的表述是：社区实践反馈中存在 PHP 8 环境下的安装问题，但官方 README 未声明不支持，且官方自身以 PHP 8 构建并运行 DVWA。再往"硬性不兼容"上写，就超出依据了。

那版本这一层到底什么时候才真的相关？把几份官方口径并排看，会清楚很多：

最后一行补一句就够：upload-labs 手装推荐的 5.2.17，恰好是 PHP 5.2 分支的最后一个版本。这条只作事实引用，本文不展开。

5.1 想在本机拿到这些版本，渠道也要看清

如果你想在本机同时备好几个 PHP 版本，站内最常见的两个渠道，各有一条已核事实：

• phpStudy 现名"小皮面板"，官方站点为 xp.cn。它的 Windows 版官方产品页原文写的是「多版本切换运php5.2至php7.3任意切换」「PHP多版本共存 可为每个站点配置一个PHP版本」「多环境切换 Apache+Nginx+IIS」，官方推荐版本为phpStudy v8.1。这里有两处要并列写清：这段文案在子页/phpstudy、不在首页；同一页面的另一处又写作「5.1-7.3」，前后口径不一致。另外，官方只写到"php5.2"这一分支，未点名 5.2.17。（核验 2026-09-16）
• Homebrew tapshivammathur/php（第三方 tap，非 PHP 官方）支持PHP 5.6 – 8.6（NTS / ZTS / debug 均有），运行于 Linux x86_64 / arm64 与 macOS arm64，macOS Intel 不支持；不含 5.2.x。（核验 2026-09-16）

第二条的结论很直接：它最低只到 5.6，跑不了 upload-labs 手装推荐的 5.2.17——macOS / Linux 用户想对齐那个推荐版本，容器是更省事的路子。这里只讲渠道事实，不展开共存方案（那是另一个题目）。

⚠️代码待验证

# 确认自己实际在跑哪个 PHP 版本（命令行 + Web 响应头各看一遍）php-vcurl-s-Ihttp://127.0.0.1:4280/|grep-i'^server'# 若是容器方式，看容器实际使用的基础镜像dockerinspect--format'{{.Config.Image}}'<容器名>

完整版环境对照表：本章这几条"官方口径 vs 官方容器实际镜像"的并排对照，连同三平台上的可行路径，整理成了一张表，放在资料包里，扫码即可获取：

本章可以带走的一句：版本这一层要放到最后看；DVWA 的官方口径是三句话，不是"≥7.3"；"不支持 PHP 8"与官方 Dockerfile 直接冲突。

六、两个官方一手事实冲突时怎么读

第五章那张表里，有两条并排放在一起的事实值得单独拎出来——它们是同一个项目的两份一手材料，给出的答案却不一样。

两条都是一手、都是官方，但它们不是"谁错了"，而是两个不同场景下的事实：README 回答的是"你自己装的时候推荐用哪个"，Dockerfile 回答的是"官方交付容器时用的是哪个"。这两个答案本来就可以不一样。

正确的读法是并列写出来，而不是挑一个用。挑一个用会出现两种失真：

• 只写"官方推荐 5.2.17"，读者会以为官方容器也是 5.2.17；
• 只写"官方容器是 PHP 5.5"，读者会以为手装也该用 5.5。

同一份官方资产里，还有一处同类的"文档与实际不同步"，顺手一并给出：

（两条核验日均为 2026-09-16。）

这两张表合起来，其实是同一条阅读方法：读官方材料时，先分清手里这份是"文档"还是"交付物"，再决定它能代表什么。README 是写给人看的建议，Dockerfile 是机器实际执行的东西；两者不一致时不是二选一，而是各自在自己的场景里有效。

这种不同步还有一个共同成因：文档与交付物不是同一时间写的，也不会在同一时间更新。upload-labs 仓库的最后一次提交是2020-01-15，此后未再更新（核验 2026-09-16），README 正文里的关数就停在了被写下时的那个状态，而仓库里的目录结构是另一回事。知道这一点，就不会在两者之间反复怀疑自己看错了。

这套读法不只适用于 PHP 版本这一个问题。凡是官方同时给了"文档"和"交付物"的地方，都要先问一句：这两样是不是在回答同一个问题。若答案是否定的，把两条都写出来，比挑一条"看起来更权威"的更有用。

⚠️代码待验证

# 把"文档口径"与"交付物口径"分别取出来对照（全部为只读查看）gitclone--depth1https://github.com/c0ny1/upload-labsgrep-n-i'php'upload-labs/docker/Dockerfilelsupload-labs|grep-c'^Pass-'

最后一行只做一件事：数一遍仓库里实际有多少个Pass-目录，用它去和 README 正文里的数字对照。

本章可以带走的一句：官方文档与官方交付物不一致时，不择一，要并列——它们回答的是两个不同场景的问题。

七、收束：三步自查清单

回到最初那个现象：浏览器里显示的不是页面，而是一整段代码文本。到这一章，把它压成一份能对着用的清单。

7.1 三步，顺序不能颠倒

三步之外的第四步才是版本。而且走到版本这一步时，要先把口径校准好——DVWA 是三句话（拒绝 5.x / 低于 7.3 有已知问题且不给支持 / 建议最新稳定版），不是"≥7.3"。

三步里最容易漏的是第二步：第一步不通，页面根本打不开，问题很显眼；第三步不对，页面至少还能出来。只有第二步错了，才会出现"PHP 明明装了、页面却是源码"这种最像故障的现象，也最容易被误判成版本问题。

7.2 现象与步骤的对应关系

7.3 三条要记住的口径

• DVWA 官方拒绝支持 PHP 5.x，低于 7.3 有已知问题且不给支持，建议用最新稳定版；原文没有"≥7.3"这个写法。
• "DVWA 不支持 PHP 8"是误传：官方 README 无 8.x 表述，官方 Dockerfile 基础镜像就是php:8-apache。
• upload-labs 的 PHP 版本有两条并存的官方一手事实：手装推荐 5.2.17，官方容器用 PHP 5.5——两条都要写。
• 三件事的顺序是固定的：装上没有、当不当 PHP 处理、扩展装了没有；版本排在三件事之后，而且要先校准口径再谈。

本文涉及的命令，本机没有对应环境，全部未实测，代码块上方均保留了待验证标注；文中所有版本、日期与官方原文，以2026-09-16的核验结果为准。

⚠️代码待验证

# 三步自查：一段一条，逐段看结果php-v# 第一步：PHP 在不在apachectl-M2>/dev/null|grep-iphp# 第一步：模块有没有启用grep-ri'php'/etc/apache2/mods-enabled/2>/dev/null|head# 第二步：解析配置php-m|grep-i-E'gd|exif'# 第三步：扩展装了没有

本章清单速查卡：上面那张"三步自查表"，加上"现象对步骤"的对应关系，整理成了一页可以随时对照的卡片，放在资料包里，扫码即可获取：

本章可以带走的一句：看到源码文本，按"装上没有 → 当不当 PHP 处理 → 扩展装了没有"三步走，版本放到最后，并且先把官方口径校准。

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

附表 B：术语速查表

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

写这篇时我把"页面显示成源码"这件事按官方材料从下往上捋了一遍，最费劲的是确认 DVWA 官方到底怎么表述 PHP 版本——最后落点是官方那三句话，"≥7.3"那个流传很广的写法在原文里并不存在，顺手整理了几份配套的东西：

• 靶场环境对照表：DVWA、upload-labs 在 Windows / macOS / Linux 三平台的可行性与推荐路径
• Web 安全学习路线图：从基础打牢到安全管理，四个阶段各学什么
• 常用靶场清单：每个靶场练什么、适合哪个阶段

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

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

拿到之后建议先看靶场环境对照表那一份，把自己手上那套环境"官方文档要什么、官方容器实际用什么"两栏先对齐。