HTTP 504 Gateway Timeout kontra tidsavbrotet i klienten din

Klienten din er villig til å vente seksti sekund. Ti sekund seinare får han HTTP 504. Å auke tidsavbrotet i klienten til to minutt gir ikkje gatewayen femti sekund ekstra å arbeide på.

504 skildrar ein gateway eller proxy som ikkje fekk eit rettidig upstream-svar medan han prøvde å fullføre førespurnaden. Gatewayen har alt teke avgjerda si og returnert eit svar. Klienten din kan lese det svaret utan problem.

Kva mellomledd returnerte det?

Vidaresendingsproxyen kan vere avsendaren. Det kan òg vere ein seinare gateway som nettstaden driv. Med vanleg ende-til-ende-TLS inne i CONNECT er eit HTTP-svar frå den verna utvekslinga med destinasjonen ikkje det same som ei avvising av sjølve CONNECT.

Ta vare på trinnet, svarhovuda, ordlyden på feilsida og dei tilhøyrande loggane der dei finst. Eit servernamn kan vere eit hint, men bør ikkje behandlast som ufeilbar tilskriving. Ruta kan innehalde fleire mellomledd enn det som er sett i klienten din.

Undersøk så kvifor den upstream-operasjonen ikkje vart fullført. Tilgjenge, overbelasta tenester, ein førespurnadskropp som upstream ikkje kan handsame som venta, og åtferda til applikasjonen kan alle vere viktige. Den numeriske statusen åleine beviser ikkje at ein endra User-Agent eller ei ekstra tidsavbrotinnstilling er den universelle løysinga.

Samanlikn den same førespurnaden

Når eit anna verktøy virkar, samanlikn metode, mål, kroppskoding, autentisering og rute. «URL-en opnar i ein nettlesar» er ikkje ein fullstendig samanliknad med ei multipart-innsending via ein tenesteklient.

Styrer du gatewayen som sender svaret, bør du tilpasse upstream-budsjettet hans til arbeidslasta som er støtta og fristane rundt. Viss ikkje, ta vare på resultatet som bevis og bruk den dokumenterte tilgangs- eller støttevegen til operatøren. Lengre lokal venting kan ikkje endre eit svar som alt er kome.