Ubuntu 18.04 Apache安装与虚拟主机配置实战指南

1. 环境准备与安装前置思路

写这个系列第五篇的时候，我特意回头翻了翻前几篇的内容。前面讲了Ubuntu 18.04的初始化配置、SSH远程连接、基础软件包管理，还有LAMP架构里MySQL的部署。这次轮到Apache了，但我还是想多说一句：很多人觉得Apache安装是个老掉牙的话题，apt install apache2一两分钟就能搞定，有什么好写的？我最初也是这么想的，后来在帮几个朋友排查环境问题时发现，真正把Apache装好并跑起来的不少，但装完能讲清楚目录结构、能配置出多站点、遇到权限和重写问题能快速定位的，确实不多。

说白了，Apache安装这件事，门槛不在安装命令本身，而在安装之后那一整套配置逻辑。这篇文章我会按实际部署流程往下走，覆盖从软件安装、服务管理、核心配置解读到虚拟主机配置、模块启用、性能调优和故障排查的完整链路。Ubuntu 18.04虽然是2018年发布的老版本，但至今还有大量服务器跑在上面，Apache的配置方式在18.04和20.04、22.04之间并没有天翻地覆的变化，所以这篇文章的绝大部分内容对后续版本同样适用。

先交代一下本文的适用读者：已经完成了Ubuntu 18.04系统基础安装和网络配置，准备在这台机器上搭建Web服务的人。如果你计划用的是LAMP组合，这篇文章就是为你的Apache环节扫清障碍；如果你只是临时需要跑一个静态站点或者做反向代理，同样可以按这篇文章的步骤操作。前置知识方面，需要了解Linux的基本命令操作，比如cd、ls、vim、sudo这些，如果还不太熟也没关系，文中每一步都会交代清楚命令的作用和执行后应该看到的结果。

有一点我在做事前强调的习惯：无论装什么软件，先确认系统处于什么状态再动手。经常有人在刚执行过apt upgrade的机器上装Apache，结果依赖版本冲突折腾半天；也有人拿到手的机器网络源都没配置好，apt install直接就报错了。我已经踩过太多类似的坑，所以在实操之前，建议先花一分钟做三件事：检查系统版本、确认网络连通性、更新软件包索引。

lsb_release -a # 查看当前系统版本 ping -c 4 archive.ubuntu.com # 测试Ubuntu官方源连通性 sudo apt update # 更新软件包索引

这三步做完，系统状态基本就摸清了。接着就可以正式进入Apache的安装流程。

2. 为什么选Apache以及Ubuntu下安装方式的选择

在正式执行安装命令之前，我想先花点篇幅聊聊两个问题：为什么选Apache而不是Nginx，以及为什么推荐用apt安装而不是源码编译。这两个问题如果没想清楚，后面配置的时候容易心里没底。

先说我自己的选择倾向。现在的Web服务器领域，Nginx凭借高并发性能和灵活的反向代理配置占据了很大市场份额，很多新项目上来就直接套Nginx。但Apache依然有它不可替代的位置，尤其在兼容性和灵活性上。Apache的模块化设计非常成熟，mod_rewrite、mod_ssl、mod_proxy这些模块经过十几年生产环境检验，稳定性和文档丰富度都极高。很多老牌PHP项目、企业内部系统，跑在Apache上的比例依然不低。另外，.htaccess机制也是Apache的一大特色，虽然生产环境里我建议尽量在虚拟主机配置里写规则而不是用.htaccess，但不可否认它确实给不拥有服务器根权限的使用者提供了很大的便利。

再聊安装方式。Ubuntu的软件源里已经维护好了Apache的二进制包，直接apt install就能装上一个开箱即用、文件路径规范、服务管理方式和系统完全集成的Apache。我见过不少人一上来就下载源码包configure、make、make install，非要自己折腾一遍才放心，其实对于绝大多数Web服务场景完全没有必要。源码编译适合需要定制模块路径、自定义编译参数或者需要最新版本特性的场景，而Ubuntu 18.04软件源里的Apache版本虽然不算最新，但安全更新和bug修复一直有人维护，稳定性是有保障的。生产环境的黄金法则是：能用系统包管理器解决的依赖和升级问题，就不要自己手动维护一套。省下来的时间可以用来理解配置和服务本身，而不是陪编译器较劲。

