# mod_php spiegato: PHP nel processo Apache

> mod_php spiegato: come PHP gira come modulo Apache nel server web, come riconoscerlo, che cosa c'entrano prefork e .htaccess e perché php.net lo sconsiglia.

Fonte: https://phpsos.de/it/php/mod-php-erklaert/  
Stato: 25/10/2026  
Fornitore: PHP SOS, Assistenza di emergenza PHP e sicurezza dei server. Assistenza immediata su WhatsApp: https://wa.me/491736494914?text=Buongiorno%20PHP%20SOS%2C%20abbiamo%20bisogno%20di%20aiuto%20con%20il%20nostro%20server%20PHP.%20Azienda%3A%20%E2%80%A6%20Sito%20web%3A%20%E2%80%A6

**In breve:** mod_php è PHP come modulo nel server web Apache. Ogni processo Apache contiene allora un interprete PHP completo ed esegue da solo il codice PHP; la SAPI si chiama `apache2handler`. È semplice da configurare, ma lega PHP ad Apache, richiede di solito il MPM prefork e consente a stento la separazione tra siti web. Il manuale PHP lo sconsiglia per le nuove installazioni e con PHP2Shell il team PHP classifica per mod_php il rischio più alto.

## Che cos'è mod_php?

Con mod_php Apache carica PHP come modulo proprio nei suoi processi. Non esiste un servizio PHP separato: quando Apache deve consegnare un file `.php`, lo stesso processo che ha accettato la richiesta esegue anche il codice PHP. Per molti anni è stato il modo standard di gestire PHP ed è tuttora diffuso sui server meno recenti e in alcune immagini Docker.

Secondo il manuale PHP, come modulo del server PHP legge la propria configurazione una sola volta, all'avvio del server web. Le modifiche al php.ini e gli aggiornamenti del modulo hanno quindi effetto solo dopo un riavvio di Apache.

Importante per capire: i processi Apache vivono a lungo. Un processo accetta una dopo l'altra molte connessioni prima di essere sostituito; quante lo regola la direttiva Apache `MaxConnectionsPerChild`. L'interprete PHP incorporato in questo periodo resta lo stesso. Chi sostituisce sul disco la libreria `libphp` non cambia nulla nei processi in esecuzione.

Per la direzione e i responsabili di progetto si può riassumere così: con mod_php server web e PHP sono un'unità. Chi tocca l'uno coinvolge l'altro. Un aggiornamento di PHP significa un riavvio del server web, un errore in PHP gira con i permessi del server web e una separazione tra più siti web sullo stesso server è appena possibile.

## Come si integra mod_php?

Il manuale PHP mostra l'integrazione in due passaggi: caricare il modulo e stabilire quali file PHP debba elaborare.

```apache
LoadModule php_module modules/libphp.so

<FilesMatch \.php$>
    SetHandler application/x-httpd-php
</FilesMatch>
```

Il manuale raccomanda `FilesMatch` con `SetHandler` invece del solo `AddType`, in modo che file caricati come `bild.php.jpg` non vengano eseguiti come PHP. Su Debian e Ubuntu pacchetti come `libapache2-mod-php8.3` e i comandi `a2enmod` e `a2dismod` svolgono questo lavoro.

Se mod_php sia attivo si può verificare in sola lettura:

```bash
apachectl -M 2>/dev/null | grep -i php    # Debian/Ubuntu
httpd -M 2>/dev/null | grep -i php        # famiglia RHEL
apachectl -V | grep -i mpm               # MPM attivo (prefork, worker, event)
```

## Prefork, Thread Safety e risorse

Apache distribuisce le richieste tramite un modulo di multi-processing (MPM). Secondo il manuale PHP, mod_php richiede il MPM `prefork`, a meno che PHP non sia stato compilato con Zend Thread Safety (`--enable-zts`). La maggior parte dei pacchetti delle distribuzioni è compilata senza Thread Safety.

Prefork significa: un processo per connessione simultanea, e ogni processo porta con sé un interprete PHP completo. Anche le richieste di immagini o file CSS occupano così un processo con PHP al seguito. Ciò costa memoria e limita il carico che un server può sostenere.

| Caratteristica | mod_php | PHP-FPM |
|---|---|---|
| Dove gira PHP? | in ogni processo Apache | in un servizio proprio |
| MPM di Apache | di solito `prefork` | `event` possibile |
| Utente per ogni sito | no, tutto come utente Apache | sì, per ogni pool |
| Riavviare PHP | solo con Apache | indipendente da Apache |
| Impostazioni per directory | `php_value` in `.htaccess` | pool o `.user.ini` |

