प्रॉक्सी त्रुटि 502 "कारण: रिमोट सर्वर से पढ़ने में त्रुटि" Apache 2.2.3 (डेबियन) mod_proxy और जेट लिंक 6.1.38 के साथ

Question

अपाचे बंदरगाह पर अनुरोध प्राप्त कर रहे हैं: 80 और उन्हें जेट्टी बंदरगाह पर: 8080 पर प्रॉक्सिमेट कर रहे हैं

The proxy server received an invalid response from an upstream server
The proxy server could not handle the request GET /.

मेरी दुविधा: सब कुछ सामान्य रूप से ठीक काम करता है (तेज़ अनुरोध, कुछ सेकंड या कुछ दसियों सेकंड लंबे अनुरोध ठीक होते हैं )। समस्याएँ तब होती हैं जब अनुरोध प्रसंस्करण में लंबा समय लगता है (कुछ मिनट?)।

अगर मैं पोर्ट पर सीधे जेट्टी के बजाय अनुरोध जारी करता हूं : 8080 अनुरोध ठीक है। इसलिए समस्या यह है कि मैं Apache और Jetty के बीच कहीं बैठ सकता हूँ जहाँ मैं mod_proxy का उपयोग कर रहा हूँ । इसे कैसे हल करें?

मैंने पहले से ही बिना भाग्य के KeepAlive सेटिंग्स से संबंधित कुछ "ट्रिक्स" आज़माए हैं । यहाँ मेरा वर्तमान विन्यास है, कोई सुझाव?

#keepalive Off                     ## I have tried this, does not help
#SetEnv force-proxy-request-1.0 1  ## I have tried this, does not help
#SetEnv proxy-nokeepalive 1        ## I have tried this, does not help
#SetEnv proxy-initial-not-pooled 1 ## I have tried this, does not help
KeepAlive 20                       ## I have tried this, does not help
KeepAliveTimeout 600               ## I have tried this, does not help
ProxyTimeout 600                   ## I have tried this, does not help

NameVirtualHost *:80
<VirtualHost _default_:80>
    ServerAdmin [e-mail]

    ServerName www.mydomain.fi

    ServerAlias mydomain.fi mydomain.com mydomain www.mydomain.com

    ProxyRequests On
    ProxyVia On
    <Proxy *>
            Order deny,allow
            Allow from all
    </Proxy>

    ProxyRequests Off
    ProxyPass / http://www.mydomain.fi:8080/ retry=1 acquire=3000 timeout=600
    ProxyPassReverse / http://www.mydomain.fi:8080/

    RewriteEngine On
    RewriteCond %{SERVER_NAME} !^www\.mydomain\.fi
    RewriteRule /(.*) http://www.mydomain.fi/$1 [redirect=301L]

    ErrorLog /var/log/apache2/error.log

    # Possible values include: debug, info, notice, warn, error, crit,
    # alert, emerg.
    LogLevel warn

    CustomLog /var/log/apache2/access.log combined
    ServerSignature On

</VirtualHost>

यहाँ भी एक असफल अनुरोध से डीबग लॉग है:

74.125.43.99 - - [29/Sep/2010:20:15:40 +0300] "GET /?wicket:bookmarkablePage=newWindow:com.mydomain.view.application.reports.SaveReportPage HTTP/1.1" 502 355 "https://www.mydomain.fi/?wicket:interface=:0:2:::" "Mozilla/5.0 (Windows; U; Windows NT 6.1; fi; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10"
[Wed Sep 29 20:20:40 2010] [error] [client 74.125.43.99] proxy: error reading status line from remote server www.mydomain.fi, referer: https://www.mydomain.fi/?wicket:interface=:0:2:::
[Wed Sep 29 20:20:40 2010] [error] [client 74.125.43.99] proxy: Error reading from remote server returned by /, referer: https://www.mydomain.fi/?wicket:interface=:0:2:::

Comments

हाय .. मैं अभी भी इस एक के साथ फंस गया हूँ। उपरोक्त सभी सेटिंग्स ने कोशिश की और जेटी मैक्सिमलटाइम बढ़ाने से भी मदद नहीं मिली। किसी भी संकेत क्या आगे की कोशिश करने के लिए?

— मार्टिन

Answer 1

मैंने समस्या हल कर दी है। Keepalive=Onमें डाला जाना चाहिए ProxyPassconfig लाइन:

ProxyPass / http://www.dom.fi:8080/ retry=1 acquire=3000 timeout=600 Keepalive=On

देखना है कि

Keepalive=On

वहाँ? यह जटिल है ;)

Comments

मेरा मानना ​​है कि आप स्वीकृत के रूप में अपने खुद के जवाबों को चिह्नित कर सकते हैं। यह अन्य लोगों को खोजने के लिए सिस्टम में हल किए गए प्रश्न को चिह्नित करता है।

