NGINX 499 त्रुटि कोड के संभावित कारण

Question

मुझे 499 NGINX त्रुटि कोड मिल रहे हैं। मैं देख रहा हूं कि यह एक क्लाइंट साइड इश्यू है। यह NGINX या मेरे uWSGI स्टैक के साथ कोई समस्या नहीं है। मैं 499 पाने पर uWSGI लॉग में सहसंबंध पर ध्यान देता हूं।

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

मैं और अधिक गहराई से स्पष्टीकरण की तलाश कर रहा हूं और उम्मीद करता हूं कि यह मेरे एनजीआईएनएक्स कॉन्फिग के साथ कुछ भी गलत नहीं है। मैं इसे अंकित मूल्य पर ले रहा हूं। यह एक क्लाइंट इश्यू की तरह लगता है।

Comments

क्या आपको कभी इसका कोई हल मिला? मुझे uWSGI और nginx दोनों के साथ एक ही मुद्दा दिखाई देता है।

— राज

मुझे यह तब मिलता है जब मैं jQuery के AJAX अनुरोध को निरस्त कर देता हूं।

— मप्र

मुझे पता है कि यह एक बहुत पुराना प्रश्न है लेकिन एसओ पर गलत प्रश्नों की मात्रा चौंका रही है। यह स्पष्ट रूप से SF पर है।

— सोसुकोडो

Answer 1

Nginx में HTTP 499 का अर्थ है कि क्लाइंट ने सर्वर द्वारा अनुरोध का जवाब देने से पहले कनेक्शन को बंद कर दिया । मेरे अनुभव में आमतौर पर क्लाइंट साइड टाइमआउट के कारण होता है । जैसा कि मुझे पता है कि यह एक Nginx विशिष्ट त्रुटि कोड है।

Comments

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

— एंटोनी पिंसर्ड

यह नोट करना महत्वपूर्ण है कि "क्लाइंट" वास्तव में एक प्रॉक्सी हो सकता है। उदाहरण के लिए, यदि आप लोड बैलेंसर का उपयोग कर रहे हैं, तो यह समय समाप्त होने के कारण nginx सर्वर के अनुरोध को रद्द कर सकता है।

— ब्रैड कोच

यह मेरे कोणीय एपीपी पर होता है यदि उपयोगकर्ता टैब बंद कर देता है और मेरा एपीआई अनुरोध पूरा नहीं होता है।

— विवेक सौरभ

यह नोट करना महत्वपूर्ण है कि यह सर्वर के कारण भी हो सकता है ; यदि सर्वर को प्रतिक्रिया देने में बहुत अधिक समय लगता है, तो क्लाइंट देता है।

— जोजफ

Answer 2

मेरे मामले में, मैं अधीर था और लॉग की गलत व्याख्या कर रहा था।

वास्तव में, वास्तविक समस्या नगनेक्स और उव्सगी के बीच का संचार था, न कि ब्राउज़र और नग्नेक्स के बीच। अगर मैंने अपने ब्राउज़र में साइट को लोड किया था और काफी समय तक इंतजार किया था तो मुझे "504 - बैड गेटवे" मिल गया होगा। लेकिन इसमें इतना समय लगा, कि मैं सामान रखने की कोशिश करता रहा, और फिर ब्राउज़र में ताज़ा हो गया। इसलिए मैंने 504 त्रुटि को देखने के लिए लंबे समय तक इंतजार नहीं किया। ब्राउज़र में ताज़ा करते समय, जब कि पिछला अनुरोध बंद हो जाता है, और नेग्नेक्स लिखते हैं कि लॉग में 499 है।

विस्तार

यहाँ मैं यह मानूंगा कि पाठक को तब तक कम पता है जब मैंने खेलना शुरू किया था।