关于Apache在Ubuntu下的包名还有一个历史遗留问题。CentOS等RedHat系发行版里Apache的服务名是httpd，包名也是httpd；而Debian/Ubuntu系里包名和服务名都是apache2。我第一次从CentOS切到Ubuntu的时候就被这个命名差异坑过，习惯性地敲systemctl status httpd，结果提示服务不存在。后来才慢慢适应，Ubuntu下的Apache，配置文件在/etc/apache2/，服务名是apache2，默认站点目录是/var/www/html/，这些都要和CentOS区分开。

3. 正式安装Apache全过程

3.1 安装命令与版本验证

接下来就真正动手了。在Ubuntu 18.04上安装Apache，核心命令其实只有一条：

sudo apt install apache2 -y

由于前面已经执行过apt update，这里安装过程会比较顺利。安装完成后，Apache会作为systemd服务自动注册，默认开机自启。你可以用systemctl命令查看服务当前状态：

sudo systemctl status apache2

正常输出会显示Active: active (running)，说明Apache已经成功运行。安装完Apache后我习惯顺手确认一下版本号，这能帮你判断当前有哪些特性和安全补丁：

apache2 -v

18.04默认源里的Apache版本一般是2.4.29左右。这个版本已经支持HTTP/2协议（需要额外启用模块）、完整的mod_proxy系列，以及完善的SSL配置能力。对于大多数业务场景，这个版本完全够用。

3.2 防火墙放行Web端口

装好Apache之后，如果服务器开启了UFW防火墙，千万别忘记放行HTTP和HTTPS端口，否则浏览器访问会出现连接超时或者拒绝连接，但你在服务器本机用curl测又一切正常。这个问题极其常见，几乎每个人都会踩一次。

Ubuntu 18.04自带的是UFW防火墙管理工具，放行Apache端口有两种做法。第一种是直接放行端口号：

sudo ufw allow 80/tcp sudo ufw allow 443/tcp

第二种是利用Apache安装时自动注册的UFW应用配置文件，更省事：

sudo ufw app list

这个命令会输出一系列Apache相关条目，通常有Apache、Apache Full、Apache Secure三种。Apache对应只放行80端口，Apache Secure对应只放行443端口，Apache Full则同时放行80和443。一般直接执行sudo ufw allow 'Apache Full'即可，如果你需要同时跑HTTP和HTTPS的话。

3.3 验证安装结果

第一次验证我习惯在服务器本机用命令测试，排除网络因素干扰：

curl -I http://localhost

如果返回HTTP/1.1 200 OK，说明Apache已经在正常工作了。接下来用浏览器访问服务器的IP地址，能看到Apache2 Ubuntu Default Page这个默认页面，安装就算正式完成了。

从外网访问之前，还需要确认一下服务器IP。我常用的命令是：

hostname -I | awk '{print $1}'

把输出的IP输进浏览器地址栏，能看到默认页面就说明一切正常。这里的默认页面其实也是Apache在Ubuntu下的一个特色，很多人以为这个页面只是装完后的欢迎页，其实它还顺带展示了一些重要配置文件和目录的位置，值得花两分钟看一眼。

4. 配置文件实战解析：从主配置到站点配置

4.1 核心目录结构快速上手

安装只是开始，真正的重头戏是配置文件的理解。我见过太多人把配置改得乱七八糟以后直接在网上提问，问“为什么Apache起不来了”，一问才知道他们连配置文件在哪里都没搞清楚。所以这一节我会把Ubuntu下Apache的目录结构完整梳理一遍，对照着讲清楚每个文件的作用，这才是后续一切操作的地基。

Ubuntu的Apache把所有配置文件都集中在/etc/apache2/目录下，结构非常清晰：

