nginx-Fehler "recv () fehlgeschlagen (104: Verbindung von Peer zurückgesetzt) ​​beim Lesen des Antwort-Headers vom Upstream"

Ich habe einen Server, der bis zum 3. Oktober 2013 um 10:50 Uhr in Ordnung war, als er anfing, zeitweise "502 Bad Gateway" -Fehler an den Client zurückzugeben.

Ungefähr 4 von 5 Browseranforderungen sind erfolgreich, aber ungefähr 1 von 5 schlagen mit einer 502 fehl.

Das nginx-Fehlerprotokoll enthält viele hundert dieser Fehler.

2013/10/05 06:28:17 [error] 3111#0: *54528 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 66.249.66.75, server: www.bec-components.co.uk  request: ""GET /?_n=Fridgefreezer/Hotpoint/8591P;_i=x8078 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "www.bec-components.co.uk"

Das PHP-Fehlerprotokoll enthält jedoch keine übereinstimmenden Fehler.

Gibt es eine Möglichkeit, PHP dazu zu bringen, mir weitere Informationen darüber zu geben, warum die Verbindung zurückgesetzt wird?

Das ist nginx.conf;

user              www-data;
worker_processes  4;
error_log         /var/log/nginx/error.log;
pid               /var/run/nginx.pid;

events {
   worker_connections  1024;
}

