DevOps Wissensdatenbank
DevOps Wissensdatenbank

Fehlerbehebung bei häufigen Nginx-Fehlern: Ein praktischer Leitfaden

Treffen Sie auf Nginx-Fehler? Dieser praktische Leitfaden hilft Ihnen bei der Diagnose und Behebung gängiger Probleme. Lernen Sie, Konfigurationsprobleme, „Permission denied“-Fehler, „Connection refused“, 502/504 Gateway-Fehler und mehr anzugehen. Wir bieten klare Erklärungen, umsetzbare Lösungen und wesentliche Nginx-Befehle, damit Ihre Website zugänglich bleibt und reibungslos läuft.

63 Aufrufe

Fehlerbehebung bei häufigen Nginx-Fehlern: Ein praktischer Leitfaden

Nginx ist ein leistungsstarker und vielseitiger Webserver, aber wie jede komplexe Software kann er manchmal Herausforderungen mit sich bringen. Fehler können frustrierend sein, besonders wenn sie die Verfügbarkeit Ihrer Website beeinträchtigen. Dieser Leitfaden bietet einen praktischen Ansatz zur Diagnose und Behebung einiger der häufigsten Nginx-Fehler, einschließlich Konfigurationsproblemen, Berechtigungsproblemen, Timeouts und clientbezogenen Fehlern. Indem Sie diese gängigen Fallstricke verstehen und lernen, wie man sie behebt, können Sie sicherstellen, dass Ihr Nginx-Server reibungslos läuft und Ihre Website für Benutzer zugänglich bleibt.

Dieser Artikel soll Sie mit dem Wissen und den Werkzeugen ausstatten, um Nginx effektiv Fehler zu beheben. Wir werden typische Fehlerszenarien durchgehen, deren zugrunde liegende Ursachen erläutern und konkrete Lösungen mit anschaulichen Beispielen anbieten. Egal, ob Sie Anfänger oder ein erfahrener Nginx-Administrator sind, dieser Leitfaden wird Ihnen als wertvolle Ressource dienen, um Ihren Webserver in optimalem Zustand zu halten.

Häufige Nginx-Fehlerkategorien

Nginx-Fehler können grob nach ihrer Ursache kategorisiert werden. Das Verständnis dieser Kategorien hilft, den Problembereich einzugrenzen.

  • Konfigurationsfehler: Fehler in nginx.conf oder den enthaltenen Konfigurationsdateien. Diese sind oft die häufigsten Übeltäter.
  • Berechtigungsfehler: Nginx-Worker-Prozessen fehlen die erforderlichen Berechtigungen, um auf Dateien oder Verzeichnisse zuzugreifen.
  • Timeout-Fehler: Probleme, bei denen der Server nicht innerhalb der erwarteten Zeit reagiert, oft aufgrund von Problemen mit der Backend-Anwendung oder Netzwerklatenz.
  • Client-Fehler: Probleme, die auf der Client-Seite entstehen, aber manchmal als serverseitige Probleme missinterpretiert werden.
  • Ressourcenfehler: Der Server läuft aus Ressourcen wie Speicher, CPU oder Dateideskriptoren.

Diagnose von Nginx-Fehlern

Der erste Schritt bei der Fehlerbehebung ist die Identifizierung der Fehlermeldung und ihres Speicherorts. Nginx-Logs sind Ihre primäre Informationsquelle.

Überprüfung der Nginx-Logs

Nginx protokolliert Fehler typischerweise in zwei Hauptdateien:

  • Error Log (error.log): Hier zeichnet Nginx alle Fehler und Warnungen auf. Der Standardort ist normalerweise /var/log/nginx/error.log auf Linux-Systemen.
  • Access Log (access.log): Obwohl hauptsächlich zur Verfolgung von Anfragen gedacht, kann dieses Log manchmal Kontext für Fehler liefern, insbesondere HTTP-Statuscodes.

Um die neuesten Einträge im Error Log anzuzeigen, können Sie den Befehl tail verwenden:

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

Dieser Befehl streamt die Logdatei in Echtzeit, sodass Sie Fehler sehen können, sobald sie auftreten.

Überprüfung der Nginx-Konfiguration

Bevor Sie Nginx nach Konfigurationsänderungen neu starten, ist es entscheidend, die Konfiguration auf Syntaxfehler zu testen:

