HTTP 504 Gateway Timeout срещу таймаута на вашия клиент
Разграничете заявката към upstream, чието време е изтекло в шлюза, от таймаута, зададен в собствения ви прокси клиент.
Вашият клиент е готов да чака шестдесет секунди. Десет секунди по-късно получава HTTP 504. Увеличаването на таймаута на клиента до две минути не дава на шлюза още петдесет секунди работа.
504 описва шлюз или прокси, което не е получило навременен отговор от upstream, докато се е опитвало да завърши заявката. Шлюзът вече е взел решението си и е върнал отговор. Вашият клиент може успешно да прочете този отговор.
Кой посредник го е върнал?
Издателят може да е предното прокси. Също и по-късен шлюз, управляван от уебсайта. При обикновен TLS от край до край в CONNECT HTTP отговор от тази защитена размяна с дестинацията не е същото като отказ на самия CONNECT.
Запазете етапа, заглавките на отговора, формулировката на страницата с грешка и съответните журнали, когато са налични. Името на сървъра може да е подсказка, но не бива да се приема за безпогрешно приписване. Маршрутът може да съдържа повече посредници от този, конфигуриран в клиента ви.
След това проверете защо тази операция към upstream не е завършила. Достижимостта, претоварените услуги, тяло на заявката, което upstream не може да обработи както се очаква, и поведението на приложението могат да имат значение. Само числовият статус не доказва, че смяната на User-Agent или добавянето на една опция за таймаут е универсалното решение.
Сравнете същата заявка
Когато друг инструмент работи, сравнете метода, целта, кодирането на тялото, удостоверяването и маршрута. "URL адресът се отваря в браузър" не е пълно сравнение с multipart подаване през клиент на услуга.
Ако управлявате издаващия шлюз, съобразете неговия upstream бюджет с поддържаното натоварване и околните крайни срокове. Ако не, запазете резултата му като доказателство и използвайте документирания от оператора път за достъп или поддръжка. По-дългото локално чакане не може да промени отговор, който вече е пристигнал.