— sysadmin1138

वास्तव में आप इसे कहां रखते हैं?

— AlxVallejo

@AlxVallejo आपको अपनी कॉन्फ़िग फाइल्स यहाँ /etc/apache2/sites-enabled/ Issitenameiding.conf

— स्टीवन

हमारे पास ठीक उसी तरह की प्रॉक्सी त्रुटियाँ हैं। वे बहुत कम ही होते हैं (एक हजार अनुरोधों में से एक)। क्यों वास्तव में Keepalive=Onमहत्वपूर्ण है?

— डोकसपर

क्या यह नहीं हो सकता है timeout=600या retry=1इसके बजाय इसे ठीक करता है? (या कॉम्बो)

— मैटबायनको

Answer 2

क्या आपने सेटिंग करने की कोशिश की है setenv proxy-initial-not-pooled 1?

यहाँ संदर्भ

Comments

नहीं, इससे मदद नहीं मिली। फिर यह दौड़ की स्थिति के बारे में नहीं है, यह लंबी देरी है और बीच में कुछ होता है (जेट्टी और mod_proxy के बीच किसी तरह की गलतफहमी)।

Answer 3

यह त्रुटि तब भी हो सकती है यदि आप अपने प्रॉक्सी यूआरएल को ए के साथ समाप्त नहीं करते हैं /। या तो दोनों रास्तों का अंत होना चाहिए /और न ही।

Answer 4

लॉग को देखते हुए, ऐसा कुछ समय है जो 5 मिनट (= 300 सेकंड) पर है। प्रतिक्रिया के लिए प्रतीक्षा करने के लिए यह बहुत लंबा समय है। जब आप सीधे जेट्टी सर्वर का उपयोग करते हैं, तो क्या यह संसाधन वास्तव में प्रतिक्रिया उत्पन्न करने में लंबा समय लेता है?

यदि पांच मिनट वास्तव में संभव प्रतिक्रिया समय के भीतर है, तो आप प्रॉक्सीनेटाउट कॉन्फ़िगरेशन निर्देश को ट्विक करने का प्रयास कर सकते हैं।

आपके नेटवर्क सेट-अप के आधार पर, यह अच्छी तरह से हो सकता है कि किसी भी रखने की प्रणाली का उपयोग करने की कोशिश करने का कोई कारण नहीं है (क्या ऐप सर्वर और प्रॉक्सी के बीच फ़ायरवॉल है जो ड्रॉप सत्रों को कॉन्फ़िगर किया जा सकता है जो बहुत लंबे समय तक निष्क्रिय हैं?) , लेकिन ProxyTimeout प्रॉक्सी के व्यवहार को प्रभावित करेगा।

यदि एक ही प्रॉक्सी अन्य बैकएंड की भी सेवा करती है, तो बेहतर होगा कि वर्तमान प्रॉक्सी टाइमआउट रखें, और प्रॉक्सीपेस निर्देश में टाइमआउट कॉन्फ़िगर करें (mod_proxy प्रलेखन देखें)।

यदि, हालाँकि, प्रॉक्सी के बिना प्रतिक्रियाएँ लगातार पाँच मिनट से कुछ कम हैं, यहाँ कट-ऑफ सीमा के रूप में देखते हैं, तो वास्तव में प्रॉक्सी और ऐप सर्वर के बीच कुछ विषम हस्तक्षेप हो सकता है, लेकिन आप कुछ भी प्रदान नहीं कर रहे हैं यह क्या हो सकता है की पहचान करने के लिए मूल्य।

Comments

"जब आप सीधे जेट्टी सर्वर का उपयोग करते हैं, तो क्या यह संसाधन वास्तव में प्रतिक्रिया उत्पन्न करने में लंबा समय लेता है?" -- हाँ। मैंने भी इस ProxyTimeout को 600 पर सेट करने की कोशिश की। मदद नहीं करता प्रॉक्सी और जेटी के बीच कोई फ़ायरवॉल नहीं है। ProxyPass में टाइमआउट भी कॉन्फ़िगर किया गया है।

"आप यह क्या हो सकता है इसकी पहचान के लिए कुछ भी मूल्य नहीं दे रहे हैं": मुझे नहीं पता कि यह क्या हो सकता है। सर्वर से मुझे एक त्रुटि संदेश मिल रहा है: प्रॉक्सी त्रुटि प्रॉक्सी सर्वर को अपस्ट्रीम सर्वर से एक अवैध प्रतिक्रिया मिली। प्रॉक्सी सर्वर अनुरोध प्राप्त नहीं कर सका /। कारण: दूरस्थ सर्वर से पढ़ने में त्रुटि

