Apache2, nginx oder lighttpd? Der Webserver-Vergleich für Selfhoster

Warum die Frage meist falsch gestellt wird

Die verbreitete Frage lautet: „Welcher Webserver ist der schnellste?“ Sie führt zu Benchmarks, die statische Dateien mit maximaler Nebenläufigkeit ausliefern – eine Situation, die im Selfhosting fast nie vorkommt. Deine Nextcloud, dein Blog, deine Weboberfläche liefern dynamische Antworten: Die Zeit entsteht in Datenbank, PHP-Prozessen oder im Proxy dahinter, nicht im Webserver selbst.

Die tatsächlich relevanten Fragen sind andere:

Drei Architekturen, drei Denkweisen

Der Unterschied zwischen den drei Servern ist nicht „schnell“ oder „langsam“, sondern wie sie mit vielen gleichzeitigen Verbindungen umgehen.

Wichtig: Das alte „Apache kann keine vielen Verbindungen“-Argument ist überholt. Mit mpm_event ist Apache der modernen Konkurrenz näher als sein Ruf. Was bleibt, sind andere Kosten – etwa die Suche nach .htaccess-Dateien entlang des Pfads bei jedem Zugriff.

Apache 2.4: der Vielseitige

Apache ist der älteste der drei und der einzige mit Konfiguration pro Verzeichnis. Genau das ist sein Markenkern – und gleichzeitig sein Preis.

<VirtualHost *:80>
    ServerName static.meine.domain
    DocumentRoot /srv/www/static

    <Directory /srv/www/static>
        Options -Indexes +FollowSymLinks
        # .htaccess aus: spart Zugriffe pro Anfrage und ist sicherer
        AllowOverride None
        Require all granted
    </Directory>

    DirectoryIndex index.html index.php
    Header always set X-Content-Type-Options "nosniff"
    ErrorLog  /var/log/static-error.log
    CustomLog /var/log/static-access.log combined
</VirtualHost>

nginx: der Verteiler

nginx wurde als Ereignis-Server für hohe Nebenläufigkeit entworfen – und hat sich davon zum De-facto-Standard vor Anwendungen entwickelt. In diesem Blog läuft fast alles darüber: Reverse Proxy, TLS-Terminierung, Header und HTTP/3.

lighttpd: der Leichtgewichtige

lighttpd war früh ereignisbasiert, als „leicht“ noch ein Alleinstellungsmerkmal war. Heute ist sein Argument nicht mehr die Geschwindigkeit, sondern der Fußabdruck: wenige Megabyte Speicher, eine kompakte Konfiguration, wenig Ballast.

Die große Vergleichstabelle

Speicherbedarf und Nebenwirkungen

Der größte praktische Unterschied zwischen den dreien ist nicht der Durchsatz, sondern die Frage: Wie viel RAM kostet eine offene Verbindung? Grobe Größenordnungen:

# Speicherverbrauch der Webserver-Prozesse vergleichen (Debian/Arch)
ps_mem -p "$(pgrep -d, -x 'nginx|httpd|lighttpd')" 2>/dev/null || ps -o rss,cmd -C nginx,httpd,lighttpd

# Systemd-Dienste direkt fragen
systemctl show -p MemoryCurrent nginx
systemctl show -p MemoryCurrent apache2 2>/dev/null || systemctl show -p MemoryCurrent httpd

# Offene Verbindungen zaehlen
ss -tn state established '( sport = :443 )' | wc -l

Dieselbe Aufgabe in allen drei

Eine statische Seite mit index.html, ohne Verzeichnislisting, mit Upload-Limit, einem Sicherheits-Header und Protokolldateien. Nichts davon ist exotisch – und man sieht gut, wie unterschiedlich die drei Denkweisen sind.

Apache (Konfiguration pro Vhost):

<VirtualHost *:80>
    ServerName static.meine.domain
    DocumentRoot /srv/www/static

    <Directory /srv/www/static>
        Options -Indexes +FollowSymLinks
        AllowOverride None
        Require all granted
    </Directory>

    DirectoryIndex index.html
    LimitRequestBody 0
    Header always set X-Content-Type-Options "nosniff"
    ErrorLog  /var/log/static-error.log
    CustomLog /var/log/static-access.log combined
</VirtualHost>

nginx (Serverblock):

server {
    listen 80;
    server_name static.meine.domain;

    root  /srv/www/static;
    index index.html;
    autoindex off;
    client_max_body_size 0;

    add_header X-Content-Type-Options "nosniff" always;

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

    access_log /var/log/static-access.log;
    error_log  /var/log/static-error.log;
}

lighttpd (eine Konfigurationsdatei):

server.document-root = "/srv/www/static"
server.port          = 80
server.upload-dirs   = ( "/var/cache/lighttpd/uploads" )
index-file.names     = ( "index.html" )

# Kein Verzeichnislisting und ein Header
server.dir-listing   = "disable"
setenv.add-response-header = ( "X-Content-Type-Options" => "nosniff" )

# Umleitung, wenn die Datei nicht existiert
url.rewrite-if-not-file = ( "^/(.*)$" => "/index.html" )

PHP: mod_php gegen php-fpm

Die PHP-Anbindung ist der Punkt, an dem sich viele Setups historisch entschieden haben – und an dem Apache heute am häufigsten zu Unrecht mit mod_php betrieben wird.

# Apache an php-fpm (Debian-Pfad, Socket statt TCP)
<FilesMatch "\.php$>">
    SetHandler "proxy:unix:/run/php/php-fpm.sock|fcgi://localhost"
</FilesMatch>

# nginx an php-fpm
location ~ \.php$ {
    include        fastcgi_params;
    fastcgi_pass   unix:/run/php/php-fpm.sock;
    fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

# lighttpd an php-fpm
fastcgi.server = ( ".php" => (( "socket" => "/run/php/php-fpm.sock" )) )

TLS, HTTP/2 und HTTP/3

Alle drei terminieren TLS direkt. Die Unterschiede liegen in Bequemlichkeit und darin, welche Protokollversionen überhaupt verfügbar sind.

Kombinationen und Reverse Proxy

Man muss sich nicht entscheiden: Ein kleiner Server vor einem großen ist ein klassisches Muster. Sinnvoll ist es aber nur mit einem Grund.

Umsteigen: die Stolpersteine

Ein Wechsel ist selten das Problem der Software, sondern der übersehenen Kleinigkeiten:

Sicherheit und Wartung

Entscheidungshilfe

Häufige Fragen (FAQ)

Fazit

Apache, nginx und lighttpd sind keine Konkurrenten im Sinne von „richtig und falsch“. Sie verkörpern drei Denkweisen: Regeln pro Verzeichnis (Apache), Kontexte und Standorte (nginx), Eigenschaften eines schlanken Servers (lighttpd). Wer das weiß, wählt nach seinem Anwendungsfall – und nicht nach einem Benchmark, der eine Situation misst, die bei ihm nie eintritt.

Für dieses Blog ist die Antwort unspektakulär: nginx vorne, weil dort TLS, Header, HTTP/3 und die Dienste zusammenlaufen; Apache nur, wo eine Anwendung es verlangt; lighttpd dort, wo ein System wirklich klein sein muss.