Reverse Proxy NGINX: muchas respuestas de código de estado html 400, ¿por qué?

Recientemente hemos implementado un proxy inverso basado en nginx.Reverse Proxy NGINX: muchas respuestas de código de estado html 400, ¿por qué?

Mientras que, depurando nuestros registros de acceso, estamos viendo bastante código de estado 400 resultados.

Se verá algo como esto:

[07/Sep/2011:05:49:04 -0700] - "400" 0 "-" "-" "-"

hemos habilitado el registro de errores de depuración, y por lo general corresponden a algo como esto:

2011/09/07 05:09:28 [info] 5937#0: *30904 client closed prematurely connection while reading client request line

Hemos tratado de elevar un número de las memorias intermedias, como mencioné en algunas páginas pudimos googlear.

http://www.ruby-forum.com/topic/173362

http://blog.craz8.com/articles/2009/06/17/nginx-400-bad-request-errors-due-to-cookies-and-what-to-do-about-them

en vano.

¿Por qué sucede esto?

Este es un proxy nginx inverso estándar -> servidor backend apache.

Vale la pena mencionar que el tipo único de contenido en nuestro sitio es bastante mínimo. Hemos probado esto usando muchos navegadores y no estamos recibiendo personalmente ninguno de estos 400 resultados.

Gracias!

Otras direcciones URL que detallan entradas similares en sus registros:

http://blog.rayfoo.info/2009/10/weird-web-server-access-log-entries

Fuente

2011-09-07 anonymous-one

¿El primer registro es el de Apache y el segundo el de nginx? – palacsint

Negativo. El primero es el registro de acceso nginx, el segundo es el registro de error nginx configurado para depuración. –

¿Está detrás de un EC2 Elastic Load Balancer? Parte de su chequeo de salud hace que estos se registren con frecuencia en los registros. – Meekohi

primer lugar, es bastante posible que sus clientes envían solicitud con cabeceras http realmente grandes o URL. Tal vez una versión anterior de su aplicación establezca algunas (probablemente grandes) cookies que no se utilizan ahora y algunos clientes todavía intentan enviarlas de vuelta.

Establecería los almacenamientos intermedios del encabezado a un valor realmente grande y en el lado de la aplicación registrará el tamaño de los encabezados/solicitudes y la solicitud completa si son más grandes que de costumbre. O elimine por completo el nginx de la cadena y registre el encabezado/solicitud con las mismas condiciones. Si puede, elimine el nginx solo para aquellas IP/subredes de donde vinieron los 400 errores. Supongo que nginx puede registrar la dirección IP de origen para estos 400 errores.

Fuente

2011-09-11 20:56:46 palacsint

intenté establecer el tamaño máximo de encabezado en 2048k. el mismo problema persistió ya que esto está sucediendo con bastante frecuencia, intento hacer algunas ejecuciones de tcpdump ... aunque esto es en un servidor de producción muy activo, unas pocas ejecuciones de 2-3 minutos no deberían sobrecargar la caja. –

Uh, 2097152 bytes debería ser suficiente para cualquier solicitud http. tcpdump es una buena idea. Avísame si encuentras algo. – palacsint

¿Está manejando conexiones SSL? ¿Puedes agregar $ssl_cipher $ssl_protocol a tu formato de registro de acceso?

Fuente

2011-11-17 14:42:50 Jehiah

Encontré que esto fue causado por el uso de Chrome, que aparentemente abre conexiones adicionales de vez en cuando sin enviar ningún dato.

Aquí hay alguna información más: http://www.ruby-forum.com/topic/2953545

Ahora la pregunta es qué hacer con ellos - la respuesta siempre y cuando no fue muy satisfactorio.

Fuente

2012-04-20 21:01:32 Ross117

Reverse Proxy NGINX: muchas respuestas de código de estado html 400, ¿por qué?

Respuesta

Cuestiones relacionadas