HTTP 504 Gateway Timeout વિરુદ્ધ તમારા ક્લાયન્ટનો ટાઈમઆઉટ

તમારો ક્લાયન્ટ સાઠ સેકન્ડ રાહ જોવા તૈયાર છે. દસ સેકન્ડ પછી તેને HTTP 504 મળે છે. ક્લાયન્ટનો ટાઈમઆઉટ બે મિનિટ કરવાથી ગેટવેને વધુ પચાસ સેકન્ડ કામ મળતું નથી.

504 એ એવા ગેટવે કે પ્રોક્સીનું વર્ણન છે જેણે વિનંતી પૂરી કરવાનો પ્રયાસ કરતી વખતે સમયસર અપસ્ટ્રીમ પ્રતિસાદ મેળવ્યો નહીં. ગેટવે પહેલેથી જ તેનો નિર્ણય લઈને પ્રતિસાદ પરત કરી ચૂક્યું છે. તમારો ક્લાયન્ટ તે પ્રતિસાદ સફળતાપૂર્વક વાંચી શકે છે.

કયા મધ્યસ્થે તેને પરત મોકલ્યો?

ફોરવર્ડ પ્રોક્સી જ જારી કરનાર હોઈ શકે. વેબસાઇટ દ્વારા ચલાવાતું પછીનું ગેટવે પણ હોઈ શકે. CONNECT ની અંદર સામાન્ય એન્ડ-ટુ-એન્ડ TLS સાથે, તે સુરક્ષિત ગંતવ્ય વિનિમયમાંથી આવતો HTTP પ્રતિસાદ CONNECT નો જ અસ્વીકાર જેવો નથી.

તબક્કો, પ્રતિસાદ હેડર, ભૂલ પાનાની ભાષા અને ઉપલબ્ધ હોય તો મેળ ખાતા લોગ સાચવો. સર્વરનું લેબલ સંકેત હોઈ શકે, પણ તેને અચૂક આરોપણ તરીકે ગણવું ન જોઈએ. માર્ગમાં તમારા ક્લાયન્ટમાં ગોઠવેલા એક કરતાં વધુ મધ્યસ્થ હોઈ શકે.

પછી તપાસો કે તે અપસ્ટ્રીમ કામગીરી કેમ પૂરી ન થઈ. પહોંચ, વધુ ભાર વહન કરતી સેવાઓ, અપસ્ટ્રીમ જેને અપેક્ષા મુજબ પ્રક્રિયા કરી શકતું નથી તેવું વિનંતી શરીર, અને એપ્લિકેશનનું વર્તન — બધું મહત્વનું હોઈ શકે. માત્ર સંખ્યાત્મક સ્થિતિ સાબિત કરતી નથી કે User-Agent બદલવો કે એક ટાઈમઆઉટ વિકલ્પ ઉમેરવો એ સાર્વત્રિક ઉપાય છે.

એ જ વિનંતીની સરખામણી કરો

બીજું સાધન કામ કરે ત્યારે પદ્ધતિ, લક્ષ્ય, બોડી એન્કોડિંગ, પ્રમાણીકરણ અને માર્ગની સરખામણી કરો. "URL બ્રાઉઝરમાં ખૂલે છે" એ સેવા ક્લાયન્ટ દ્વારા multipart સબમિશન સાથેની સંપૂર્ણ સરખામણી નથી.

જો તમે જારી કરનાર ગેટવે ચલાવો છો, તો તેનું અપસ્ટ્રીમ બજેટ સમર્થિત કાર્યભાર અને આસપાસની સમયમર્યાદા સાથે સુમેળમાં રાખો. જો નહીં, તો તેનું પરિણામ પુરાવા તરીકે રાખો અને ઓપરેટરના દસ્તાવેજીકૃત ઍક્સેસ કે સપોર્ટ માર્ગનો ઉપયોગ કરો. સ્થાનિક રીતે વધુ સમય રાહ જોવાથી પહેલેથી આવી ગયેલો પ્રતિસાદ બદલાતો નથી.