Nginx

Lösung für 504 Bad Gateway nginx Fehlermeldung

Ich erhalte seit kurzen ein 504 nginx Bad Gateway error Code, wenn ich meine Webseite besuche. Ich habe schon viele Anleitungen im Internet befolgt. Leider hat bisher nichts dieses Problem lösen können. Ich weiss nicht woran es liegt. Kann mir jemand helfen den nginx Bad Gateway Fehler zu beheben?

Bild des Benutzers Codemaster

nginx wartet vergeblich auf Antwort

Answer to the question: 
1934
Vote the answer: 
5
Average: 5 (1 vote)

             

504 Bad Gateway Time-out nginx/1.15.5

 

Wenn man im Internet eine Webseite aufruft, so sendet der Server bei jeder Anfrage einen HTTP-Statuscode. Wenn man anstelle der Webseite nur eine weiße Webseite mit einem HTTP-Statuscode sieht, so kann dies sehr verschiedene Ursachen haben. Eine Übersicht über alle möglichen HTTP-Statuscodes findet Ihr hier auf Wikipedia.

 

Um herauszufinden warum genau ein 504 Bad Gateway nginx HTTP-Statuscode angezeigt wird, muss man zunächst verstehen, wie eine Serveranfrage von einem Browser ausgehend auf dem Server beantwortet wird. Eine Anfrage beginnt meist durch die Eingabe einer Internet-Adresse in den Browser oder einen Klick auf ein Element auf der Webseite. Die daraus resultierende HTTP-Anfrage wird dann an große DNS-Server weitergeleitet. Dort wird dann der Domain eine IP-Adresse zugewiesen, so dass die Eingabe an den richtigen Server gesendet wird. Auf dem Zielserver sind meist mehrere inerinander verbundene Systeme für die Beantwortung eines versendeten HTTP-Requests verantwortlich. Man spricht in diesem Zusammenhang von einem Stack. 

 

Stark vereinfachte bildliche Darstellung eines LAMP Softwarestacks:

Häufig kommen heute spezielle Linux/ Varnish/ Memcached/ Apache/ Nginx/ PHP/ Mysql Softwarestack-Konfigurationen zum Einsatz, um Serveranfragen intern zu verarbeiten. Natürlich gibt es auch noch unzählige weitere Softwarestack-Konfigurationen. In dem genannten Beispiel ist Nginx häufig als Netzwerk-Gateway konfiguriert, um HTTP-Anfragen an den Apache Webserver weiterzuleiten. Ein Netzwerk-Gateway ist im Prinzip ein Vermittler zwischen häufig auch zwischen einander inkompatiblen Systemen. So kann der Apache Webserver nicht ohne weiteres HTTPS-Anfragen verstehen. NGINX kann dieses Protokoll lesen und so weiterleiten, dass der Apache Server etwas damit anfangen kann. Darüber hinaus kommen auch noch weitere Systeme, wie z.B. Varnish oder Memcached zum Einsatz, um wiederholte Anfragen in den schnelleren Arbeitsspeicher auszulagern. Auch Varnish kann HTTPS-Anfragen nicht direkt bearbeiten. Die Aufgabe des Vermittlers übernimmt hier NGINX, welches in unserem Beispiel als Netzwerk-Gateway konfiguriert ist. Jede einzelne Kommunikationsstation arbeitet wie in einem Schweizer-Präzisionsuhrwerk zusammen und erfüllt seine ganz speziellen Aufgaben, um die Serveranfragen so effizient und schnell wie möglich zu verarbeiten. Es ist aber nicht nur der Softwarestack, welcher für die Verarbeitung und Weiterleitung der Daten verantwortlich ist. Auch die Hardware muss einwandfrei funktionieren. Fällt eines dieser Kommunikationsstationen aus, so kommt es zu einer Zeitüberschreitung. In diesem Fall sieht dann der Benutzer nur ein weißes Browserfenster mit der nginx Bad Gateway 504 Meldung. Um den Fehler zu beheben, muss man also identifizieren, welches der Kommunikationsstationen ausgefallen ist. Hier findet Ihr eine Übersicht über die häufigsten Fehlermeldungen in diesem Zusammenhang:

 

  • "Bad Gateway Timeout 504 NGINX"
  • "NGINX Bad Gateway Timeout 504"
  • "HTTP 504 Gateway Timout NGINX"
  • "504 Gateway Timeout NGINX"
  • "Gateway Timeout 504 NGINX"

 

