# mod_php forklaret: PHP i Apache-processen

> mod_php forklaret: sådan kører PHP som Apache-modul, hvordan I genkender det, hvad prefork og .htaccess har med det at gøre, og hvorfor php.net fraråder.

Kilde: https://phpsos.de/da/php/mod-php-erklaert/  
Status: 25.10.2026  
Udbyder: PHP SOS, PHP-nødhjælp og serversikkerhed. Akut hjælp på WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20har%20brug%20for%20hj%C3%A6lp%20med%20vores%20PHP-server.%20Firma%3A%20%E2%80%A6%20Website%3A%20%E2%80%A6

**Kort sagt:** mod_php er PHP som modul i Apache-webserveren. Hver Apache-proces indeholder så en komplet PHP-fortolker og udfører selv PHP-koden; SAPI'en hedder `apache2handler`. Det er enkelt at sætte op, men binder PHP til Apache, kræver som regel prefork-MPM og tillader næppe adskillelse mellem websites. PHP-manualen fraråder det til nye installationer, og ved PHP2Shell vurderer PHP-teamet risikoen ved mod_php som den højeste.

## Hvad er mod_php?

Ved mod_php indlæser Apache PHP som eget modul i sine processer. Der findes ingen adskilt PHP-tjeneste: Når Apache skal levere en `.php`-fil, udfører den samme proces, som har modtaget forespørgslen, også PHP-koden. I mange år var det standardvejen til at drive PHP, og den er den dag i dag udbredt på ældre servere og i nogle Docker-images.

Ifølge PHP-manualen læser PHP som servermodul sin konfiguration kun én gang, når webserveren starter. Ændringer i php.ini og opdateringer af modulet virker derfor først efter en genstart af Apache.

Vigtigt for forståelsen: Apache-processer lever længe. En proces modtager mange forbindelser efter hinanden, før den erstattes; hvor mange, styrer Apache-direktivet `MaxConnectionsPerChild`. Den indlejrede PHP-fortolker forbliver i den tid den samme. Den, der udskifter biblioteket `libphp` på disken, ændrer intet ved de kørende processer.

For direktionen og projektansvarlige kan det opsummeres sådan: Ved mod_php er webserver og PHP én enhed. Den, der rører ved det ene, påvirker det andet. En PHP-opdatering betyder en genstart af webserveren, en fejl i PHP kører med webserverens rettigheder, og en adskillelse mellem flere websites på den samme server er næppe mulig.

## Hvordan indbindes mod_php?

PHP-manualen viser indbindingen i to trin: indlæse modulet og fastlægge, hvilke filer PHP skal behandle.

```apache
LoadModule php_module modules/libphp.so

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

Manualen anbefaler `FilesMatch` med `SetHandler` frem for blot `AddType`, for at uploadede filer som `bild.php.jpg` ikke udføres som PHP. Under Debian og Ubuntu overtager pakker som `libapache2-mod-php8.3` og kommandoerne `a2enmod` og `a2dismod` dette arbejde.

Om mod_php er aktivt, kan kontrolleres læsende:

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

## Prefork, Thread Safety og ressourcer

Apache fordeler forespørgsler via et multi-processing-modul (MPM). Ifølge PHP-manualen kræver mod_php `prefork`-MPM, medmindre PHP er bygget med Zend Thread Safety (`--enable-zts`). De fleste distributionspakker er bygget uden Thread Safety.

Prefork betyder: én proces pr. samtidig forbindelse, og hver proces bærer en komplet PHP-fortolker. Også forespørgsler på billeder eller CSS-filer optager dermed en proces med PHP i bagagen. Det koster hukommelse og begrænser den belastning, en server kan bære.

| Kendetegn | mod_php | PHP-FPM |
|---|---|---|
| Hvor kører PHP? | i hver Apache-proces | i egen tjeneste |
| Apache-MPM | som regel `prefork` | `event` muligt |
| Bruger pr. website | nej, alt som Apache-bruger | ja, pr. pool |
| Genstarte PHP | kun sammen med Apache | uafhængigt af Apache |
| Indstillinger pr. mappe | `php_value` i `.htaccess` | pool eller `.user.ini` |

Manualen anbefaler derfor til alle moderne installationer PHP-FPM med `mod_proxy_fcgi`: bedre ressourcestyring, procesadskillelse, genstart af PHP uden Apache-genstart og kompatibilitet med `event`-MPM, som siden Apache 2.4 er standard. Grundlaget står under [PHP-FPM forklaret](https://phpsos.de/da/php/php-fpm-erklaert/).

## Indstillinger med .htaccess, php_value og php_admin_value

Med mod_php kan PHP-indstillinger sættes direkte i Apache-konfigurationen. Manualen skelner herved mellem ændringstilstande: Poster med `INI_PERDIR` må stå i php.ini, `.htaccess` eller `httpd.conf`, poster med `INI_SYSTEM` kun i php.ini eller `httpd.conf`.

```apache
# I VirtualHost-konfigurationen: låst for applikationen
php_admin_flag  display_errors off
php_admin_value upload_max_filesize 24M

