HTTP 504 Gateway Timeout ir jūsų kliento laukimo laikas

Jūsų klientas pasirengęs laukti šešiasdešimt sekundžių. Po dešimties sekundžių jis gauna HTTP 504. Padidinus kliento laukimo laiką iki dviejų minučių, tarpinė programa negauna dar penkiasdešimt sekundžių darbo.

504 apibūdina tarpinę programą arba proxy, kuri, bandydama užbaigti užklausą, laiku negavo upstream atsakymo. Tarpinė programa jau priėmė sprendimą ir grąžino atsakymą. Jūsų klientas tą atsakymą gali sėkmingai perskaityti.

Kuris tarpininkas jį grąžino?

Išdavėjas gali būti tiesioginis proxy. Taip pat vėlesnė tarpinė programa, kurią valdo svetainė. Naudojant įprastą TLS nuo galo iki galo CONNECT viduje, HTTP atsakymas iš to saugaus mainų su tikslu nėra tas pats, kas paties CONNECT atmetimas.

Išsaugokite etapą, atsakymo antraštes, klaidos puslapio tekstą ir atitinkamus žurnalus, kai jie prieinami. Serverio pavadinimas gali būti užuomina, bet neturėtų būti laikomas neklystančiu priskyrimu. Maršrute gali būti daugiau tarpininkų nei tas, kuris sukonfigūruotas jūsų kliente.

Tada išsiaiškinkite, kodėl ta upstream operacija nebuvo baigta. Pasiekiamumas, perkrautos paslaugos, užklausos turinys, kurio upstream negali apdoroti taip, kaip tikėtasi, ir programos elgsena gali turėti reikšmės. Vien skaitmeninis statusas neįrodo, kad User-Agent pakeitimas ar vienos laukimo laiko parinkties pridėjimas yra universali išeitis.

Palyginkite tą pačią užklausą

Kai veikia kitas įrankis, palyginkite metodą, tikslą, turinio kodavimą, autentifikavimą ir maršrutą. „URL atsidaro naršyklėje“ nėra išsamus palyginimas su multipart siuntimu per paslaugos klientą.

Jei valdote išduodančią tarpinę programą, suderinkite jos upstream biudžetą su palaikomu darbo krūviu ir aplinkiniais terminais. Jei ne, išsaugokite jos rezultatą kaip įrodymą ir naudokitės operatoriaus dokumentuotu prieigos arba palaikymo keliu. Ilgesnis vietinis laukimas negali pakeisti jau atėjusio atsakymo.