मेरा सेटअप एक रिवर्स प्रॉक्सी, nginx सर्वर और एक एप्लिकेशन सर्वर था, इसके पीछे uWSGI सर्वर था। क्लाइंट से सभी अनुरोध nginx सर्वर पर जाएंगे, फिर uWSGI सर्वर पर भेज दिया जाएगा, और फिर प्रतिक्रिया को उसी तरह वापस भेज दिया जाएगा। मुझे लगता है कि यह कैसे हर कोई nginx / uwsgi का उपयोग करता है और इसका उपयोग करने वाले हैं।

मेरे नगनेक्स को काम करना चाहिए जैसा कि होना चाहिए, लेकिन कुछ uwsgi सर्वर के साथ गलत था। दो तरीके (शायद अधिक) हैं जिसमें uwsgi सर्वर नेगनेक्स सर्वर का जवाब देने में विफल हो सकता है।

1) uWSGI कहता है, "मैं प्रसंस्करण कर रहा हूं, बस इंतजार करें और आपको जल्द ही प्रतिक्रिया मिल जाएगी"। nginx में समय की एक निश्चित अवधि होती है, यह 20 सेकंड fx, प्रतीक्षा करने के लिए तैयार है। उसके बाद, यह 504 त्रुटि के साथ क्लाइंट को जवाब देगा।

2) uWSGI मर चुका है, या uWSGi मर जाता है, जबकि nginx इसके लिए इंतजार कर रहा है। nginx इसे तुरंत और उस स्थिति में देखता है, यह 499 त्रुटि देता है।

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

इसलिए मैं 499 इर्रो के साथ डिबगिंग करता रहा, जिसका अर्थ है 499 त्रुटि के लिए गोलगप्पा। लेकिन अगर मैं काफी देर तक इंतजार करता, तो मुझे 504 त्रुटि मिलती। अगर मैं 504 त्रुटि प्राप्त कर लेता, तो मैं समस्या को बेहतर ढंग से समझ पाता, और फिर डिबग कर पाता।

तो निष्कर्ष यह है, कि समस्या uWGSI के साथ थी, जो लटका रहा ("थोड़ी देर प्रतीक्षा करें, अभी थोड़ी देर है, तो मेरे पास आपके लिए एक उत्तर होगा ...")।

मैंने उस समस्या को कैसे ठीक किया , मुझे याद नहीं है। मुझे लगता है कि यह बहुत सारी चीजों के कारण हो सकता है।

Comments

आपने इसे कैसे हल किया? मैं एक ही मुद्दा रहा हूँ और कारण को बताने में सक्षम नहीं हूँ।

— कॉलिन निकोल्स 16

मैंने एक विस्तार जोड़ा, दुर्भाग्य से, मुझे नहीं लगता कि यह आपकी समस्या को हल करेगा।

— मैड्स स्केजर्न

बस आपको धन्यवाद कहना चाहता था! मेरे पास ठीक वैसी ही स्थिति थी और इसने मुझे सही रास्ते पर ला खड़ा किया।

— हारून

@ शेफुल: मेरा विस्तार यह नहीं बताता है कि uWSGI के कारण क्या समस्या है, यह केवल यह बताता है कि uWSGI इसका कारण था (और नगनेक्स नहीं)। विस्तार में लक्षणों का वर्णन है और मैंने इनका गलत अर्थ कैसे निकाला। मैं आपकी निराशा को समझता हूं, लेकिन आपने मेरे उत्तर के सार को गलत समझा है। निष्ठा से।

— मैड्स स्केजर्न

बेहद उपयोगी जवाब, कभी नहीं हटा! इन अवधारणाओं को दस्तावेज़ीकरण में कहीं दूर किया जाना चाहिए, आप यह बताकर एक महान सेवा करते हैं कि यह डॉक्स की तुलना में अलग तरीके से कैसे व्यवहार करेगा!

— jerclarke

Answer 3

ग्राहक ने कनेक्शन बंद कर दिया इसका मतलब यह नहीं है कि यह एक ब्राउज़र समस्या है !? हर्गिज नहीं!

