HTTP 504 Gateway Timeout kontra din klients tidsgräns
Skilj mellan en upstream-begäran som löpt ut i gatewayen och den tidsgräns som är inställd i din egen proxyklient.
Din klient är beredd att vänta sextio sekunder. Tio sekunder senare får den HTTP 504. Att höja klientens tidsgräns till två minuter ger inte gatewayen femtio sekunder extra arbete.
504 beskriver en gateway eller proxy som inte fick ett rättidigt upstream-svar när den försökte slutföra begäran. Gatewayen har redan fattat sitt beslut och returnerat ett svar. Din klient kan läsa det svaret utan problem.
Vilken mellanhand returnerade det?
Vidarebefordringsproxyn kan vara avsändaren. Det kan också en senare gateway som webbplatsen driver vara. Med vanlig TLS från ände till ände inuti CONNECT är ett HTTP-svar från det skyddade utbytet med målet inte detsamma som ett avvisande av själva CONNECT.
Spara steget, svarshuvudena, ordalydelsen på felsidan och motsvarande loggar när de finns. Ett servernamn kan vara en ledtråd, men bör inte behandlas som en ofelbar tillskrivning. Rutten kan innehålla fler mellanhänder än den som är konfigurerad i din klient.
Undersök sedan varför den upstream-åtgärden inte slutfördes. Tillgänglighet, överbelastade tjänster, en förfrågningskropp som upstream inte kan bearbeta som förväntat och programmets beteende kan alla spela roll. Enbart den numeriska statusen bevisar inte att en ändrad User-Agent eller en extra tidsgränsinställning är den universella lösningen.
Jämför samma begäran
När ett annat verktyg fungerar, jämför metod, mål, kroppskodning, autentisering och rutt. "URL:en öppnas i en webbläsare" är inte en fullständig jämförelse med en multipart-överföring via en tjänsteklient.
Om du driver den utfärdande gatewayen, anpassa dess upstream-budget till den arbetsbelastning som stöds och tidsfristerna runt omkring. Om inte, spara resultatet som bevis och använd operatörens dokumenterade åtkomst- eller supportväg. Längre lokal väntan kan inte ändra ett svar som redan har kommit.