Nginx liest seine Konfiguration beim Start. Eine Dateiänderung bewirkt nichts, bis Sie ihm sagen, er soll neu lesen - und wie Sie es ihm sagen, entscheidet, ob es jemandem auffällt.

Immer zuerst testen

nginx -t

Er liest alles ein und nennt Datei und Zeile von allem, was ihm missfällt. Er ändert nichts. Es gibt nie einen Grund, das zu überspringen.

Neu laden, nicht neu starten

  • reload - startet neue Worker mit der neuen Konfiguration, lässt die alten zu Ende bringen, was sie tun, und verabschiedet sie dann. Keine Verbindung geht verloren.
  • restart - hält alles an und startet neu. Jede laufende Anfrage scheitert.
systemctl reload nginx
Ein reload mit kaputter Konfiguration zerlegt die Website NICHT: Nginx verweigert die neue und läuft mit der alten weiter. Ein restart mit kaputter Konfiguration lässt die Website unten. Das allein ist der Grund, neu zu laden.

Wann ein Neustart wirklich nötig ist

  • Wenn der Benutzer wechselt, unter dem Nginx läuft.
  • Wenn ein Modul hinzukommt.
  • Wenn sich im Hauptkontext etwas ändert, das laufende Worker nicht übernehmen können.

Die Änderung umkehrbar halten

cp /etc/nginx/sites-available/mysite{,.bak-$(date +%F)}
# edit, test, reload
# and if it is wrong:
cp /etc/nginx/sites-available/mysite.bak-2026-09-04 /etc/nginx/sites-available/mysite
nginx -t && systemctl reload nginx

Prüfen, was tatsächlich geladen ist

nginx -T | grep -A5 "server_name yourdomain.com"

Das große T druckt die gesamte laufende Konfiguration mit allen aufgelösten Includes - der einzige Weg, sicherzugehen, dass die Datei, die Sie bearbeitet haben, auch die benutzte ist.

Wenn eine Änderung nichts zu bewirken scheint, suchen Sie nach einem zweiten Serverblock mit demselben Namen. Der erste Treffer gewinnt, und eine alte Datei in sites-enabled ist der übliche Grund.