এনজিআইএনএক্স 499 ত্রুটি কোডের সম্ভাব্য কারণ

Question

আমি প্রচুর 499 এনজিআইএনএক্স ত্রুটি কোড পাচ্ছি। আমি দেখতে পাচ্ছি যে এটি একটি ক্লায়েন্ট পক্ষের সমস্যা। এটি এনজিআইএনএক্স বা আমার ইউডাব্লুএসজিআই স্ট্যাকের সমস্যা নয়। আমি যখন 499 পাই তখন ইউডাব্লুএসজিআই লগগুলিতে পারস্পরিক সম্পর্ক নোট করি।

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 এজ্যাক্স অনুরোধ বাতিল করি তখন তা পেয়ে যাই।

— এমপেন

আমি জানি এটি একটি খুব পুরানো প্রশ্ন তবে এসও তে ভুল প্রশ্নাবলীর প্রশ্নের পরিমাণ বিস্ময়কর। এটি স্পষ্টভাবে এসএফ এর অন্তর্গত।

— সোসুকোডো

Answer 1

এনগিনেক্সে এইচটিটিপি 499 এর অর্থ সার্ভার অনুরোধটির উত্তর দেওয়ার আগে ক্লায়েন্টটি সংযোগটি বন্ধ করে দিয়েছে। আমার অভিজ্ঞতা সাধারণত ক্লায়েন্ট পার্শ্ব সময়সীমার কারণে হয় । আমি জানি যে এটি একটি এনগিনেক্স নির্দিষ্ট ত্রুটি কোড।

Comments

একটি বিশেষ কেস হিসাবে, আমি লক্ষ্য করেছি যে কখনও কখনও শেষ ব্যবহারকারী যখন একটি ফর্ম জমা বোতামটিতে ডাবল ক্লিক করে। ফর্মটি দু'বার প্রেরণ করা হলেও ক্লায়েন্ট কেবলমাত্র একটি প্রতিক্রিয়া প্রত্যাশিত। জেএসে প্রথমবার ক্লিক করার পরে বোতামগুলি (কমপক্ষে কয়েক সেকেন্ডের জন্য) অক্ষম করে এটি প্রায় কাজ করা যেতে পারে।

— এন্টোইন পিনসার্ড

এটি উল্লেখ করা গুরুত্বপূর্ণ যে "ক্লায়েন্ট" আসলে প্রক্সি হতে পারে important উদাহরণস্বরূপ, আপনি যদি লোড ব্যালেন্সার ব্যবহার করেন তবে এটি একটি সময়সীমার কারণে nginx সার্ভারের অনুরোধটি বাতিল করছে।

— ব্র্যাড কোচ

যদি ব্যবহারকারী ট্যাবটি বন্ধ করে দেয় এবং আমার এপিআই অনুরোধগুলি সম্পন্ন না হয় তবে এটি আমার কৌণিক অ্যাপ্লিকেশনে ঘটে।

— বিবেক সৌরভ

এটি লক্ষ্য করা গুরুত্বপূর্ণ যে এটি সার্ভারের কারণেও হতে পারে ; যদি সার্ভার সাড়া দিতে খুব বেশি সময় নেয়, ক্লায়েন্টটি ছেড়ে দেয়।

— আইজোসেফ

Answer 2

আমার ক্ষেত্রে, আমি অধৈর্য হয়েছি এবং লগটির ভুল ব্যাখ্যা দিয়ে শেষ করেছি।

আসলে, আসল সমস্যাটি ছিল এনজিনেক্স এবং উউজগির মধ্যে যোগাযোগ, না ব্রাউজার এবং এনজিনেক্সের মধ্যে। আমি যদি আমার ব্রাউজারে সাইটটি লোড করে থাকতাম এবং দীর্ঘ সময় অপেক্ষা করতাম তবে আমি একটি "504 - ব্যাড গেটওয়ে" অর্জন করতে পারতাম। তবে এটি এত দীর্ঘ সময় নিয়েছে যে আমি স্টাফ চেষ্টা করে চলেছি এবং তারপরে ব্রাউজারে রিফ্রেশ করেছি। 504 ত্রুটিটি দেখার জন্য আমি কখনই যথেষ্ট অপেক্ষা করিনি। ব্রাউজারে রিফ্রেশ করার সময়, যখন পূর্বের অনুরোধটি বন্ধ হয়, এবং এনগিনেক্স লিখেছেন যে লগটিতে 499 হিসাবে লেখা আছে।