Il manuale raccomanda perciò per tutte le installazioni moderne PHP-FPM con `mod_proxy_fcgi`: migliore gestione delle risorse, separazione dei processi, riavvio di PHP senza riavviare Apache e compatibilità con il MPM `event`, che è lo standard da Apache 2.4. Le basi sono in [PHP-FPM spiegato](https://phpsos.de/it/php/php-fpm-erklaert/).

## Impostazioni con .htaccess, php_value e php_admin_value

Con mod_php le impostazioni PHP si possono definire direttamente nella configurazione di Apache. Il manuale distingue qui le modalità di modifica: le voci con `INI_PERDIR` possono stare in php.ini, `.htaccess` o `httpd.conf`, quelle con `INI_SYSTEM` solo in php.ini o `httpd.conf`.

```apache
# Nella configurazione del VirtualHost: bloccato per l'applicazione
php_admin_flag  display_errors off
php_admin_value upload_max_filesize 24M

# Possibile in .htaccess, ma sovrascrivibile dall'applicazione
php_value max_execution_time 60
```

`php_admin_value` e `php_admin_flag` sono consentiti solo nella configurazione del server, non in `.htaccess`. Proprio questa distinzione è importante per le misure transitorie contro PHP2Shell, perché valori come `session.upload_progress.enabled` non devono poter essere reimpostati dall'applicazione.

## mod_php e PHP2Shell: perché il rischio è il più alto

Il team PHP classifica per mod_php il rischio maggiore legato a PHP2Shell: lì è stato dimostrato un exploit prima ancora che giri qualsiasi codice dell'applicazione. I plugin di sicurezza o i controlli nel CMS arrivano quindi troppo tardi. Si aggiunge che con mod_php PHP gira con i permessi e nella memoria del server web. La classificazione dettagliata è in [Perché mod_php porta il rischio più alto](https://phpsos.de/it/php2shell/mod-php-risiko/).

Per chi gestisce i sistemi vale perciò:

1. Aggiornare il modulo PHP a 8.5.12, 8.4.27, 8.3.36 o 8.2.35 oppure a un backport confermato.
2. Riavviare Apache completamente, non solo ricaricarlo, e controllare l'ora di avvio dei processi.
3. Impostare i valori transitori tramite `php_admin_value` nella configurazione del server, se l'aggiornamento non è ancora possibile.
4. Poi pianificare il passaggio a PHP-FPM, come descritto in [Mettere in sicurezza Apache con mod_php](https://phpsos.de/it/server/apache-mod-php/).

## Come aiuta concretamente PHP SOS?

- **Riconoscere:** verifichiamo su quali server gira mod_php, con quale MPM e da quale repository di pacchetti.
- **Aggiornare:** aggiorniamo il modulo PHP, riavviamo Apache completamente e documentiamo lo stato.
- **Mettere in sicurezza la fase transitoria:** dove l'aggiornamento è bloccato, impostiamo le misure di php.net in forma bloccata nella configurazione del server.
- **Migrare:** nell'ambito dell'[hardening del server](https://phpsos.de/it/leistungen/server-haertung/) migriamo, con test, a PHP-FPM con pool propri.


## Domande frequenti

**Perché si chiama mod_php se il modulo si chiama php_module?**  
mod_php è il nome colloquiale di PHP come modulo Apache. Nella configurazione viene caricato con LoadModule; il manuale PHP cita come esempio LoadModule php_module modules/libphp.so. Le versioni più vecchie usavano nomi come php7_module o php5_module.

**Perché mod_php richiede il MPM prefork?**  
Secondo il manuale PHP, mod_php richiede il MPM prefork, a meno che PHP non sia stato compilato con Zend Thread Safety. La maggior parte dei pacchetti delle distribuzioni è compilata senza Thread Safety. Prefork avvia un processo proprio per ogni connessione simultanea, il che richiede più memoria.

**Le righe php_value in .htaccess funzionano anche con PHP-FPM?**  
No. php_value e php_flag in .htaccess sono direttive Apache del modulo PHP e hanno effetto solo con mod_php. Con PHP-FPM tali impostazioni vanno nel pool oppure, per i valori consentiti, in un .user.ini.

**Devo abbandonare subito mod_php?**  
Prima viene l'aggiornamento di PHP con riavvio completo di Apache. Il passaggio a PHP-FPM è sensato dopo, ma va pianificato e testato. Non chiude PHP2Shell, perché anche PHP-FPM è interessato.

## Fonti

- [Manuale PHP: Apache 2 su Unix](https://www.php.net/manual/en/install.unix.apache2.php)
- [Manuale PHP: modalità di modifica INI](https://www.php.net/manual/en/configuration.changes.modes.php)
- [Documentazione di Apache](https://httpd.apache.org/docs/)
- [php.net: avvisi di sicurezza](https://www.php.net/)
