HTTP 504 Gateway Timeout versus o tempo limite do seu cliente

O seu cliente está disposto a esperar sessenta segundos. Dez segundos depois recebe HTTP 504. Aumentar o tempo limite do cliente para dois minutos não dá à gateway mais cinquenta segundos de trabalho.

O 504 descreve uma gateway ou proxy que não recebeu uma resposta atempada do upstream enquanto tentava concluir o pedido. A gateway já tomou a sua decisão e devolveu uma resposta. O seu cliente consegue ler essa resposta sem problemas.

Que intermediário a devolveu?

O emissor pode ser o proxy direto. Também pode ser uma gateway posterior operada pelo site. Com TLS normal de ponta a ponta dentro de CONNECT, uma resposta HTTP vinda dessa troca protegida com o destino não é o mesmo que uma rejeição do próprio CONNECT.

Guarde a etapa, os cabeçalhos da resposta, o texto da página de erro e os registos correspondentes quando estiverem disponíveis. O nome do servidor pode ser uma pista, mas não deve ser tratado como uma atribuição infalível. A rota pode conter mais intermediários do que aquele configurado no seu cliente.

Depois examine porque é que essa operação no upstream não foi concluída. A acessibilidade, os serviços sobrecarregados, um corpo de pedido que o upstream não consegue processar como esperado e o comportamento da aplicação podem todos ser relevantes. O estado numérico por si só não prova que mudar o User-Agent ou acrescentar uma opção de tempo limite seja a solução universal.

Compare o mesmo pedido

Quando outra ferramenta funciona, compare método, destino, codificação do corpo, autenticação e rota. «O URL abre no navegador» não é uma comparação completa com um envio multipart através de um cliente de serviço.

Se operar a gateway emissora, alinhe o seu orçamento de upstream com a carga de trabalho suportada e os prazos em volta. Se não, guarde o resultado como evidência e use o caminho de acesso ou suporte documentado pelo operador. Esperar mais tempo localmente não pode alterar uma resposta que já chegou.