বিবরণাদি

এখানে আমি ধরে নেব যে আমি যখন চারপাশে খেলা শুরু করি তখন পাঠক আমার মতোই কম জানেন।

আমার সেটআপটি ছিল একটি বিপরীত প্রক্সি, এনগিনেক্স সার্ভার এবং একটি অ্যাপ্লিকেশন সার্ভার, এর পেছনের ইউডাব্লুএসজিআই সার্ভার। ক্লায়েন্টের সমস্ত অনুরোধগুলি nginx সার্ভারে যাবে, তারপরে uWSGI সার্ভারে পাঠানো হবে এবং তারপরে একইভাবে প্রতিক্রিয়া পাঠানো হয়েছিল। আমি মনে করি সবাই এভাবেই এনজিনেক্স / ইউউজি ব্যবহার করে এবং এটি ব্যবহার করার কথা।

আমার এনজিনেক্স যেমনটি করা উচিত কাজ করেছিল তবে উউজি সার্ভারে কিছু ভুল ছিল। দুটি উপায় আছে (সম্ভবত আরও) যা ইউউজি সার্ভারটি এনজিএনএক্স সার্ভারটিতে প্রতিক্রিয়া জানাতে ব্যর্থ হতে পারে।

1) ইউডাব্লুএসজিআই বলে, "আমি প্রক্রিয়াজাত করছি, অপেক্ষা করুন এবং শীঘ্রই আপনি একটি প্রতিক্রিয়া পাবেন"। এনগিনেক্সের একটি নির্দিষ্ট সময়কাল থাকে, এটি অপেক্ষা করতে ইচ্ছুক, fx 20 সেকেন্ড। এর পরে, এটি 504 ত্রুটি সহ ক্লায়েন্টকে প্রতিক্রিয়া জানাবে।

2) ইউডাব্লুএসজিআই মারা গেছে, বা এনজিএনএক্স অপেক্ষা করার সময় ইউডাব্লুএসজিআই মারা যায়। nginx এখনই এটি দেখতে পায় এবং সেই ক্ষেত্রে এটি 499 ত্রুটি প্রদান করে।

আমি ক্লায়েন্ট (ব্রাউজার) এ অনুরোধ করে আমার সেটআপটি পরীক্ষা করছিলাম। ব্রাউজারে কিছুই ঘটেনি, এটি কেবল ঝুলিয়ে রাখা হয়েছে। সম্ভবত 10 সেকেন্ড পরে (সময়সীমার চেয়ে কম) আমি এই সিদ্ধান্তে পৌঁছেছি যে কিছু ঠিক নেই (যা সত্য ছিল), এবং কমান্ড লাইন থেকে uWSGI সার্ভারটি বন্ধ করে দিয়েছে। তারপরে আমি uWSGI সেটিংসে যাব, নতুন কিছু চেষ্টা করব এবং তারপরে uWSGI সার্ভারটি পুনরায় চালু করব। আমি uWSGI সার্ভারটি বন্ধ করার মুহুর্তে, nginx সার্ভারটি 499 ত্রুটি ফিরিয়ে দেবে।

সুতরাং আমি 499 এরো দিয়ে ডিবাগিং চালিয়েছি, যার অর্থ 499 ত্রুটির জন্য গুগলিং। তবে আমি যদি দীর্ঘ অপেক্ষা করতাম তবে আমি 504 ত্রুটিটি পেয়েছি। আমি যদি 504 ত্রুটিটি অর্জন করতে পারি তবে আমি সমস্যাটি আরও ভালভাবে বুঝতে সক্ষম হয়েছি এবং তারপরে ডিবাগ করতে সক্ষম হব।

সুতরাং উপসংহারটি হ'ল, সমস্যাটি ইউডাব্লুজিএসআই-এর সাথে ছিল, যা ঝুলিয়ে রেখেছিল ("কিছুক্ষণ অপেক্ষা করুন, আরও খানিকক্ষণ অপেক্ষা করুন, তবে আপনার উত্তর আমার কাছে থাকবে ...")।

