Errores de nginx "recv() falló (104: Connection reset by peer) while reading response header from upstream"

Tengo un servidor que funcionaba bien hasta el 3 de octubre de 2013 a las 10:50am cuando empezó a devolver intermitentemente errores "502 Bad Gateway" al cliente.

Aproximadamente 4 de cada 5 peticiones del navegador tienen éxito, pero alrededor de 1 de cada 5 fallan con un 502.

El registro de errores de nginx contiene muchos cientos de estos errores;

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"

Sin embargo, el registro de errores de PHP no contiene ningún error que coincida.

**¿Hay alguna manera de hacer que PHP me dé más información sobre por qué está restableciendo la conexión?

Esto es 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;

}

Y este es el .conf para este sitio;

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;
}
Administración del sistema
nginx php
5º octubre 2013 в 11:28
74 vistas
Solución

Siempre confío en que mis servidores web me digan: 502 Bad Gateway.

  • ¿cuál es el tiempo de actividad de su proceso fastcgi/nginx?
  • ¿monitorea las conexiones de red?
  • ¿puede confirmar o negar un cambio en el número de visitantes ese día?

¿Qué significa?

  • su proceso fastcgi no es accesible por nginx; ya sea muy lento o no corresponde en absoluto. bad gateway significa: nginx no puede fastcgi_pass a ese recurso definido 127.0.0.1:9000; en ese momento específico.

  • su error-logs inicial lo dice todo:

.

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???

desde mi limitado punto de vista, sugeriría:

  • reiniciar su fastcgi_process / servidor
  • compruebe su registro de acceso
  • habilitar el registro de depuración
that guy from over there
Respuesta editada 31º marzo 2014 в 3:51
Comentarios (4)

Quizás quieras considerar este git en github: https://gist.github.com/amichaelgrant/90d99d7d5d48bf8fd209

Me encontré con una situación similar, cuando revisé los registros de error de mis servidores upstream estaban reportando algún error de ulimit así que lo aumenté a 1000000(en ambas cajas upstream y nginx) y todo funcionó bien

Michael Hampton
Respuesta editada 11º noviembre 2014 в 5:51
Comentarios (0)

En mi caso del mismo problema, simplemente reinicié el servicio php-fpm y se solucionó.

sudo service php5-fpm restart

O algunas veces este problema sucede debido a la gran cantidad de solicitudes. Por defecto el pm.max_requests en php5-fpm puede ser 100 o menos.

Para solucionarlo aumente su valor dependiendo de las peticiones de su sitio, por ejemplo 500.

Y después de que usted tiene que reiniciar el servicio

shgnInc
Respuesta editada 10º noviembre 2015 в 6:09
Comentarios (0)