用 Dockerfile 构建生产级 Apache Web 服务器

1. 项目概述：为什么用 Dockerfile 构建 Apache Web Server 是当前最稳妥的入门路径

Apache HTTP Server 是互联网上运行时间最长、部署最广泛的开源 Web 服务器之一，至今仍支撑着全球近 30% 的活跃网站。而 Dockerfile 则是将服务“可重现、可验证、可迁移”的核心载体——它不是简单的打包工具，而是一份精确到字节的构建说明书。当你看到标题“Building an Apache Web Server through a Dockerfile”，它背后真正指向的，是一个现代运维与开发协同落地的最小可行闭环：从零开始，不依赖宿主机环境，不污染系统配置，5 分钟内启动一个干净、隔离、可审计的 Apache 实例，并且这个过程能被 Git 版本化、CI/CD 自动化、团队成员一键复现。

我带过十几期 DevOps 实训班，发现新手最容易卡在三个地方：一是直接在 Ubuntu 主机上 apt install apache2，结果和系统自带的 systemd、logrotate、SELinux 规则缠斗半天；二是下载二进制包手动编译，遇到 apr/apr-util 依赖版本不匹配直接报错退出；三是用 docker run -d -p 80:80 httpd 镜像，却无法修改默认首页、挂载自定义配置、或调试 .htaccess 行为。而这三类问题，恰恰都能被一个设计得当的 Dockerfile 彻底规避。它强制你把“环境”变成代码：哪一行安装什么包、哪一行复制什么配置、哪一行暴露什么端口、哪一行设置什么用户权限——全部白纸黑字，没有隐藏状态，没有“我本地好使但上线就崩”的玄学。

这个项目天然适配三类人：第一类是刚接触 Linux 服务部署的大学生或转行者，你需要的不是“Apache 所有模块详解”，而是“如何让 index.html 稳稳显示在浏览器里”；第二类是正在搭建 CI/CD 流水线的后端工程师，你关心的是“如何把测试环境的 Apache 配置和生产环境完全对齐”；第三类是安全合规岗位人员，你在意的是“这个镜像里有没有多余用户、是否禁用了危险模块、日志是否按规范输出”。而 Dockerfile 就是这三类需求的交汇点——它不解决 Apache 本身的功能问题，但它解决了 Apache 在真实世界中“活下来”的所有基础设施问题。

关键词 Apache、Web Server、Dockerfile、Docker、Ubuntu 并非随意堆砌。它们构成了一条清晰的技术链路：Ubuntu 是最主流的 Docker 宿主操作系统（尤其在云服务器和 WSL2 场景），Docker 是容器运行时标准，Dockerfile 是构建指令集，Apache 是你要交付的服务实体。整条链路上，任何一个环节出偏差，都会导致最终服务不可靠。比如你用 Alpine 基础镜像写 Dockerfile，虽然体积小，但 musl libc 和 glibc 的差异会让某些 Apache 模块（如 mod_ssl 的某些 OpenSSL 绑定）静默失效；又比如你在 Dockerfile 里用 RUN apt-get install -y apache2 && systemctl start apache2，这在容器里根本跑不通——因为容器没有 systemd，你必须用 exec 启动 httpd 进程并以前台模式运行。这些坑，我都在生产环境踩过，也正因如此，才敢说：一个合格的 Apache Dockerfile，不是“能跑就行”，而是要经得起 strace 追踪进程、curl 抓包验证响应头、docker inspect 查看元数据、以及三年后新人拉取代码仍能 100% 复现的考验。

2. 整体设计思路与方案选型逻辑：为什么选 Ubuntu 22.04 + Apache 2.4.52 而非其他组合

2.1 基础镜像选择：Ubuntu 22.04 LTS 是当前最平衡的决策

很多人一上来就想用更小的镜像，比如 debian:slim 或 alpine:latest。我实测对比过 7 种基础镜像在 Apache 场景下的表现，结论很明确：对于初学者和中小规模生产环境，ubuntu:22.04 是唯一推荐的起点。原因有三：

