HTTP 504 Gateway Timeout proti časovni omejitvi vašega odjemalca
Razlikujte zahtevo na upstream, ki je v prehodu potekla, od časovne omejitve, nastavljene v vašem lastnem odjemalcu proxy.
Vaš odjemalec je pripravljen čakati šestdeset sekund. Deset sekund pozneje prejme HTTP 504. Povečanje omejitve odjemalca na dve minuti prehodu ne da še petdesetih sekund dela.
504 opisuje prehod ali proxy, ki med poskusom dokončanja zahteve ni prejel pravočasnega odgovora z upstreama. Prehod se je že odločil in vrnil odgovor. Vaš odjemalec lahko ta odgovor brez težav prebere.
Kateri posrednik ga je vrnil?
Izdajatelj je lahko posredniški proxy. Tudi poznejši prehod, ki ga upravlja spletno mesto. Pri običajnem TLS od konca do konca znotraj CONNECT odgovor HTTP iz te zaščitene izmenjave s ciljem ni isto kot zavrnitev samega CONNECT.
Shranite stopnjo, glave odgovora, besedilo strani z napako in ustrezne dnevnike, kadar so na voljo. Ime strežnika je lahko namig, vendar ga ne gre imeti za nezmotljivo pripisovanje. Na poti je lahko več posrednikov, kot jih je konfiguriranih v vašem odjemalcu.
Nato preverite, zakaj ta operacija na upstreamu ni bila dokončana. Dosegljivost, preobremenjene storitve, telo zahteve, ki ga upstream ne more obdelati po pričakovanjih, in vedenje aplikacije so lahko pomembni. Samo številčno stanje ne dokazuje, da je sprememba User-Agenta ali dodajanje ene možnosti časovne omejitve univerzalna rešitev.
Primerjajte isto zahtevo
Ko drugo orodje deluje, primerjajte metodo, cilj, kodiranje telesa, preverjanje pristnosti in pot. »URL se odpre v brskalniku« ni popolna primerjava s pošiljanjem multipart prek odjemalca storitve.
Če upravljate prehod, ki izdaja odgovor, uskladite njegov proračun za upstream s podprto obremenitvijo in okoliškimi roki. Če ne, shranite rezultat kot dokaz in uporabite dokumentirano pot dostopa ali podpore operaterja. Daljše lokalno čakanje ne more spremeniti odgovora, ki je že prispel.