यदि आप अपने वेबसर्वर (nginx) या तो AWS या haproxy (कस्टम) के सामने एक LB (लोड बैलेंसर) रखते हैं, तो आप लॉग फ़ाइल में 499 त्रुटियां पा सकते हैं। उस ने कहा कि LB nginx के लिए एक ग्राहक के रूप में कार्य करेगा।

यदि आप के लिए haproxy डिफ़ॉल्ट मान चलाते हैं:

    timeout client  60000
    timeout server  60000

इसका मतलब यह होगा कि nginx से कोई प्रतिक्रिया नहीं होने पर, 60000ms के बाद LB बाहर हो जाएगा। व्यस्त वेबसाइट या स्क्रिप्ट के लिए समय बहिष्कार हो सकता है जिन्हें निष्पादन के लिए अधिक समय की आवश्यकता होती है। आपको टाइमआउट ढूंढना होगा जो आपके लिए काम करेगा। उदाहरण के लिए इसे बढ़ाएँ:

    timeout client  180s
    timeout server  180s

और आप शायद सेट हो जाएंगे।

आपके सेटअप के आधार पर आपको अपने ब्राउज़र में 504 गेटवे टाइमआउट त्रुटि दिखाई दे सकती है जो इंगित करता है कि php-fpm के साथ कुछ गलत है लेकिन आपकी लॉग फ़ाइलों में 499 त्रुटियों के साथ ऐसा नहीं होगा।

Answer 4

जैसा कि आप 499एक कनेक्शन गर्भपात nginx द्वारा लॉग इंगित करते हैं। लेकिन आमतौर पर यह तब उत्पन्न होता है जब आपका बैकेंड सर्वर बहुत धीमा हो रहा होता है , और दूसरा प्रॉक्सी टाइमआउट पहले या उपयोगकर्ता सॉफ्टवेयर कनेक्शन को बंद कर देता है। तो जांचें कि क्या uWSGI तेजी से उत्तर दे रहा है या नहीं, अगर uWSGI / डेटाबेस सर्वर पर कोई लोड है या नहीं।

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

अगर आपकी तरफ कोई लोडबॉलर / सीडीएन जैसे परदे के पीछे हैं ... तो आपको अपने बैकएंड को टाइमआउट करने के लिए समय-समय पर सेट करना चाहिए और उपयोगकर्ता को अन्य प्रॉक्सी को उत्तरोत्तर देना चाहिए।

यदि आपके पास है:

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

मैं आपको सेट करने की सलाह दूंगा:

• n सेकंड के लिए uWSGI टाइमआउट
• n+1 nginx मध्यांतर तक सेकंड
• n+2 बाल्कान लोड करने के लिए समय सीमा के बाद
• n+3 सीडीएन को टाइमआउट के सेकंड।

यदि आप कुछ टाइमआउट सेट नहीं कर सकते हैं (जैसे कि CDN) तो पता लगाएं कि whats इसका टाइमआउट है और इसके अनुसार दूसरों को समायोजित करें ( ... n, n-1)।

यह टाइमआउट की एक सही श्रृंखला प्रदान करता है। और आप वास्तव में पाएंगे जिसे टाइमआउट दे रहा है और उपयोगकर्ता को सही प्रतिक्रिया कोड लौटाता है।

Answer 5

मेरे मामले में मुझे 499 मिला जब क्लाइंट के एपीआई ने कोई प्रतिक्रिया मिलने से पहले कनेक्शन बंद कर दिया। सचमुच एक POST भेजा और तुरंत कनेक्शन बंद कर दिया। यह विकल्प द्वारा हल किया गया है:

xy_ignore_client_abort पर

नगनेक्स डॉक

Comments

मुझे समझ में नहीं आता कि यह मदद कैसे करता है

— व्लादिमीर स्टार्कोव

