emperor - python django nginx uwsgi
Nginx uwsgi(104: Restablecimiento de la conexión por pares) al leer el encabezado de respuesta desde la parte superior (6)
Cuando recibimos un mensaje como (104: Connection reset by peer) while reading response header from upstream , muy a menudo, podríamos culpar al lado ascendente de este tipo de error.
Como se describió, la conexión fue restablecida por el par ascendente, no por el propio nginx. Nginx como cliente apenas puede hacer nada para hacerlo bien.
Estoy sospechando si modificar el tamaño del búfer hará la magia. Básicamente, el comando cambia el tamaño del búfer donde se almacenan los encabezados de respuesta. Esto tendría efecto cuando el encabezado de respuesta es demasiado grande, de lo que recibimos un mensaje que dice que el upstream sent too big header while reading response header from upstream , y eso es totalmente diferente del connection reset by peer .
Dado que este tipo de error se desencadena al azar, le sugiero que compruebe si nginx usa keepalive cuando habla con las fuentes ascendentes. Si este fuera el caso, la conexión podría ser restablecida por el servidor ascendente cuando el tiempo de inactividad se agotara, mientras que nginx no tenía idea de que la conexión se había caído, por lo tanto reenviando la solicitud utilizando la misma conexión.
No hay una solución elegante para arreglarlo hasta donde yo sé. Podría intentar de nuevo o establecer un valor de keepalive_timeout en el grupo de conexiones en sentido ascendente en nginx para evitar el problema.
referenciando:
Error provisional de Apache HttpClient: NoHttpResponseException
http://tengine.taobao.org/document/http_upstream_keepalive_timeout.html
El entorno es Nginx + uwsgi.
Obteniendo un error de puerta de enlace 502 de Nginx en ciertas solicitudes GET. Parece estar relacionado con la longitud de la URL. En nuestro caso particular, fue una larga lista de parámetros GET. Acorte los parámetros GET y ningún error 502.
Desde el nginx / error.log
[error] 22113#0: *1 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 192.168.1.100, server: server.domain.com, request: "GET <long_url_here>"
No hay información en el registro de error uwsgi.
Después de pasar mucho tiempo en esto, finalmente lo descubrí. Hay muchas referencias a Nginx y restablecimiento de conexión por pares. La mayoría de ellos parecían estar relacionados con PHP. No pude encontrar una respuesta específica para Nginx y uwsgi.
Finalmente encontré una referencia a fastcgi y un error de puerta de enlace 502 incorrecta ( https://support.plesk.com/hc/en-us/articles/213903705 ). Eso me llevó a buscar un límite de tamaño de búfer en la configuración de uwsgi que existe como buffer-size . El valor predeterminado es 4096. De la documentación, dice:
Si planea recibir grandes pedidos con muchos encabezados, puede aumentar este valor hasta 64k (65535).
Hay muchas formas de configurar uwsgi, por casualidad uso un archivo .ini. Entonces en mi archivo .ini probé:
buffer-size=65535
Esto solucionó el problema. Puedes ajustar eso al gusto. Tal vez comience con el máximo y trabaje hasta que tenga un valor aceptable, o simplemente lo deje al máximo.
Esto fue frustrante para rastrear porque no había ningún error en el lado uwsgi de las cosas.
Estaba obteniendo el mismo error nginx y tampoco había información en el registro uwsgi. El problema era que, en algunos casos, la aplicación no consumía todo el cuerpo de la solicitud, como se aconseja en http://uwsgi-docs.readthedocs.org/en/latest/ThingsToKnow.html :
Si una solicitud HTTP tiene un cuerpo (como una solicitud POST generada por un formulario), debe leerla (consumirla) en su aplicación. Si no lo hace, el socket de comunicación con su servidor web puede ser destruido. Si eres perezoso, puedes utilizar la opción de almacenamiento de datos de almacenamiento automático que leerá automáticamente los datos por ti. Para aplicaciones Rack, esto se habilita automáticamente.
Por supuesto, esto no es un problema en su caso, pero puede ser útil para otros que están recibiendo el mismo error nginx.
Gracias, la misma solución se adopta en el caso de un servidor PHP. Solo necesitamos aumentar el valor del atributo "output_buffering", en php.ini, a un valor mayor como 65535 u otro valor apropiado.
Necesita volver a instalar PHP:
apt-get install --reinstall php5-fpm
--post-buffering 32768 funcionó para mí según lo sugerido (y desaconsejado) aquí NGINX + uWSGI Connection Reset by Peer
No tengo tiempo para investigar más en este momento (modo de prototipado rápido :), pero como me tomó mucho tiempo encontrar este truco, valdría la pena publicarlo aquí.