sudo nginx -t

Dieser Befehl überprüft die Konfigurationsdateien und meldet alle gefundenen Syntaxfehler zusammen mit der Zeilennummer, in der der Fehler aufgetreten ist. Wenn der Test erfolgreich ist, wird ausgegeben:

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

Häufige Nginx-Fehler und Lösungen

Tauchen wir ein in spezifische Fehlerszenarien und deren Abhilfen.

1. (13: Permission denied) Fehler

Dieser Fehler erscheint häufig im error.log, wenn der Nginx-Worker-Prozess keine Berechtigung zum Lesen von Dateien oder zum Zugriff auf Verzeichnisse hat, die er bereitstellen soll.

Ursache: Die user-Direktive in nginx.conf (oft www-data oder nginx) hat keine Leseberechtigungen für das Web-Root-Verzeichnis oder die darin enthaltenen Dateien.

Lösung: Stellen Sie sicher, dass der Nginx-Benutzer über die entsprechenden Leseberechtigungen für Ihr Web-Content-Verzeichnis verfügt. Dies können Sie mit den Befehlen chown und chmod erreichen.

Beispiel:

Wenn Ihr Web-Root /var/www/html ist und der Nginx-Benutzer www-data ist:

# Eigentum an den Nginx-Benutzer und die Gruppe übertragen
sudo chown -R www-data:www-data /var/www/html

# Sicherstellen, dass Verzeichnisse ausführbar und Dateien lesbar sind
sudo find /var/www/html -type d -exec chmod 755 {} \;
sudo find /var/www/html -type f -exec chmod 644 {} \;

Tipp: Wenn Sie statische Dateien bereitstellen und den direkten Zugriff auf bestimmte Verzeichnisse verhindern müssen, stellen Sie sicher, dass der Nginx-Benutzer über Ausführungsberechtigungen für die Verzeichnisse verfügt, um diese zu durchsuchen, aber nicht unbedingt über Leseberechtigungen für den Verzeichnisinhalt, wenn dieser nicht aufgelistet werden soll.

2. (111: Connection refused) Fehler

Dieser Fehler bedeutet, dass der Nginx-Server versucht hat, sich mit einem anderen Dienst zu verbinden (z. B. einem Backend-Anwendungsserver wie Node.js, Python/Gunicorn oder PHP-FPM), aber die Verbindung vom Ziel aktiv verweigert wurde.

Ursache: Der Backend-Anwendungsdienst läuft nicht, lauscht an einem anderen Port oder einer anderen IP-Adresse, als Nginx erwartet, oder eine Firewall blockiert die Verbindung.

Lösung:

  • Backend-Dienststatus überprüfen: Stellen Sie sicher, dass Ihr Anwendungsserver (z. B. Gunicorn, Node.js, PHP-FPM) läuft.
    • Für systemd-Dienste: sudo systemctl status <service_name> (z. B. php8.1-fpm, gunicorn).
    • Für andere Prozesse: ps aux | grep <process_name>.
  • Listening-Adresse/Port überprüfen: Bestätigen Sie, dass der Backend-Dienst an der in Ihren Nginx proxy_pass- oder fastcgi_pass-Direktiven angegebenen IP-Adresse und Port lauscht.
    bash # Beispiel: Prüfen, ob Node.js an Port 3000 lauscht sudo ss -tulnp | grep 3000
  • Firewall-Regeln: Stellen Sie sicher, dass keine Firewall die Verbindung zwischen Nginx und dem Backend-Dienst blockiert.

Beispiel-Nginx-Konfigurationsausschnitt: 

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
}

In diesem Fall stellen Sie sicher, dass Ihre Anwendung läuft und an http://127.0.0.1:3000 lauscht.

3. 502 Bad Gateway Fehler

Der Fehler 502 Bad Gateway bedeutet, dass Nginx als Gateway oder Proxy fungierte und eine ungültige Antwort vom Upstream-Server erhielt.

Ursache: Ähnlich wie bei Connection refused, aber der Upstream-Server ist erreichbar, hat jedoch eine ungültige oder unvollständige Antwort zurückgegeben. Dies könnte zurückzuführen sein auf:
* Das Abstürzen der Backend-Anwendung oder das Auftreten eines internen Fehlers.
* Die Backend-Anwendung benötigt zu lange, um zu antworten.
* Netzwerkprobleme zwischen Nginx und dem Upstream.
* Falsche Konfiguration von proxy_pass oder fastcgi_pass.

