2011-09-07 18 views
12

हमने हाल ही में एक nginx आधारित रिवर्स प्रॉक्सी लागू किया है।एनजीआईएनएक्स रिवर्स प्रॉक्सी: कई एचटीएमएल स्टेटस कोड 400 प्रतिक्रियाएं, क्यों?

जबकि, हमारे एक्सेस लॉग डीबग करते समय, हम स्टेटस कोड 400 परिणामों का थोड़ा सा हिस्सा देख रहे हैं।

वे कुछ इस तरह दिखाई:

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

हम सक्षम किया है डिबग त्रुटि लॉगिंग, और वे आमतौर पर कुछ इस तरह के अनुरूप:

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

हम बफ़र्स के एक नंबर को ऊपर उठाने की कोशिश की है, जैसा कि कुछ पृष्ठों द्वारा उल्लेख किया गया है, हम 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

कोई लाभ नहीं हुआ है।

ऐसा क्यों हो रहा है?

यह एक मानक nginx रिवर्स प्रॉक्सी -> अपाचे बैकएंड सर्वर है।

उल्लेखनीय मूल्य, हमारी साइट पर अद्वितीय प्रकार की सामग्री काफी कम है। हमने कई ब्राउज़रों का उपयोग करके इसका परीक्षण किया है और इन 400 परिणामों में से कोई भी व्यक्तिगत रूप से प्राप्त नहीं कर रहे हैं।

धन्यवाद!


इसके अलावा यूआरएल अपने लॉग्स में इसी तरह की प्रविष्टियों का ब्यौरा:

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

+0

क्या आपका अपाचे का लॉग पहला और दूसरा nginx है? – palacsint

+0

नकारात्मक। पहला nginx एक्सेस लॉग है, दूसरा nginx त्रुटि लॉग डीबग करने के लिए सेट है। –

+1

क्या आप ईसी 2 लोचदार लोड बैलेंसर के पीछे हैं? उनके स्वास्थ्य जांच का हिस्सा इन्हें अक्सर लॉग में दर्ज किया जाता है। – Meekohi

उत्तर

0

सबसे पहले, यह काफी संभव है कि अपने ग्राहकों को वास्तव में बड़ी http हेडर या यूआरएल के साथ अनुरोध भेजें। हो सकता है कि आपके एप्लिकेशन का एक पुराना संस्करण कुछ (शायद बड़ी) कुकीज़ सेट करें जो अब अप्रयुक्त हैं और कुछ क्लाइंट अभी भी उन्हें वापस भेजने की कोशिश कर रहे हैं।

मैं हेडर बफर को वास्तव में एक बड़े मूल्य पर सेट करता हूं और एप्लिकेशन पक्ष पर हेडर/अनुरोधों के आकार को लॉग करता हूं और यदि वे सामान्य से बड़े होते हैं तो पूर्ण अनुरोध। या पूरी तरह से श्रृंखला से nginx बाहर ले और एक ही शर्तों के साथ हेडर/अनुरोध लॉग इन करें। यदि आप कर सकते हैं, केवल उन आईपी/सबनेट्स के लिए nginx निकालें जहां 400 त्रुटियां आईं। मुझे लगता है कि nginx इन 400 त्रुटियों के लिए स्रोत आईपी लॉग कर सकते हैं।

+0

ने अधिकतम हेडर आकार को 2048k पर सेट करने का प्रयास किया। एक ही मुद्दा जारी रखा। चूंकि यह काफी बार हो रहा है बीमार कुछ टीसीपीडम्प रन करने की कोशिश करता है ... यहां तक ​​कि यह एक बहुत ही सक्रिय, उत्पादन सर्वर पर है, कुछ 2-3 मिनट रन बॉक्स को ओवरलोड नहीं करना चाहिए। –

+0

उह, 20 9 7152 बाइट किसी भी http अनुरोध के लिए पर्याप्त होना चाहिए। tcpdump अच्छा विचार है। अगर आपको कुछ मिलता है तो मुझे बताएं। – palacsint

1

क्या आप SSL कनेक्शन प्रबंधित कर रहे हैं? क्या आप अपने एक्सेस लॉग प्रारूप में $ssl_cipher $ssl_protocol जोड़ सकते हैं?

8

मुझे पता चला कि यह Chrome का उपयोग करके हुआ था, जो स्पष्ट रूप से किसी भी डेटा को भेजने के बिना अतिरिक्त कनेक्शन खोलता है। - उत्तर प्रदान वहाँ बहुत संतोषजनक नहीं था http://www.ruby-forum.com/topic/2953545

अब सवाल उनके बारे में क्या करना है है:

यहां कुछ और जानकारी है।

संबंधित मुद्दे