# mod_php förklarat: PHP i Apache-processen

> mod_php förklarat: så körs PHP som Apache-modul i webbservern, hur ni känner igen det, vad prefork och .htaccess har med saken att göra och varför php.net avråder.

Källa: https://phpsos.de/sv/php/mod-php-erklaert/  
Aktualitet: 2026-10-25  
Leverantör: PHP SOS, PHP-nödhjälp och serversäkerhet. Omedelbar hjälp via WhatsApp: https://wa.me/491736494914?text=Hej%20PHP%20SOS%2C%20vi%20beh%C3%B6ver%20hj%C3%A4lp%20med%20v%C3%A5r%20PHP-server.%20F%C3%B6retag%3A%20%E2%80%A6%20Webbplats%3A%20%E2%80%A6

**Kort sagt:** mod_php är PHP som modul i Apache-webbservern. Varje Apache-process innehåller då en fullständig PHP-tolk och kör PHP-koden själv; SAPI:t heter `apache2handler`. Det är enkelt att installera men binder PHP till Apache, kräver oftast prefork-MPM och medger knappt någon åtskillnad mellan webbplatser. PHP-manualen avråder från det för nya installationer, och vid PHP2Shell bedömer PHP-teamet risken som högst vid mod_php.

## Vad är mod_php?

Med mod_php laddar Apache PHP som egen modul i sina processer. Det finns ingen separat PHP-tjänst: När Apache ska leverera en `.php`-fil kör samma process som tog emot förfrågan också PHP-koden. Under många år var det standardsättet att driva PHP, och det är fortfarande utbrett på äldre servrar och i vissa Docker-avbilder.

Enligt PHP-manualen läser PHP som servermodul sin konfiguration bara en gång, vid webbserverns start. Ändringar i php.ini och uppdateringar av modulen verkar därför först efter en omstart av Apache.

Viktigt för förståelsen: Apache-processer lever länge. En process tar emot många anslutningar efter varandra innan den ersätts; hur många styr Apache-direktivet `MaxConnectionsPerChild`. Den inbyggda PHP-tolken förblir under tiden densamma. Den som byter ut biblioteket `libphp` på disken ändrar ingenting i de pågående processerna.

För ledning och projektansvariga kan det sammanfattas så: Med mod_php är webbserver och PHP en enhet. Den som rör det ena påverkar det andra. En PHP-uppdatering innebär en omstart av webbservern, ett fel i PHP körs med webbserverns rättigheter, och en åtskillnad mellan flera webbplatser på samma server är knappt möjlig.

## Hur kopplas mod_php in?

PHP-manualen visar inkopplingen i två steg: ladda modulen och bestämma vilka filer PHP ska bearbeta.

```apache
LoadModule php_module modules/libphp.so

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

Manualen rekommenderar `FilesMatch` med `SetHandler` i stället för bara `AddType`, så att uppladdade filer som `bild.php.jpg` inte körs som PHP. Under Debian och Ubuntu sköter paket som `libapache2-mod-php8.3` och kommandona `a2enmod` och `a2dismod` det arbetet.

Om mod_php är aktivt kan kontrolleras enbart läsande:

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

## Prefork, Thread Safety och resurser

Apache fördelar förfrågningar via en multi-processing-modul (MPM). Enligt PHP-manualen kräver mod_php `prefork`-MPM, om inte PHP har byggts med Zend Thread Safety (`--enable-zts`). De flesta distributionspaket är byggda utan Thread Safety.

Prefork betyder: en process per samtidig anslutning, och varje process bär en komplett PHP-tolk. Även förfrågningar efter bilder eller CSS-filer upptar alltså en process med PHP i bagaget. Det kostar minne och begränsar den belastning en server kan bära.

| Kännetecken | mod_php | PHP-FPM |
|---|---|---|
| Var körs PHP? | i varje Apache-process | i egen tjänst |
| Apache-MPM | oftast `prefork` | `event` möjligt |
| Användare per webbplats | nej, allt som Apache-användare | ja, per pool |
| Starta om PHP | bara tillsammans med Apache | oberoende av Apache |
| Inställningar per katalog | `php_value` i `.htaccess` | pool eller `.user.ini` |

Manualen rekommenderar därför för alla moderna installationer PHP-FPM med `mod_proxy_fcgi`: bättre resurshantering, processåtskillnad, omstart av PHP utan omstart av Apache och kompatibilitet med `event`-MPM, som är standard sedan Apache 2.4. Grunderna står under [PHP-FPM förklarat](https://phpsos.de/sv/php/php-fpm-erklaert/).

## Inställningar med .htaccess, php_value och php_admin_value

Med mod_php kan PHP-inställningar sättas direkt i Apache-konfigurationen. Manualen skiljer därvid mellan ändringslägen: Poster med `INI_PERDIR` får stå i php.ini, `.htaccess` eller `httpd.conf`, poster med `INI_SYSTEM` bara i php.ini eller `httpd.conf`.

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

# Möjligt i .htaccess, men kan skrivas över av applikationen
php_value max_execution_time 60
```