আমি কীভাবে এই সমস্যাটি স্থির করেছি , মনে নেই। আমার ধারণা এটি অনেক কিছুর কারণে হতে পারে।

Comments

কিভাবে আপনি এই সমাধান শেষ? আমার একই সমস্যা আছে এবং কারণটি পিন করতে সক্ষম হইনি।

— কলিন নিকোলস

আমি একটি বিশদ যোগ করেছি, দুর্ভাগ্যক্রমে, আমি মনে করি না এটি আপনার সমস্যার সমাধান করবে।

— ম্যাডস স্কজার্ন

শুধু আপনাকে ধন্যবাদ বলতে চেয়েছিলেন! আমার ঠিক একই অবস্থা ছিল এবং এটি আমাকে সঠিক পথে ফেলেছে।

— অ্যারন

@ শাফিউল: আমার বিবরণে ইউডাব্লুএসজিআইতে সমস্যাটি কী কারণে ঘটেছে তা ব্যাখ্যা করে না, এটি কেবল ব্যাখ্যা করে যে ইউডাব্লুএসজিআই কারণ ছিল (এবং এনজিনেক্স নয়)। বিস্তারিত লক্ষণগুলি এবং কীভাবে আমি এগুলির ভুল ব্যাখ্যা করেছি তা বর্ণনা করে। আমি আপনার হতাশা বুঝতে পারি, তবে আপনি আমার উত্তরটির সারাংশ ভুল বুঝেছেন। বিনীত।

— ম্যাডস স্কজার্ন

অত্যন্ত দরকারী উত্তর, মুছুন না! এই ধারণাগুলি কোথাও ডকুমেন্টেশনে প্রকাশিত হওয়া উচিত, আপনি ডক্সের দ্বারা বোঝানো থেকে ভিন্নভাবে এটি কীভাবে আচরণ করে তা বিশদ দিয়ে আপনি দুর্দান্ত পরিষেবা করেন!

— জার্কার্ক

Answer 3

ক্লায়েন্টটি সংযোগটি বন্ধ করে দেওয়ার অর্থ এটি ব্রাউজারের সমস্যা নয় !? একেবারেই না!

আপনার ওয়েবসারভার (এনগিনেক্স) এর সামনে যদি এলডাব্লু বা হ্যাপ্রোক্সি (কাস্টম) থাকে তবে আপনার কোনও লগ ফাইলে 499 ত্রুটিগুলি খুঁজে পেতে পারেন file এটি বলেছিল যে এলবি এনজিএনএক্সের ক্লায়েন্ট হিসাবে কাজ করবে।

যদি আপনি এর জন্য হ্যাপ্রোক্সি ডিফল্ট মানগুলি চালনা করেন:

    timeout client  60000
    timeout server  60000

এর অর্থ হ'ল এনজিঙ্কস থেকে কোনও প্রতিক্রিয়া না এলে 60000 মিমি পরে এলবি শেষ হয়ে যাবে। সময় ব্যয়কারী ব্যস্ত ওয়েবসাইট বা স্ক্রিপ্টগুলির জন্য ঘটতে পারে যার প্রয়োগের জন্য আরও সময় প্রয়োজন। আপনাকে এমন সময়সীমা খুঁজে বের করতে হবে যা আপনার পক্ষে কার্যকর হবে। উদাহরণস্বরূপ এটিকে প্রসারিত করুন:

    timeout client  180s
    timeout server  180s

এবং আপনি সম্ভবত সেট করা হবে।

আপনার সেটআপের উপর নির্ভর করে আপনি আপনার ব্রাউজারে একটি 504 গেটওয়ে টাইমআউট ত্রুটি দেখতে পাচ্ছেন যা নির্দেশ করে যে পিএইচপি-এফপিএম-এ কিছু ভুল হয়েছে তবে এটি আপনার লগ ফাইলগুলিতে 499 ত্রুটির সাথে হবে না।

Answer 4