第一，兼容性无死角。Ubuntu 22.04 自带的 Apache 2.4.52 完全兼容所有主流模块：mod_rewrite、mod_ssl、mod_headers、mod_expires，甚至 mod_security2（OWASP CRS）也能通过 apt 直接安装。而 Alpine 的 apk add apache2 安装的是精简版 httpd，缺少 apachectl 脚本、a2enmod 工具、以及完整的 MPM（Multi-Processing Module）配置体系，你得自己手写启动脚本，这对新手是灾难。

第二，文档生态最完善。所有官方 Apache 文档、Ubuntu Server 指南、甚至 Stack Overflow 上 90% 的 Apache 配置问题，其答案都基于 Debian/Ubuntu 的文件路径（/etc/apache2/sites-available/、/var/log/apache2/、a2ensite 命令）。你用 Alpine，就得把所有路径映射成 /etc/httpd/、/var/log/httpd/，还要重写所有教程里的命令，学习成本翻倍。

第三，长期支持有保障。Ubuntu 22.04 是 LTS（Long Term Support）版本，官方维护到 2027 年 4 月，这意味着你构建的镜像在未来五年内，只要定期 docker build --no-cache，就能自动获取安全更新（比如 OpenSSL 补丁、Apache CVE 修复），无需重构整个 Dockerfile。相比之下，ubuntu:latest 是滚动发布，可能某天构建出来的镜像 Apache 版本突然从 2.4 升到 2.5，导致 mod_php 兼容性断裂。

提示：不要用 ubuntu:20.04。虽然它也是 LTS，但其 Apache 2.4.41 存在已知的 HTTP/2 流控缺陷（CVE-2022-36760），在高并发场景下会触发连接重置。22.04 的 2.4.52 已彻底修复。

2.2 Apache 安装方式：apt 安装优于源码编译，但必须精准控制启用模块

有人坚持“源码编译才能掌控一切”，这在十年前或许成立，但现在完全没必要。Ubuntu 官方仓库的 apache2 包经过严格 QA，所有依赖（apr、apr-util、pcre、openssl）版本均已锁定并测试兼容。你手动编译，反而容易引入 ABI 不兼容——比如你升级了系统 openssl 到 3.0，但自己编译的 Apache 还链接着旧版 libssl.so.1.1，运行时直接段错误。

但 apt install apache2 默认启用的模块太多，存在安全冗余。我们必须在 Dockerfile 中显式控制：

• 必须启用：mod_rewrite（URL 重写）、mod_ssl（HTTPS）、mod_headers（响应头控制）、mod_expires（缓存策略）
• 必须禁用：mod_info（泄露服务器内部信息）、mod_status（暴露实时连接数，可被滥用）、mod_userdir（允许用户目录访问，易引发越权）

这个控制不是靠注释配置文件实现的，而是用a2dismod命令在构建阶段就移除。为什么？因为如果只注释配置，模块二进制文件仍在镜像里，攻击者可通过恶意请求触发加载，或利用其他模块漏洞绕过限制。真正的最小化，是让不需要的模块文件物理消失。

2.3 启动机制设计：前台进程模型是容器化的铁律

这是新手最容易犯的致命错误：在 Dockerfile 里写RUN systemctl start apache2或RUN service apache2 start。这两条命令在构建阶段执行时，只是临时启动了一个进程，构建结束后该进程立即终止，镜像里根本没留下任何“服务状态”。容器启动时，如果没有指定前台进程，就会立刻退出。

正确做法是：让 httpd 进程以 -D FOREGROUND 模式运行，且作为容器的 PID 1。Docker 要求容器必须有一个前台主进程，否则认为服务已结束。Apache 官方文档明确说明：httpd -D FOREGROUND会阻止进程转入后台，保持 stdout/stderr 打开，完美契合容器生命周期。我们不在 Dockerfile 的 RUN 指令里启动服务，而是在最后用CMD ["apache2ctl", "-D", "FOREGROUND"]声明——这条指令只在容器运行时执行，且是唯一的主进程。

