如何在 Apache 中配置 PHP 环境

你需要在 Windows、Ubuntu 或 CentOS 上，为 Apache 配置 PHP 环境，并部署在香港服务器上。你的第一个决定将决定后续一切：选择 mod_php（嵌入式）还是 PHP-FPM（独立进程）。根据 W3Techs 截至 2025 年初的数据，在所有已知使用服务器端语言的网站中，有 74.5% 使用 PHP。本文提供两种方式的逐步命令和配置说明。

这张表展示了真实的取舍：mod_php 胜在简单，PHP-FPM 则在性能和隔离性上更有优势。在 Windows 上，你需要设置 PATH 变量并编辑 php.ini；在 Ubuntu 上，可以通过 libapache2-mod-php 安装。下面从选择开始展开。

关键要点

• 小型或简单环境适合使用 mod_php，高并发与多版本场景更适合 PHP-FPM。

• 在 Ubuntu 上通过 libapache2-mod-php 安装 mod_php，在 Windows 上通过设置 PATH 和 php.ini 完成配置。

• 使用 PHP-FPM 可以运行多个 PHP 版本，并在高流量下提升稳定性。

• 通过 phpinfo.php 测试配置，并查看错误日志以快速定位问题。

• 启用 OPcache 并合理设置 memory_limit，可提升性能并支撑更多工作进程。

配置 PHP 环境：mod_php 与 PHP-FPM 对比

你在 mod_php 与 PHP-FPM 之间的选择，将决定 Apache 处理 PHP 请求的方式。两种方法各有适用场景。理解它们的取舍，有助于为你的项目选对基础方案。

mod_php 概述

mod_php 直接将 PHP 解释器嵌入到 Apache 进程中。当有请求到来时，Apache 在内部执行 PHP 代码，而无需启动单独的程序。这种方式的配置相对简单：安装一个模块，启用它，然后重启 Apache，整个服务器在同一进程中完成所有工作。

性能测试表明，在中低访问量下，mod_php 的表现并不逊色。在 10–100 并发请求时，Apache + mod_php 与 Apache + PHP-FPM 的性能几乎相同，都能平稳地处理负载。不过，由于每个 Apache worker 都携带完整的 PHP 解释器，mod_php 每个请求的内存占用更高，当流量增加时可扩展性会受影响。

主要短板会在高负载下暴露出来：在 1,000 并发请求时，mod_php 只能维持基础表现，而其他方案会明显领先。对中小型网站来说，这一点通常并不严重；但对于高流量应用，你可能需要更适合扩展的方式。

PHP-FPM 概述

PHP-FPM（FastCGI Process Manager）将 PHP 作为独立服务运行，Apache 通过代理与该服务通信。这种分离带来了更好的隔离性：单个 PHP 进程崩溃不会拖垮整个 Web 服务器；你还可以同时运行多个 PHP 版本，每个版本独立配置。

基准测试显示了有趣的性能特点：在低并发时，PHP-FPM 与 mod_php 表现几乎相同；而在高并发下，差距逐渐扩大。Nginx + PHP-FPM 在 1,000 个并发连接时，处理的请求数约为基于 Apache 的方案的两倍。Apache + PHP-FPM 在原始吞吐量上与 mod_php 接近，但通过进程隔离获得更好的稳定性。

连接方式也很关键：Unix 套接字在多数测试中优于 TCP/IP。某次 500 连接的测试中，Unix 套接字达到了 2,613.18 req/s，而 TCP/IP 为 2,245.43 req/s，提升约 16.4%。在 60,000 用户压力下，Unix 套接字依然能无错误运行，而 TCP/IP 在该水平下失败。不过在 5,000 并发时，TCP 反而更稳定，零错误，而 Unix 套接字出现了 499 个错误。

当你为 Apache 配置 PHP 环境时，应结合自己的流量模式来选择方案。对于较小部署，mod_php 提供了更简单的路径；对于正在增长的应用，PHP-FPM 提供了更灵活和更安全的基础。下表对关键差异进行了总结。

在 Apache 上部署 mod_php

部署 mod_php 会将 PHP 直接嵌入 Apache 进程中。这种方式适合中小型网站，配置简单。Ubuntu 与 Windows 的具体步骤略有不同，但核心思路是一致的：安装模块、配置 Apache、重启服务。

