Beherrschung der wichtigsten Nginx-Befehle zur Dienststeuerung

Die Beherrschung der wichtigsten Nginx-Befehle zur Dienststeuerung hilft Ihnen, sicher neu zu starten, die Konfiguration ohne Traffic-Verlust neu zu laden und zu diagnostizieren, warum der Server nicht antwortet. Die meiste tägliche Nginx-Arbeit beschränkt sich auf eine kleine Reihe sorgfältig verwendeter Befehle.

Dieser Leitfaden konzentriert sich auf die praktische Befehlsnutzung auf Linux-Systemen, auf denen Nginx von systemd verwaltet wird, was auf Ubuntu, Debian, CentOS, Rocky Linux und vielen Cloud-Images üblich ist.

Die Beispiele gehen davon aus, dass der Dienst nginx heißt. Einige benutzerdefinierte Builds oder Kontrollpanels verwenden einen anderen Einheitennamen, aber verpackte Nginx-Installationen folgen normalerweise dieser Konvention. Listen Sie im Zweifelsfall passende Einheiten auf:

systemctl list-units '*nginx*'
systemctl list-unit-files '*nginx*'

Diese kleine Überprüfung verhindert einen häufigen Fehler: die Fehlersuche am falschen Dienst, während ein anderer Webserver oder Container tatsächlich den Traffic verarbeitet.

Überprüfen, ob Nginx läuft

Beginnen Sie mit dem Dienststatus:

sudo systemctl status nginx

Dies zeigt an, ob Nginx aktiv, fehlgeschlagen, deaktiviert oder noch am Starten ist. Es zeigt auch aktuelle Logzeilen von systemd an, die oft den Grund für einen fehlgeschlagenen Start oder Neuladevorgang enthalten.

Lesen Sie die ersten Statuszeilen sorgfältig. active (running) bedeutet, dass systemd glaubt, dass der Master-Prozess lebt. failed bedeutet, dass der letzte Start- oder Neuladeversuch fehlgeschlagen ist. enabled oder disabled sagt Ihnen das Startverhalten, nicht ob der Dienst gerade läuft.

Für eine kürzere Ausgabe, die in Skripten nützlich ist:

systemctl is-active nginx

Mögliche Ausgaben sind active, inactive, failed oder activating. Wenn Sie nur wissen müssen, ob Nginx beim Start aktiviert ist, verwenden Sie:

systemctl is-enabled nginx

Sie können auch bestätigen, dass Nginx auf Web-Ports lauscht:

sudo ss -ltnp | grep nginx

Sie sollten Listener auf Ports wie 80 oder 443 sehen. Wenn der Dienst aktiv ist, aber kein erwarteter Port lauscht, überprüfen Sie Ihre listen-Direktiven und die enthaltenen Konfigurationsdateien.

Wenn ss nichts anzeigt, bestätigen Sie, ob ein anderer Prozess den Port bereits belegt:

sudo ss -ltnp 'sport = :80'
sudo ss -ltnp 'sport = :443'

Portkonflikte sind häufig nach der Installation von Apache, Caddy, einem lokalen Entwicklungsserver oder einer Container-Laufzeitumgebung, die denselben Port veröffentlicht. In diesem Fall hilft ein wiederholter Neustart von Nginx nicht. Sie müssen den konkurrierenden Dienst stoppen oder den Listener ändern.

Starten, Stoppen, Neustarten und Neuladen von Nginx

Verwenden Sie start, wenn Nginx nicht läuft:

sudo systemctl start nginx

Verwenden Sie stop, wenn Sie es absichtlich offline nehmen möchten:

sudo systemctl stop nginx

Seien Sie vorsichtig mit stop auf Produktionsservern. Es macht den Dienst sofort unverfügbar, es sei denn, ein anderer Server oder Load Balancer verarbeitet den Traffic.

Verwenden Sie restart, wenn Sie einen vollständigen Stopp und Start benötigen:

sudo systemctl restart nginx

Ein Neustart ist einfach, aber nicht immer die beste Wahl. Er kann aktive Verbindungen unterbrechen, besonders auf stark ausgelasteten Servern oder wenn die Konfiguration Startprobleme hat.

Verwenden Sie den Neustart, wenn der Nginx-Prozess selbst nicht gesund ist, wenn ein Modul- oder Paketupdate einen frischen Prozess erfordert, oder wenn Sie bewusst den Worker-Status löschen möchten. Für gewöhnliche Server-Block-Bearbeitungen, Zertifikatspfad-Updates, Upstream-Änderungen, Weiterleitungen und Header-Änderungen ist das Neuladen normalerweise die bessere erste Wahl.

Für die meisten Konfigurationsänderungen bevorzugen Sie das Neuladen:

sudo systemctl reload nginx

Ein Neuladen fordert den Nginx-Master-Prozess auf, die neue Konfiguration zu lesen und neue Worker zu starten. Alte Worker beenden bestehende Anfragen und beenden sich dann. Dies ist der normale Weg, um Änderungen mit weniger Unterbrechungen anzuwenden.

Ein praktisches Beispiel: Sie fügen einen neuen Server-Block für api.example.com hinzu. Führen Sie zuerst sudo nginx -t aus. Wenn der Test bestanden wird, führen Sie sudo systemctl reload nginx aus. Benutzer auf bestehenden Verbindungen sollten nichts bemerken.

Sie können Nginx auch direkt zum Neuladen auffordern:

sudo nginx -s reload

Auf systemd-Systemen bevorzugen Sie systemctl reload nginx für Routineoperationen, da systemd die Quelle der Wahrheit für Dienststatus und Logs bleibt. Die direkte nginx -s-Form ist immer noch nützlich auf minimalen Systemen oder in Containern, wo systemd nicht vorhanden ist.

Kennen Sie den Unterschied zwischen Neuladen und Neustarten

Diese Unterscheidung verhindert viel vermeidbare Ausfallzeit.

Ein Neuladen fordert den Nginx-Master-Prozess auf, die neue Konfiguration zu lesen und neue Worker zu starten. Wenn die Konfiguration gültig ist, akzeptieren neue Worker neue Verbindungen, während alte Worker bestehende Arbeit beenden und beenden. Deshalb ist das Neuladen der normale Produktionspfad.

Ein Neustart stoppt und startet den Dienst. Abhängig vom Timing, Traffic und Supervisor-Verhalten können Clients Verbindungsfehler sehen. Ein Neustart kann auch einen kleinen Konfigurationsfehler in einen Ausfall verwandeln, wenn Nginx zuvor mit einer gültigen alten Konfiguration lief und mit der neuen nicht starten kann.

Ein sicherer Rhythmus sieht so aus:

sudo nginx -t
sudo systemctl reload nginx
sudo systemctl status nginx --no-pager

Wenn das Neuladen fehlschlägt, versuchen Sie es nicht weiter. Lesen Sie den genauen Fehler, korrigieren Sie die Datei, testen Sie erneut und laden Sie dann neu.

Konfiguration vor dem Anwenden von Änderungen testen

Der wichtigste Befehl ist:

sudo nginx -t

Dies überprüft die Syntax und meldet, ob Nginx die Konfiguration laden kann. Es erfasst fehlende Semikolons, falsche Dateipfade, doppelte Direktiven, unbekannte Module und viele Zertifikatspfadprobleme.

Sie könnten eine Ausgabe wie diese sehen:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Wenn es fehlschlägt, lesen Sie die Zeilennummer sorgfältig. Nginx sagt Ihnen oft die Datei und Zeile, in der das Parsen fehlgeschlagen ist. Der eigentliche Fehler könnte direkt über dieser Zeile liegen, besonders wenn eine Klammer oder ein Semikolon fehlt.