Lösung:

  • Backend-Anwendungsprotokolle überprüfen: Überprüfen Sie die Protokolle Ihrer Backend-Anwendung auf Fehler oder Ausnahmen. Dies ist oft der direkteste Weg zur Ursachenfindung.
  • Timeouts erhöhen: Wenn die Anwendung einen langen Vorgang ausführt, müssen Sie möglicherweise die Timeout-Werte von Nginx erhöhen.
    nginx proxy_connect_timeout 60s; proxy_send_timeout 60s; proxy_read_timeout 60s; fastcgi_send_timeout 60s; fastcgi_read_timeout 60s;
    Passen Sie diese Werte sorgfältig an, da übermäßig lange Timeouts Worker-Prozesse blockieren können.
  • Upstream-Konfiguration überprüfen: Überprüfen Sie die proxy_pass- oder fastcgi_pass-Direktiven auf Korrektheit.

4. 413 Request Entity Too Large Fehler

Dieser Fehler tritt auf, wenn der Client einen Anfragetext sendet, der die in Nginx konfigurierte Größenbeschränkung überschreitet.

Ursache: Ein Client versucht, eine Datei hochzuladen oder Daten zu senden, die größer sind, als Nginx zu akzeptieren konfiguriert ist.

Lösung: Passen Sie die client_max_body_size-Direktive in Ihrer Nginx-Konfiguration an. Diese Direktive wird typischerweise innerhalb der http-, server- oder location-Blöcke festgelegt.

Beispiel:

Um Anfragen bis zu 100 MB zu erlauben:

http {
    # ... andere http-Konfigurationen ...
    client_max_body_size 100M;
}

Denken Sie daran, sudo nginx -t auszuführen und Nginx neu zu laden (sudo systemctl reload nginx), nachdem Sie Änderungen vorgenommen haben.

5. 403 Forbidden Fehler

Ein 403 Forbidden-Fehler bedeutet, dass der Server die Anfrage verstanden, aber die Autorisierung verweigert hat. Bei statischen Dateien bedeutet dies normalerweise, dass Nginx keine Berechtigung zum Zugriff auf die angeforderte Datei oder das Verzeichnis hat.

Ursache: Ähnlich wie bei Permission denied-Fehlern, führt aber speziell zu einem HTTP 403-Statuscode. Dies kann auch passieren, wenn die Verzeichnisauflistung deaktiviert ist und keine index-Datei gefunden wird.