• apache2.conf：主配置文件，Apache启动时最先读取的全局配置都在这里
• ports.conf：监听端口配置，默认监听80端口
• sites-available/：所有可用站点的配置存放目录
• sites-enabled/：实际生效的站点配置目录，这里的文件通常是sites-available里配置的符号链接
• mods-available/：可用的模块配置文件目录
• mods-enabled/：已启用的模块配置目录，同样是指向mods-available的符号链接
• conf-available/：额外的配置文件目录
• conf-enabled/：已启用的额外配置文件目录
• envvars：Apache环境变量配置文件
• magic：mod_mime_magic模块使用的MIME类型识别文件

这套目录结构的设计精髓在于：可用配置和生效配置是分开的。你新建一个站点或者启用一个模块，不是把配置文件改完就立即生效，而是需要在sites-enabled或者mods-enabled里建立符号链接，或者用专门的命令来启用。这样做的最大好处是配置变更可以随时回退，不会因为一次性改动过多导致服务崩溃后找不到原因。

拿站点配置来举例。sites-available目录下默认会有000-default.conf这个文件，里面配置了默认虚拟主机。如果你要新增一个站点，就在sites-available里新建一个配置文件，然后执行sudo a2ensite 站点名.conf来启用它。这个命令本质就是在sites-enabled目录下创建一个指向该配置文件的符号链接。反过来，sudo a2dissite 站点名.conf则可以停用站点，本质是移除符号链接。

4.2 主配置apache2.conf的静态拆分逻辑

为了理解这套机制，需要看一下apache2.conf编译出来的实际有效内容。配置文件的末尾有一段有趣的逻辑，无论你有没有修改过主配置它都会存在。让我在细节上做一点深挖，这段配置专门负责按规则加载sites-enabled和conf-enabled中的文件。

# Include module configuration: IncludeOptional mods-enabled/*.load IncludeOptional mods-enabled/*.conf # Include all the user configurations: IncludeOptional ports.conf # Include generic snippets of statements IncludeOptional conf-enabled/*.conf # Include the virtual host configurations: IncludeOptional sites-enabled/*.conf

这个把配置拆分成多个目录加载的设计，我认为是Debian/Ubuntu系Apache做得最优秀的设计之一。如果你去查看CentOS的httpd.conf，所有内容堆在一个文件里，一改动就得小心翼翼。Ubuntu的做法是让你把不同功能拆开放在不同文件里，比如某个域名绑定的ServerName和DocumentRoot放在site配置里，某个模块的参数放在mods-available对应的conf文件里，互不干扰。

主配置文件里还有几个重要的全局配置段，稍微留意一下：

• Timeout：服务器等待接收请求和响应的时间，默认60秒。做过大批量文件上传业务的会把这个值调大。
• KeepAlive：是否启用HTTP持久连接。现代网页往往一个页面几十个资源，开启KeepAlive可以减少TCP握手次数，明显提升页面加载速度。默认配置是关闭的，生产环境建议打开。
• MaxKeepAliveRequests：一个持久连接内允许的最大请求数，默认100，建议调大到500以上。
• KeepAliveTimeout：持久连接中等待下一个请求的超时时间，默认5秒，不需要调大，5秒足够。
• User/Group：Apache工作进程运行时的系统用户和用户组，默认是www-data。权限问题的根源和这两个参数有直接关系。

4.3 默认站点与端口配置细节

接着看ports.conf，这个文件默认内容很简单，就一行http监听80端口，外加一个NameVirtualHost注释说明。如果你要用SSL，在启用mod_ssl之后，ports.conf会自动追加Listen 443的配置。这里要提醒一点，如果你改了ports.conf里监听的端口，记得同时去站点配置里把VirtualHost的端口改成一致，否则会出现Apache正常监听但你配置的站点完全不生效的情况。

再看默认站点配置文件sites-available/000-default.conf：

<VirtualHost *:80> ServerAdmin webmaster@localhost DocumentRoot /var/www/html ErrorLog ${APACHE_LOG_DIR}/error.log CustomLog ${APACHE_LOG_DIR}/access.log combined </VirtualHost>

