Posible motivo de los códigos de error NGINX 499

Recibo muchos códigos de error 499 NGINX. Veo que este es un problema del lado del cliente. No es un problema con NGINX o mi pila uWSGI. Observo la correlación en los registros de uWSGI cuando obtengo un 499.

address space usage: 383692800 bytes/365MB} {rss usage: 167038976
bytes/159MB} [pid: 16614|app: 0|req: 74184/222373] 74.125.191.16 ()
{36 vars in 481 bytes} [Fri Oct 19 10:07:07 2012] POST /bidder/ =>
generated 0 bytes in 8 msecs (HTTP/1.1 200) 1 headers in 59 bytes (1
switches on core 1760)
SIGPIPE: writing to a closed pipe/socket/fd (probably the client
disconnected) on request /bidder/ (ip 74.125.xxx.xxx) !!!
Fri Oct 19 10:07:07 2012 - write(): Broken pipe [proto/uwsgi.c line
143] during POST /bidder/ (74.125.xxx.xxx)
IOError: write error

Estoy buscando una explicación más detallada y espero que no haya nada de malo en mi configuración de NGINX para uwsgi. Lo tomo por su valor nominal. Parece un problema de cliente.

HTTP 499 en Nginx significa que el cliente cerró la conexión antes de que el servidor respondiera a la solicitud. En mi experiencia, generalmente se debe al tiempo de espera del lado del cliente . Como sé, es un código de error específico de Nginx.

En mi caso, estaba impaciente y terminé malinterpretando el registro.

De hecho, el problema real era la comunicación entre nginx y uwsgi, y no entre el navegador y nginx. Si hubiera cargado el sitio en mi navegador y hubiera esperado lo suficiente, habría obtenido un "504 - Bad Gateway". Pero tomó tanto tiempo que seguí probando cosas y luego actualicé en el navegador. Así que nunca esperé lo suficiente para ver el error 504. Cuando se actualiza en el navegador, es cuando se cierra la solicitud anterior, y Nginx escribe eso en el registro como 499.

Elaboración

Aquí asumiré que el lector sabe tan poco como yo cuando empecé a jugar.

Mi configuración era un proxy inverso, el servidor nginx y un servidor de aplicaciones, el servidor uWSGI detrás de él. Todas las solicitudes del cliente irían al servidor nginx, luego se enviarían al servidor uWSGI y luego se enviaría la respuesta de la misma manera. Creo que así es como todos usan nginx / uwsgi y se supone que deben usarlo.

Mi nginx funcionó como debería, pero algo andaba mal con el servidor uwsgi. Hay dos formas (tal vez más) en las que el servidor uwsgi puede fallar al responder al servidor nginx.

1) uWSGI dice: "Estoy procesando, solo espera y pronto recibirás una respuesta". nginx tiene un cierto período de tiempo, que está dispuesto a esperar, fx 20 segundos. Después de eso, responderá al cliente con un error 504.

2) uWSGI está muerto, o uWSGi muere mientras nginx lo está esperando. nginx lo ve de inmediato y, en ese caso, devuelve un error 499.

Estaba probando mi configuración haciendo solicitudes en el cliente (navegador). En el navegador no pasó nada, simplemente seguía colgando. Después de tal vez 10 segundos (menos que el tiempo de espera) concluí que algo no estaba bien (lo cual era cierto) y cerré el servidor uWSGI desde la línea de comando. Luego iría a la configuración de uWSGI, probaría algo nuevo y luego reiniciaría el servidor uWSGI. En el momento en que cerré el servidor uWSGI, el servidor nginx devolvería un error 499.

Así que seguí depurando con el error 499, lo que significa buscar en Google el error 499. Pero si hubiera esperado lo suficiente, habría obtenido el error 504. Si hubiera recibido el error 504, habría podido comprender mejor el problema y luego podría depurarlo.

Entonces, la conclusión es que el problema era con uWGSI, que seguía colgando ("Espera un poco más, solo un poco más, entonces tendré una respuesta para ti ...").

Cómo solucioné ese problema, no lo recuerdo. Supongo que podría deberse a muchas cosas.

¿El cliente cerró la conexión no significa que sea un problema del navegador? ¡De ningún modo!

Puede encontrar 499 errores en un archivo de registro si tiene un LB (equilibrador de carga) frente a su servidor web (nginx), ya sea AWS o haproxy (personalizado). Dicho esto, LB actuará como cliente de nginx.

Si ejecuta los valores predeterminados de haproxy para:

    timeout client  60000
    timeout server  60000

Eso significaría que LB expirará después de 60000ms si no hay respuesta de nginx. Pueden ocurrir tiempos de espera para sitios web ocupados o scripts que necesitan más tiempo para su ejecución. Necesitará encontrar un tiempo de espera que funcione para usted. Por ejemplo, extenderlo a:

    timeout client  180s
    timeout server  180s

