HTTP 504 Gateway Timeout față de timeout-ul clientului tău

Clientul tău este dispus să aștepte șaizeci de secunde. Zece secunde mai târziu primește HTTP 504. Creșterea timeout-ului clientului la două minute nu îi dă gateway-ului alte cincizeci de secunde de lucru.

504 descrie un gateway sau un proxy care nu a primit un răspuns oportun de la upstream în timp ce încerca să finalizeze cererea. Gateway-ul și-a luat deja decizia și a returnat un răspuns. Clientul tău poate citi acel răspuns fără probleme.

Ce intermediar l-a returnat?

Emițătorul poate fi proxy-ul direct. La fel și un gateway ulterior operat de site. Cu TLS obișnuit cap-la-cap în interiorul CONNECT, un răspuns HTTP venit din acel schimb protejat cu destinația nu este același lucru cu o respingere a CONNECT însuși.

Păstrează etapa, antetele răspunsului, formularea paginii de eroare și jurnalele corespunzătoare atunci când sunt disponibile. Numele serverului poate fi un indiciu, dar nu trebuie tratat ca o atribuire infailibilă. Ruta poate conține mai mulți intermediari decât cel configurat în clientul tău.

Apoi verifică de ce acea operațiune upstream nu s-a finalizat. Accesibilitatea, serviciile supraîncărcate, un corp de cerere pe care upstream-ul nu îl poate procesa conform așteptărilor și comportamentul aplicației pot conta toate. Statusul numeric singur nu dovedește că schimbarea User-Agentului sau adăugarea unei opțiuni de timeout este soluția universală.

Compară aceeași cerere

Când un alt instrument funcționează, compară metoda, ținta, codificarea corpului, autentificarea și ruta. „URL-ul se deschide în browser” nu este o comparație completă cu o trimitere multipart prin clientul unui serviciu.

Dacă administrezi gateway-ul emitent, aliniază-i bugetul upstream la volumul de lucru acceptat și la termenele din jur. Dacă nu, păstrează rezultatul ca dovadă și folosește calea de acces sau de suport documentată de operator. Așteptarea mai lungă local nu poate schimba un răspuns care a sosit deja.