# mod_php objašnjen: PHP u Apacheovu procesu

> mod_php objašnjen: kako PHP radi kao Apache modul u web-poslužitelju, kako ga prepoznati, kakve veze imaju prefork i .htaccess i zašto php.net odvraća.

Izvor: https://phpsos.de/hr/php/mod-php-erklaert/  
Stanje: 25.10.2026  
Pružatelj: PHP SOS, PHP hitna pomoć i sigurnost poslužitelja. Hitna pomoć putem WhatsAppa: https://wa.me/491736494914?text=Pozdrav%20PHP%20SOS%2C%20trebamo%20pomo%C4%87%20s%20na%C5%A1im%20PHP%20poslu%C5%BEiteljem.%20Tvrtka%3A%20%E2%80%A6%20Web-stranica%3A%20%E2%80%A6

**Ukratko:** mod_php je PHP kao modul u Apache web-poslužitelju. Svaki Apache proces tada sadrži potpun PHP interpreter i sam izvršava PHP kod; SAPI se zove `apache2handler`. To je jednostavno postaviti, ali PHP veže uz Apache, najčešće traži prefork MPM i jedva dopušta razdvajanje web-stranica. PHP priručnik za nove instalacije od toga odvraća, a kod PHP2Shella PHP tim rizik kod mod_php-a ocjenjuje najvišim.

## Što je mod_php?

Kod mod_php-a Apache PHP učitava kao zaseban modul u svoje procese. Nema odvojene PHP usluge: kada Apache treba isporučiti `.php` datoteku, isti proces koji je primio zahtjev izvršava i PHP kod. Dugi niz godina to je bio standardni način pokretanja PHP-a i do danas je raširen na starijim poslužiteljima i u nekim Docker slikama.

Prema PHP priručniku PHP kao modul poslužitelja svoju konfiguraciju čita samo jednom, pri pokretanju web-poslužitelja. Izmjene u php.ini i ažuriranja modula zato djeluju tek nakon ponovnog pokretanja Apachea.

Važno za razumijevanje: Apache procesi žive dugo. Jedan proces redom prima mnogo veza prije nego što se zamijeni; koliko, regulira Apache direktiva `MaxConnectionsPerChild`. Ugrađeni PHP interpreter u tom vremenu ostaje isti. Tko zamijeni biblioteku `libphp` na disku, ne mijenja ništa na pokrenutim procesima.

Za upravu i voditelje projekata to se može sažeti ovako: kod mod_php-a web-poslužitelj i PHP čine jedinstvo. Tko dira jedno, pogađa drugo. PHP ažuriranje znači ponovno pokretanje web-poslužitelja, pogreška u PHP-u izvršava se s pravima web-poslužitelja, a razdvajanje više web-stranica na istom poslužitelju jedva je moguće.

## Kako se mod_php uključuje?

PHP priručnik prikazuje uključivanje u dva koraka: učitati modul i odrediti koje datoteke PHP treba obrađivati.

```apache
LoadModule php_module modules/libphp.so

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

Priručnik preporučuje `FilesMatch` sa `SetHandler` umjesto samo `AddType`, kako se učitane datoteke poput `bild.php.jpg` ne bi izvršavale kao PHP. Na Debianu i Ubuntuu taj posao preuzimaju paketi poput `libapache2-mod-php8.3` te naredbe `a2enmod` i `a2dismod`.

Je li mod_php aktivan, može se provjeriti samo čitanjem:

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

## Prefork, Thread Safety i resursi

Apache zahtjeve raspoređuje putem modula za višeprocesiranje (MPM). Prema PHP priručniku mod_php treba `prefork` MPM ako PHP nije izgrađen sa Zend Thread Safety (`--enable-zts`). Većina paketa distribucija izgrađena je bez Thread Safety.

Prefork znači: jedan proces po istodobnoj vezi i svaki proces nosi kompletan PHP interpreter. Čak i zahtjevi za slikama ili CSS datotekama tako zauzimaju proces s PHP-om u prtljazi. To košta memoriju i ograničava opterećenje koje poslužitelj može nositi.

| Obilježje | mod_php | PHP-FPM |
|---|---|---|
| Gdje radi PHP? | u svakom Apache procesu | u zasebnoj usluzi |
| Apache MPM | najčešće `prefork` | moguć `event` |
| Korisnik po web-stranici | ne, sve kao Apache korisnik | da, po poolu |
| Ponovno pokretanje PHP-a | samo s Apacheom | neovisno o Apacheu |
| Postavke po direktoriju | `php_value` u `.htaccess` | pool ili `.user.ini` |

Priručnik zato za sve moderne instalacije preporučuje PHP-FPM s `mod_proxy_fcgi`: bolje upravljanje resursima, razdvajanje procesa, ponovno pokretanje PHP-a bez ponovnog pokretanja Apachea i kompatibilnost s `event` MPM-om, koji je od Apachea 2.4 standard. Osnove su u članku [PHP-FPM objašnjen](https://phpsos.de/hr/php/php-fpm-erklaert/).

## Postavke s .htaccess, php_value i php_admin_value

S mod_php-om PHP postavke mogu se postaviti izravno u Apache konfiguraciji. Priručnik pritom razlikuje načine promjene: unosi s `INI_PERDIR` smiju stajati u php.ini, `.htaccess` ili `httpd.conf`, unosi s `INI_SYSTEM` samo u php.ini ili `httpd.conf`.

```apache
# U konfiguraciji VirtualHosta: zaključano za aplikaciju
php_admin_flag  display_errors off
php_admin_value upload_max_filesize 24M