注意：不要用ENTRYPOINT ["apache2ctl", "-D", "FOREGROUND"]。ENTRYPOINT 不易覆盖，调试时想进容器查日志会非常麻烦。CMD 可以被docker run --rm -it your-image bash覆盖，保留调试灵活性。

2.4 配置分层策略：分离“不变基础设施”与“可变业务配置”

一个健壮的 Dockerfile 必须区分两类配置：

• 基础设施层：Apache 核心行为，如 MPM 模型（prefork/event）、超时时间、最大连接数、日志格式。这些应硬编码在 Dockerfile 的 COPY 指令中，确保每次构建都一致。
• 业务层：虚拟主机配置（VirtualHost）、SSL 证书路径、RewriteRule 规则。这些应通过 docker run 的 -v 参数挂载，或通过环境变量注入（需配合 entrypoint 脚本）。

我们在 Dockerfile 中只处理基础设施层。例如，将自定义的/etc/apache2/mods-enabled/mpm_prefork.conf和/etc/apache2/apache2.conf通过 COPY 指令写入镜像。其中 mpm_prefork.conf 明确设置：

<IfModule mpm_prefork_module> StartServers 2 MinSpareServers 2 MaxSpareServers 5 MaxRequestWorkers 150 MaxConnectionsPerChild 1000 </IfModule>

这个配置针对容器场景做了优化：MaxRequestWorkers 设为 150（而非默认 256），避免单个容器占用过多内存；MaxConnectionsPerChild 设为 1000（而非 0），强制进程定期回收，防止内存泄漏累积。这些数字不是拍脑袋定的，而是根据 2GB 内存容器实测得出的平衡点——Worker 数再高，内存 OOM 就会杀死容器；再低，QPS 上不去。

3. Dockerfile 核心细节解析与实操要点：逐行拆解每一行指令的深意

3.1 基础镜像与元数据声明：FROM 与 LABEL 的隐含契约

FROM ubuntu:22.04 LABEL maintainer="devops@example.com" \ description="Production-ready Apache 2.4 web server with security hardening" \ version="1.0.0"

FROM 指令看似简单，但它锁定了整个构建链的根基。ubuntu:22.04 这个 tag 对应的是一个具体的镜像 digest（如 sha256:4b...），而不是某个浮动的“最新版”。这意味着你今天构建的镜像，和三个月后同事在另一台机器上构建的，只要 base 镜像 digest 相同，构建结果就 100% 一致。这是可重现性的第一道保险。

LABEL 指令常被忽略，但它至关重要。maintainer 字段不是摆设——当你的镜像被推送到私有仓库（如 Harbor），运维平台会自动抓取这个字段生成责任人看板；description 字段会在 docker inspect 输出中显示，帮助排查时快速识别镜像用途；version 字段则是语义化版本控制的起点。我见过太多团队因为没加 LABEL，导致线上故障时花 20 分钟才搞清“这个叫 web-server 的镜像是谁打的、改了什么”。

实操心得：永远用docker pull ubuntu:22.04显式拉取基础镜像，再构建。不要依赖本地缓存。因为docker build默认会跳过已存在的 layer，如果基础镜像在你本地是半年前的旧版，构建出的镜像就可能包含未修复的 CVE。

3.2 系统更新与依赖安装：APT 缓存清理的黄金法则

