GNU/Linux >> Tutoriales Linux >  >> Linux

Upstream envió un encabezado demasiado grande al leer el encabezado de respuesta de upstream:error de NGINX

Mientras trabajaba en el sitio web de mi cliente, que se basa en WooCommerce, vi que la página de pago fallaba con un mensaje de error "502 Puerta de enlace incorrecta". Sospeché que el problema podría deberse a NGINX y resultó ser cierto. El registro de errores de NGINX se lee como 'upstream envió un encabezado demasiado grande al leer el encabezado de respuesta de la solicitud upstream:GET /checkout/ HTTP/1.1, upstream:fastcgi://unix:/var/run/php-fpm/php- fpm.calcetín '. En este tutorial, explicaré de qué se trata el error y cómo solucionarlo.

¿Qué significa el error "Upstream envió un encabezado demasiado grande mientras se lee"? encabezado de respuesta desde arriba” significa?

Entiendo que la página parece enviar un encabezado demasiado grande que la capacidad del extremo receptor. Pero, ¿cuál era el tamaño del encabezado que era demasiado grande para que lo manejara el servidor? Como la página que obtuve, el error era la página de pago, que incluía 10 artículos agregados al carrito. Por lo tanto, las cookies, el contenido de la página era alto y eso podría haber resultado en un tamaño de encabezado más grande. Entonces, ¿cómo encontrar lo que incluyen los encabezados de respuesta? Eso es simple.

  1. Inicie el navegador Chrome, haga clic derecho y seleccione Inspect
  2. Haga clic en Network pestaña
  3. Recargar la página
  4. Seleccione cualquiera de las solicitudes HTTP del panel izquierdo y vea los encabezados HTTP en el panel derecho.

Está bien, ya sabes ver los encabezados HTTP. Pero, ¿por qué el servidor falló con el error "Upstream envió un encabezado demasiado grande al leer el encabezado de respuesta de upstream"? Bueno, la respuesta es que cada servidor web tiene un tamaño de encabezado máximo establecido y los encabezados de solicitud HTTP enviados eran demasiado grandes que el establecido en el servidor web. A continuación se muestra el límite de tamaño máximo de encabezado en varios servidores web.

  • Servidor web Apache:8K
  • NGINX:de 4K a 8K
  • IIS (varía en cada versión):8K a 16K
  • Tomcat (varía en cada versión):8K a 48K.

Como el servidor web que estoy usando es NGINX, el límite de tamaño de encabezado predeterminado es de 4K a 8K. De forma predeterminada, NGINX usa el tamaño de página del sistema, que es 4K en la mayoría de los sistemas. Puede encontrarlo usando el siguiente comando:

# getconf PAGESIZE
4096

Aquí hay un fragmento que explica los tamaños de búfer de respuesta NGINX FastCGI.

De manera predeterminada, cuando Nginx comienza a recibir una respuesta de un backend FastCGI (como PHP-FPM), almacena la respuesta en la memoria antes de entregarla al cliente. Cualquier respuesta mayor que el tamaño de búfer establecido se guarda en un archivo temporal en el disco.

Los dos parámetros relacionados con el almacenamiento en búfer de respuesta FastCGI son:

fastcgi_buffers 
fastcgi_buffer_size

fastcgi_buffers – controla el número y el tamaño de la memoria de los segmentos de búfer utilizados para la carga útil de la respuesta FastCGI.

fastcgi_buffer_size – controla el tamaño del búfer que solía contener la primera parte de la respuesta fastCGI de los encabezados de respuesta HTTP.

De acuerdo con la documentación de NGNIX, no es necesario que ajuste el valor predeterminado de los parámetros de respuesta de fastCGI, ya que NGINX usa de forma predeterminada el tamaño de página más pequeño de 4 KB y debería ajustarse a la mayoría de las solicitudes de encabezado HTTP. Sin embargo, no parece encajar en mi caso. La misma documentación dice que algunos de los marcos pueden enviar una gran cantidad de datos de cookies a través de Set-Cookie encabezado HTTP y eso podría explotar el búfer y generar un error HTTP 500. En tales casos, es posible que deba aumentar el tamaño del búfer a 8k/16k/32k para acomodar un encabezado HTTP ascendente más grande.

Cómo encontrar los tamaños de respuesta FastCGI promedio y máximo recibidos por la web servidor?

Eso se puede averiguar haciendo grepping en los archivos de registro de acceso de NGINX. Para hacer eso, ejecute el siguiente comando proporcionando el access_log archivo como entrada

$ awk '($9 ~ /200/) { i++;sum+=$10;max=$10>max?$10:max; } END { printf("Maximum: %d\nAverage: %d\n",max,i?sum/i:0); }' access.log

Muestra en mi servidor web:

Maximum: 3501304
Average: 21065

Nota :Solo se consideró la respuesta HTTP 200 OK.

De la instantánea anterior, está claro que el tamaño promedio del búfer es más de 21K. Por lo tanto, debemos establecer el tamaño del búfer un poco más que la solicitud promedio, que probablemente sea de 32K. Para hacerlo, abra el archivo nginx.conf y agregue las siguientes líneas debajo de location sección – location ~ \.php$ { }

fastcgi_buffers 32 32k;
fastcgi_buffer_size 32k;

Nota :Es posible que deba establecer un valor de búfer menor. Había configurado 32 K porque el tamaño promedio era superior a 21 K.

Obtén más información sobre los búferes de respuesta FastCGI aquí.


Linux
  1. nginx - 413 Entidad de solicitud demasiado grande

  2. Resolución de error de Mysql:Demasiados archivos abiertos

  3. 502 Error de puerta de enlace incorrecta NGINX [Solución]

  4. Ssh:¿"error al leer la longitud de respuesta del socket de autenticación"?

  5. ¿Cómo evitar que los registros se vuelvan demasiado grandes?

Cómo almacenar en caché archivos estáticos en nginx

Solucionar el error de Nginx:413 Entidad de solicitud demasiado grande

rpm:error al cargar bibliotecas compartidas:encabezado ELF no válido

Lectura de un archivo en ensamblaje

Error al usar una versión más nueva de glibc

Yum error al instalar MongoDB en CentOS?