Ubuntu/Debian 使用 libapache2-mod-php 安装

首先安装 mod_php 包。在终端中运行 sudo apt install libapache2-mod-php。该命令会同时安装 PHP 模块和 Apache 模块。安装完成后，通过 sudo a2enmod php8.x 启用模块（将 8.x 替换为你的 PHP 版本）。

接下来配置 Apache 的多进程模块（MPM）。mod_php 需要使用 prefork MPM。prefork 采用多进程单线程模型，每个子进程同时只处理一个连接，这种方式比其他 MPM 更耗内存，但与 mod_php 兼容。event MPM 在高并发下表现更好，但无法与 mod_php 一起使用。另外，prefork 不支持 HTTP/2，如果你计划使用现代 Web 协议，这一限制需要特别注意。

打开 Apache 配置文件。在 Ubuntu 中，该配置通常位于 /etc/apache2/mods-available/mpm_prefork.conf。取消加载 prefork 模块相关行的注释，然后找到 mpm_event_module 和 mpm_worker_module 的配置行，将它们注释掉。保存文件并重启 Apache。

完成这些步骤后，仍可能遇到一些常见错误。安装或升级软件包后，你可能会看到 500 服务器错误，尤其是从 CGI 封装切换过来的场景。通常的解决办法是改用 mod_php 或安装 PHP-FPM。如果日志提示缺少 mod_fcgid，可以通过 sudo apt install libapache2-mod-fcgid 安装并启用，然后重新检查配置。需要注意的是，mod_php 已逐渐被弃用，并不推荐用于共享主机环境，这种场景下更适合使用 PHP-FPM。

Windows 下通过 PATH 和 php.ini 配置

在 Windows 上的流程有所不同。首先从官方站点下载 PHP 压缩包，选择适用于 Apache + mod_php 的非线程安全版本，将压缩包解压到例如 C: 这样的目录中。

解压后，需要配置 php.ini。在 PHP 目录中找到 php.ini-development 文件，将其重命名为 php.ini，再用文本编辑器打开它。找到 extension_dir 设置，将其修改为正确路径，例如 extension_dir = "C:"。将 date.timezone 设置为你的时区，例如 date.timezone = "America/New_York"。如有需要，可以提高 memory_limit，比如设置为 memory_limit = 128M。这些设置可以避免常见问题，例如时区警告和内存限制错误。

Windows 环境中的常见错误包括由于 PHP 错误被隐藏而导致的空白页面。你可以在 PHP 代码中添加 error_reporting(E_ALL) 和 ini_set('display_errors', 1)，或者在 php.ini 中设置 error_log 来记录错误。如果 PHP 完全无法加载，可以通过 php --ini 命令检查实际加载的配置文件路径；必要时在注册表 HKEY_LOCAL_MACHINE 下设置 IniFilePath 键，指向包含 php.ini 的目录。

接着，把 PHP 目录添加到系统 PATH 中。打开系统属性，进入“环境变量”，找到 Path 变量，并加入 C:。这样 Apache 才能找到 PHP 可执行文件。你可以在命令行中运行 php -m 来验证是否正确加载了模块。

完成上述步骤后，重启 Apache：在 Ubuntu 上使用 sudo systemctl restart apache2，在 Windows 上则通过“服务”面板重启 Apache 服务。通过这些步骤，你就可以在不同平台上为 Apache 配置好 PHP 环境。

在 Apache 上部署 PHP-FPM

PHP-FPM 通过独立进程来处理 PHP 请求，这种方式在稳定性和可扩展性方面更有优势。当你需要更好的隔离，或者计划在同一台服务器上运行多个 PHP 版本时，可以选择这种方式来为 Apache 配置 PHP 环境。核心步骤包括安装 PHP-FPM 服务，以及配置 Apache 与之通信。

安装 PHP-FPM 并配置服务

在 Ubuntu 上，先通过 sudo apt install php8.x-fpm 安装 PHP-FPM（将 8.x 替换为真实版本）。包管理器会自动完成大部分基础配置。你还需要安装 libapache2-mod-fcgid 来启用 FastCGI 支持，可用 sudo apt install libapache2-mod-fcgid 完成。