शायद यह आपका मामला नहीं है? क्लाइंट डेटा भेजता है और इसमें दिलचस्पी नहीं है कि उनके साथ क्या होगा और इसका जवाब क्या होगा। लेकिन मेरे आवेदन को डेटा को संसाधित करना चाहिए। इस विकल्प के बिना, डेटा के पास मेरे आवेदन तक पहुंचने का समय नहीं है।

— Derkkythe

धन्यवाद। सटीक लक्षण और सही समाधान।

— टीटीमो

वाह! मुझे लगभग यही चाहिए। केवल एक चीज जो मैं जोड़ूंगा - वह यह कि खुद कनेक्शन बंद करने से पहले वेबहुक स्रोत को 200 प्रतिक्रिया भेजनी होगी । अन्यथा, वे वेबहूक को निष्क्रिय कर देते हैं और न ही उन्हें फिर से भेजते हैं ... क्या मैं चयनित URL के लिए ऐसा कर सकता हूं?

— पायलेट

यह आपके क्लाइंट की प्रतिक्रिया नहीं मिलने की समस्या को हल नहीं करता है। यह आपके लॉग में केवल 499 त्रुटियों को समाप्त करता है और उन्हें स्टेटस कोड 200 से बदल देता है। ऐसा करने के लिए बुरा विचार। वास्तविक समाधान उनके टाइमआउट सेटिंग बढ़ाने के लिए अपने ग्राहक को बताने के लिए है ...

— marcinx

Answer 6

499 का वास्तव में मतलब है "ग्राहक बाधित कनेक्शन।"

मेरे पास 60 के दशक का एक क्लाइंट टाइमआउट था (और nginx में 60 के दशक का डिफ़ॉल्ट प्रॉक्सी_ड्रेड_टाइमआउट भी है)। तो मेरे मामले में क्या हो रहा था कि nginx error.log होगा upstream timed out (110: Connection timed out) while reading upstreamऔर फिर nginx "आपके द्वारा कॉन्फ़िगर किए गए बैकेंड सर्वर समूह में अगला प्रॉक्सी सर्वर होगा।" अगर आपके पास एक से अधिक हैं।

फिर यह अगले और अगले तक ( डिफ़ॉल्ट रूप से ) यह उन सभी को समाप्त कर देता है। जैसा कि हर एक बार होता है, यह उन्हें "लाइव" बैकएंड सर्वर की सूची से हटा देता है, साथ ही साथ। सब समाप्त हो जाने के बाद, यह एक रिटर्न देता है504 gateway timeout.

इसलिए मेरे मामले में nginx ने सर्वर को "अनुपलब्ध" के रूप में चिह्नित किया, इसे अगले सर्वर पर फिर से आज़माया, फिर मेरे ग्राहक का 60sसमय समाप्त हो गया (तुरंत), इसलिए मुझे एक upstream timed out (110: Connection timed out) while reading upstreamलॉग दिखाई देगा , जिसके तुरंत बाद 499 लॉग होगा। लेकिन यह सिर्फ समय का संयोग था।

सम्बंधित:

यदि समूह के सभी सर्वर वर्तमान में अनुपलब्ध के रूप में चिह्नित हैं, तो यह 502 Bad Gateway.10 के लिए भी रिटर्न करता है । यहाँ देखें max_failsऔर fail_time सराय लोग इसे कहेंगेno live upstreams while connecting to upstream.

यदि आपके सर्वर समूह में केवल एक प्रॉक्सी बैकएंड है, तो यह केवल एक सर्वर का प्रयास करता है, और एक को वापस 504 Gateway Time-outकरता है और एकल सर्वर को "लाइव" सर्वर की सूची से नहीं हटाता है, यदि proxy_read_timeoutइसे पार किया जाता है। यहां देखें "यदि किसी समूह में केवल एक ही सर्वर है, तो max_fails, fail_timeout और slow_start मापदंडों को अनदेखा किया जाता है, और ऐसे सर्वर को कभी भी अनुपलब्ध नहीं माना जाएगा।"

