Apache oder nginx: Entscheidungshilfe

Die Frage wird oft als Glaubensfrage geführt und ist in der Praxis eine Frage nach dem Lastprofil und danach, wer die Konfiguration ändern darf.

Was die beiden unterscheidet

Das ereignisgesteuerte Modell ist der eigentliche Unterschied. nginx bearbeitet tausende offene Verbindungen mit einer Handvoll Prozessen. Apache braucht dafür in der klassischen Variante pro Verbindung einen Worker. Mit mpm_event hat sich das relativiert, weil wartende Verbindungen dort ebenfalls gebündelt werden.

Wann nginx die bessere Wahl ist

• Ein grosser Anteil statischer Dateien: Bilder, Videos, Downloads, Build-Artefakte.
• Sehr viele langsame Verbindungen, etwa mobile Nutzer mit schwacher Anbindung oder offene WebSockets.
• Der Server soll als Reverse Proxy vor mehreren Anwendungen stehen und dabei TLS terminieren und cachen.
• Speicher ist knapp und die Last besteht überwiegend aus Auslieferung, nicht aus Berechnung.

Wann Apache die bessere Wahl bleibt

• Mehrere Projekte oder Kunden teilen sich einen Server und sollen eigene Regeln setzen dürfen, ohne Root-Zugriff zu bekommen.
• Es existiert eine gewachsene .htaccess mit hunderten Weiterleitungen, die nach einem Relaunch weiter greifen müssen.
• Die Anwendung ist ein klassisches PHP-Projekt, und die Antwortzeit entsteht ohnehin in der Anwendung.
• Regeln müssen häufig und schnell angepasst werden, ohne dass ein Deployment nötig ist.

Der letzte Punkt wird unterschätzt. Eine Weiterleitung in der .htaccess ist nach dem Speichern aktiv. Dieselbe Regel unter nginx bedeutet: Datei ändern, nginx -t, systemctl reload nginx – und alles davon braucht Serverzugriff.

Die pragmatische Antwort: beides

Die verbreitetste Produktivkonfiguration nutzt beide Server nach ihren Stärken:

server {
  listen 443 ssl http2;
  server_name example.com;

  # statische Dateien direkt aus dem Dateisystem
  location ~* \.(css|js|jpg|jpeg|png|webp|svg|woff2|ico)$ {
    root /var/www/example.com/public;
    expires 1y;
    add_header Cache-Control "public, immutable";
    access_log off;
  }

  # alles andere an Apache
  location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Host              $host;
    proxy_set_header X-Real-IP         $remote_addr;
    proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
  }
}

Apache lauscht dann nur noch auf 127.0.0.1:8080 und behält seine .htaccess-Regeln. Wichtig ist mod_remoteip auf der Apache-Seite, sonst steht in jedem Logeintrag die IP des Proxys statt die des Besuchers:

LoadModule remoteip_module modules/mod_remoteip.so
RemoteIPHeader X-Forwarded-For
RemoteIPInternalProxy 127.0.0.1

Regeln übersetzen

Eine .htaccess-Regel lässt sich sinngemäß übertragen, aber nicht kopieren:

# Apache
RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [R=301,L,NE]

# nginx
server {
  server_name www.example.com;
  return 301 https://example.com$request_uri;
}

Die nginx-Variante ist kürzer, weil der passende server-Block bereits die Bedingung ersetzt. Umgekehrt fehlt jede Möglichkeit, die Regel ohne Serverzugriff zu ändern.

Automatische Konverter geben einen brauchbaren Startpunkt. Prüfe das Ergebnis anschliessend gegen die echte Alt-URL-Liste – mit curl -sI und einem Blick auf Statuscode und Zielangabe, nicht nur auf der Startseite.