HTTP 504 Gateway Timeout kontra tidsavbruddet i klienten din

Klienten din er villig til å vente seksti sekunder. Ti sekunder senere mottar den HTTP 504. Å øke tidsavbruddet i klienten til to minutter gir ikke gatewayen femti sekunder ekstra å arbeide på.

504 beskriver en gateway eller proxy som ikke fikk et rettidig upstream-svar mens den forsøkte å fullføre forespørselen. Gatewayen har allerede tatt beslutningen sin og returnert et svar. Klienten din kan lese det svaret uten problemer.

Hvilket mellomledd returnerte det?

Videresendingsproxyen kan være avsenderen. Det kan også en senere gateway som nettstedet driver være. Med vanlig ende-til-ende-TLS inne i CONNECT er et HTTP-svar fra den beskyttede utvekslingen med destinasjonen ikke det samme som en avvisning av selve CONNECT.

Ta vare på trinnet, svarhodene, ordlyden på feilsiden og de tilhørende loggene der de finnes. Et servernavn kan være et hint, men bør ikke behandles som ufeilbar tilskrivning. Ruten kan inneholde flere mellomledd enn det som er konfigurert i klienten din.

Undersøk deretter hvorfor den upstream-operasjonen ikke ble fullført. Tilgjengelighet, overbelastede tjenester, en forespørselskropp som upstream ikke kan behandle som forventet, og applikasjonsatferd kan alle være relevante. Den numeriske statusen alene beviser ikke at en endret User-Agent eller én ekstra tidsavbruddsinnstilling er den universelle løsningen.

Sammenlign den samme forespørselen

Når et annet verktøy virker, sammenlign metode, mål, kroppskoding, autentisering og rute. «URL-en åpnes i en nettleser» er ikke en fullstendig sammenligning med en multipart-innsending via en tjenesteklient.

Hvis du drifter gatewayen som sender svaret, bør du tilpasse upstream-budsjettet til arbeidsbelastningen som støttes og fristene rundt. Hvis ikke, ta vare på resultatet som bevis og bruk operatørens dokumenterte tilgangs- eller støttevei. Lengre lokal venting kan ikke endre et svar som allerede har kommet.