Windows 用户则需要走另一条路径：同样从官网下载安装包并解压到例如 C: 的目录中。压缩包中包含 php-cgi.exe，它会作为 FastCGI 进程使用。Windows 不需要单独的 FPM 二进制文件，而是通过配置 Apache，在收到 PHP 请求时启动 CGI 进程。

安装完成后，配置 PHP-FPM 的进程池（pool）参数。Ubuntu 中，该配置文件通常位于 /etc/php/8.x/fpm/pool.d/www.conf（将 8.x 替换为真实版本）。它决定多少 worker 进程参与处理请求。对于高流量站点，可以将 pm.max_children 设置为至少 25，将 pm.max_requests 设置为至少 10000，以便 worker 定期重启。将模式设为 ondemand，可以在真正有请求时才启动 worker，在空闲时节省内存。

你还可以启用状态页来做监控。该端点会显示活动进程数、请求时长以及队列长度。当活动 worker 超过 max_children 的 80% 时，应触发告警。启用带 JIT 的 OPcache 可以减少单个 worker 的内存占用，从而在总内存不变的情况下提高 max_children 的上限。

安全性同样很重要。为每个站点单独创建 Linux 用户，例如通过 sudo useradd -m user1 创建用户，再通过 sudo usermod -a -G user1 www-data 将 Web 服务器用户加入相应用户组。确认家目录权限为 drwxr-x---，保证只有对应用户和其组可以访问。删除或禁用默认站点，避免对外暴露占位页面。

Apache 通过代理连接 PHP-FPM

Apache 需要通过代理模块与 PHP-FPM 通信。首先启用代理模块：运行 sudo a2enmod proxy 和 sudo a2enmod proxy_fcgi。如果需要透传 Authorization 头，可以选择启用 setenvif。然后通过 sudo systemctl reload apache2 重新加载配置，使用 apache2ctl -M | grep proxy_fcgi 检查模块是否启用。

同时需要将 Apache 切换到 event MPM。PHP-FPM 可以配合 event MPM 使用，而 event MPM 在高并发场景下比 prefork 更省资源、性能更好。你需要在 Apache 配置中禁用 mpm_prefork_module，启用 mpm_event_module，这样就能借助 event MPM 更高效地处理连接。

在虚拟主机配置中添加 ProxyPassMatch 指令，让 Apache 将 PHP 请求转发给 FPM 服务。示例配置如下：ProxyPassMatch ^/(.*\.php)$ fcgi://127.0.0.1:9000/var/www/your-site/$1，将路径替换为你的实际站点根目录。对于部署在同一台服务器上的场景，建议使用 Unix 套接字而非 TCP/IP，以减少开销。

你还应通过额外的指令加固配置安全性。例如使用 Options -Indexes 禁用目录浏览；禁止访问 .htaccess、.env、.log 等敏感文件；限制 HTTP 方法只允许应用实际需要的请求类型；在不需要 .htaccess 的目录中设置 AllowOverride None；防止在上传目录中执行 PHP 文件；通过 ServerSignature Off 和 ServerTokens Prod 隐藏 Apache 版本信息；并添加 X-Content-Type-Options: nosniff、X-Frame-Options: SAMEORIGIN 等安全响应头。

通过包管理器安装简单省事；从源代码编译则能获得更多版本控制和定制空间。大多数生产环境更适合使用包管理器方式，因为可以方便地自动获取安全更新。你可以根据对“控制力”与“便利性”的侧重来选择方式。

测试 PHP 配置

创建 phpinfo 文件

phpinfo() 函数会输出当前运行环境的完整快照，包括 PHP 版本、编译选项、已加载扩展、全局配置值和局部配置值。通过它，你可以快速确认线上环境中真正生效的配置，而不是依赖推测或某个单独配置文件。这比“猜测配置是否生效”要可靠得多。

在你的 Web 根目录中创建一个测试文件，命名为 phpinfo.php，内容只需一行：<?php phpinfo(); ?>。然后在浏览器中访问 http://your-server/phpinfo.php，你应该可以看到一个包含所有 PHP 设置的详细页面。

该输出特别有助于检查如下关键信息：

• 编译选项与扩展——用来识别缺失或冲突的模块

• PHP 版本与操作系统版本——用于对照已知兼容性问题

• 全局与本地配置值——帮助确认配置是在哪一层被修改的

• 路径信息——包括 include_path、extension_dir 等目录设置

