Nginx + PHP 8.4-FPM auf dem LAN-Server einrichten

Nginx und PHP 8.4 ohne Fremdquelle

Debian 13 „Trixie“ enthält PHP 8.4 in den offiziellen Paketquellen. Für eine Neuinstallation im August 2026 ist deshalb kein zusätzliches Sury-Repository nötig. Das verkleinert die Vertrauenskette und hält Updates im Debian-Sicherheitsmodell.

Der Artikel setzt den zuvor eingerichteten Debian-13-Server, sudo-Zugriff und eine funktionierende Namensauflösung oder feste LAN-IP voraus.

1. Pakete installieren

sudo apt update
sudo apt install -y nginx php8.4-fpm php8.4-cli php8.4-curl \
  php8.4-xml php8.4-mbstring php8.4-zip php8.4-gd php8.4-opcache
sudo systemctl enable --now nginx php8.4-fpm

php8.4-mysql wird nur benötigt, wenn die Anwendung MySQL oder MariaDB verwendet. Nicht benötigte Erweiterungen bleiben besser deinstalliert.

2. Document Root und Testdatei anlegen

sudo install -d -o www-data -g www-data -m 0750 /var/www/example/public

Für den ersten Test genügt eine Datei /var/www/example/public/index.php:

<?php
header('Content-Type: text/plain; charset=utf-8');
echo "PHP funktioniert\n";

Eine öffentlich erreichbare phpinfo()-Seite sollte nicht liegen bleiben; sie verrät zahlreiche Details der Laufzeitumgebung.

3. Nginx-Serverblock konfigurieren

server {
    listen 80;
    server_name server.example.lan;

    root /var/www/example/public;
    index index.php index.html;

    client_max_body_size 20m;

    location / {
        try_files $uri $uri/ =404;
    }

    location ~ \.php$ {
        try_files $uri =404;
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.4-fpm.sock;
    }

    location ~ /\. {
        deny all;
    }
}

Die Datei wird als /etc/nginx/sites-available/example gespeichert und aktiviert:

sudo ln -s /etc/nginx/sites-available/example /etc/nginx/sites-enabled/example
sudo nginx -t
sudo systemctl reload nginx

client_max_body_size ist laut Nginx-Dokumentation in den Kontexten http, server und location gültig; der Standardwert beträgt 1m. Im Beispiel steht die Direktive absichtlich im betreffenden server-Block.

4. PHP-Upload-Grenzen abstimmen

In /etc/php/8.4/fpm/php.ini müssen mindestens upload_max_filesize und post_max_size zur Nginx-Grenze passen. post_max_size sollte nicht kleiner als upload_max_filesize sein:

upload_max_filesize = 20M
post_max_size = 22M

Danach:

sudo systemctl restart php8.4-fpm
sudo nginx -t
sudo systemctl reload nginx

Bei Anwendungen mit eigener Upload-Grenze muss auch diese Einstellung berücksichtigt werden.

5. PHP-FPM nur nach Messung dimensionieren

pm.max_children begrenzt die Zahl gleichzeitig bedienter PHP-Anfragen. Eine pauschale Formel mit dem gesamten RAM ist riskant, weil Betriebssystem, Datenbank und andere Dienste ebenfalls Speicher benötigen. Zuerst reichen für einen kleinen LAN-Dienst meist konservative Werte; danach misst man den realen Resident Set Size der Worker und beobachtet das FPM-Log.

pm = dynamic
pm.max_children = 10
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 4
pm.max_requests = 500

Diese Werte sind ein Startpunkt, kein aus 8 GB RAM abgeleiteter Leistungsnachweis.

6. TLS passend zum Einsatzort

Let's Encrypt stellt öffentlich vertrauenswürdige Zertifikate aus, wenn die Domain und die gewählte ACME-Prüfung erreichbar beziehungsweise kontrollierbar sind. Für einen ausschließlich internen Namen wie server.example.lan funktioniert die übliche HTTP-Prüfung nicht. Dann kommen eine interne Zertifizierungsstelle, ein anderer interner TLS-Ansatz oder der Zugriff ausschließlich über ein geschütztes LAN/VPN infrage.

Für eine öffentliche Domain mit erfüllten Voraussetzungen:

sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d example.de -d www.example.de

Eine öffentliche Freigabe erweitert die Angriffsfläche erheblich und ist nicht Bestandteil eines reinen LAN-Servers.

Fehlersuche

• nginx -t prüft die Syntax vor jedem Reload.
• systemctl status nginx php8.4-fpm zeigt den Dienststatus.
• journalctl -u nginx -u php8.4-fpm und /var/log/nginx/error.log liefern Fehlerdetails.
• Bei 502 Bad Gateway Socketpfad und FPM-Status prüfen.
• Bei 413 Request Entity Too Large Nginx-, PHP- und Anwendungsgrenzen vergleichen.
• Mit php -v wird die CLI-Version geprüft; sie beweist nicht, dass Nginx denselben FPM-Socket verwendet.

Fazit

Auf Debian 13 ist Nginx mit PHP 8.4-FPM ohne Drittanbieter-Repository möglich. Ein enger Document Root, die Existenzprüfung vor der PHP-Übergabe, abgestimmte Upload-Limits und ein zum Netz passendes TLS-Konzept sind wichtiger als vermeintliche Universalwerte für FPM.

Quellen und technische Dokumentation

• Debian-Paket: php8.4-fpm
• Nginx: client_max_body_size
• PHP: FPM-Konfiguration
• Certbot-Dokumentation