प्रॉक्सी टाइमआउट को बढ़ाने के लिए, क्या इसने आपके ब्राउज़र को 502 त्रुटि होने से पहले स्पिन करने के समय को भी बदल दिया?

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

मुझे पता है कि यह धीमा क्यों है। मुझे नहीं पता कि अपाचे प्रॉक्सी प्रतिक्रिया को मना क्यों करता है जब यह आखिरकार तैयार होता है।

Answer 5

मेरे लिए Transfer-Encoding" (binary)मेरे सर्वर-ऐप (PHP) में हेडर वैल्यू को हटाने से समस्या हल हो गई है:

[xy_http: error] [pid 17623] (22) अमान्य तर्क: [ग्राहक 127.0.0.1.144929] AH01102: दूरस्थ सर्वर से त्रुटि पढ़ने की स्थिति 0.0.0.0:80

अन्य सभी सुझाव जैसे कि SetEnv proxy-initial-not-pooledया Keep-Aliveनहीं।

Answer 6

यदि उपरोक्त समाधान काम नहीं करते हैं, तो एक चीज जो आप आजमा सकते हैं, वह है कि आप अपने सभी अपाचे मॉड्यूल को यह सुनिश्चित करने में सक्षम करें कि ऐसा कोई मॉड्यूल नहीं है जिसकी आपको आवश्यकता है कि किसी तरह गलती से विकलांग हो गया।

उदाहरण के लिए, मुझे कैसे पता चला कि मेरी समस्या का कारण मेरे सभी अपाचे कॉन्फिग फाइलों में लोडमैड्यूल के साथ #LadModule के सभी उदाहरणों को बदलना था। चूँकि मेरे लिए यह समस्या हल हो गई थी, इसलिए मैं जानता था कि मेरी समस्या "लापता" निर्देश संबंधी तर्क नहीं थी, बल्कि, मेरी समस्या एक लापता निर्भरता थी।

क्योंकि, याद रखें, .so फाइलें मूल रूप से स्टैटिक लाइब्रेरी हैं। एक मॉड्यूल सक्षम होने का मतलब यह नहीं है कि इसका उपयोग किया जाएगा, लेकिन एक अक्षम होने का मतलब यह है कि इसका उपयोग नहीं किया जा सकता है, और इसलिए, जो कुछ भी इस पर निर्भर करता है वह आवश्यक रूप से विफल हो जाएगा।

नोट: इस उत्तर को इस तथ्य के कारण कुछ डाउन वोट प्राप्त हुए हैं कि मेरा प्रारंभिक उत्तर सभी मॉड्यूल को हमेशा के लिए सक्षम करने का सुझाव देता है। हालांकि आप सैद्धांतिक रूप से ऐसा कर सकते हैं कि बिना किसी चीज को तोड़ने के, यह स्पष्ट रूप से सबसे अच्छा अभ्यास समाधान नहीं है।

तो, कृपया समझें, मैं इसे केवल एक समस्या निवारण कदम के रूप में सुझा रहा हूं, अंतिम समाधान नहीं।

इसके अलावा, कृपया ध्यान दें: मैं अपने सभी स्थानीय मशीन के अपाचे विन्यास फाइल को ट्रैक करने के लिए एक विशेष गिट परियोजना का उपयोग करता हूं। इस तरह मैं अपने अपाचे कॉन्फिग वर्किंग डाइरेक्टरी में ग्लोबल सर्च-एंड-रिप्लेस ऑपरेशंस के इन कर सकते हैं, एक समस्या निवारण कदम के रूप में। यदि सभी मॉड्यूल को सक्षम करना सफल हो जाता है, तो उन्हें फिर से एक-एक करके अक्षम करने का प्रयास करें और बीच-बीच में अपाचे को फिर से चालू करें, जब तक कि आपको यह पता न हो जाए कि कौन सा मॉड्यूल सक्षम होना चाहिए। एक बार जब आप यह पता लगा लेते हैं, तो रेपो को उसकी मूल स्थिति में वापस सेट कर लेते हैं, और केवल उस एक मॉड्यूल को सक्षम करते हैं जिसे सक्षम रहने की आवश्यकता होती है।

आपको यह भी पता चलेगा कि आपकी अपाचे कॉन्फिग फाइलों को ट्रैक करने के लिए git का उपयोग करने से आप उन डाइरेक्टरीज़ को क्लीन कर सकते हैं, क्योंकि आपको उन-फ़ैशन-.bak और .default फ़ाइल्स की ज़रूरत नहीं होगी।

Comments

प्रत्येक पुस्तकालय एक अलग विशेषता लाता है, जो कि छद्म से संबंधित नहीं है

— अर्नोल्ड रोआ