• HTTP 头与 EGPCS 数据——展示服务器变量、环境变量、GET、POST、Cookie 和 Session 数据

需要注意的是，phpinfo() 在调试时非常有用，但也会暴露环境变量和版本号，甚至可能泄露类似 APP_KEY 这样的应用密钥，以及基于版本的已知漏洞信息。因此，应只在受控的非生产环境中使用，问题解决后立即删除该文件。

在生产环境中，可以遵循以下安全建议：

1. 使用身份验证或 IP 白名单限制访问，只允许授权人员查看

2. 在 php.ini 中通过 disable_functions 指令禁用 phpinfo()

3. 审计代码库并删除所有 phpinfo() 调用

4. 使用 Monolog 等结构化日志工具代替 phpinfo() 进行诊断

5. 通过漏洞扫描工具监测是否存在信息泄露

通过错误日志进一步验证

错误日志为排查问题提供了另一层信息，它可以记录 phpinfo() 无法展示的细节。你可以从多个日志字段中分析和追踪配置问题。

根据环境设置合理的错误级别。在开发和测试环境中，通常应使用 E_ALL 捕获所有问题；对于包含大量历史代码的生产环境，可以考虑使用 E_ALL & ~E_DEPRECATED & ~E_USER_DEPRECATED，以屏蔽废弃特性相关的提醒。可以在 php.ini 中通过 error_reporting = E_ALL 设置，也可以在运行时通过 error_reporting(E_ALL); 动态调整。

常见的坑包括：Ubuntu 上缺少 mpm_prefork、Windows 上 PATH 配置不正确、扩展模块加载失败等。当你遇到空白页面或 500 错误时，第一步应该检查错误日志，它通常会指明根本原因。

总体而言，mod_php 为小型项目提供了异常简单的路径，而 PHP-FPM 则为成长中的应用提供了更好的可扩展性。无论选择哪种方式，每次修改 PHP 配置后，都必须重启 Apache 才能生效。

在配置 PHP 环境时，建议启用 OPcache 以提升性能。这一优化可以让任务处理速度提升 30–40%，对复杂任务尤其明显。合理设置 memory_limit，让它同时匹配应用需求与可用内存。

例如，将限制调整为 64 MB 往往比较安全，同时相对于默认配置，可以支持大约两倍数量的 worker 进程。

使用 phpinfo() 来核对你的配置是否生效；对于更高级的场景，如运行多个 PHP 版本，可以参考官方 PHP 文档。先选定适合你项目的方案，然后结合上述步骤进行部署和验证。

常见问题（FAQ）

小型个人站点应该选择哪种方式？

对于个人站或小型网站，mod_php 通常是更合适的选择。你只需要安装一个模块、启用并重启 Apache，即可完成部署。在低到中等流量下，这种嵌入式方式足以胜任，而 PHP-FPM 额外的灵活性在此类项目中往往用不到。

为什么修改 PHP 配置后必须重启 Apache？

Apache 在启动时会加载 PHP 模块和配置。对 php.ini 或模块配置文件所做的修改，只有在服务器重启后才会重新加载并生效。在 Ubuntu 上可以使用 sudo systemctl restart apache2，在 Windows 上则通过服务管理面板重启 Apache。

能否在同一台服务器上运行多个 PHP 版本？

可以。要实现这一点，通常应使用 PHP-FPM。每个 PHP 版本以独立服务的方式运行，Apache 通过 ProxyPassMatch 等指令，将不同站点或目录的请求转发到对应的 PHP 版本。mod_php 一次只能加载一个版本。

配置完成后出现空白页面或 500 错误通常是什么原因？

在 Ubuntu 上常见原因包括缺少 mpm_prefork；在 Windows 上则多与 PATH 配置错误有关。第一步应查看错误日志；同时可在 PHP 文件中加入 error_reporting(E_ALL) 以显示隐藏错误，并确认是否加载了正确的模块。

如何确认 PHP 在配置完成后正常工作？

在 Web 根目录创建一个名为 phpinfo.php 的文件，内容为 <?php phpinfo(); ?>，然后在浏览器中访问该文件。如果你看到显示 PHP 版本、扩展和配置值的详细页面，就说明 PHP 工作正常。出于安全考虑，请在测试完成后删除该文件。