Ein Gateway 504 nginx Error bedeutet, dass nginx in der Kommunikationskette auf eine Antwort eines anderen Webservers bzw. einer Netzwerkschnittstelle einen zu langen Zeitraum warten muss. Deshalb kommt es zu einer Gateway-Zeitüberschreitung. Die Zeitspanne, die erforderlich ist, um die "Bad Gateway Timeout 504" Meldung auszulösen, ist in den einzelnen Konfigurationsdateien der Softwarestackkomponenten festgelegt. Als Beispiel weisen PHP, Apache, NGINX, Plesk und FastCGI Konfigurationsdateien auf, wo Änderungen der Timeout-Einstellungen vorgenommen werden können. Dazu später mehr.

 

Zunächst einmal sollte man sich darüber im Klaren sein, dass ein nginx Gateway 504 Error nicht aus heiterem Himmel auftritt. Meist liegt eine Veränderung in der Systemkonfiguration oder Hardware vor, so dass ein Skript oder eine Hardwarekomponente die zugewiesenen Aufgaben nicht mehr in der vorgegebenen Zeit erledigt. Viele Anleitungen im Internet zeigen, wie man die Zeitspanne erhöhen kann, um die Meldung nicht mehr angezeigt zu bekommen. Leider ist damit in den meisten Fällen keinesfalls das Problem gelöst. Ein besserer Ansatz wäre es, wenn man identifiziert, was genau für den Timeout verantwortlich ist. Falls das Problem innerhalb der php-fpm auftritt, so kann man mittels slow-log langsame Skripte identifizieren. Dazu muss man dann die Konfigurationsdatei des Pools anpassen:

sudo vi /etc/php-fpm.d/www.conf
slowlog = /var/log/php-fpm/www-slow.log
request_slowlog_timeout = 3s

In dem gezeigten Beispiel werden alle php Skripte, die zur Ausführung länger als 3 Sekunden benötigen, in die Logfiles geschrieben.

 