Um die vollständig geladene Konfiguration einschließlich der enthaltenen Dateien auszugeben, verwenden Sie:

sudo nginx -T

Dies ist nützlich, wenn Sie nicht sicher sind, welche Datei eine Direktive enthält. Es kann Überraschungen aus /etc/nginx/conf.d/, sites-enabled oder paketbereitgestellten Snippets aufdecken.

nginx -T kann sensible Pfade, Upstream-Namen und manchmal eingebettete Konfigurationswerte ausgeben. Seien Sie vorsichtig, wenn Sie die vollständige Ausgabe in Tickets, Chats oder öffentliche Foren einfügen. Redigieren Sie Geheimnisse und interne Hostnamen bei Bedarf.

Wenn Sie mehrere Nginx-Instanzen oder benutzerdefinierte Präfixe verwalten, geben Sie die Konfigurationsdatei explizit an:

sudo nginx -t -c /etc/nginx/nginx.conf

Die meisten Paketsysteme benötigen kein -c, aber es ist nützlich, wenn Sie eine Kandidatenkonfiguration in einem Staging-Pfad vergleichen.

Für eine tiefere Befehlscheckliste siehe Testen von Nginx-Konfigurationen und Überwachen des Status.

Logs anzeigen, während Sie den Dienst steuern

Wenn ein Befehl fehlschlägt, erklären Logs normalerweise warum. Beginnen Sie mit dem Journal:

sudo journalctl -u nginx --since "10 minutes ago"

Für einen fehlgeschlagenen Start oder Neustart entfernen Sie das Zeitfenster und zeigen Sie die letzten Einträge an:

sudo journalctl -u nginx -n 100 --no-pager

Um Logs live zu verfolgen:

sudo journalctl -u nginx -f

Nginx schreibt auch eigene Logs, normalerweise hier:

sudo tail -f /var/log/nginx/error.log
sudo tail -f /var/log/nginx/access.log

Das systemd-Journal ist am besten für Dienststart, -stopp, -neuladen und Berechtigungsfehler geeignet. Das Nginx-Fehlerprotokoll ist am besten für Laufzeitprobleme wie Upstream-Fehler, fehlende Dateien, Client-Body-Größenbeschränkungen und TLS-Probleme geeignet.

Wenn Ihr Server mehrere Sites hostet, überprüfen Sie, ob jeder Server-Block seine eigenen Logdateien hat. Separate Logs machen es viel einfacher, eine Dienststeuerungsänderung mit einer bestimmten defekten Domain zu verbinden.

Nach einem Neuladen beobachten Sie sowohl das Journal als auch das Fehlerprotokoll für eine Minute:

sudo journalctl -u nginx -f
sudo tail -f /var/log/nginx/error.log

Der Neuladebefehl kann schnell zurückkehren, aber ein defekter Upstream, ein fehlendes Root-Verzeichnis oder ein Berechtigungsproblem kann erst auftreten, wenn die erste echte Anfrage diesen Server-Block erreicht.

Nginx beim Start aktivieren oder deaktivieren

Um Nginx automatisch nach einem Neustart zu starten:

sudo systemctl enable nginx

Um es in einem Schritt zu aktivieren und zu starten:

sudo systemctl enable --now nginx

Um zu verhindern, dass es automatisch startet:

sudo systemctl disable nginx

Das Deaktivieren stoppt nicht den aktuell laufenden Dienst. Es ändert nur das Startverhalten. Wenn Sie es deaktivieren und stoppen möchten, führen Sie sowohl disable als auch stop aus.

Auf Produktionssystemen bestätigen Sie das Startverhalten nach Wartungsarbeiten. Ein Server kann nach manuellem Start gesund aussehen, aber nach dem nächsten Neustart nicht wiederhergestellt werden, weil Nginx nie aktiviert wurde.

Wenn Sie die Abhängigkeitsreihenfolge bestätigen möchten, überprüfen Sie die Einheit:

systemctl cat nginx
systemctl show nginx -p WantedBy -p After -p Requires