# Muligt i .htaccess, men kan overskrives af applikationen
php_value max_execution_time 60
```

`php_admin_value` og `php_admin_flag` er kun tilladt i serverkonfigurationen, ikke i `.htaccess`. Netop denne skelnen er vigtig ved overgangsforanstaltningerne til PHP2Shell, fordi værdier som `session.upload_progress.enabled` ikke må kunne nulstilles af applikationen.

## mod_php og PHP2Shell: hvorfor risikoen er højest

PHP-teamet vurderer risikoen ved PHP2Shell som højest for mod_php: Dér blev en exploit vist, før der overhovedet kører applikationskode. Sikkerhedsplugins eller kontroller i CMS'et kommer dermed for sent. Hertil kommer, at PHP ved mod_php kører med webserverens rettigheder og i dens hukommelse. Den udførlige vurdering står under [Hvorfor mod_php bærer den højeste risiko](https://phpsos.de/da/php2shell/mod-php-risiko/).

For driftsansvarlige gælder derfor:

1. Opdatér PHP-modulet til 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 hhv. en bekræftet backport.
2. Genstart Apache fuldstændigt, ikke blot reload, og kontrollér processernes starttidspunkt.
3. Sæt overgangsværdier via `php_admin_value` i serverkonfigurationen, hvis opdateringen endnu ikke er mulig.
4. Planlæg derefter skiftet til PHP-FPM, som beskrevet under [Sikring af Apache med mod_php](https://phpsos.de/da/server/apache-mod-php/).

## Hvordan hjælper PHP SOS konkret?

- **Genkende:** Vi kontrollerer, på hvilke servere mod_php kører, med hvilket MPM og fra hvilken pakkekilde.
- **Patche:** Vi opdaterer PHP-modulet, genstarter Apache fuldstændigt og dokumenterer status.
- **Sikre overgangen:** Hvor opdateringen er blokeret, sætter vi foranstaltningerne fra php.net låst i serverkonfigurationen.
- **Omstille:** Som led i [serverhærdningen](https://phpsos.de/da/leistungen/server-haertung/) migrerer vi testet til PHP-FPM med egne pools.


## Ofte stillede spørgsmål

**Hvorfor hedder det mod_php, når modulet hedder php_module?**  
mod_php er det daglige navn for PHP som Apache-modul. I konfigurationen indlæses det med LoadModule; PHP-manualen nævner som eksempel LoadModule php_module modules/libphp.so. Ældre versioner brugte navne som php7_module eller php5_module.

**Hvorfor kræver mod_php prefork-MPM?**  
Ifølge PHP-manualen kræver mod_php prefork-MPM, medmindre PHP er bygget med Zend Thread Safety. De fleste distributionspakker er bygget uden Thread Safety. Prefork starter en egen proces for hver samtidig forbindelse, hvilket kræver mere hukommelse.

**Virker php_value-linjer i .htaccess også med PHP-FPM?**  
Nej. php_value og php_flag i .htaccess er Apache-direktiver fra PHP-modulet og virker kun med mod_php. Under PHP-FPM hører sådanne indstillinger hjemme i poolen eller, for tilladte værdier, i en .user.ini.

**Skal jeg afskaffe mod_php med det samme?**  
Først kommer opdateringen af PHP med fuldstændig genstart af Apache. Skiftet til PHP-FPM er derefter fornuftigt, men bør planlægges og testes. Det lukker ikke PHP2Shell, fordi PHP-FPM også er berørt.

## Kilder

- [PHP-manualen: Apache 2 under Unix](https://www.php.net/manual/en/install.unix.apache2.php)
- [PHP-manualen: INI-ændringstilstande](https://www.php.net/manual/en/configuration.changes.modes.php)
- [Apache-dokumentation](https://httpd.apache.org/docs/)
- [php.net: Sikkerhedsmeddelelser](https://www.php.net/)