আপনি 499nginx দ্বারা লগ করা একটি সংযোগ গর্ভপাত নির্দেশ হিসাবে । তবে সাধারণত এটি তখন উত্পাদিত হয় যখন আপনার ব্যাকএন্ড সার্ভারটি খুব ধীর হয়ে চলেছে এবং অন্য একটি প্রক্সি টাইমআউট প্রথমে বা ব্যবহারকারী সফ্টওয়্যার সংযোগটি বাতিল করে দেয়। সুতরাং পরীক্ষা করুন যে ইউডাব্লুএসজিআই দ্রুত উত্তর দিচ্ছে বা ইউডাব্লুএসজিআই / ডাটাবেস সার্ভারে কোনও লোড আছে কিনা তা নয়।

অনেক ক্ষেত্রে ব্যবহারকারী এবং এনজিনেক্সের মধ্যে কিছু অন্যান্য প্রক্সি রয়েছে। কিছু আপনার অবকাঠামোতে হতে পারে যেমন কোনও সিডিএন, লোড ব্যালার, একটি বার্নিশ ক্যাশে ইত্যাদি Others অন্যরা ক্যাশে প্রক্সি ইত্যাদির মতো ব্যবহারকারীর পক্ষে থাকতে পারে etc.

যদি আপনার পাশে কোনও লোডবালেন্সার / সিডিএন এর মতো প্রক্সি থাকে ... আপনার প্রথমে আপনার ব্যাকএন্ডটি টাইমআউট করার সময়সীমা নির্ধারণ করা উচিত এবং ক্রমশ অন্যান্য ব্যবহারকারীর কাছে প্রক্সি স্থাপন করা উচিত।

যদি তোমার থাকে:

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

আমি আপনাকে সেট করতে সুপারিশ করব:

• n uWSGI সময়সীমা শেষ
• n+1 nginx সময়সীমা থেকে সেকেন্ড
• n+2 লোড ব্যালান্সারের সময়সীমা অতিক্রম করতে সানকন্ডস
• n+3 সিডিএন থেকে সময়সীমা সেকেন্ড।

আপনি যদি কিছু সময়সীমা সেট করতে না পারেন (সিডিএন এর মতো) এর সময়সীমাটি কী তা খুঁজে বের করুন এবং এটি ( n, n-1...) অনুসারে অন্যদেরকে সামঞ্জস্য করুন ।

এটি টাইমআউটগুলির একটি সঠিক শৃঙ্খলা সরবরাহ করে। এবং আপনি সত্যই খুঁজে পাবেন যার সময়সীমা দেওয়া এবং ব্যবহারকারীর কাছে সঠিক প্রতিক্রিয়া কোডটি ফিরিয়ে দিন।

Answer 5

আমার ক্ষেত্রে আমি 499 পেয়েছিলাম যখন ক্লায়েন্টের এপিআই কোনও প্রতিক্রিয়া পাওয়ার আগে সংযোগটি বন্ধ করে দেয়। আক্ষরিকভাবে একটি পোস্ট পাঠিয়েছেন এবং তত্ক্ষণাত সংযোগটি বন্ধ করুন। এটি বিকল্প দ্বারা সমাধান করা হয়েছে:

প্রক্সি_গনোর_সকল_আবার্ট চালু on

এনগিনেক্স ডক

Comments

আমি বুঝতে পারি না কীভাবে এটি সাহায্য করে

— ভ্লাদিমির স্টারকভ

সম্ভবত এটি আপনার ক্ষেত্রে না? ক্লায়েন্ট ডেটা প্রেরণ করে এবং তাদের কী হবে এবং তার উত্তর কী হবে সে বিষয়ে আগ্রহী নয়। তবে আমার অ্যাপ্লিকেশনটির ডেটা প্রক্রিয়া করা উচিত। এই বিকল্পটি ব্যতীত, ডেটাগুলিতে আমার অ্যাপ্লিকেশনটিতে পৌঁছানোর জন্য কেবল সময় নেই।

— ডেরস্কিথে

ধন্যবাদ. সঠিক লক্ষণ এবং নিখুঁত ঠিক করা।

— টিটিমো

ওহো! এটা প্রায় ঠিক কি আমি প্রয়োজন। কেবলমাত্র আমি যুক্ত করব - এটি হ'ল সংযোগটি বন্ধ করার আগে ওয়েব হুক উত্সটিতে 200 প্রতিক্রিয়া পাঠানো । অন্যথায়, তারা ওয়েবহুকগুলি অক্ষম করে এবং তাদের আবার পাঠাবে না ... আমি নির্বাচিত ইউআরএলগুলির জন্য কি এটি করতে পারি?

