NGINX: tiempo de espera en sentido ascendente (110: tiempo de espera de conexión agotado) mientras se lee el encabezado de respuesta en sentido ascendente

130

Tengo a Puma ejecutándose como el servidor de aplicaciones ascendente y Riak como mi clúster de base de datos de fondo. Cuando envío una solicitud de que el mapa reduce una porción de datos para aproximadamente 25K usuarios y la devuelve desde Riak a la aplicación, aparece un error en el registro de Nginx:

tiempo de espera de flujo ascendente (110: tiempo de espera de conexión agotado) mientras se lee el encabezado de respuesta

Si consulto mi upstream directamente sin proxy nginx, con la misma solicitud, obtengo los datos requeridos.

El tiempo de espera de Nginx ocurre una vez que se coloca el proxy.

**nginx.conf**

http {
    keepalive_timeout 10m;
    proxy_connect_timeout  600s;
    proxy_send_timeout  600s;
    proxy_read_timeout  600s;
    fastcgi_send_timeout 600s;
    fastcgi_read_timeout 600s;
    include /etc/nginx/sites-enabled/*.conf;
}

**virtual host conf**

upstream ss_api {
  server 127.0.0.1:3000 max_fails=0  fail_timeout=600;
}

server {
  listen 81;
  server_name xxxxx.com; # change to match your URL

  location / {
    # match the name of upstream directive which is defined above
    proxy_pass http://ss_api; 
    proxy_set_header  Host $http_host;
    proxy_set_header  X-Real-IP  $remote_addr;
    proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_cache cloud;
    proxy_cache_valid  200 302  60m;
    proxy_cache_valid  404      1m;
    proxy_cache_bypass $http_authorization;
    proxy_cache_bypass http://ss_api/account/;
    add_header X-Cache-Status $upstream_cache_status;
  }
}

Nginx tiene un montón de directivas de tiempo de espera. No sé si me estoy perdiendo algo importante. Cualquier ayuda sería muy apreciada....

usuario2768537
fuente
Solo debería agotar el tiempo de espera después de 600 s. Puede simularlo para configurarlo en un servidor tcp en 127.0.0.1:3000 que solo acepta conexiones y no hace nada con ellas, para ver cuánto tiempo lleva. Debería ser 600s ...
rogerdpack

Respuestas:

47

Esto sucede porque su flujo ascendente tarda demasiado en responder la solicitud y NGINX cree que el flujo ascendente ya no pudo procesar la solicitud, por lo que responde con un error. Simplemente incluya e incremente proxy_read_timeout en el locationbloque de configuración. Me pasó lo mismo y usé 1 hora de tiempo de espera para una aplicación interna en el trabajo:

proxy_read_timeout 3600;

Con esto, NGINX esperará una hora (3600s) para que su flujo ascendente devuelva algo.

Sergio Gonzalez
fuente
66
Tenga proxy_read_timeouten cuenta que tener en la sección http podría no ayudar. Tengo la proxy_passdirectiva en la sección de ubicación y solo allí la proxy_read_timeoutconfiguración marcó la diferencia. (nginx 1.16.0)
JonnyJD
Parece que funciona en http / server / location para mí ... tal vez las cosas han cambiado :)
rogerdpack
39

Siempre debe abstenerse de aumentar los tiempos de espera, dudo que el tiempo de respuesta del servidor de fondo sea el problema aquí en cualquier caso.

Resolví este problema borrando la bandera de mantener viva la conexión y especificando la versión http según la respuesta aquí: https://stackoverflow.com/a/36589120/479632

server {
    location / {
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_set_header   Host      $http_host;

        # these two lines here
        proxy_http_version 1.1;
        proxy_set_header Connection "";

        proxy_pass http://localhost:5000;
    }
}

Desafortunadamente, no puedo explicar por qué funciona esto y tampoco logré descifrarlo de los documentos mencionados en la respuesta vinculada, por lo que si alguien tiene una explicación, me interesaría mucho escucharla.

Almund
fuente
1
¿Por qué no ajustaría proxy_read_timeoutsi supiera que el proxy (incluso para una URL específica) requiere más tiempo de procesamiento?
Josh M.
¡Hola! Ya no recuerdo el problema exacto, pero creo que no estaba relacionado con el tiempo real de la URL, sino que el tiempo de espera no se procesaba correctamente sin esta configuración.
Almund
@magicbacon esto fue hace años, así que apenas recuerdo el caso, pero, ¿cambiaste el $http_hostderecho? Supongo que eso no volaría para https. Es posible que también se requieran configuraciones adicionales para enviar proxy a las solicitudes https.
Almund
+1 ... esto parece un truco incómodo, pero en realidad es de los documentos oficiales :) nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive Tengo un problema ligeramente diferente "conexión ascendente cerrada prematuramente mientras leía la respuesta header from upstream "cuando uso la directiva upstream con keepalive y el uso de estas dos líneas parece solucionarlo.
Karussell
1
@TimDavis Ya veo, tal vez eso sea mejor. Supongo que podría depender del tráfico, como en esta publicación diciendo que es necesario para WebSockets: serverlab.ca/tutorials/linux/web-servers-linux/…
Almund
26

Primero descubra qué flujo ascendente se está desacelerando consultando el archivo de registro de errores nginx y ajuste el tiempo de lectura en consecuencia en mi caso fue fastCGI

2017/09/27 13:34:03 [error] 16559#16559: *14381 upstream timed out (110: Connection timed out) while reading response header from upstream, client:xxxxxxxxxxxxxxxxxxxxxxxxx", upstream: "fastcgi://unix:/var/run/php/php5.6-fpm.sock", host: "xxxxxxxxxxxxxxx", referrer: "xxxxxxxxxxxxxxxxxxxx"

Entonces tengo que ajustar fastcgi_read_timeout en la configuración de mi servidor

 location ~ \.php$ {
     fastcgi_read_timeout 240;
     ...
 }

Ver: publicación original

Ruberandinda Paciencia
fuente
Aquí hay una manera de agregar información de tiempo, la falla para ver cuánto "necesita" aumentarlo a: stackoverflow.com/questions/18627469/… FWIW
rogerdpack
10

En su caso, ayuda a una pequeña optimización en el proxy, o puede usar "# configuración de tiempo de espera"

location / 
{        

  # time out settings
  proxy_connect_timeout 159s;
  proxy_send_timeout   600;
  proxy_read_timeout   600;
  proxy_buffer_size    64k;
  proxy_buffers     16 32k;
  proxy_busy_buffers_size 64k;
  proxy_temp_file_write_size 64k;
  proxy_pass_header Set-Cookie;
  proxy_redirect     off;
  proxy_hide_header  Vary;
  proxy_set_header   Accept-Encoding '';
  proxy_ignore_headers Cache-Control Expires;
  proxy_set_header   Referer $http_referer;
  proxy_set_header   Host   $host;
  proxy_set_header   Cookie $http_cookie;
  proxy_set_header   X-Real-IP  $remote_addr;
  proxy_set_header X-Forwarded-Host $host;
  proxy_set_header X-Forwarded-Server $host;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
Dimitrios
fuente
Para mí, hace la diferencia tener estas configuraciones en la sección de ubicación . Tenerlos en la sección http no ayudó (posiblemente porque yo también tuve proxy_passen la sección de ubicación .)
JonnyJD
¿Qué estás optimizando exactamente con estas declaraciones?
Vlad
9

Creo que este error puede ocurrir por varias razones, pero puede ser específico del módulo que está utilizando. Por ejemplo, vi esto usando el módulo uwsgi, así que tuve que configurar "uwsgi_read_timeout".

Ricardo
fuente
2
Creo que uwsgi_read_timeout 3600; proxy_send_timeout 3600; proxy_read_timeout 3600; funciona para mi.
tyan
9

Recomendaría mirar el error_logs, específicamente en la parte ascendente, donde se muestra un flujo ascendente específico que está agotando el tiempo de espera.

Luego, según eso, puede ajustar proxy_read_timeout, fastcgi_read_timeouto uwsgi_read_timeout.

También asegúrese de que su configuración esté cargada.

Más detalles aquí Nginx upstream expiró (por qué y cómo solucionarlo)

Gansbrest
fuente
4

Como muchos otros han señalado aquí, aumentar la configuración del tiempo de espera para NGINX puede resolver su problema.

Sin embargo, aumentar la configuración del tiempo de espera puede no ser tan sencillo como sugieren muchas de estas respuestas. Yo mismo enfrenté este problema e intenté cambiar la configuración de mi tiempo de espera en el archivo /etc/nginx/nginx.conf , como sugieren casi todos en estos hilos. Esto no me ayudó un poco; no hubo cambios aparentes en la configuración de tiempo de espera de NGINX. Ahora, muchas horas después, finalmente pude solucionar este problema.

La solución se encuentra en este hilo del foro , y lo que dice es que debe poner su configuración de tiempo de espera en /etc/nginx/conf.d/timeout.conf (y si este archivo no existe, debe crearlo). Usé la misma configuración que se sugiere en el hilo:

proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;
Andreas Forslöw
fuente
1

Tuve el mismo problema y resultó que era un error "todos los días" en el controlador de rieles. No sé por qué, pero en producción, puma ejecuta el error una y otra vez causando el mensaje:

tiempo de espera de flujo ascendente (110: tiempo de espera de conexión agotado) mientras se lee el encabezado de respuesta

Probablemente porque Nginx intenta obtener los datos de puma una y otra vez. Lo curioso es que el error causó el mensaje de tiempo de espera incluso si estoy llamando a una acción diferente en el controlador, por lo tanto, un solo error tipográfico bloquea toda la aplicación.

Verifique su archivo log / puma.stderr.log para ver si esa es la situación.

aarkerio
fuente
0

Por nuestro lado, estaba usando spdy con caché proxy. Cuando la caché caduca, obtenemos este error hasta que la caché se haya actualizado.

Timhaak
fuente
0

Espero que ayude a alguien: me encontré con este error y la causa era un permiso incorrecto en la carpeta de registro de phpfpm, después de cambiarlo para que phpfpm pudiera escribir, todo estaba bien.

Maurício Otta
fuente
0

Para el proxy_upstreamtiempo de espera, probé la configuración anterior pero no funcionó.

La configuración resolver_timeoutfuncionó para mí, sabiendo que me estaba tomando 30 segundos producir el mensaje de tiempo de espera ascendente. Por ejemplo, me.atwibble.com no se pudo resolver (110: Se agotó el tiempo de espera de la operación) .

http://nginx.org/en/docs/http/ngx_http_core_module.html#resolver_timeout

David Mercer
fuente