Vermeiden Sie es, verpackte Einheitendateien direkt zu bearbeiten. Verwenden Sie stattdessen einen Override:

sudo systemctl edit nginx

Dies erstellt einen Drop-In unter dem Override-Verzeichnis von systemd und hält Paket-Upgrades sauberer. Nach dem Ändern von Einheiten-Overrides führen Sie aus:

sudo systemctl daemon-reload
sudo systemctl restart nginx

Ändern Sie Einheitenabhängigkeiten nur, wenn Sie die Startbeziehung verstehen. Viele Nginx-Probleme gehören in die Nginx-Konfiguration, nicht in die systemd-Konfiguration.

Signale nur senden, wenn Sie es ernst meinen

Nginx hat einen Master-Prozess und Worker-Prozesse. Der Master liest die Konfiguration, verwaltet Worker und reagiert auf Signale. systemd verbirgt das meiste davon vor Ihnen, was für den normalen Betrieb gut ist.

Wenn Sie den Prozessbaum überprüfen müssen:

ps -o pid,ppid,user,cmd -C nginx

Sie werden normalerweise einen Master-Prozess sehen, der als root läuft, und Worker-Prozesse, die als der konfigurierte Nginx-Benutzer laufen, oft www-data, nginx oder nobody, abhängig von der Distribution.

Direkte Signale existieren:

sudo nginx -s reload
sudo nginx -s quit
sudo nginx -s stop

quit fordert eine ordnungsgemäße Beendigung an. stop beendet schnell. Im täglichen Systemadministration verwenden Sie systemctl, es sei denn, Sie haben einen bestimmten Grund, es nicht zu tun. Es hält Dienststatus, Logs und Neustartverhalten an einem Ort.

Häufige Befehlsfehler, die Sie vermeiden sollten

Laden Sie nicht neu, nachdem ein Konfigurationstest fehlgeschlagen ist. Das Neuladen sollte fehlschlagen, aber sich darauf zu verlassen ist schlampig und macht die Fehlersuche lauter.

Verwenden Sie kill -9 nicht für die normale Nginx-Steuerung. Lassen Sie systemd und den Nginx-Master-Prozess die Worker verwalten. Das erzwungene Töten von Prozessen kann verwirrende Zustände und abgebrochene Verbindungen hinterlassen.

Bearbeiten Sie keine Dateien in sites-available und nehmen Sie an, dass sie aktiv sind. Bei Debian-artigen Layouts ist die aktivierte Datei normalerweise ein Symlink in sites-enabled. Bestätigen Sie mit:

ls -l /etc/nginx/sites-enabled/

Vergessen Sie nicht die Berechtigungen der Zertifikatsdateien. Wenn Nginx während des Neuladens ein Zertifikat oder einen Schlüssel nicht lesen kann, können HTTPS-Server-Blöcke nicht geladen werden.

Gehen Sie nicht davon aus, dass sudo systemctl status nginx beweist, dass jede Site funktioniert. Nginx kann laufen, während ein Server-Block auf einen toten Upstream oder ein falsches Dokumentenverzeichnis zeigt.

Testen Sie nicht nur HTTP, wenn die Änderung HTTPS-bezogen ist. Zertifikatskette, Schlüsselberechtigungen, SNI-Matching und Weiterleitungsverhalten benötigen alle eine HTTPS-Überprüfung:

curl -I https://example.com/
openssl s_client -connect example.com:443 -servername example.com </dev/null

curl -I reicht für viele Überprüfungen aus. openssl s_client ist ausführlicher und nützlich, wenn Sie das von einem bestimmten Namen ausgestellte Zertifikat überprüfen müssen.

Eine sichere Checkliste für Produktionsänderungen

Für eine kleine Nginx-Konfigurationsänderung verwenden Sie eine wiederholbare Checkliste:

