# mod_php explicado: PHP dentro del proceso de Apache

> mod_php explicado: cómo PHP funciona como módulo dentro de Apache, cómo reconocerlo, qué tienen que ver prefork y .htaccess y por qué php.net lo desaconseja.

Fuente: https://phpsos.de/es/php/mod-php-erklaert/  
Actualizado: 25/10/2026  
Proveedor: PHP SOS, Ayuda de emergencia para PHP y seguridad de servidores. Ayuda inmediata por WhatsApp: https://wa.me/491736494914?text=Hola%20PHP%20SOS%2C%20necesitamos%20ayuda%20con%20nuestro%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Sitio%20web%3A%20%E2%80%A6

**En resumen:** mod_php es PHP como módulo del servidor web Apache. Cada proceso de Apache contiene entonces un intérprete de PHP completo y ejecuta él mismo el código PHP; la SAPI se llama `apache2handler`. Es fácil de configurar, pero ata PHP a Apache, suele exigir el MPM prefork y apenas permite separar unos sitios web de otros. El manual de PHP lo desaconseja para instalaciones nuevas y, en PHP2Shell, el equipo de PHP considera que el riesgo es mayor en mod_php.

## ¿Qué es mod_php?

En mod_php, Apache carga PHP como módulo propio en sus procesos. No hay un servicio PHP independiente: cuando Apache debe entregar un archivo `.php`, el mismo proceso que aceptó la petición ejecuta también el código PHP. Durante muchos años fue la forma habitual de ejecutar PHP y sigue extendida hoy en servidores antiguos y en algunas imágenes Docker.

Según el manual de PHP, como módulo de servidor, PHP lee su configuración solo una vez, al iniciar el servidor web. Por eso, los cambios en el php.ini y las actualizaciones del módulo solo surten efecto tras reiniciar Apache.

Importante para entenderlo: los procesos de Apache viven mucho tiempo. Un proceso atiende muchas conexiones seguidas antes de ser sustituido; cuántas, lo regula la directiva de Apache `MaxConnectionsPerChild`. El intérprete de PHP incorporado sigue siendo el mismo durante ese tiempo. Quien sustituye la biblioteca `libphp` en el disco no cambia nada en los procesos en ejecución.

Para la dirección y los responsables de proyectos puede resumirse así: en mod_php, el servidor web y PHP son una unidad. Tocar uno afecta al otro. Una actualización de PHP implica reiniciar el servidor web, un fallo en PHP se ejecuta con los permisos del servidor web y separar varios sitios web en el mismo servidor es casi imposible.

## ¿Cómo se integra mod_php?

El manual de PHP muestra la integración en dos pasos: cargar el módulo y definir qué archivos debe procesar PHP.

```apache
LoadModule php_module modules/libphp.so

<FilesMatch \.php$>
    SetHandler application/x-httpd-php
</FilesMatch>
```

El manual recomienda `FilesMatch` con `SetHandler` en lugar de solo `AddType`, para que los archivos subidos como `bild.php.jpg` no se ejecuten como PHP. En Debian y Ubuntu, paquetes como `libapache2-mod-php8.3` y los comandos `a2enmod` y `a2dismod` se encargan de este trabajo.

Si mod_php está activo se puede comprobar en modo lectura:

```bash
apachectl -M 2>/dev/null | grep -i php    # Debian/Ubuntu
httpd -M 2>/dev/null | grep -i php        # familia RHEL
apachectl -V | grep -i mpm               # MPM activo (prefork, worker, event)
```

## Prefork, Thread Safety y recursos

Apache reparte las peticiones mediante un módulo de multiprocesamiento (MPM). Según el manual de PHP, mod_php necesita el MPM `prefork`, salvo que PHP se haya compilado con Zend Thread Safety (`--enable-zts`). La mayoría de los paquetes de las distribuciones se compilan sin Thread Safety.

Prefork significa: un proceso por conexión simultánea y cada proceso lleva un intérprete de PHP completo. Incluso las peticiones de imágenes o de archivos CSS ocupan así un proceso con PHP a cuestas. Esto cuesta memoria y limita la carga que un servidor puede soportar.

| Característica | mod_php | PHP-FPM |
|---|---|---|
| ¿Dónde se ejecuta PHP? | en cada proceso de Apache | en un servicio propio |
| MPM de Apache | normalmente `prefork` | `event` posible |
| Usuario por sitio web | no, todo como usuario de Apache | sí, por pool |
| Reiniciar PHP | solo junto con Apache | independiente de Apache |
| Ajustes por directorio | `php_value` en `.htaccess` | pool o `.user.ini` |