— পাইলেট

এটি আপনার ক্লায়েন্টের প্রতিক্রিয়া না পেয়ে সমস্যার সমাধান করে না। এটি কেবলমাত্র আপনার লগগুলিতে 499 ত্রুটিগুলি মুছে ফেলে এবং স্থিতি কোড 200 এর সাথে তাদের প্রতিস্থাপন করে this এটি করার জন্য খারাপ ধারণা। আসল সমাধানটি হ'ল আপনার ক্লায়েন্টকে তাদের সময়সীমা নির্ধারণের পরিমাণ বাড়ানোর জন্য ...

— মার্চিনেক্স

Answer 6

499 এর সত্যিকারের অর্থ হল "ক্লায়েন্ট বাধা সংযোগ" does

আমার ক্লায়েন্টের 60০ এর দশকের পাঠের টাইমআউট ছিল (এবং এনগিনেক্সেও 60 এর দশকের ডিফল্ট প্রক্সি_ড্রেডটাইমআউট রয়েছে)। সুতরাং আমার ক্ষেত্রে যা ঘটছিল তা হ'ল এনজিনেক্স ত্রুটিযুক্ত হয়ে যাবে upstream timed out (110: Connection timed out) while reading upstreamএবং একটি এনজিএনএক্স "আপনার কনফিগার করা ব্যাকএন্ড সার্ভার গ্রুপের পরবর্তী প্রক্সি সার্ভার" পুনরায় চেষ্টা করবে। এটি যদি আপনার একাধিক থাকে।

তারপরে এটি পরবর্তী এবং পরের পর্যন্ত চেষ্টা করে ( ডিফল্টরূপে ) এটি সমস্তটি শেষ করে দেয়। প্রতি এক বার আউট হওয়ার সাথে সাথে এটি তাদের "লাইভ" ব্যাকএন্ড সার্ভারের তালিকা থেকেও সরিয়ে দেয়। সমস্ত ক্লান্ত হয়ে যাওয়ার পরে, এটি a504 gateway timeout.

সুতরাং আমার ক্ষেত্রে এনগিনেক্স সার্ভারটিকে "অনুপলব্ধ" হিসাবে চিহ্নিত করেছে, পরের সার্ভারে এটি আবার চেষ্টা করল, তারপরে আমার ক্লায়েন্টের 60sসময়সীমা (তাত্ক্ষণিক) ঘটেছিল, তাই আমি একটি upstream timed out (110: Connection timed out) while reading upstreamলগ দেখতে পাব , ততক্ষনে 499 লগ লাগবে । তবে এটি ছিল কেবল সময়ের কাকতালীয় ঘটনা।

সম্পর্কিত:

গোষ্ঠীর সমস্ত সার্ভার যদি বর্তমানে অনুপলব্ধ হিসাবে চিহ্নিত করা হয়, তবে এটি 502 Bad Gateway.10 এর জন্যও একটি ফেরত দেয় । এখানে দেখুন max_failsএবং ব্যর্থ_কালআউট। ইন লগ এটি বলবেno live upstreams while connecting to upstream.

আপনার সার্ভার গোষ্ঠীতে যদি কেবলমাত্র একটি প্রক্সি ব্যাকএন্ড থাকে তবে এটি কেবল একটি সার্ভারের চেষ্টা করে এবং একটিটি ফিরে আসে 504 Gateway Time-outএবং "লাইভ" সার্ভারগুলির তালিকা থেকে একক সার্ভারকে সরিয়ে না দেয়, যদি proxy_read_timeoutছাড়িয়ে যায়। এখানে দেখুন "যদি একটি গোষ্ঠীতে কেবলমাত্র একটি সার্ভার থাকে তবে ম্যাক্সফয়েল, ব্যর্থ_কালীনআউট এবং স্লো_স্টার্ট প্যারামিটারগুলি উপেক্ষা করা হয় এবং এ জাতীয় সার্ভারটি কখনই অনুপলব্ধ বলে বিবেচিত হবে না।"