# Moguće u .htaccess, ali aplikacija ga može nadjačati
php_value max_execution_time 60
```

`php_admin_value` i `php_admin_flag` dopušteni su samo u konfiguraciji poslužitelja, a ne u `.htaccess`. Upravo je ta razlika važna kod prijelaznih mjera za PHP2Shell, jer aplikacija ne smije moći poništiti vrijednosti poput `session.upload_progress.enabled`.

## mod_php i PHP2Shell: zašto je rizik najviši

PHP tim rizik zbog PHP2Shella kod mod_php-a ocjenjuje najvišim: tamo je pokazan exploit prije nego što se uopće izvrši kod aplikacije. Sigurnosni dodaci ili provjere u CMS-u tako stižu prekasno. Uz to, kod mod_php-a PHP radi s pravima i u memoriji web-poslužitelja. Detaljna procjena nalazi se na stranici [Zašto mod_php nosi najviši rizik](https://phpsos.de/hr/php2shell/mod-php-risiko/).

Za operatere zato vrijedi:

1. PHP modul ažurirati na 8.5.12, 8.4.27, 8.3.36 ili 8.2.35 odnosno potvrđeni backport.
2. Apache potpuno ponovno pokrenuti, ne samo ponovno učitati, i provjeriti vrijeme pokretanja procesa.
3. Prijelazne vrijednosti postaviti putem `php_admin_value` u konfiguraciji poslužitelja ako ažuriranje još nije moguće.
4. Nakon toga planirati prelazak na PHP-FPM, kako je opisano u članku [Osiguravanje Apachea s mod_php-om](https://phpsos.de/hr/server/apache-mod-php/).

## Kako PHP SOS konkretno pomaže?

- **Prepoznati:** Provjeravamo na kojim poslužiteljima radi mod_php, s kojim MPM-om i iz kojeg izvora paketa.
- **Zakrpati:** Ažuriramo PHP modul, potpuno ponovno pokrećemo Apache i dokazujemo stanje.
- **Osigurati prijelaz:** Gdje je ažuriranje blokirano, mjere s php.net-a postavljamo zaključano u konfiguraciji poslužitelja.
- **Prebaciti:** U okviru [ojačavanja poslužitelja](https://phpsos.de/hr/leistungen/server-haertung/) testirano prelazimo na PHP-FPM s vlastitim poolovima.


## Česta pitanja

**Zašto se zove mod_php ako se modul zove php_module?**  
mod_php je kolokvijalni naziv za PHP kao Apache modul. U konfiguraciji se učitava s LoadModule; PHP priručnik kao primjer navodi LoadModule php_module modules/libphp.so. Starije verzije koristile su nazive poput php7_module ili php5_module.

**Zašto mod_php treba prefork MPM?**  
Prema PHP priručniku mod_php treba prefork MPM ako PHP nije izgrađen sa Zend Thread Safety. Većina paketa distribucija izgrađena je bez Thread Safety. Prefork za svaku istodobnu vezu pokreće vlastiti proces, što traži više memorije.

**Rade li php_value retci u .htaccess i s PHP-FPM-om?**  
Ne. php_value i php_flag u .htaccess Apache su direktive PHP modula i djeluju samo s mod_php-om. Pod PHP-FPM-om takve postavke pripadaju u pool ili, za dopuštene vrijednosti, u .user.ini.

**Moram li mod_php odmah ukinuti?**  
Prvo dolazi ažuriranje PHP-a uz potpuno ponovno pokretanje Apachea. Prelazak na PHP-FPM nakon toga je smislen, ali ga treba planirati i testirati. On ne zatvara PHP2Shell jer je i PHP-FPM pogođen.

## Izvori

- [PHP priručnik: Apache 2 na Unixu](https://www.php.net/manual/en/install.unix.apache2.php)
- [PHP priručnik: Načini promjene INI postavki](https://www.php.net/manual/en/configuration.changes.modes.php)
- [Apache dokumentacija](https://httpd.apache.org/docs/)
- [php.net: Sigurnosne objave](https://www.php.net/)