Por eso, el manual recomienda para todas las instalaciones modernas PHP-FPM con `mod_proxy_fcgi`: mejor gestión de recursos, separación de procesos, reinicio de PHP sin reiniciar Apache y compatibilidad con el MPM `event`, que es el predeterminado desde Apache 2.4. Los fundamentos están en [PHP-FPM explicado](https://phpsos.de/es/php/php-fpm-erklaert/).

## Ajustes con .htaccess, php_value y php_admin_value

Con mod_php, los ajustes de PHP pueden fijarse directamente en la configuración de Apache. El manual distingue aquí modos de modificación: las entradas con `INI_PERDIR` pueden figurar en php.ini, `.htaccess` o `httpd.conf`; las entradas con `INI_SYSTEM`, solo en php.ini o `httpd.conf`.

```apache
# En la configuración del VirtualHost: bloqueado para la aplicación
php_admin_flag  display_errors off
php_admin_value upload_max_filesize 24M

# Posible en .htaccess, pero la aplicación puede sobrescribirlo
php_value max_execution_time 60
```

`php_admin_value` y `php_admin_flag` solo están permitidos en la configuración del servidor, no en `.htaccess`. Justo esta distinción es importante en las medidas provisionales frente a PHP2Shell, porque valores como `session.upload_progress.enabled` no deben poder ser restablecidos por la aplicación.

## mod_php y PHP2Shell: por qué el riesgo es el mayor

El equipo de PHP considera que el riesgo por PHP2Shell es mayor en mod_php: allí se demostró un exploit antes de que se ejecute siquiera código de la aplicación. Los plugins de seguridad o las comprobaciones en el CMS llegan, por tanto, demasiado tarde. A ello se suma que, en mod_php, PHP se ejecuta con los permisos y en la memoria del servidor web. La valoración detallada está en [Por qué mod_php soporta el mayor riesgo](https://phpsos.de/es/php2shell/mod-php-risiko/).

Para los operadores rige, por tanto:

1. Actualizar el módulo de PHP a 8.5.12, 8.4.27, 8.3.36 o 8.2.35, o a un backport confirmado.
2. Reiniciar Apache por completo, no solo recargarlo, y comprobar la hora de inicio de los procesos.
3. Fijar los valores provisionales mediante `php_admin_value` en la configuración del servidor si la actualización todavía no es posible.
4. Después, planificar el cambio a PHP-FPM, como se describe en [Proteger Apache con mod_php](https://phpsos.de/es/server/apache-mod-php/).

## ¿Cómo ayuda PHP SOS en concreto?

- **Reconocer:** comprobamos en qué servidores se ejecuta mod_php, con qué MPM y desde qué origen de paquetes.
- **Parchear:** actualizamos el módulo de PHP, reiniciamos Apache por completo y demostramos el estado.
- **Asegurar la transición:** donde la actualización está bloqueada, fijamos las medidas de php.net de forma bloqueada en la configuración del servidor.
- **Migrar:** en el marco del [refuerzo del servidor](https://phpsos.de/es/leistungen/server-haertung/) migramos, con pruebas, a PHP-FPM con pools propios.


## Preguntas frecuentes

**¿Por qué se llama mod_php si el módulo se llama php_module?**  
mod_php es el nombre coloquial de PHP como módulo de Apache. En la configuración se carga con LoadModule; el manual de PHP da como ejemplo LoadModule php_module modules/libphp.so. Las versiones anteriores utilizaban nombres como php7_module o php5_module.

**¿Por qué necesita mod_php el MPM prefork?**  
Según el manual de PHP, mod_php necesita el MPM prefork, salvo que PHP se haya compilado con Zend Thread Safety. La mayoría de los paquetes de las distribuciones se compilan sin Thread Safety. Prefork inicia un proceso propio por cada conexión simultánea, lo que requiere más memoria.

**¿Funcionan las líneas php_value de .htaccess también con PHP-FPM?**  
No. php_value y php_flag en .htaccess son directivas de Apache del módulo de PHP y solo funcionan con mod_php. Con PHP-FPM, esos ajustes van en el pool o, para los valores permitidos, en un .user.ini.

**¿Debo eliminar mod_php de inmediato?**  
Lo primero es la actualización de PHP con reinicio completo de Apache. El cambio a PHP-FPM es después recomendable, pero debe planificarse y probarse. No cierra PHP2Shell, porque PHP-FPM también está afectado.

## Fuentes

- [Manual de PHP: Apache 2 en Unix](https://www.php.net/manual/en/install.unix.apache2.php)
- [Manual de PHP: modos de modificación de INI](https://www.php.net/manual/en/configuration.changes.modes.php)
- [Documentación de Apache](https://httpd.apache.org/docs/)
- [php.net: avisos de seguridad](https://www.php.net/)