这个文件非常简洁，只有一个从任意IP的80端口接收请求的虚拟主机，根目录指向/var/www/html。${APACHE_LOG_DIR}这个变量定义在envvars文件里，通常指向/var/log/apache2。在实际业务中，这个文件往往作为模板，你复制一份改成自己的域名和目录，就能创建出新的站点。

这里有一个关键认知要建立：Apache从上到下读取所有启用的虚拟主机配置，当一个请求进来时，会匹配ServerName字段。如果有多个VirtualHost，只有ServerName匹配的那个才会生效。如果没有任何匹配，则使用加载顺序中的第一个虚拟主机作为默认站点。所以默认站点配置文件的名称叫000-default.conf是有讲究的，000开头的排序让它在没有匹配域名时兜底。这就是为什么如果你买了新域名却忘记修改配置，访问IP时看到的还是默认页面，因为000-default.conf是第一个被加载的。

5. 虚拟主机配置与多站点部署实战

5.1 手动创建虚拟主机配置

现在开始真正动手配置一个虚拟主机。我自己部署网站服务器时，几乎每次都要用到这个流程，所以把完整步骤写在这里，照着操作即可。

假设我要在一个IP上同时跑两个站点，域名为test1.example.com和test2.example.com，站点目录分别设在/var/www/test1和/var/www/test2。第一步先创建这两个目录并写入测试页面：

sudo mkdir -p /var/www/test1 sudo mkdir -p /var/www/test2 echo '<h1>Test Site 1</h1>' | sudo tee /var/www/test1/index.html echo '<h1>Test Site 2</h1>' | sudo tee /var/www/test2/index.html

第二步，复制默认配置生成两个新配置文件：

sudo cp /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/test1.conf sudo cp /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/test2.conf

第三步，对test1.conf做修改。用你习惯的编辑器打开配置文件，至少需要完成以下几个改动：把DocumentRoot改成/var/www/test1，把ServerName改成test1.example.com，并给日志加上独立的文件名，方便后续排查问题时区分两个站点的日志。同样处理test2.conf。

改好后测试配置语法，确认没有拼写错误：

sudo apachectl configtest

输出Syntax OK说明配置文件全部正常。接着启用这两个站点并重载Apache：

sudo a2ensite test1.conf sudo a2ensite test2.conf sudo systemctl reload apache2

此时如果你在本机的hosts文件里把test1.example.com和test2.example.com指向服务器IP，打开浏览器输入这两个域名，就能看到各自对应的测试页面。注意，为了让两个站点在同一个80端口上共存，它们各自的VirtualHost定义里端口都是*:80，靠不同的ServerName来区分请求。如果不设置ServerName，Apache在启动时会以默认站点方式处理所有请求，两个站点就都会显示第一个站点的内容，很容易让人误以为配置没生效。

5.2 目录访问权限配置的经典坑

虚拟主机配置完以后，一个极其常见的坑即将出现。当你把DocumentRoot指向一个自己新建的目录，比如/var/www/test1，却忘记给这个目录配置访问权限时，浏览器访问会出现403 Forbidden。

原因在于Apache默认的目录权限配置非常严格。看一下apache2.conf里的默认Deny规则就能理解：

<Directory /> Options FollowSymLinks AllowOverride None Require all denied </Directory>

这个配置对根目录做了拒绝一切访问的处理，然后各站点目录通过自己的Directory配置段显式放开权限。而你新建的/var/www/test1目录不在任何允许列表里，自然会被拦住。解决办法是在虚拟主机配置里显式添加Directory配置段：

<Directory /var/www/test1> Options Indexes FollowSymLinks AllowOverride All Require all granted </Directory>

这里有几个参数顺便解释一下：

• Options Indexes：允许目录索引展示，当目录没有index文件时，浏览器会看到文件列表。生产环境建议去掉Indexes，防止目录结构被随意浏览。
• FollowSymLinks：允许Apache跟随符号链接访问文件，如果你在站点目录里做了软链接，这个选项是必需的。
• AllowOverride All：允许.htaccess文件覆盖当前目录及子目录的配置。如果你的站点程序依赖.htaccess，比如很多PHP开源程序，这个选项必须设为All。
• Require all granted：允许所有来源的请求访问该目录。这是Apache 2.4的授权语法，完全取代了2.2时代Order Allow,Deny的写法。