RUN apt-get update && \ apt-get install -y --no-install-recommends \ apache2 \ apache2-utils \ ssl-cert && \ rm -rf /var/lib/apt/lists/*

这一行是性能与安全的博弈场。apt-get update必须和install在同一 RUN 指令中，否则 Docker 构建缓存会失效——因为 update 生成的包索引文件（/var/lib/apt/lists/）在下一层会被清除，install 时找不到最新包列表。

--no-install-recommends是关键开关。Ubuntu 的 apt 默认会安装“推荐依赖”（Recommends），比如 apache2 会推荐安装 mailutils（用于发送邮件告警），这完全没必要。开启此选项，可减少镜像体积 30MB 以上，更重要的是消除未知依赖带来的安全面。

rm -rf /var/lib/apt/lists/*不是可选项。这些 lists 文件平均大小 25MB，纯粹是构建中间产物，不清理会永久留在镜像层中，增大推送体积、拖慢拉取速度。我曾帮一个客户优化镜像，仅这一行就让 420MB 的镜像缩减到 310MB，CI/CD 流水线构建时间从 8 分钟降到 4 分钟。

3.3 配置文件覆盖：COPY 指令的原子性与路径陷阱

COPY apache2.conf /etc/apache2/apache2.conf COPY mpm_prefork.conf /etc/apache2/mods-enabled/mpm_prefork.conf COPY 000-default.conf /etc/apache2/sites-available/000-default.conf

COPY 指令有两大陷阱：

第一，路径必须绝对精确。/etc/apache2/sites-available/000-default.conf这个路径，少一个斜杠或拼错字母，Apache 启动时就会报Could not open configuration file。建议在本地先用docker run -it --rm ubuntu:22.04 bash进入容器，手动创建对应目录结构，再用ls -la /etc/apache2/验证路径。

第二，文件权限继承。COPY 进去的文件，默认权限是 644（rw-r--r--），但 Apache 某些模块（如 mod_ssl）要求 ssl.key 文件权限为 600。所以如果你要 COPY 证书，必须紧跟一条RUN chmod 600 /etc/ssl/private/your.key。

这里我们覆盖的三个文件，每个都有明确目的：

• apache2.conf：全局配置，我们在这里禁用 ServerTokens（隐藏 Apache 版本号）、设置 KeepAliveTimeout 为 5 秒（减少空闲连接占用）、关闭 TraceEnable（防 HTTP TRACE 攻击）。
• mpm_prefork.conf：如前所述，定制进程模型参数。
• 000-default.conf：默认虚拟主机，我们将其 DocumentRoot 改为/var/www/html（标准路径），并添加<Directory "/var/www/html"> AllowOverride All </Directory>，确保 .htaccess 生效。

3.4 模块启停控制：a2enmod/a2dismod 的幂等性设计

RUN a2dismod status info userdir && \ a2enmod rewrite ssl headers expires

a2dismod 和 a2enmod 是 Debian/Ubuntu 独有的 Apache 模块管理工具，它们的本质是创建/删除/etc/apache2/mods-enabled/目录下的符号链接。a2dismod status会删除status.load和status.conf链接，a2enmod rewrite会创建rewrite.load链接。

关键点在于：这些命令是幂等的。即a2dismod status执行多次，结果相同；如果 status 模块已被禁用，再次执行不会报错。这使得 Dockerfile 构建具备强鲁棒性——即使某次构建中断，重新运行也不会因“模块已禁用”而失败。

我们禁用 status/info/userdir 的理由再强调一次：status 模块暴露实时连接数、每秒请求数、CPU 使用率，攻击者可据此发起精准 DoS；info 模块显示完整编译参数、加载模块列表、甚至部分配置片段；userdir 允许http://server/~username/访问用户主目录，极易成为横向移动入口。这不是过度防御，而是 OWASP ASVS 4.0.1 的明确要求。

3.5 日志与文档清理：减小体积与提升安全性的一体两面

RUN rm -rf /usr/share/doc/* /usr/share/man/* /var/www/html/index.html && \ mkdir -p /var/www/html && \ echo "<h1>Welcome to Apache on Docker</h1>" > /var/www/html/index.html

/usr/share/doc/和/usr/share/man/是纯文本文档，总大小约 120MB，对运行时零价值，却显著增加镜像体积和攻击面（文档中可能包含过时的配置示例，被误用）。rm -rf是最彻底的清理方式。

/var/www/html/index.html是 Apache 默认首页，内容是 Ubuntu 的欢迎页，包含大量 HTML 注释和冗余 CSS。我们删除它，然后创建一个极简的 index.html。这不仅是“好看”，更是安全实践：默认页常被扫描器识别为“未加固 Apache”，触发安全告警。一个空白或自定义的首页，能降低被自动化工具标记的风险。

注意：mkdir -p /var/www/html必须在echo之前。因为rm -rf /var/www/html/index.html不会删除 html 目录本身，但如果目录不存在，echo 会失败。-p参数确保目录存在，这是 Shell 脚本的健壮性常识。

4. 完整实操流程与核心环节实现：从编写到验证的全流程记录

4.1 项目目录结构与文件准备：建立可版本化的工程骨架

在开始写 Dockerfile 前，先规划好本地目录结构。这不是形式主义，而是为了未来扩展（比如加入 SSL 证书、PHP 支持、监控探针）做准备：

apache-docker/ ├── Dockerfile ├── apache2.conf ├── mpm_prefork.conf ├── 000-default.conf ├── html/ │ └── index.html └── scripts/ └── healthcheck.sh

其中html/目录用于存放你的静态网站文件，scripts/用于存放健康检查脚本。这种结构让 Dockerfile 保持简洁，所有业务资产都外置。

现在，我们逐个创建核心配置文件。先看apache2.conf，这是全局配置的中枢：

# /etc/apache2/apache2.conf - Hardened for Docker DefaultRuntimeDir ${APACHE_RUN_DIR} PidFile ${APACHE_PID_FILE} Timeout 30 KeepAlive On MaxKeepAliveRequests 100 KeepAliveTimeout 5 User ${APACHE_RUN_USER} Group ${APACHE_RUN_GROUP} HostnameLookups Off ErrorLog ${APACHE_LOG_DIR}/error.log LogLevel warn IncludeOptional mods-enabled/*.load IncludeOptional mods-enabled/*.conf Include ports.conf <Directory /> Options FollowSymLinks AllowOverride None Require all denied </Directory> <Directory /usr/share> AllowOverride None Require all granted </Directory> <Directory /var/www/> Options Indexes FollowSymLinks AllowOverride All Require all granted </Directory> AccessFileName .htaccess <FilesMatch "^\.ht"> Require all denied </FilesMatch> LogFormat "%v:%p %h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined LogFormat "%h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" combined ServerTokens Prod TraceEnable off

这个配置的关键点：

• ServerTokens Prod：响应头中只显示Server: Apache，不泄露版本号。
• TraceEnable off：禁用 HTTP TRACE 方法，防跨站跟踪攻击。
• <Directory />的Require all denied：根目录默认拒绝所有访问，强制所有流量必须命中明确的 VirtualHost。
• AllowOverride All：在/var/www/下启用 .htaccess，方便前端路由（如 Vue Router 的 history 模式）。

4.2 Dockerfile 编写与构建：一次成功的关键参数

现在，把前面分析的所有要点，整合成最终的 Dockerfile：

# apache-docker/Dockerfile FROM ubuntu:22.04 LABEL maintainer="devops@example.com" \ description="Production-ready Apache 2.4 web server with security hardening" \ version="1.0.0" # 更新源并安装 Apache 及必要工具 RUN apt-get update && \ apt-get install -y --no-install-recommends \ apache2 \ apache2-utils \ ssl-cert && \ rm -rf /var/lib/apt/lists/* # 复制自定义配置文件 COPY apache2.conf /etc/apache2/apache2.conf COPY mpm_prefork.conf /etc/apache2/mods-enabled/mpm_prefork.conf COPY 000-default.conf /etc/apache2/sites-available/000-default.conf # 禁用不安全模块，启用必要模块 RUN a2dismod status info userdir && \ a2enmod rewrite ssl headers expires # 清理文档、手册和默认首页 RUN rm -rf /usr/share/doc/* /usr/share/man/* /var/www/html/index.html && \ mkdir -p /var/www/html && \ echo "<h1>Welcome to Apache on Docker</h1>" > /var/www/html/index.html # 暴露端口 EXPOSE 80 443 # 健康检查（可选，但强烈推荐） HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \ CMD curl -f http://localhost/ || exit 1 # 启动命令 CMD ["apache2ctl", "-D", "FOREGROUND"]

构建命令必须带上--no-cache参数，确保每次都拉取最新基础镜像和包索引：

docker build --no-cache -t my-apache:1.0.0 .

--no-cache是生产构建的铁律。如果不加，Docker 会复用本地缓存的 layer，可能导致你本地的旧版基础镜像被复用，从而遗漏安全更新。构建成功后，用docker images | grep my-apache查看镜像大小，理想值应在 180~220MB 之间。如果超过 250MB，大概率是忘记清理/var/lib/apt/lists/*或/usr/share/doc/*。

4.3 容器运行与端口映射：理解 -p 参数背后的网络模型

构建完成后，启动容器：

docker run -d \ --name my-apache \ -p 8080:80 \ -p 8443:443 \ -v $(pwd)/html:/var/www/html:ro \ -v $(pwd)/certs:/etc/ssl/certs:ro \ -v $(pwd)/private:/etc/ssl/private:ro \ --restart=unless-stopped \ my-apache:1.0.0

参数详解：

• -p 8080:80：将宿主机的 8080 端口映射到容器的 80 端口。注意顺序：宿主机端口:容器端口。很多新手写反，导致访问 localhost:80 找不到服务。
• -v $(pwd)/html:/var/www/html:ro：将本地html/目录挂载为只读（:ro），防止 Apache 进程意外修改文件。这是安全最佳实践。
• --restart=unless-stopped：容器异常退出时自动重启，但手动docker stop后不会重启，兼顾稳定性与可控性。

启动后，用docker ps确认容器状态为Up X seconds，再用curl -I http://localhost:8080检查响应头：

HTTP/1.1 200 OK Date: Mon, 15 Apr 2024 08:22:34 GMT Server: Apache Last-Modified: Mon, 15 Apr 2024 08:20:00 GMT Content-Length: 42 Content-Type: text/html

注意Server: Apache（不是Apache/2.4.52 (Ubuntu)），证明ServerTokens Prod生效；Content-Length正确，证明页面能正常返回。

4.4 HTTPS 配置实战：从自签名证书到 Let's Encrypt 的平滑过渡

要启用 HTTPS，只需两步：准备证书、修改虚拟主机配置。

首先，生成自签名证书（仅用于测试）：

mkdir -p certs private openssl req -x509 -nodes -days 365 -newkey rsa:2048 \ -keyout private/apache.key \ -out certs/apache.crt \ -subj "/C=CN/ST=Beijing/L=Beijing/O=MyOrg/CN=localhost"

然后，修改000-default.conf，在末尾添加 HTTPS 虚拟主机：

<IfModule mod_ssl.c> <VirtualHost _default_:443> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined SSLEngine on SSLCertificateFile /etc/ssl/certs/apache.crt SSLCertificateKeyFile /etc/ssl/private/apache.key <FilesMatch "\.(cgi|shtml|phtml|php)$"> SSLOptions +StdEnvVars </FilesMatch> <Directory /usr/lib/cgi-bin> SSLOptions +StdEnvVars </Directory> </VirtualHost> </IfModule>

重新构建并运行容器，访问https://localhost:8443。浏览器会提示证书不安全（因为是自签名），点击“高级”->“继续前往”，即可看到加密连接。

生产环境当然要用 Let's Encrypt。这时，你不需要改 Dockerfile，只需：

1. 在宿主机用 certbot 获取证书；
2. 将证书文件放入certs/和private/目录；
3. 重启容器docker restart my-apache。

这就是配置分层的价值：基础设施（Dockerfile）不变，业务配置（证书、域名）通过挂载动态注入。

4.5 日志与调试：进入容器内部的正确姿势

当页面打不开时，别急着删容器重来。先进入容器查日志：

# 查看实时错误日志 docker exec -it my-apache tail -f /var/log/apache2/error.log # 查看访问日志 docker exec -it my-apache tail -f /var/log/apache2/access.log # 进入容器 Bash（调试用） docker exec -it my-apache bash

在容器内，你可以运行apache2ctl configtest验证配置语法是否正确；用ps aux | grep httpd确认进程是否在运行；用netstat -tuln | grep :80检查端口是否监听。

实操心得：永远在 Dockerfile 中加入HEALTHCHECK。它让 Kubernetes 或 Docker Swarm 能自动检测容器健康状态。上面的curl -f http://localhost/命令，-f参数表示失败时不输出错误信息，只返回非零退出码，这是 HEALTHCHECK 的标准写法。

5. 常见问题与排查技巧实录：那些年我们踩过的坑与独家解决方案

5.1 问题速查表：高频故障现象、原因与一键修复命令

这张表来自我处理过的 217 个 Apache Docker 相关工单。其中“容器立即退出”占比 43%，几乎全是 CMD 配置错误；“403 Forbidden”占 28%，根源 90% 是挂载目录权限问题。

5.2 深度排查案例：一次诡异的 413 Request Entity Too Large 故障

有位学员反馈：上传大于 1MB 的文件时，Apache 返回 413 错误。他确认000-default.conf里写了LimitRequestBody 10485760（10MB），但依然失败。

我让他执行docker exec my-apache apache2ctl -M | grep rewrite，发现rewrite_module确实已加载。再执行docker exec my-apache apache2ctl -t，语法检查通过。问题不在配置。

深入排查：curl -v -F "file=@large.zip" http://localhost:8080/upload.php，用-v查看详细响应。发现响应头中有X-Powered-By: PHP/8.1.2，说明请求被转发给了 PHP-FPM，而非 Apache 直接处理。

真相浮出水面：他的html/目录下有个.htaccess文件，内容是：

RewriteEngine On RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ index.php [QSA,L]

这个规则把所有请求（包括 POST 上传）都重写到了index.php。而 PHP 的upload_max_filesize默认是 2MB，post_max_size是 8MB，但client_max_body_size（Nginx 术语）在 Apache 里对应的是LimitRequestBody，它只对 Apache 直接处理的请求生效，对转发给 PHP 的请求无效。

解决方案有两个：

1. 治标：在.htaccess中排除上传路径RewriteCond %{REQUEST_URI} !^/upload/；
2. 治本：在000-default.conf的<Directory>块中，为上传目录单独设置LimitRequestBody，并确保该目录不被 RewriteRule 捕获。

这个案例说明：Dockerfile 只解决 Apache 本身的配置，但业务逻辑（如 .htaccess）的 Bug，必须结合应用层一起分析。容器化不是万能的银弹，它只是把环境问题标准化，业务逻辑问题依然存在。

5.3 性能调优实录：从 100 QPS 到 1200 QPS 的三次关键调整

用ab -n 1000 -c 100 http://localhost:8080/（Apache Bench）压测初始镜像，QPS 仅 100。通过docker stats my-apache发现 CPU 使用率 35%，内存 180MB，瓶颈不在资源，而在配置。

第一次调整：MPM 模型从 prefork 改为 eventmpm_prefork.conf改为：

<IfModule mpm_event_module> StartServers 3 MinSpareThreads 75 MaxSpareThreads 250 ThreadsPerChild 25 MaxRequestWorkers 400 MaxConnectionsPerChild 0 </IfModule>

event MPM 使用线程而非进程，内存占用更低，适合高并发。QPS 提升至 420。

第二次调整：启用 OPcache（需集成 PHP）虽然本项目纯静态，但很多用户会在此基础上加 PHP。在Dockerfile中追加：

RUN apt-get update && apt-get install -y php8.1 libapache2-mod-php8.1 && \ rm -rf /var/lib/apt/lists/* && \ echo "opcache.enable=1" >> /etc/php/8.1/apache2/conf.d/opcache.ini

OPcache 将 PHP 字节码缓存到共享内存，避免重复编译。QPS 再提升至 850。

第三次调整：启用 Brotli 压缩网络热词中提到if using custom web server, verify that web server is sending .br files，Brotli 压缩比 Gzip 高 15%。在Dockerfile中：

RUN apt-get update && apt-get install -y brotli && \ a2enmod brotli && \ echo "AddOutputFilterByType BROTLI_COMPRESS text/html text/plain text/css text/javascript application/javascript" >> /etc/apache2/apache2.conf

最终