वास्तव में मुश्किल हिस्सा यह है कि यदि आप "लोकलहोस्ट" को प्रॉक्सी_पास निर्दिष्ट करते हैं और आपका बॉक्स एक ही समय में उस पर भी आईपीवी ६ और आईपीवी ४ "स्थान के संस्करण" होता है (अधिकांश बॉक्स डिफ़ॉल्ट रूप से करते हैं), तो यह इस तरह से गिनेगा आपके सर्वर समूह में कई सर्वरों की एक "सूची", जिसका अर्थ है कि आप इसे केवल 10 सर्वरों के लिए "102 के लिए 502" वापस होने की स्थिति में प्राप्त कर सकते हैं । यहां देखें "यदि एक डोमेन नाम कई पते पर हल होता है, तो उन सभी का उपयोग राउंड-रॉबिन फैशन में किया जाएगा।" एक वर्कअराउंड इसे ipv6 और ipv4 दोनों proxy_pass http://127.0.0.1:5001;से बचने के लिए (इसके ipv4 एड्रेस) के रूप में घोषित करना है । तब यह "केवल एक ही सर्वर" व्यवहार के रूप में गिना जाता है।

वहाँ कुछ अलग सेटिंग्स आप एक समस्या के इस "कम" बनाने के लिए tweak कर सकते हैं। टाइमआउट बढ़ाने या इसे बनाने की तरह यह सर्वरों को "अक्षम" के रूप में चिह्नित नहीं करता है, जब वे टाइमआउट करते हैं ... या सूची को ठीक करना इसलिए यह केवल आकार 1 है, ऊपर देखें :)

इसे भी देखें: https://serverfault.com/a/783624/27813

Answer 7

यह त्रुटि php-fpm के साथ मानक nginx विन्यास का उपयोग कर पुन: पेश करने के लिए बहुत आसान है।

एक पृष्ठ पर F5 बटन को नीचे रखने से सर्वर को दर्जनों ताज़ा अनुरोध मिलेंगे। प्रत्येक पिछले अनुरोध को नए सिरे से ब्राउज़र द्वारा रद्द कर दिया जाता है। मेरे मामले में मुझे अपने ग्राहक की ऑनलाइन शॉप लॉग फाइल में दर्जनों 499 मिले। एक nginx दृष्टिकोण से: यदि प्रतिक्रिया ग्राहक को अगले ताज़ा अनुरोध से पहले वितरित नहीं की गई है तो nginx 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)

अगर php-fpm प्रोसेसिंग में अधिक समय लगता है (जैसे कि हैवीपी WP पेज) तो इससे समस्याएँ हो सकती हैं। मैंने उदाहरण के लिए php-fpm क्रैश के बारे में सुना है, लेकिन मेरा मानना ​​है कि उन्हें xmlrpc.php पर कॉल को संभालने जैसी सेवाओं को ठीक से कॉन्फ़िगर करने से रोका जा सकता है।

Answer 8

... एक Google खोज से यहां आया था

मुझे उत्तर कहीं और मिला -> https://stackoverflow.com/a/15621223/1093174

जो मेरे AWS इलास्टिक लोड बैलेंसर के कनेक्शन निष्क्रिय समय-सीमा को बढ़ाने के लिए था!

(मैं nginx / अपाचे रिवर्स प्रॉक्सी के साथ एक Django साइट सेटअप किया था, और वास्तव में वास्तव में वास्तव में बैकएंड नौकरी / दृश्य लॉग इन करता हूं।)

Answer 9

एक बार जब मैं 499 मिला "एंटीवायरस द्वारा अनुरोध अनुरोध किया गया है" एक AJAX http प्रतिक्रिया के रूप में (हल्के हेरास्टिक विश्लेषण के साथ कैसपर्सकी इंटरनेट सुरक्षा द्वारा गलत सकारात्मक, गहरी हेरास्टिक विश्लेषण सही ढंग से जानता था कि कुछ भी गलत नहीं था)।

