HTTP 504 Gateway Timeout teenoor jou kliënt se timeout

Jou kliënt is bereid om sestig sekondes te wag. Tien sekondes later ontvang dit HTTP 504. Om die kliënt se timeout na twee minute te verhoog, gee nie vir die gateway nog vyftig sekondes om te werk nie.

504 beskryf 'n gateway of proxy wat nie 'n tydige upstream-antwoord ontvang het nie terwyl dit die versoek probeer voltooi het. Die gateway het reeds sy besluit geneem en 'n antwoord teruggegee. Jou kliënt kan daardie antwoord suksesvol lees.

Watter tussenskakel het dit teruggestuur?

Die voorwaartse proxy kan die afsender wees. So ook 'n latere gateway wat deur die webwerf bedryf word. Met gewone end-tot-end TLS binne CONNECT is 'n HTTP-antwoord vanuit daardie beskermde bestemming-uitruiling nie dieselfde as 'n verwerping van CONNECT self nie.

Hou die fase, antwoordkoppe, die bewoording van die foutblad en ooreenstemmende logs waar beskikbaar. 'n Etiket op die bediener kan 'n leidraad wees, maar moet nie as onfeilbare toeskrywing beskou word nie. Die roete kan meer tussenskakels bevat as die een wat in jou kliënt opgestel is.

Ondersoek dan waarom daardie upstream-bewerking nie kon voltooi nie. Bereikbaarheid, oorlaaide dienste, 'n versoekliggaam wat die upstream nie verwag kan verwerk nie, en toepassingsgedrag kan alles saak maak. Die numeriese status alleen bewys nie dat 'n verandering aan 'n User-Agent of die byvoeging van een timeout-opsie die universele oplossing is nie.

Vergelyk dieselfde versoek

Wanneer 'n ander hulpmiddel werk, vergelyk metode, teiken, liggaam-enkodering, verifikasie en roete. "Die URL open in 'n blaaier" is nie 'n volledige vergelyking met 'n multipart-indiening deur 'n dienskliënt nie.

As jy die afsender-gateway bedryf, stem sy upstream-begroting op die ondersteunde werklading en die omliggende spertye af. Doen jy dit nie, hou sy resultaat as bewyse en gebruik die operateur se gedokumenteerde toegangs- of ondersteuningspad. Langer plaaslik wag kan nie 'n antwoord verander wat reeds aangekom het nie.