সত্যিই জটিল অংশটি হ'ল যদি আপনি "লোকালহোস্ট" -র জন্য প্রক্সি_পাস নির্দিষ্ট করে থাকেন এবং আপনার বাক্সে একই সাথে আইপিভি 6 এবং আইপিভি 4 "অবস্থানের সংস্করণ" রয়েছে (বেশিরভাগ বাক্স ডিফল্টরূপে করা হয়), এটি গণনা করা হবে যেমন আপনার ছিল আপনার সার্ভার গ্রুপে একাধিক সার্ভারের একটি "তালিকা", যার অর্থ আপনি কেবলমাত্র একটি সার্ভারের তালিকাভুক্ত হলেও "102 এর জন্য 502" ফিরিয়ে দেওয়ার উপরের অবস্থাতে যেতে পারেন । এখানে দেখুন "যদি কোনও ডোমেইনের নাম বেশ কয়েকটি ঠিকানায় সমাধান করে তবে সেগুলি সমস্ত একটি গোল-রবিন ফ্যাশনে ব্যবহৃত হবে।" একটি workaround হ'ল এটি আইপিভি 6 এবং আইপিভি 4 উভয়ই এড়াতে এটিকে proxy_pass http://127.0.0.1:5001;(এর আইপিভি 4 ঠিকানা) হিসাবে ঘোষণা করা । তারপরে এটি "শুধুমাত্র একটি একক সার্ভার" আচরণ হিসাবে গণনা করা হয়।

এই সমস্যার একটি "কম" করতে আপনি কিছুটা আলাদা আলাদা সেটিংসে টুইট করতে পারেন। সময়সীমা বাড়াতে বা এটি তৈরি করার মতো যাতে সার্ভারগুলি যখন তাদের সময়সীমা শেষ হওয়ার সাথে সাথে "অক্ষম" হিসাবে চিহ্নিত করে না ... বা তালিকাটি ঠিক করার জন্য এটি কেবলমাত্র আকার 1, উপরে দেখুন :)

আরও দেখুন: https://serverfault.com/a/783624/27813

Answer 7

এই ত্রুটিটি পিএইচপি-এফএমপি সহ স্ট্যান্ডার্ড এনজিনেক্স কনফিগারেশন ব্যবহার করে পুনরুত্পাদন করা বেশ সহজ।

কোনও পৃষ্ঠায় 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)

যদি পিএইচপি-এফপিএম প্রসেসিং বেশি সময় নেয় (একটি ভারী ডাব্লুপি পৃষ্ঠার মতো) এটি অবশ্যই সমস্যা তৈরি করতে পারে। উদাহরণস্বরূপ, আমি পিএইচপি-এফপিএম ক্র্যাশগুলির কথা শুনেছি, তবে আমি বিশ্বাস করি যে এক্সএমএলআরপিসি.পিপি-তে কল পরিচালনা করার মতো পরিষেবাগুলি সঠিকভাবে কনফিগার করতে বাধা দেওয়া যেতে পারে।

Answer 8

... একটি গুগল অনুসন্ধান থেকে এখানে এসেছেন

আমি উত্তরটি এখানে অন্যত্র পেয়েছি -> https://stackoverflow.com/a/15621223/1093174

যা ছিল আমার এইডাব্লুএস ইলাস্টিক লোড ব্যালেন্সারের সংযোগ নিষ্ক্রিয় সময়সীমা বাড়ানোর জন্য!

(আমি এনজিনেক্স / অ্যাপাচি বিপরীত প্রক্সি সহ একটি জ্যাঙ্গো সাইট সেটআপ করেছি এবং সত্যিই সত্যই লগ ব্যাকএন্ড জব / ভিউয়ের সময় শেষ হয়ে গেছে)

Answer 9

একবার আমি এজেএক্স পোস্টের প্রতিক্রিয়া হিসাবে 499 "অ্যান্টিভাইরাস দ্বারা অনুরোধ নিষিদ্ধ করা হয়েছে" পেয়েছি (হালকা হিউরিস্টিক বিশ্লেষণের সাথে ক্যাস্পারস্কি ইন্টারনেট সুরক্ষা দ্বারা মিথ্যা ইতিবাচক, গভীর তাত্ত্বিক বিশ্লেষণ সঠিকভাবে জানত যে কোনও ভুল নেই)।

Answer 10