1. Bearbeiten Sie die beabsichtigte Datei.
2. Führen Sie sudo nginx -t aus.
3. Wenn der Test fehlschlägt, korrigieren Sie die Konfiguration, bevor Sie den laufenden Dienst berühren.
4. Führen Sie sudo systemctl reload nginx aus.
5. Überprüfen Sie sudo systemctl status nginx --no-pager.
6. Testen Sie die betroffene URL mit curl.
7. Beobachten Sie das Fehlerprotokoll auf neue Nachrichten.

Zum Beispiel nach dem Hinzufügen einer Weiterleitung:

sudo nginx -t
sudo systemctl reload nginx
curl -I http://example.com/old-path
sudo tail -n 50 /var/log/nginx/error.log

Für eine Reverse-Proxy-Änderung testen Sie den tatsächlichen Upstream-Pfad:

curl -I https://api.example.com/health
sudo journalctl -u nginx --since "5 minutes ago" --no-pager

Dies ist absichtlich langweilig. Die meisten Nginx-Ausfälle durch Konfigurationsbearbeitungen passieren, weil jemand den Test übersprungen, den falschen Host neu geladen oder die betroffene Route nicht überprüft hat.

Fehlerbehebung bei fehlgeschlagenen Starts und Neuladevorgängen

Wenn Nginx nicht startet, führen Sie zuerst den Konfigurationstest aus:

sudo nginx -t

Wenn die Syntax gültig ist, aber der Start immer noch fehlschlägt, überprüfen Sie das Journal:

sudo journalctl -u nginx -n 100 --no-pager

Häufige Ursachen sind:

• Ein anderer Prozess verwendet bereits Port 80 oder 443.
• Ein Zertifikats- oder Schlüsseldateipfad ist falsch.
• Nginx kann eine Datei aufgrund von Berechtigungen oder SELinux/AppArmor-Richtlinien nicht lesen.
• Ein referenziertes Verzeichnis existiert nicht.
• Ein dynamisches Modul, das in nginx.conf konfiguriert ist, fehlt nach einer Paketänderung.

Für Portkonflikte:

sudo ss -ltnp 'sport = :80'
sudo ss -ltnp 'sport = :443'

Für fehlende Dateien vertrauen Sie der Nginx-Fehlermeldung. Sie nennt normalerweise den Pfad. Überprüfen Sie den Pfad genau so, wie er geschrieben ist, nicht den Pfad, den Sie erwartet haben:

sudo ls -l /path/from/error/message

Wenn ein Neuladen fehlschlägt, Nginx aber noch läuft, ist die alte Konfiguration möglicherweise noch aktiv. Das sind gute Nachrichten: Benutzer sind möglicherweise noch nicht betroffen. Korrigieren Sie die Konfiguration, testen Sie erneut und laden Sie erneut. Starten Sie nicht neu, es sei denn, Sie wissen, dass die aktive Konfiguration sauber starten kann.

Wann Sie Probleme mit der Dienststeuerung eskalieren sollten

Rufen Sie einen DevOps-Ingenieur oder Linux-Administrator, wenn Nginx nach einem Paket-Upgrade nicht startet, wenn Neuladevorgänge auf einem Produktionsserver fehlschlagen, oder wenn systemd Berechtigungs- und Sandboxing-Fehler anzeigt, die Sie nicht verstehen. Holen Sie sich auch Hilfe, bevor Sie Einheitendateien auf gemeinsam genutzter Infrastruktur ändern.

Wenn Nginx hinter einem Load Balancer sitzt, koordinieren Sie Neustarts mit Health Checks und Drain-Verhalten. Ein lokaler Befehl kann breitere Auswirkungen haben als erwartet.

Der sicherste Rhythmus ist einfach: Status überprüfen, Konfiguration testen, nach Möglichkeit neu laden, nur bei Bedarf neu starten und Logs sofort nach Änderungen lesen. Diese Gewohnheiten machen die Nginx-Dienststeuerung vorhersehbar statt stressig.