HTTP 504 Gateway Timeout і тайм-аўт вашага кліента
Адрознівайце запыт да upstream, які не паспеў у шлюза, ад тайм-аўту, настроенага ў вашым кліенце проксі.
Ваш кліент гатовы чакаць шэсцьдзясят секунд. Праз дзесяць секунд ён атрымлівае HTTP 504. Павелічэнне тайм-аўту кліента да дзвюх хвілін не дае шлюзу яшчэ пяцьдзясят секунд працы.
504 апісвае шлюз або проксі, які не атрымаў своечасовага адказу ад upstream, спрабуючы завяршыць запыт. Шлюз ужо прыняў рашэнне і вярнуў адказ. Ваш кліент можа паспяхова прачытаць гэты адказ.
Які пасярэднік яго вярнуў?
Крыніцай можа быць прамы проксі. Таксама наступны шлюз, якім кіруе сайт. Пры звычайным наскрозным TLS унутры CONNECT адказ HTTP з гэтага абароненага абмену з прызначэннем не тоесны адмове ў самім CONNECT.
Фіксуйце этап, загалоўкі адказу, фармулёўку старонкі памылкі і адпаведныя журналы, калі яны даступныя. Назва сервера можа быць падказкай, але не павінна лічыцца бясспрэчнай атрыбуцыяй. У маршруце можа быць больш пасярэднікаў, чым той, што настроены ў вашым кліенце.
Затым даследуйце, чаму гэтая аперацыя upstream не завяршылася. Даступнасць, перагружаныя службы, цела запыту, якое upstream не можа апрацаваць як чакалася, і паводзіны праграмы — усё гэта можа мець значэнне. Адзін лікавы статус не даказвае, што змена User-Agent або даданне адной опцыі тайм-аўту — універсальнае рашэнне.
Параўнайце той самы запыт
Калі іншы інструмент працуе, параўнайце метад, мэту, кадаванне цела, аўтэнтыфікацыю і маршрут. "URL адкрываецца ў браўзеры" — гэта не поўнае параўнанне з адпраўкай multipart праз кліент службы.
Калі вы кіруеце шлюзам-крыніцай, узгадніце яго бюджэт upstream з падтрымліванай нагрузкай і навакольнымі тэрмінамі. Калі не, захоўвайце яго вынік як доказ і карыстайцеся дакументаваным шляхам доступу або падтрымкі аператара. Больш доўгае чаканне лакальна не можа змяніць адказ, які ўжо прыйшоў.