আমি এই সমস্যার মুখোমুখি হয়েছি এবং এর কারণটি ব্রাউজারে ক্যাসপারস্কি সুরক্ষা প্লাগইন ছিল। যদি আপনি এটির মুখোমুখি হন তবে আপনার প্লাগইনগুলি অক্ষম করার চেষ্টা করুন এবং দেখুন এটি আপনার সমস্যার সমাধান করে।

Answer 11

এই আচরণের অন্যতম কারণ আপনি পরিবর্তে ব্যবহার httpকরছেন । আপনি যদি সরাসরি ব্যবহার করছেন তবে নীচের কমান্ডটি ব্যবহার করুন ।uwsgisocketuwsgi

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).

আমি ইসিএস (পিএইচপি-এফপিএম) পরিষেবাটির জন্য ভুল এডাব্লুএস সুরক্ষা গোষ্ঠীটি কনফিগার করেছিলাম, তাই এনগিনেক্স পিএইচপি-এফপিএম টাস্ক ধারকটিতে পৌঁছাতে সক্ষম হয় নি। এজন্যই আমি এনজিএনএক্স টাস্ক লগে ত্রুটি পেয়েছি

499 0 - elb-healthchecker/2.0

পিএইচপি-এফপিএম পরিষেবা যাচাই করতে এবং এটি শেষ হয়ে গেছে এবং একটি প্রতিক্রিয়া ফিরিয়ে দিতে স্বাস্থ্য পরীক্ষাটি কনফিগার করা হয়েছিল।

Answer 15

আমি জানি এটি একটি পুরানো থ্রেড, তবে এটি সম্প্রতি আমার সাথে যা ঘটেছিল তার সাথে ঠিক মেলে এবং আমি ভেবেছিলাম যে আমি এটি এখানে নথিভুক্ত করব। সেটআপ (ডকারে) নীচে রয়েছে:

• nginx_proxy
• nginx
• php_fpm আসল অ্যাপটি চালাচ্ছে

লক্ষণটি অ্যাপ্লিকেশন লগইন প্রম্পটে একটি "502 গেটওয়ে টাইমআউট" ছিল। লগের পরীক্ষা পাওয়া গেছে:

• একটি HTTP এর মাধ্যমে বাটন কাজ POSTকরতে /login... আর তাই ...
• nginx- প্রক্সিটি /loginঅনুরোধটি পেয়েছে এবং শেষ পর্যন্ত একটি সময়সীমা সম্পর্কে রিপোর্ট করেছে।
• nginx একটি 499প্রতিক্রিয়া ফিরিয়েছিল , যার অবশ্যই অর্থ "হোস্ট মারা গেছে।"
• /loginঅনুরোধ সমস্ত (!) প্রদর্শিত করা হয়নি FPM সার্ভারের লগ রয়েছে!
• এফপিএম-তে কোনও ট্রেসব্যাক বা ত্রুটি-বার্তা নেই ... নাদা, শূন্য, জিপ্পো, কিছুই নেই।

দেখা গেল যে লগইন যাচাই করার জন্য সমস্যাটি ডাটাবেসের সাথে সংযোগ করতে ব্যর্থ। তবে কীভাবে এটি নির্ধারণ করা যায় তা বিশুদ্ধ অনুমানক হিসাবে প্রমাণিত ।

অ্যাপ্লিকেশন ট্রেসব্যাক লগের সম্পূর্ণ অনুপস্থিতি ... বা এফপিএম দ্বারা অনুরোধটি পেয়েছিল এমন রেকর্ড এমনকি ... একটি সম্পূর্ণ (এবং, ধ্বংসাত্মক ...) আমার জন্য অবাক হয়েছিল। হ্যাঁ, অ্যাপ্লিকেশনটির ব্যর্থতা লগ হওয়ার কথা, তবে এই ক্ষেত্রে দেখে মনে হচ্ছে এফপিএম কর্মী প্রক্রিয়াটি রানটাইম ত্রুটির সাথে মারা গেছে, যা 499এনজিনেক্সের প্রতিক্রিয়া দেখিয়েছে। এখন, স্পষ্টতই এটি আমাদের আবেদনের সমস্যা ... কোথাও। তবে আমি পরবর্তী লোকদের উপকারের জন্য যা ঘটেছিল তার কিছু বিবরণ রেকর্ড করতে চেয়েছিলাম যারা এরকম কিছু সম্মুখীন হয়।