HTTP 504 Gateway Timeout kontraŭ la tempolimo de via kliento

Via kliento pretas atendi sesdek sekundojn. Post dek sekundoj ĝi ricevas HTTP 504. Pliigi la tempolimon de la kliento al du minutoj ne donas al la pordego pliajn kvindek sekundojn da laboro.

504 priskribas pordegon aŭ prokurilon, kiu ne ricevis ĝustatempan upstream-respondon dum ĝi provis fini la peton. La pordego jam decidis kaj resendis respondon. Via kliento povas legi tiun respondon sukcese.

Kiom da perantoj resendis ĝin?

La antaŭa prokurilo povas esti la eldoninto. Ankaŭ pli malfrua pordego funkciigata de la retejo. Ĉe ordinara TLS de fino al fino ene de CONNECT, HTTP-respondo el tiu protektita interŝanĝo kun la celo ne samas kiel rifuzo de CONNECT mem.

Konservu la etapon, la respondajn kapliniojn, la vortumon de la erarpaĝo kaj la respondajn protokolojn kiam disponeblaj. Servila etikedo povas esti indiko, sed ĝi ne estu traktata kiel neerarema atribuo. La vojo povas enhavi pli da perantoj ol tiu agordita en via kliento.

Poste esploru kial tiu upstream-operacio ne finiĝis. Atingebleco, troŝarĝitaj servoj, peta korpo, kiun la upstream ne povas prilabori laŭatende, kaj aplikaĵa konduto povas ĉiuj gravi. La sola numera statuso ne pruvas, ke ŝanĝo de User-Agent aŭ aldono de unu tempolima opcio estas la universala solvo.

Komparu la saman peton

Kiam alia ilo funkcias, komparu metodon, celon, korpan kodadon, aŭtentikigon kaj vojon. "La URL malfermiĝas en retumilo" ne estas kompleta komparo kun multipart-sendo per serva kliento.

Se vi funkciigas la eldonantan pordegon, agordu ĝian upstream-buĝeton laŭ la subtenata laborŝarĝo kaj la ĉirkaŭaj limdatoj. Se ne, konservu ĝian rezulton kiel pruvon kaj uzu la dokumentitan aliron aŭ subtenvojon de la operatoro. Pli longa loka atendo ne povas ŝanĝi respondon jam alvenintan.