5.3 启用常见模块与URL重写

站点目录配置好之后，接下来要考虑模块的启用。Apache的很多功能默认是关闭的，最典型的就是mod_rewrite，很多程序对URL进行伪静态处理时依赖这个模块。启用命令如下：

sudo a2enmod rewrite sudo systemctl restart apache2

如果你在配置文件中启用了AllowOverride All，而在站点目录下放置了.htaccess文件，那么这些重写规则会自动生效。不过用户体验更好的方案是直接在虚拟主机配置里写RewriteRule，而不是依赖.htaccess文件。原因很简单：Apache需要在每个目录里检查是否有.htaccess文件，这个行为在AllowOverride All开启时会对每个请求产生额外的文件读取开销。生产环境高并发下，这能明显节省性能。但如果你是租用的虚拟主机，不能修改Apache主配置，那就只能用.htaccess了。

如果你需要部署HTTPS，还要启用SSL相关模块并配置证书。在Ubuntu 18.04上启用SSL比较简单：

sudo a2enmod ssl sudo a2ensite default-ssl.conf sudo systemctl restart apache2

然后在sites-available/default-ssl.conf里配置证书路径和DocumentRoot即可。当然生产环境用Let's Encrypt免费证书会更方便，用certbot配合Apache插件可以自动完成证书申请和配置，这里就不展开讲了。

5.4 多站点配置过程中的日志观测

无论你按上面的步骤配置了多少个站点，我建议你在配置完成后打开日志做一次实时观测。我排查问题多年的经验证明，日志是最客观的事实来源。

Apache的日志位于/var/log/apache2/，默认有两个核心文件：access.log（访问日志）和error.log（错误日志）。启用多站点后，同名文件会变多，比如test1_error.log、test1_access.log。

跟踪错误日志的实时输出，可以这样操作：

sudo tail -f /var/log/apache2/test1_error.log

单开一个终端窗口挂着这个命令，然后在浏览器里访问test1.example.com，任何错误信息都会立刻刷出来。和配置猜测相比，日志信息通常直接告诉你问题出在哪一行，包括文件权限、配置路径、语法错误、证书问题等等。我把这个习惯养成之后，排查故障的速度提升了不止一个档次。

6. 性能参数调整与常见故障排查

6.1 MPM多进程模块的选择与优化

配置层面的问题解决之后，聊聊性能调优。Apache 2.4版本在Ubuntu上默认使用MPM（Multi-Processing Module）来决定如何处理请求。Debian/Ubuntu打包时默认启用的是mpm_event模块，同时保留了mpm_prefork和mpm_worker两个备选模块。

三者的核心区别和工作原理需要有一点点概念：

• mpm_prefork：一个请求由一个进程处理，进程之间完全隔离，稳定性最好，但在高并发下内存占用大。PHP在非线程安全模式下必须使用prefork，因为PHP 5.6及更早版本的一些库不是线程安全的。
• mpm_worker：使用进程加线程的混合模式，每个进程可以生成多个线程，每个线程处理一个请求。并发能力比prefork强很多，内存利用更高效。
• mpm_event：基于worker的改进版，专门优化了KeepAlive请求处理机制。在KeepAlive连接保持期间，event模式不会占用工作线程而是交给专门的事件线程管理，所以相同内存下可以支撑更多并发连接。Apache 2.4.29以上的event模式已经非常稳定。

在Ubuntu 18.04上切换MPM模式的命令是：

sudo a2dismod mpm_event sudo a2enmod mpm_prefork sudo systemctl restart apache2

注意先禁用旧模块再启用新模块，顺序乱了会提示冲突。切换后确认模式生效，可以执行apache2ctl -M查看模块列表。如果你的PHP是通过mod_php方式运行的，那么务必使用mpm_prefork，不能用event或者worker，否则会出现Apache进程崩溃或者PHP模块加载失败的情况。这是一个非常基本的合规性问题，但踩过这个坑的人不在少数。如果你的PHP是通过PHP-FPM方式运行的，那Apache只需要启用mod_proxy_fcgi并配置反向代理到PHP-FPM的socket，这种情况下event模式就是最好的选择。我自己部署PHP应用时几乎都采用这种架构，并发性能和进程隔离性都很好。

