# CGI og FastCGI: grundlæggende

> CGI og FastCGI med PHP forklaret: proces pr. forespørgsel eller vedvarende workere, php-cgi og PHP-FPM's rolle, cgi-indstillinger og sikkerhedsregler.

Kilde: https://phpsos.de/da/php/cgi-und-fastcgi/  
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:** CGI (Common Gateway Interface) er en gammel grænseflade, hvor webserveren starter et nyt program for hver forespørgsel, ved PHP programmet `php-cgi`. FastCGI er videreudviklingen: PHP-processer kører vedvarende og modtager mange forespørgsler via en socket. PHP-FPM er den vigtigste FastCGI-implementering til PHP. Sikkerhedsmæssigt er det først og fremmest `cgi.*`-indstillingerne og reglen om, at en FastCGI-adgang aldrig må kunne nås offentligt, der tæller.

## Hvad er CGI?

CGI er en af de ældste metoder, hvormed webservere skaber dynamisk indhold. PHP-manualen henviser ved indstillingen `cgi.rfc2616_headers` til RFC 3875, specifikationen af Common Gateway Interface. Også PHP's begyndelse var CGI-programmer: Rasmus Lerdorf skrev i 1994 de første "Personal Home Page Tools" som CGI-binærfiler i C.

Princippet: For hver forespørgsel starter webserveren en ny proces, overdrager forespørgselsdata via miljøvariabler og standardinput og læser svaret fra standardoutput. Derefter slutter processen. Ifølge PHP-manualen læser PHP ved CGI og CLI sin php.ini på ny ved hvert kald, ved servermoduler kun ved start.

Det gør CGI robust, fordi hver forespørgsel begynder med en frisk proces. Men det gør også CGI langsom: Procesopstart, indlæsning af konfiguration og initialisering af udvidelser koster tid ved hver forespørgsel.

## Hvad er FastCGI?

FastCGI løser ydelsesproblemet ved, at processer forbliver i live. Webserveren forbinder via en Unix-socket eller en TCP-port til en kørende proces og sender den forespørgslen i FastCGI-protokollen. Processen behandler den og venter på den næste.

| Kendetegn | CGI | FastCGI med php-cgi | FastCGI med PHP-FPM |
|---|---|---|---|
| Proces pr. forespørgsel | ja | nej | nej |
| SAPI-navn | `cgi-fcgi` | `cgi-fcgi` | `fpm-fcgi` |
| Pools med egen bruger | nej | nej | ja |
| Processtyring | webserver | webservermodul, f.eks. mod_fcgid | egen master-proces |
| `.user.ini` læses | ja | ja | ja |

PHP-FPM er ifølge manualen PHP's primære FastCGI-implementering. Den supplerer protokollen med procesadministration, pools, statussider og en slowlog. Enkeltheder står under [PHP-FPM forklaret](https://phpsos.de/da/php/php-fpm-erklaert/).

## cgi-indstillingerne i php.ini

Til CGI-drift kender PHP egne indstillinger. De følgende værdier og beskrivelser stammer fra PHP-manualen:

1. **`cgi.force_redirect`** (standard 1, `INI_SYSTEM`): ifølge manualen nødvendig for at drive PHP som CGI sikkert under de fleste webservere. Slå kun fra "på eget ansvar"; under IIS skal den være slået fra.
2. **`cgi.fix_pathinfo`** (standard 1, `INI_SYSTEM`): sørger for korrekte `PATH_INFO`- og `PATH_TRANSLATED`-værdier. Scripts bør bruge `SCRIPT_FILENAME` i stedet for `PATH_TRANSLATED`.
3. **`cgi.discard_path`** (standard 0, `INI_SYSTEM`): gør det muligt at lægge CGI-binærfilen sikkert uden for webmappen, uden at `.htaccess`-beskyttelsen kan omgås.
4. **`fastcgi.impersonate`** (standard 0, `INI_SYSTEM`): kun relevant for IIS under Windows.
5. **`user_ini.filename`** og **`user_ini.cache_ttl`** (standard `.user.ini` og 300 sekunder): styrer, om og hvor ofte PHP læser `.user.ini`-filer.

Ved Nginx hører en ren overdragelse af scriptstien med. Et læsbart grundmønster, uden garanti for ethvert miljø:

```nginx
location ~ \.php$ {
    try_files $uri =404;               # giv kun eksisterende filer videre til PHP
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
}
```

