HTTP 504 Gateway Timeout ընդդեմ ձեր client-ի timeout-ի
Տարբերեք gateway-ում ժամկետանց upstream հարցումը ձեր սեփական proxy client-ում սահմանված timeout-ից։
Ձեր client-ը պատրաստ է սպասել վաթսուն վայրկյան։ Տասը վայրկյան անց այն ստանում է HTTP 504։ Client-ի timeout-ը երկու րոպեի հասցնելը gateway-ին հիսուն վայրկյան լրացուցիչ աշխատանք չի տալիս։
504-ը նկարագրում է gateway կամ proxy, որը հարցումն ավարտելիս ժամանակին upstream պատասխան չի ստացել։ Gateway-ն արդեն կայացրել է իր որոշումը և վերադարձրել պատասխան։ Ձեր client-ը կարող է այդ պատասխանը հաջողությամբ կարդալ։
Ո՞ր միջնորդն է այն վերադարձրել։
Թողարկողը կարող է լինել forward proxy-ն։ Կարող է լինել նաև ավելի ուշ gateway, որը վարում է կայքը։ CONNECT-ի ներսում սովորական end-to-end TLS-ի դեպքում այդ պաշտպանված նպատակակետ փոխանակումից եկող HTTP պատասխանը նույնը չէ, ինչ հենց CONNECT-ի մերժումը։
Պահեք փուլը, պատասխանի վերնագրերը, սխալի էջի ձևակերպումը և համապատասխան log-երը, երբ դրանք հասանելի են։ Սերվերի պիտակը կարող է հուշում լինել, սակայն չպետք է ընդունվի որպես անսխալ վերագրում։ Երթուղին կարող է ավելի շատ միջնորդներ պարունակել, քան ձեր client-ում կարգավորված մեկը։
Այնուհետև ուսումնասիրեք, թե ինչու այդ upstream գործողությունը չավարտվեց։ Հասանելիությունը, ծանրաբեռնված ծառայությունները, հարցման մարմինը, որը upstream-ը չի կարող մշակել սպասված ձևով, և հավելվածի վարքը կարող են նշանակություն ունենալ։ Միայն թվային կարգավիճակը չի ապացուցում, որ User-Agent-ի փոփոխությունը կամ մեկ timeout ընտրանքի ավելացումը համընդհանուր լուծում է։
Համեմատեք նույն հարցումը
Երբ այլ գործիք աշխատում է, համեմատեք մեթոդը, նպատակը, մարմնի կոդավորումը, նույնականացումը և երթուղին։ «URL-ը բացվում է բրաուզերում» արտահայտությունը լրիվ համեմատություն չէ ծառայության client-ով multipart ուղարկման հետ։
Եթե դուք եք վարում թողարկող gateway-ը, համաձայնեցրեք նրա upstream բյուջեն աջակցվող ծանրաբեռնվածության և շրջապատող ժամկետների հետ։ Եթե ոչ, պահեք նրա արդյունքը որպես ապացույց և օգտագործեք օպերատորի փաստաթղթավորված մուտքի կամ աջակցության ուղին։ Տեղում ավելի երկար սպասելը չի կարող փոխել արդեն հասած պատասխանը։