Reverse Proxy NGINX: molte risposte del codice di stato 400 dello html, perché?

Abbiamo recentemente implementato un proxy inverso basato su nginx.Reverse Proxy NGINX: molte risposte del codice di stato 400 dello html, perché?

Mentre eseguiamo il debug dei nostri registri di accesso, vediamo un bel po 'di risultati del codice di stato 400.

Essi simile a questa:

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

abbiamo abilitato la registrazione degli errori di debug, e di solito corrispondono a qualcosa di simile:

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

Abbiamo provato sollevando una serie di buffer, come menzionato da poche pagine, siamo riusciti a risalire su Google.

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

inutilmente.

Perché sta succedendo?

Questo è un proxy inverso di nginx standard -> server di backend di apache.

Vale la pena menzionare, il tipo unico di contenuto sul nostro sito è abbastanza minimo. Abbiamo testato questo utilizzando molti browser e non stiamo ricevendo personalmente nessuno di questi 400 risultati.

Grazie!

Ulteriori gli URL che dettagliano le voci simili nei loro log:

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

fonte

2011-09-07 anonymous-one

È il primo registro il registro di Apache e il secondo il nginx? – palacsint

Negativo. Il primo è il log di accesso di nginx, il secondo è il log degli errori di nginx impostato per il debug. –

Sei dietro un sistema di bilanciamento del carico elastico EC2? Parte del loro healthcheck fa sì che questi vengano registrati di frequente nei log. – Meekohi

primo luogo, è abbastanza possibile che i client inviano richiesta con veramente grandi intestazioni HTTP o URL. Forse una versione precedente della tua applicazione ha impostato alcuni (probabilmente grandi) cookie che sono inutilizzati ora e alcuni client stanno ancora cercando di rimandarli indietro.

Avrei impostato i buffer dell'intestazione su un valore molto grande e sul lato applicazione registra le dimensioni delle intestazioni/richieste e la richiesta completa se sono più grandi del solito. O estrarre completamente il nginx dalla catena e registrare l'intestazione/richiesta con le stesse condizioni. Se puoi, elimina il nginx solo per quegli IP/subnet da cui provengono i 400 errori. Suppongo che nginx possa registrare l'IP sorgente per questi 400 errori.

fonte

2011-09-11 20:56:46 palacsint

ha provato a impostare la dimensione massima dell'intestazione su 2048k. lo stesso problema persisteva. dal momento che questo sta accadendo abbastanza frequentemente malato, provate a fare qualche sessione di tcpdump ... anche se questo è su un server di produzione molto attivo, alcune corse di 2-3 minuti non dovrebbero sovraccaricare la scatola. –

Uh, 2097152 byte dovrebbero essere sufficienti per qualsiasi richiesta http. tcpdump è una buona idea. Fammi sapere se trovi qualcosa. – palacsint

Si gestiscono connessioni SSL? È possibile aggiungere $ssl_cipher $ssl_protocol al formato del registro di accesso?

fonte

2011-11-17 14:42:50 Jehiah

Ho trovato questo è stato causato utilizzando Chrome, che apparentemente apre le connessioni extra di tanto in tanto senza l'invio di dati.

Ecco qualche informazione in più: http://www.ruby-forum.com/topic/2953545

Ora la domanda è che cosa fare su di loro - la risposta fornita non c'era molto soddisfacente.

fonte

2012-04-20 21:01:32 Ross117

Reverse Proxy NGINX: molte risposte del codice di stato 400 dello html, perché?

risposta

Problemi correlati