HTTP 504 Gateway Timeout проти тайм-ауту вашого клієнта
Розрізняйте запит до upstream, час якого минув у шлюзі, від тайм-ауту, заданого у вашому власному проксі-клієнті.
Ваш клієнт готовий чекати шістдесят секунд. Через десять секунд він отримує HTTP 504. Збільшення тайм-ауту клієнта до двох хвилин не дає шлюзу ще п'ятдесят секунд роботи.
504 описує шлюз або проксі, який, намагаючись завершити запит, не отримав вчасної відповіді від upstream. Шлюз уже ухвалив рішення й повернув відповідь. Ваш клієнт може успішно прочитати цю відповідь.
Який посередник її повернув?
Видавцем може бути прямий проксі. А також пізніший шлюз, яким керує сайт. За звичайного наскрізного TLS усередині CONNECT відповідь HTTP із цього захищеного обміну з призначенням — не те саме, що відмова самого CONNECT.
Збережіть етап, заголовки відповіді, формулювання сторінки помилки та відповідні журнали, якщо вони доступні. Назва сервера може бути підказкою, але не повинна вважатися безпомилковим віднесенням. У маршруті може бути більше посередників, ніж той, що налаштований у вашому клієнті.
Потім з'ясуйте, чому ця операція до upstream не завершилася. Доступність, перевантажені служби, тіло запиту, яке upstream не може обробити так, як очікується, і поведінка застосунку можуть мати значення. Лише числовий статус не доводить, що зміна User-Agent або додавання однієї опції тайм-ауту є універсальним рішенням.
Порівняйте той самий запит
Коли інший інструмент працює, порівняйте метод, ціль, кодування тіла, автентифікацію та маршрут. «URL відкривається в браузері» — це не повне порівняння з надсиланням multipart через клієнт служби.
Якщо ви обслуговуєте видавничий шлюз, узгодьте його бюджет upstream із підтримуваним навантаженням і навколишніми термінами. Якщо ні, збережіть його результат як доказ і скористайтеся документованим шляхом доступу або підтримки оператора. Довше локальне очікування не може змінити відповідь, яка вже надійшла.