Вашият клиент е готов да чака шестдесет секунди. Десет секунди по-късно получава HTTP 504. Увеличаването на таймаута на клиента до две минути не дава на шлюза още петдесет секунди работа.

504 описва шлюз или прокси, което не е получило навременен отговор от upstream, докато се е опитвало да завърши заявката. Шлюзът вече е взел решението си и е върнал отговор. Вашият клиент може успешно да прочете този отговор.

Кой посредник го е върнал?

Издателят може да е предното прокси. Също и по-късен шлюз, управляван от уебсайта. При обикновен TLS от край до край в CONNECT HTTP отговор от тази защитена размяна с дестинацията не е същото като отказ на самия CONNECT.

Запазете етапа, заглавките на отговора, формулировката на страницата с грешка и съответните журнали, когато са налични. Името на сървъра може да е подсказка, но не бива да се приема за безпогрешно приписване. Маршрутът може да съдържа повече посредници от този, конфигуриран в клиента ви.

След това проверете защо тази операция към upstream не е завършила. Достижимостта, претоварените услуги, тяло на заявката, което upstream не може да обработи както се очаква, и поведението на приложението могат да имат значение. Само числовият статус не доказва, че смяната на User-Agent или добавянето на една опция за таймаут е универсалното решение.

Сравнете същата заявка

Когато друг инструмент работи, сравнете метода, целта, кодирането на тялото, удостоверяването и маршрута. "URL адресът се отваря в браузър" не е пълно сравнение с multipart подаване през клиент на услуга.

Ако управлявате издаващия шлюз, съобразете неговия upstream бюджет с поддържаното натоварване и околните крайни срокове. Ако не, запазете резултата му като доказателство и използвайте документирания от оператора път за достъп или поддръжка. По-дългото локално чакане не може да промени отговор, който вече е пристигнал.

Подобни статии