http {
  include          /etc/nginx/mime.types;
  access_log       /var/log/nginx/access.log;

  sendfile               on;
  keepalive_timeout      30;
  tcp_nodelay            on;
  client_max_body_size   100m;

  gzip         on;
  gzip_types   text/plain application/xml text/javascript application/x-javascript text/css;
  gzip_disable "MSIE [1-6]\.(?!.*SV1)";

  include /gvol/sites/*/nginx.conf;

}

Und das ist das .conffür diese Seite;

server {

  server_name   www.bec-components.co.uk bec3.uk.to bec4.uk.to bec.home;
  root          /gvol/sites/bec/www/;
  index         index.php index.html;

  location ~ \.(js|css|png|jpg|jpeg|gif|ico)$ {
    expires        2592000;   # 30 days
    log_not_found  off;
  }

  ## Trigger client to download instead of display '.xml' files.
  location ~ \.xml$ {
    add_header Content-disposition "attachment; filename=$1";
  }

   location ~ \.php$ {
      fastcgi_read_timeout  3600;
      include               /etc/nginx/fastcgi_params;
      keepalive_timeout     0;
      fastcgi_param         SCRIPT_FILENAME  $document_root$fastcgi_script_name;
      fastcgi_pass          127.0.0.1:9000;
      fastcgi_index         index.php;
   }
}

## bec-components.co.uk ##
server {
   server_name   bec-components.co.uk;
   rewrite       ^/(.*) http://www.bec-components.co.uk$1 permanent;
}

Ich würde immer vertrauen, wenn meine Webserver mir sagen: 502 Bad Gateway

• Was ist die Betriebszeit Ihres FastCGI / Nginx - Prozesses?
• Überwachen Sie Netzwerkverbindungen?
• Können Sie eine Änderung der Besucherzahl an diesem Tag bestätigen / verweigern?

Was heißt das:

• ihr fastcgi-prozess ist für nginx nicht zugänglich; entweder zu langsam oder überhaupt nicht entsprechend. Ein fehlerhaftes Gateway bedeutet: nginx kann nicht fastcgi_pass zu der definierten Ressource 127.0.0.1:9000; in diesem ganz bestimmten Moment .

• Ihre ersten Fehlerprotokolle sagen alles:

.

recv() failed 
    -> nginx failed

(104: Connection reset by peer) while reading response header from upstream, 
    -> no complete answer, or no answer at all
upstream: "fastcgi://127.0.0.1:9000", 
    -> who is he, who failed???

von meinem begrenzten pov würde ich vorschlagen:

• Starten Sie Ihren fastcgi_process / server neu
• Überprüfen Sie Ihr Zugangsprotokoll
• Aktivieren Sie das Debug-Protokoll

Ich weiß, dass dieses Thema alt ist, aber es taucht gelegentlich immer wieder auf. Auf der Suche nach Antworten im Internet habe ich mir die folgenden drei Möglichkeiten ausgedacht:

1. Ein Programmierfehler ist manchmal ein Fehler in php-fpm, was wiederum bedeutet, dass die Verbindung mit nginx getrennt wird. In der Regel verbleiben dabei mindestens einige Protokolle und / oder Core-Dumps, die weiter analysiert werden können.
2. Aus irgendeinem Grund kann PHP keine Sitzungsdatei schreiben (normalerweise:) session.save_path = "/var/lib/php/sessions". Dies können fehlerhafte Berechtigungen, fehlerhafte Besitzer, fehlerhafte Benutzer / Gruppen oder esoterische / obskure Probleme sein, z. B. das Fehlen von Inodes in diesem Verzeichnis (oder sogar eine vollständige Festplatte!). Dies wird normalerweise nicht viele Speicherabbilder und möglicherweise auch nichts in den PHP-Fehlerprotokollen hinterlassen.
3. Noch kniffliger ist das Debuggen: Eine Erweiterung verhält sich fehlerhaft (trifft gelegentlich eine Art inneres Limit oder ein Fehler, der nicht immer ausgelöst wird), führt zu einem Seg-Fehler und beendet damit den PHP-FPM-Prozess - und beendet damit die Verbindung mit Nginx . Die üblichen Schuldigen sind APC, memcache / d usw. (in meinem Fall war es die New Relic-Erweiterung). Die Idee hier ist also, jede Erweiterung auszuschalten, bis der Fehler verschwindet.

Habe es auch immer geschafft. Gelöst durch Erhöhen des opcacheSpeicherlimits, wenn Sie es verwenden (Ersatz für APC). Scheint, als hätte PHP-FPM Verbindungen abgebrochen, wenn der Cache zu voll wurde. Dies ist auch der Grund, warum die Antwort von shgnInc das Problem für kurze Zeit behebt.

Suchen Sie also die Datei /etc/php5/fpm/php.ini(oder eine Entsprechung in Ihrer Distribution) und erhöhen Sie sie memory_consumptionauf das für Ihre Site erforderliche Niveau. Das Deaktivieren opcachefunktioniert möglicherweise auch.

[opcache]
opcache.memory_consumption = 196 

Möglicherweise möchten Sie diesen Git auf Github berücksichtigen: https://gist.github.com/amichaelgrant/90d99d7d5d48bf8fd209

Ich habe eine ähnliche Situation festgestellt, als ich Fehlerprotokolle für meine Upstream-Server überprüfte, die einen ulimit-Fehler meldeten. Ich habe diesen auf 1000000 erhöht (sowohl für die Upstream- als auch für die Nginx-Box), und alles hat einwandfrei funktioniert

Bei demselben Problem starte ich den php-fpmDienst einfach neu , damit er behoben wird.

sudo service php5-fpm restart

Oder manchmal tritt dieses Problem aufgrund einer Vielzahl von Anfragen auf. Standardmäßig ist pm.max_requestsin php5-fpm vielleicht 100 oder weniger.

Um es zu lösen, erhöhen Sie seinen Wert abhängig von den Anforderungen Ihrer Site, zum Beispiel 500.

Und nach dem müssen Sie den Dienst neu starten

In meinem Fall hat das Deaktivieren der xdebug- Erweiterung geholfen.

Ich hatte gerade ein ähnliches Problem:

Sie stellen über Port 9000 eine Verbindung zu php-fpm her. (Fastcgi: //127.0.0.1: 9000)

Die Standardkonfiguration unter Ubuntu auf meinem Server ist:

/etc/php/7.0/fpm/pool.d/www.conf:

listen = /run/php/php7.0-fpm.sock

Sie müssen dies ändern zu:

listen = 0.0.0.0:9000

In meinem Fall habe ich meinen Server vor 1 1/2 Monaten aktualisiert und dabei meine Standardkonfiguration überschrieben. Nach dem Neustart von php-fpm trat dieser Fehler mit Verzögerung auf.

Für mich war es der Server, dem der Speicher ausgeht und PHP-FPM, der vom OOM-Killer getötet wurde. Die Lösung bestand darin, den Serverspeicher zu vergrößern.

Für mich war es, weil PHP-FPM das max_childrenLimit erreicht hat. Das PHP-FPM-Protokoll für den betreffenden Pool hat mich in die richtige Richtung geleitet

Dieses Problem kann auch auftreten, wenn ein PHP-FPM-Prozess das zugewiesene Speicherlimit überschreitet. In diesem Fall wird die Verbindung zwischen NGINX und PHP-FPM getrennt und NGINX gibt a zurück 502 Bad Gateway. Das PHP-FPM-Prozessspeicherlimit wird durch die memory_limitVariable gesteuert . Dies kann php_admin_value[memory_limit]in der PHP-FPM-Konfigurationsdatei eingestellt werden.

Es ist wichtig zu beachten, dass das Speicherlimit pro Skript gilt . Bei nPHP-FPM-Prozessen kann die Gesamtspeicherauslastung bis zu betragen memory_limit * n. Vergewissern Sie sich, dass Ihr Computer über ausreichend Speicherplatz verfügt!