Linjen `try_files $uri =404;` forhindrer, at forespørgsler på ikke-eksisterende `.php`-stier gives videre til PHP.

## Hvorfor en åben FastCGI-adgang er farlig

PHP-manualen advarer udtrykkeligt: Den, der kan åbne en FastCGI-forbindelse til PHP, kontrollerer forespørgslens konfiguration, f.eks. `auto_prepend_file`, og kan dermed udføre vilkårlig kode. Årsagen er, at webservere via FastCGI-parametre som `PHP_VALUE` og `PHP_ADMIN_VALUE` må sende PHP-indstillinger med.

Heraf følger klare regler:

- Bind kun PHP-FPM eller php-cgi i FastCGI-tilstand via en Unix-socket, hvis webserveren kører på den samme host.
- Sæt ved TCP `listen.allowed_clients` og spær porten i firewallen; henvisninger hertil i indlægget [Firewall til webservere](https://phpsos.de/da/blog/firewall-fuer-webserver/).
- Hold socket-rettigheder snævre med `listen.owner`, `listen.group` og `listen.mode`.

> **Vigtigt:**
> Kontrollér med `ss -lntp | grep -i php`, om en PHP-proces lytter på en TCP-adresse. En binding til `0.0.0.0` eller en offentlig adresse er et akut handlingsbehov.

## CGI, FastCGI og PHP2Shell

Af PHP2Shell er både php-cgi og PHP-FPM berørt. For begge gælder: Opdatér til 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 hhv. en bekræftet backport, afslut og genstart derefter alle kørende PHP-processer. Ved FastCGI-opsætninger med php-cgi kører processer ofte ubemærket videre, fordi ingen egen tjeneste administrerer dem. Hvordan I finder og afløser denne arvelast, står under [php-cgi: arvelast med risiko](https://phpsos.de/da/server/php-cgi/). I Plesk hedder varianterne noget andet; hjælp giver [Plesk: forstå PHP-handlere](https://phpsos.de/da/blog/plesk-php-handler/).

## Hvordan hjælper PHP SOS konkret?

- **Kortlægge handlere:** Vi finder ud af, om jeres websites kører via CGI, FastCGI med php-cgi eller PHP-FPM.
- **Lukke adgange:** Vi kontrollerer sockets, porte og firewall-regler, så ingen FastCGI-adgang kan nås udefra.
- **Patche og rydde op:** Vi opdaterer PHP og afslutter alle gamle processer, også forældreløse php-cgi-instanser.
- **Afløse:** Som led i [serverhærdningen](https://phpsos.de/da/leistungen/server-haertung/) erstatter vi CGI-arvelast med PHP-FPM med egne pools.


## Ofte stillede spørgsmål

**Er FastCGI det samme som PHP-FPM?**  
Nej. FastCGI er en protokol, som en webserver taler med en applikationsproces igennem. PHP-FPM er et program, der implementerer denne protokol for PHP og administrerer processerne. Også php-cgi kan tale FastCGI, men tilbyder ingen pools.

**Hvorfor regnes rent CGI for forældet?**  
Ved CGI starter webserveren en ny proces for hver forespørgsel, og PHP læser hver gang sin konfiguration. Det koster tid og ressourcer. FastCGI og PHP-FPM holder processer vedvarende klar og er derfor væsentligt mere effektive.

**Hvad er en .user.ini?**  
En .user.ini er en lille konfigurationsfil i en webmappe. Ifølge PHP-manualen læses den kun af CGI- og FastCGI-SAPI'erne, altså også af PHP-FPM. Den må kun indeholde indstillinger med tilstandene INI_PERDIR, INI_USER eller INI_ALL.

**Hvordan kan jeg se, om php-cgi kører på min server?**  
Søg med læsende kommandoer som ps eller pgrep efter processer ved navn php-cgi, og se i webserverkonfigurationen efter poster som mod_fcgid, Action eller ScriptAlias med php-cgi. I hosting-paneler hedder driftsformen ofte CGI eller FastCGI-applikation.

## Kilder

- [PHP-manualen: Kerneindstillinger (cgi.*)](https://www.php.net/manual/en/ini.core.php)
- [PHP-manualen: .user.ini-filer](https://www.php.net/manual/en/configuration.file.per-user.php)
- [PHP-manualen: FPM-konfiguration](https://www.php.net/manual/en/install.fpm.configuration.php)
- [Nginx-dokumentation](https://nginx.org/en/docs/)