Lösung:

  • Dateiberechtigungen überprüfen: Stellen Sie sicher, dass der Nginx-Benutzer Leseberechtigungen für die angeforderte Datei und Ausführungsberechtigungen für alle übergeordneten Verzeichnisse hat, die dazu führen. Beachten Sie die Lösungen für (13: Permission denied)-Fehler.
  • index-Direktive überprüfen: Wenn ein Verzeichnis angefordert wird (z. B. http://example.com/some/directory/), sucht Nginx nach einer index-Datei (wie index.html oder index.php). Wenn keine index-Datei existiert und die Verzeichnisauflistung deaktiviert ist, tritt ein 403 Forbidden-Fehler auf.
    nginx location / { root /var/www/html; index index.html index.htm; }
  • autoindex-Direktive überprüfen: Wenn Sie Verzeichnisauflistungen zulassen möchten, stellen Sie sicher, dass autoindex on; gesetzt ist. Dies wird jedoch aus Sicherheitsgründen im Allgemeinen nicht empfohlen.

6. 504 Gateway Timeout Fehler

Dies weist darauf hin, dass Nginx, der als Gateway fungiert, keine rechtzeitige Antwort vom Upstream-Server erhalten hat.

Ursache: Die Upstream-Anwendung benötigte zu lange, um die Anfrage zu verarbeiten, und überschritt die in Nginx konfigurierten Timeout-Grenzwerte. Dies ist sehr ähnlich zu 502 Bad Gateway, weist aber speziell auf ein Timeout hin.

Lösung:

  • Nginx-Timeouts erhöhen: Wie bei 502-Fehlern kann das Erhöhen von proxy_read_timeout, proxy_send_timeout und fastcgi_read_timeout helfen.
  • Backend-Anwendung optimieren: Die effektivste langfristige Lösung ist die Optimierung der Leistung Ihrer Backend-Anwendung, um schneller zu reagieren.
  • Backend-Logs überprüfen: Suchen Sie in den Logs Ihrer Anwendung nach lang laufenden Prozessen oder Fehlern.

7. SSL/TLS-Fehler

Fehler im Zusammenhang mit SSL-Zertifikaten können Benutzer daran hindern, sicher auf Ihre Website zuzugreifen.

Ursache: Falsche Zertifikatspfade, abgelaufene Zertifikate, nicht übereinstimmende Domainnamen oder unsachgemäße Konfiguration von SSL-Direktiven.

Lösung:

  • Zertifikatspfade überprüfen: Stellen Sie sicher, dass die ssl_certificate- und ssl_certificate_key-Direktiven auf die richtigen, existierenden Dateien verweisen.
    nginx ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
  • Zertifikatablauf überprüfen: Verwenden Sie Tools wie openssl oder überprüfen Sie das Dashboard Ihres Zertifikatanbieters, um sicherzustellen, dass die Zertifikate nicht abgelaufen sind.
    bash openssl x509 -in /path/to/your/certificate.pem -noout -dates
  • Domain-Übereinstimmung sicherstellen: Überprüfen Sie, ob die alternativen Antragstellernamen (SANs) oder der allgemeine Name (CN) des Zertifikats den von den Benutzern aufgerufenen Domainnamen enthalten.
  • ssl_protocols und ssl_ciphers überprüfen: Stellen Sie sicher, dass Sie moderne, sichere Protokolle und Chiffriersuiten verwenden.

Client-seitige Fehler

Obwohl Nginx ein Server ist, können bestimmte Client-Verhaltensweisen oder -Konfigurationen als Probleme auftreten, die serverbezogen erscheinen könnten.

  • ERR_CONNECTION_RESET: Zeigt oft ein Netzwerkproblem zwischen Client und Server oder eine Firewall an beiden Enden an, die die Verbindung aggressiv schließt. Es kann auch darauf hindeuten, dass die Serveranwendung abstürzt und die Verbindung abrupt beendet.
  • 400 Bad Request: Bedeutet typischerweise, dass der Client eine Anfrage gesendet hat, die der Server nicht verstehen konnte (z. B. fehlerhafte Header). Dies ist bei Standardbrowsern seltener, kann aber bei benutzerdefinierten Clients oder Bots auftreten.

Best Practices zur Minimierung von Fehlern

  • Konfigurationsmanagement: Verwenden Sie Versionskontrolle für Ihre Nginx-Konfigurationsdateien. Testen Sie Konfigurationen gründlich, bevor Sie sie bereitstellen (nginx -t).
  • Protokollierung: Konfigurieren Sie eine umfassende Protokollierung und überprüfen Sie regelmäßig Ihr error.log auf Anomalien.
  • Überwachung: Implementieren Sie Überwachung für Ihren Nginx-Server und Ihre Backend-Anwendungen. Dies hilft, Probleme proaktiv zu erkennen, bevor sie Benutzer beeinträchtigen.
  • Nginx aktuell halten: Aktualisieren Sie Nginx regelmäßig auf die neueste stabile Version, um von Bugfixes und Sicherheitspatches zu profitieren.
  • Ihre Anwendungen verstehen: Haben Sie ein gutes Verständnis dafür, wie sich Ihre Backend-Anwendungen verhalten, welche Ressourcen sie benötigen und welche häufigen Fehlerursachen es gibt.

Fazit

Die Fehlerbehebung bei Nginx-Fehlern ist eine entscheidende Fähigkeit, um eine zuverlässige Webpräsenz aufrechtzuerhalten. Durch das systematische Überprüfen von Logs, das Validieren von Konfigurationen und das Verständnis gängiger Fehlermuster wie Berechtigungsprobleme, Verbindungsablehnungen und Timeouts können Sie Probleme effizient diagnostizieren und beheben. Denken Sie daran, Konfigurationsänderungen immer zu testen und Ihre Backend-Anwendungen für eine bessere Leistung und Stabilität zu optimieren. Mit diesen Praktiken können Sie Ihren Nginx-Server reibungslos am Laufen halten und Ihre Website für alle zugänglich machen.