Y probablemente estarás listo.

Dependiendo de su configuración, es posible que vea un error de tiempo de espera de puerta de enlace 504 en su navegador, lo que indica que algo está mal con php-fpm, pero ese no será el caso con errores 499 en sus archivos de registro.

Como señala 499un aborto de conexión registrado por el nginx. Pero generalmente esto se produce cuando su servidor backend está siendo demasiado lento y otro proxy se agota primero o el software del usuario aborta la conexión. Por lo tanto, verifique si uWSGI está respondiendo rápido o no o si hay alguna carga en uWSGI / servidor de base de datos.

En muchos casos, existen otros proxies entre el usuario y nginx. Algunos pueden estar en su infraestructura como tal vez un CDN, Load Balacer, un caché de Varnish, etc. Otros pueden estar en el lado del usuario como un proxy de almacenamiento en caché, etc.

Si hay proxies de su lado, como LoadBalancer / CDN ... debe establecer los tiempos de espera para que se agote primero su backend y progresivamente los otros proxies para el usuario.

Si usted tiene:

user >>> CDN >>> Load Balancer >>> Nginx >>> uWSGI

Te recomendaré que establezcas:

• n segundos para el tiempo de espera de uWSGI
• n+1 segundos para el tiempo de espera de nginx
• n+2 segundos para el tiempo de espera de Load Balancer
• n+3 segundos de tiempo de espera para el CDN.

Si no puede establecer algunos de los tiempos de espera (como CDN), busque cuál es su tiempo de espera y ajuste los demás de acuerdo con él ( n, n-1...).

Esto proporciona una cadena correcta de tiempos de espera. y encontrará quién da el tiempo de espera y devuelve el código de respuesta correcto al usuario.

En mi caso obtuve 499 cuando la API del cliente cerró la conexión antes de recibir alguna respuesta. Envió literalmente un POST y cierre inmediatamente la conexión. Esto se resuelve por opción:

proxy_ignore_client_abort en

Documento Nginx

Resulta que 499 realmente significa "conexión interrumpida por el cliente".

Tuve un tiempo de espera de lectura de cliente de 60 s (y nginx también tiene un proxy_read_timeout predeterminado de 60 s). Entonces, lo que estaba sucediendo en mi caso es que nginx produciría un error.log an upstream timed out (110: Connection timed out) while reading upstreamy luego nginx reintentaría "el siguiente servidor proxy en el grupo de servidores backend que configuró". Eso es si tienes más de uno.

Luego intenta el siguiente y el siguiente hasta que (por defecto ) los ha agotado todos. A medida que cada uno se agota, también los elimina de la lista de servidores backend "en vivo". Después de que todos están agotados, devuelve un504 gateway timeout.

Entonces, en mi caso, nginx marcó el servidor como "no disponible", lo volvió a intentar en el siguiente servidor, luego se 60sprodujo el tiempo de espera de mi cliente (inmediatamente), por lo que vería un upstream timed out (110: Connection timed out) while reading upstreamregistro, seguido inmediatamente por un registro 499. Pero fue solo una coincidencia de tiempo.

Relacionado:

Si todos los servidores del grupo están marcados como no disponibles actualmente, también devuelve un valor 502 Bad Gateway.de 10 segundos. Vea aquí max_fails y fail_timeout. En los troncos diráno live upstreams while connecting to upstream.

Si solo tiene un servidor proxy backend en su grupo de servidores, simplemente pruebe con el único servidor, y devuelve a 504 Gateway Time-outy no elimina el servidor único de la lista de servidores "en vivo", si proxy_read_timeoutes superado. Consulte aquí "Si solo hay un servidor en un grupo, los parámetros max_fails, fail_timeout y slow_start se ignoran, y dicho servidor nunca se considerará no disponible".

La parte realmente complicada es que si especifica proxy_pass a "localhost" y su caja también tiene ipv6 e ipv4 "versiones de ubicación" en él al mismo tiempo (la mayoría de las cajas lo hacen por defecto), contará como si tuviera una "lista" de varios servidores en su grupo de servidores, lo que significa que puede entrar en la situación anterior de que devuelva "502 por 10 segundos" aunque enumere sólo un servidor . Consulte aquí "Si un nombre de dominio se resuelve en varias direcciones, todas se utilizarán de forma rotatoria". Una solución es declararlo como proxy_pass http://127.0.0.1:5001;(su dirección ipv4) para evitar que sea tanto ipv6 como ipv4. Entonces cuenta como comportamiento de "un solo servidor".

Hay algunas configuraciones diferentes que puede modificar para hacer que esto sea un problema "menor". Como aumentar los tiempos de espera o hacer que no marque los servidores como "desactivados" cuando se agota el tiempo de espera ... o arreglar la lista para que sea solo de tamaño 1, ver arriba :)

Ver también: https://serverfault.com/a/783624/27813