`php_admin_value` och `php_admin_flag` är bara tillåtna i serverkonfigurationen, inte i `.htaccess`. Just den här skillnaden är viktig för övergångsåtgärderna kring PHP2Shell, eftersom värden som `session.upload_progress.enabled` inte får kunna återställas av applikationen.

## mod_php och PHP2Shell: varför risken är högst

PHP-teamet bedömer risken från PHP2Shell som högst vid mod_php: Där visades en exploit innan någon applikationskod alls körs. Säkerhetsplugin eller kontroller i CMS:et kommer därmed för sent. Dessutom körs PHP vid mod_php med webbserverns rättigheter och i webbserverns minne. Den utförliga bedömningen står under [Varför mod_php bär den högsta risken](https://phpsos.de/sv/php2shell/mod-php-risiko/).

För driftansvariga gäller därför:

1. Uppdatera PHP-modulen till 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 respektive en bekräftad backport.
2. Starta om Apache fullständigt, inte bara ladda om, och kontrollera processernas starttid.
3. Sätt övergångsvärden med `php_admin_value` i serverkonfigurationen om uppdateringen ännu inte är möjlig.
4. Planera därefter bytet till PHP-FPM, som beskrivs under [Säkra Apache med mod_php](https://phpsos.de/sv/server/apache-mod-php/).

## Hur hjälper PHP SOS konkret?

- **Känna igen:** Vi kontrollerar på vilka servrar mod_php körs, med vilket MPM och från vilken paketkälla.
- **Patcha:** Vi uppdaterar PHP-modulen, startar om Apache fullständigt och styrker läget.
- **Säkra övergången:** Där uppdateringen är blockerad sätter vi åtgärderna från php.net låsta i serverkonfigurationen.
- **Ställa om:** Inom ramen för [serverhärdning](https://phpsos.de/sv/leistungen/server-haertung/) migrerar vi testat till PHP-FPM med egna pooler.


## Vanliga frågor

**Varför heter det mod_php när modulen heter php_module?**  
mod_php är det vardagliga namnet på PHP som Apache-modul. I konfigurationen laddas det med LoadModule; PHP-manualen anger som exempel LoadModule php_module modules/libphp.so. Äldre versioner använde namn som php7_module eller php5_module.

**Varför kräver mod_php prefork-MPM?**  
Enligt PHP-manualen kräver mod_php prefork-MPM, om inte PHP har byggts med Zend Thread Safety. De flesta distributionspaket är byggda utan Thread Safety. Prefork startar en egen process för varje samtidig anslutning, vilket kräver mer minne.

**Fungerar php_value-rader i .htaccess även med PHP-FPM?**  
Nej. php_value och php_flag i .htaccess är Apache-direktiv från PHP-modulen och verkar bara med mod_php. Under PHP-FPM hör sådana inställningar hemma i poolen eller, för tillåtna värden, i en .user.ini.

**Måste jag avskaffa mod_php genast?**  
Först kommer uppdateringen av PHP med fullständig omstart av Apache. Bytet till PHP-FPM är därefter meningsfullt men bör planeras och testas. Det täpper inte till PHP2Shell, eftersom PHP-FPM också berörs.

## Källor

- [PHP-manualen: Apache 2 under Unix](https://www.php.net/manual/en/install.unix.apache2.php)
- [PHP-manualen: INI-ändringslägen](https://www.php.net/manual/en/configuration.changes.modes.php)
- [Apache-dokumentationen](https://httpd.apache.org/docs/)
- [php.net: säkerhetsmeddelanden](https://www.php.net/)