Answer 10

मुझे इस समस्या का सामना करना पड़ा और इसका कारण ब्राउज़र पर कास्परस्की प्रोटेक्शन प्लगइन था। यदि आप इसका सामना कर रहे हैं, तो अपने प्लगइन्स को अक्षम करने का प्रयास करें और देखें कि क्या यह आपकी समस्या को हल करता है।

Answer 11

इस व्यवहार के कारणों में से एक आप httpके uwsgiबजाय के लिए उपयोग कर रहे हो सकता है socket। यदि आप uwsgiसीधे उपयोग कर रहे हैं तो नीचे दिए गए कमांड का उपयोग करें।

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

.Ini फ़ाइल में समान कमांड है

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

Answer 12

यह ओपी प्रश्न का उत्तर नहीं देता है, लेकिन जब से मैं एक उत्तर के लिए उग्रता से खोज करने के बाद यहां समाप्त हुआ, मैं जो हमने खोजा था उसे साझा करना चाहता था।

हमारे मामले में, यह पता चलता है कि ये 499 अपेक्षित हैं। जब उपयोगकर्ता कुछ खोज बॉक्स में टाइप-फ़ॉरवर्ड फ़ीचर का उपयोग करते हैं, उदाहरण के लिए, हम लॉग में ऐसा कुछ देखते हैं।

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]

इसलिए हमारे मामले में मुझे लगता है कि इसका उपयोग सुरक्षित है proxy_ignore_client_abort onजो पिछले उत्तर में सुझाया गया था। उसके लिए धन्यवाद!

Answer 13

अपने हिस्से के लिए मैंने सक्षम किया था ufwलेकिन मैं अपनी अपस्ट्रीम पोर्ट्स को उजागर करना भूल गया था ।_

Answer 14

मेरे मामले में, मेरे पास सेटअप की तरह है

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

मैंने ECS (php-fpm) सेवा के लिए गलत AWS सुरक्षा समूह कॉन्फ़िगर किया था, इसलिए Nginx php-fpm कार्य कंटेनर तक पहुंचने में सक्षम नहीं था। इसलिए मुझे nginx टास्क लॉग में त्रुटियां हो रही थीं

499 0 - elb-healthchecker/2.0

स्वास्थ्य जांच को php-fpm सेवा की जाँच के रूप में कॉन्फ़िगर किया गया था और इसकी पुष्टि करता है और प्रतिक्रिया देता है।

Answer 15

मुझे पता है कि यह एक पुराना धागा है, लेकिन यह ठीक उसी तरह से मेल खाता है जो हाल ही में मेरे साथ हुआ था और मुझे लगा था कि मैं इसे यहाँ दस्तावेज़ित करूँगा। सेटअप (डॉकर में) इस प्रकार है:

• nginx_proxy
• nginx
• वास्तविक ऐप चलाने वाला php_fpm।

अनुप्रयोग लॉगिन प्रांप्ट पर यह लक्षण "502 गेटवे टाइमआउट" था। पाए गए लॉग की जांच:

• बटन एक HTTP के माध्यम से काम करता POSTहै /login... और इसलिए ...
• नेगनेक्स-प्रॉक्सी को /loginअनुरोध मिला , और आखिरकार एक टाइमआउट की सूचना दी।
• नगनेक्स ने एक 499प्रतिक्रिया लौटा दी, जिसका अर्थ है "मेजबान मर गया।"
• /loginअनुरोध सभी (!) पर प्रकट नहीं किया था एफ पी एम सर्वर लॉग में!
• FPM ... nada, शून्य, zippo, कोई भी ट्रेसबैक या त्रुटि-संदेश नहीं थे।

यह पता चला कि समस्या लॉगिन को सत्यापित करने के लिए डेटाबेस से कनेक्ट करने में विफलता थी। लेकिन यह कैसे पता लगाया जाए कि यह शुद्ध अनुमान है।

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