HTTP 504 Gateway Timeout kontra din klients timeout

Din klient er villig til at vente tres sekunder. Ti sekunder senere modtager den HTTP 504. At hæve klientens timeout til to minutter giver ikke gatewayen halvtreds sekunder mere at arbejde med.

504 beskriver en gateway eller proxy, som ikke modtog et rettidigt upstream-svar, mens den forsøgte at fuldføre anmodningen. Gatewayen har allerede truffet sin beslutning og returneret et svar. Din klient kan læse det svar uden problemer.

Hvilken mellemled returnerede det?

Den videresendende proxy kan være afsenderen. Det kan en senere gateway, der drives af webstedet, også være. Med almindelig end-to-end TLS inde i CONNECT er et HTTP-svar fra den beskyttede udveksling med destinationen ikke det samme som en afvisning af selve CONNECT.

Bevar trinnet, svarets headere, fejlsideens ordlyd og de tilsvarende logfiler, hvor de findes. Et servernavn kan være et fingerpeg, men bør ikke behandles som ufejlbarlig tilskrivning. Ruten kan indeholde flere mellemled end det, der er konfigureret i din klient.

Undersøg derefter, hvorfor den upstream-handling ikke blev fuldført. Tilgængelighed, overbelastede tjenester, en anmodningskrop som upstream ikke kan behandle som forventet, og applikationsadfærd kan alle være relevante. Den numeriske status alene beviser ikke, at en ændret User-Agent eller én ekstra timeout-indstilling er den universelle løsning.

Sammenlign den samme anmodning

Når et andet værktøj virker, så sammenlign metode, mål, body-kodning, godkendelse og rute. "URL'en åbner i en browser" er ikke en fuld sammenligning med en multipart-indsendelse via en serviceklient.

Hvis du driver den afsendende gateway, så afstem dens upstream-budget med den understøttede arbejdsbyrde og de omkringliggende deadlines. Hvis ikke, så gem dens resultat som bevis og brug operatørens dokumenterede adgangs- eller supportvej. Længere lokal ventetid kan ikke ændre et svar, der allerede er ankommet.