Este error es bastante fácil de reproducir usando la configuración estándar de nginx con php-fpm.

Mantener presionado el botón F5 en una página creará docenas de solicitudes de actualización al servidor. Cada solicitud anterior es cancelada por el navegador en una nueva actualización. En mi caso, encontré docenas de 499 en el archivo de registro de la tienda en línea de mi cliente. Desde el punto de vista de nginx: si la respuesta no se ha entregado al cliente antes de la próxima solicitud de actualización, nginx registra el error 499.

mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:32 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:33 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:33 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:33 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:33 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:34 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:34 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:34 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:34 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:35 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:35 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)

Si el procesamiento de php-fpm tarda más (como una página de WP pesada), puede causar problemas, por supuesto. He oído hablar de fallas de php-fpm, por ejemplo, pero creo que se pueden evitar configurando los servicios correctamente, como manejar las llamadas a xmlrpc.php.

... vino aquí de una búsqueda en Google

Encontré la respuesta en otro lugar aquí -> https://stackoverflow.com/a/15621223/1093174

que era aumentar el tiempo de espera inactivo de la conexión de mi balanceador de carga elástico de AWS.

(Había configurado un sitio de Django con nginx / apache reverse proxy, y un trabajo / vista de backend de registro realmente se agotaba)

Una vez que obtuve 499 "La solicitud ha sido prohibida por antivirus" como una respuesta http de AJAX (falso positivo de Kaspersky Internet Security con un análisis heurístico ligero, un análisis heurístico profundo sabía correctamente que no había nada malo).

Encontré este problema y la causa se debió al complemento Kaspersky Protection en el navegador. Si se encuentra con esto, intente deshabilitar sus complementos y vea si eso soluciona su problema.

Una de las razones de este comportamiento podría ser que está usando httppara en uwsgilugar de socket. Utilice el siguiente comando si lo está utilizando uwsgidirectamente.

uwsgi --socket :8080 --module app-name.wsgi

El mismo comando en el archivo .ini es

chdir = /path/to/app/folder
socket = :8080
module = app-name.wsgi

Esto no responde a la pregunta de los OP, pero como terminé aquí después de buscar furiosamente una respuesta, quería compartir lo que descubrimos.

En nuestro caso, resulta que se esperan estos 499. Cuando los usuarios usan la función de escritura anticipada en algunos cuadros de búsqueda, por ejemplo, vemos algo como esto en los registros.

GET /api/search?q=h [Status 499] 
GET /api/search?q=he [Status 499]
GET /api/search?q=hel [Status 499]
GET /api/search?q=hell [Status 499]
GET /api/search?q=hello [Status 200]

Entonces, en nuestro caso, creo que es seguro de usar, lo proxy_ignore_client_abort onque se sugirió en una respuesta anterior. ¡Gracias por eso!

Por mi parte lo había habilitado ufwpero olvidé exponer mis puertos upstreams ._.

En mi caso, he configurado como

AWS ELB >> ECS(nginx) >> ECS(php-fpm).

Había configurado el grupo de seguridad de AWS incorrecto para el servicio ECS (php-fpm), por lo que Nginx no pudo comunicarse con el contenedor de tareas php-fpm. Es por eso que recibía errores en el registro de tareas de nginx

499 0 - elb-healthchecker/2.0

La verificación de estado se configuró para verificar el servicio php-fpm y confirmar que está activo y devolver una respuesta.

Sé que este es un hilo antiguo, pero coincide exactamente con lo que me sucedió recientemente y pensé en documentarlo aquí. La configuración (en Docker) es la siguiente:

• nginx_proxy
• nginx
• php_fpm ejecutando la aplicación real.

El síntoma era un "502 Gateway Timeout" en el indicador de inicio de sesión de la aplicación. Examen de los registros encontrados:

• el botón funciona a través de un HTTP POSTpara /login... y así ...
• nginx-proxy obtuvo el /login solicitud y, finalmente, informó un tiempo de espera.
• nginx devolvió una 499respuesta, que por supuesto significa "el host murió".
• ¡La /loginsolicitud no apareció en absoluto (!) en los registros del servidor FPM.
• no hubo rastreos o mensajes de error en FPM ... nada, zero, zippo, none.

Resultó que el problema era una falla al conectarse a la base de datos para verificar el inicio de sesión. Pero cómo averiguarlo resultó ser pura conjetura.

La ausencia total de registros de seguimiento de aplicaciones ... o incluso un registro de que FPM había recibido la solicitud ... fue una sorpresa completa (y devastadora ...) para mí. Sí, se supone que la aplicación registra fallas, pero en este caso parece que el proceso de trabajo de FPM murió con un error de tiempo de ejecución, lo que 499generó la respuesta de nginx. Ahora, esto obviamente es un problema en nuestra aplicación ... en alguna parte. Pero quería registrar los detalles de lo que sucedió para beneficio de las próximas personas que enfrentan algo como esto.