HTTP 504 Gateway Timeout и тайм-аут вашего клиента
Отличайте запрос к upstream, у которого истекло время в шлюзе, от тайм-аута, заданного в вашем собственном прокси-клиенте.
Ваш клиент готов ждать шестьдесят секунд. Через десять секунд он получает HTTP 504. Увеличение тайм-аута клиента до двух минут не даёт шлюзу ещё пятьдесят секунд работы.
504 описывает шлюз или прокси, который, пытаясь завершить запрос, не получил своевременный ответ от upstream. Шлюз уже принял решение и вернул ответ. Ваш клиент может успешно прочитать этот ответ.
Какой посредник его вернул?
Издателем может быть прямой прокси. А также более поздний шлюз, которым управляет сайт. При обычном сквозном TLS внутри CONNECT HTTP-ответ из этого защищённого обмена с пунктом назначения — не то же самое, что отказ самого CONNECT.
Сохраните этап, заголовки ответа, формулировку страницы ошибки и соответствующие журналы, если они доступны. Имя сервера может быть подсказкой, но не должно считаться безошибочной атрибуцией. В маршруте может быть больше посредников, чем тот, что настроен в вашем клиенте.
Затем выясните, почему эта операция на стороне upstream не завершилась. Доступность, перегруженные службы, тело запроса, которое upstream не может обработать так, как ожидается, и поведение приложения — всё это может иметь значение. Один числовой статус не доказывает, что смена User-Agent или добавление одной опции тайм-аута — универсальное решение.
Сравните тот же запрос
Если другой инструмент работает, сравните метод, цель, кодирование тела, аутентификацию и маршрут. «URL открывается в браузере» — не полное сравнение с multipart-отправкой через клиент службы.
Если вы обслуживаете издающий шлюз, согласуйте его бюджет upstream с поддерживаемой нагрузкой и окружающими сроками. Если нет, сохраните его результат как доказательство и используйте документированный путь доступа или поддержки оператора. Более долгое локальное ожидание не может изменить уже пришедший ответ.