Liste möglicher Ursachen für einen nginx Bad Gateway 504 Error:

  1. Der DNS-Server ist ausgefallen oder viel zu langsam. Kontaktieren Sie Ihren Domain-Provider, um eine Überprüfung der DNS-Server einzuleiten. Alternativ können Sie auch die Nameserver in der Domain-Konfiguration ändern. Google stellt z.B. schnelle und zuverlässige Namensserver kostenlos zur Verfügung.
     
  2. Das Netzwerk im Rechenzentrum ist überlastet oder ausgefallen. In diesem Fall wären alle gehosteten Webseiten auf diesem Server von dem Ausfall betroffen. Ein Router, Switch oder Proxy-Server im Rechenzentrum könnte sich z.B. in Folge eines technischen Defekts oder einer Überlastung verabschiedet haben. Hier sollte man den Provider kontaktieren, um einen Hardwaredefekt auszuschließen. Ein Hardwarereset kann bei einer abgestürzten Hardwarekomponente auch geeignet sein, um das Problem zu lösen.
     
  3. Die Proxyeinstellungen können sowohl beim Client als auch beim Server falsch eingestellt sein. Man sollte also überlegen, ob man vor der 504 nginx Bad Gateway Fehlermeldung die Einstellungen des Proxy-Servers geändert hat.
     
  4. Der lokale Router könnte falsch konfiguriert oder abgestürzt sein. Funktionieren andere Webseiten im Internet ohne Probleme, so kann diese Ursache außer Betracht gezogen werden. Auf https://downforeveryoneorjustme.com/ kann man überprüfen, ob die Webseite für jeden im Internet unerreichbar ist.
     
  5. Falls Sie einen Proxy-Server verwenden, um den Webserver zu entlasten und beobachten können, dass es häufig dann zu einer nginx Bad Gateway 504 Timeout Fehlermeldung kommt, wenn der Traffic besonders hoch ist, dann ist das ein Anzeichen dafür, dass die Hardware aufgestockt werden sollte. In diesem Fall sollten Sie zusätzliche Hardware-Ressourcen kaufen oder mieten und ins System einbinden. Bei einer Cloudlösung ist das Handling um einiges flexibler. Bei einer Cloudlösung können Hardwareresourcen flexibel jederzeit an den Bedarf angepasst werden. Um zu überprüfen wie ausgelastet der jeweilige Server ist, kann man mittels

    free -h

    die Arbeitsspeicherbelegung sowie die CPU-Auslastung ermitteln. Um zu sehen welche Prozesse für eine hohe      Serverauslastung verantwortlich sind kann man folgenden Befehl ausführen:

    top

     

  6. In einem Serververbund kommen häufig Image- oder Cacheserver zum Einsatz. Diese Server dienen dem Zweck den File- und Datenbankserver zu entlasten. Ist einer dieser zusätzlichen Server nicht mehr zu erreichen, so kommt es zu einer 504 Bad Gateway Timeout Fehlermeldung, da die angeforderten Daten nicht verfügbar sind. Alle im Serververbund eingebundenen Server sollten also richtig funktionieren.
     

  7. Es kann auch sein, dass eine neu installierte Komponente oder ein eingesetzter Code mit einer speziellen Softwarestack-Komponenten-Version inkompatibel ist. Hat man z.B. vor der Fehlermeldung die PHP Version aktualisiert, so kann es sein, dass zuvor funktionierender Code nicht mehr richtig ausgeführt werden kann. Hierbei empfiehlt es sich unter

    /var/log/nginx/error.log
    /var/www/vhosts/system
    /example.com/logs/proxy_error_log

    die Logfiles einmal aufmerksam anzuschauen. Auch wenn man die Informationen auf den ersten Anblick nicht richtig versteht. Meist finden sich dort detaillierte Hinweise auf die Ursache des Problems.

  8. Die Webseite wurde durch Malware oder einen Virus infiziert und auf diese Weise verändert, so dass zugeteilte Aufgaben nicht mehr wie gewünscht ausgeführt werden können. Es könnte sein, dass der Server dazu umfunktioniert wurde Spam Mails zu versenden. Das wiederum könnte die Hardwareresourcen überlasten. Des Weiteren können DDos-Attacken oder Bots die Infrastruktur der Server überlasten.
     

  9. Ein vorgeschaltetes Content Delivery Network (CDN) könnte ausgefallen sein oder durch eine fehlerhafte Konfiguration nicht richtig funktionieren.
     

  10. Die Datenbanken könnten beschädigt sein. Hat man vor kurzen zum Beispiel ein Backup aufgespielt, so könnte es sein, dass die Datenbanken dadurch beschädigt wurden. In solch einem Fall muss man zunächst die Datenbanken reparieren. Für CMS-Systeme wie WordPress oder Drupal gibt es zum Reparieren und Aufräumen der Datenbank spezielle Module. Je nach System kommen ganz unterschiedliche Datenbanken zum Einsatz wie z.B. MySQL, MariaDB oder ApacheSolr.
     

  11. Bei der Verwendung eines Content Management Systems (CMS) wie WordPress oder Drupal könnte ein zuvor installiertes und fehlerhaftes Plugin für die Zeitüberschreitung bei der internen Datenverarbeitung verantwortlich sein.
     

  12. Die htaccess Datei könnte falsch konfiguriert sein. Dies könnte auf Grund einer fehlerhaften Änderung oder speziell bei neu aufgesetzten Systemen der Fall sein.
     

  13. Zu guter Letzt kann es sein, dass die Webseite einige sehr komplexe und zeitintensive Aufgaben ausführt, die schlicht und ergreifend die intern definierten Timeout-Zeitspannen überschreiten. In solch einem Fall sollte man die Konfigurationsdateien anpassen.

     

Hier sind die gängigsten Konfigurationsdateien für die Timeout-Einstellungen der einzelnen Stack Komponenten aufgeführt. In den jeweiligen Konfigurationsdateien können die Vorgaben für die Timeout Zeitspanne angepasst werden:

Apache (httpd.conf)

Timeout 1000

#Restart Apache

service apache2 restart

PHP (php.ini)
 

max_execution_time 1000

#Restart Apache

service apache2 restart

NGINX (/etc/nginx/nginx.conf Alternativ neue Datei unter /etc/nginx/conf.d/timeout.conf erstellen)
 

client_header_timeout 1000;
client_body_timeout 1000;
fastcgi_read_timeout 1000;
client_max_body_size 128m;
fastcgi_buffers 8 128k;
fastcgi_buffer_size 128k;
proxy_send_timeout 1000;
proxy_read_timeout 1000;
send_timeout 1000;
fastcgi_send_timeout 1000;

#Restart nginx

service nginx restart

Plesk

Unter Plesk kann man auch die Timeout limits individuell für jede einzelne Domain festlegen. Navigiere dazu unter Plesk zu Domains->yourdomain.com->Apache &nginx Setting und trage unter Additional nginx directives field folgendes ein:

proxy_connect_timeout 1000s;
proxy_send_timeout 1000s;
proxy_read_timeout 1000s;
fastcgi_send_timeout 1000s;
fastcgi_read_timeout 1000s;

 

Bildnachweis: 

By Karsten Adam (eigene Arbeit; Netzwerkkarte von OpenClipArt.org) [GFDL (http://www.gnu.org/copyleft/fdl.html)], via Wikimedia Commons

Gewerblicher Benutzer: 
Nein