相关性能参数的合理配置参考表，以比较常见的8核16G服务器和event模式为例：

修改这些参数需要在/etc/apache2/mods-available/mpm_event.conf里完成。没有绝对的正确答案，这些数值和你的业务模式强相关，需要监控实内存和连接数后逐步调整。

6.2 KeepAlive与超时参数的选择逻辑

正常配置好MPM之后，还需要回头优化一下KeepAlive相关参数。你可以这样理解KeepAlive机制的意义：传统的HTTP请求在每个资源下载后都会断开TCP连接，一个包含50个资源的页面就需要50次TCP握手；开启KeepAlive后，浏览器和服务器之间维持同一个TCP连接来传输多个资源，明显减少了握手延迟。

KeepAlive涉及三个参数：

• KeepAlive On/Off：总开关
• MaxKeepAliveRequests：一个连接内可处理的最大请求数，默认100，对静态资源较多的网站可以调大到300-500
• KeepAliveTimeout：等待下一个请求的超时时间，默认5秒，不建议超过10秒

如果你在跑高并发业务，KeepAliveTimeout要适当压小，因为每个空闲连接都在占用服务器的并发连接数。我之前接手过一个流量很大的业务，发现连接数一直顶到上限，排查了一圈发现KeepAliveTimeout被人调成了30秒，大量空闲连接耗尽了MaxRequestWorkers。调整回5秒后问题迎刃而解。

Timeout参数也要单独拎出来说。这个参数控制的是收到请求后、发送响应的过程中各个阶段的最大等待时间，默认60秒。如果你的站点有上传大文件的需求，默认60秒可能不够。我一般把Timeout设置为300秒，给大文件上传和慢速客户端预留足够的缓冲。但别把这个值调得太大，否则攻击者可以借助大量慢速连接长期占用服务器资源。

6.3 高频故障排查速查表

多年代理运营经验让我积累了清晰的Apache故障排查路径。下面按发生频率从高到低分享几个经典问题，每条附上排查方法：

其中日志文件过大这个问题值得多提一嘴。访问量大的站点，access.log一个月就能涨到几个GB。Ubuntu默认配置了logrotate每日轮转日志，保留52份，基本不需要手动干预。但如果站点访问量异常暴增，日志增长会超出logrotate的处理速度，还是建议定期检查磁盘空间：

df -h du -sh /var/log/apache2/*

数据无价，磁盘满会导致Apache直接拒绝写入日志，同时站点访问也可能会出现各种异常。

6.4 配置变更的安全回滚习惯

最后分享一个我自己的操作习惯。修改任何Apache配置文件之前，我都会先把当前生效配置完整复制一份备份，有些比较重要的节点还会打上时间戳：

sudo cp /etc/apache2/apache2.conf /etc/apache2/apache2.conf.bak-20240101

修改完执行configtest确认语法无误后，再做reload。如果改了配置后Apache启动失败，只要把备份文件复制回来再重启服务就能恢复：

sudo cp /etc/apache2/apache2.conf.bak-20240101 /etc/apache2/apache2.conf sudo systemctl restart apache2

这种做法看似多花了几秒钟，但服务器出问题时的恢复速度是翻倍的。生产环境的改动安全性和可控性，远比改动的速度重要。这套思路不只适用于Apache，任何服务器配置变更都应该遵循备份-修改-验证-确认的流程。

在Ubuntu 18.04上装了这么多年Apache，我的体会是项目初期的稳定基础往往取决于基础服务的细致程度。多站点隔离清楚、模块按需启用、日志整理规范和权限约束到位，这些都在为后续开发省时间。文章里提到的每一个坑，几乎都是我自己或者身边同事实际踩过的，把这些写下来，希望各位能少走一些弯路。如果你在部署过程中遇到其他问题，最有效的手段是sites的error.log和最经典的apachectl configtest，这两个工具总能给你指明方向。