Il tuo client è disposto ad attendere sessanta secondi. Dieci secondi dopo riceve HTTP 504. Portare il timeout del client a due minuti non dà al gateway altri cinquanta secondi di lavoro.

504 descrive un gateway o un proxy che non ha ricevuto una risposta upstream in tempo mentre tentava di completare la richiesta. Il gateway ha già preso la sua decisione e ha restituito una risposta. Il tuo client è in grado di leggerla senza problemi.

Quale intermediario l'ha restituita?

L'emittente può essere il proxy in avanti. Può esserlo anche un gateway successivo gestito dal sito. Con il normale TLS end-to-end dentro CONNECT, una risposta HTTP proveniente da quello scambio protetto con la destinazione non è la stessa cosa di un rifiuto del CONNECT stesso.

Conserva la fase, le intestazioni della risposta, il testo della pagina di errore e i log corrispondenti quando disponibili. L'etichetta del server può essere un indizio, ma non va trattata come un'attribuzione infallibile. La rotta può contenere più intermediari di quello configurato nel tuo client.

Poi esamina perché quell'operazione verso l'upstream non si è conclusa. Raggiungibilità, servizi sovraccarichi, un corpo della richiesta che l'upstream non riesce a elaborare come previsto e il comportamento dell'applicazione possono tutti contare. Il solo stato numerico non dimostra che cambiare User-Agent o aggiungere un'opzione di timeout sia la soluzione universale.

Confronta la stessa richiesta

Quando un altro strumento funziona, confronta metodo, destinazione, codifica del corpo, autenticazione e rotta. «L'URL si apre nel browser» non è un confronto completo con un invio multipart tramite un client di servizio.

Se gestisci il gateway emittente, allinea il suo budget upstream al carico supportato e alle scadenze circostanti. Se non lo gestisci, conserva il risultato come prova e usa il percorso di accesso o supporto documentato dall'operatore. Attendere più a lungo in locale non può cambiare una risposta già arrivata.

Articoli correlati