Kis eszközkészlet átirányítások és HTTP-fejlécek hibakereséséhez éles környezetben

A HTTP hibakeresésének problémája éles környezetben

A legtöbb HTTP-probléma láthatatlan a böngészőben. Egy átirányítási lánc csendben elbukik, egy gyorsítótárazási fejlécben egyetlen karakter hibás, egy CORS-szabály magyarázat nélkül blokkol egy kérést. A böngésző fejlesztői eszközei megmutatják a beszélgetés eredményét, de gyakran elrejtik azt a nyers cserét, amely a problémát okozta.

Ez éles környezetben a legfontosabb, ahol nem adhatsz hozzá naplózást, és nem indíthatsz újra szolgáltatásokat csak azért, hogy lásd, mi változott. Olyan eszközökre van szükséged, amelyek megmutatják a tényleges HTTP-beszélgetést: kérésfejléceket, válaszfejléceket, státuszkódokat, átirányítási célokat, időzítést. Íme az öt eszköz, amely megbízhatóan elvégzi ezt a feladatot, valamint a böngészős technikák, amelyek kiegészítik őket.

curl: az alap

A curl az első eszköz, amelyhez érdemes nyúlni, mert pontosan megmutatja, mit küldött a szerver, böngésző általi értelmezés nélkül.

Válaszfejlécek megtekintése törzs nélkül:

curl -I https://example.com

Átirányítások követése és minden lépés megtekintése:

curl -L -v https://example.com

A -v kapcsoló (verbose) megmutatja a teljes kérést és választ, az összes fejlécet is beleértve. A -L kapcsoló automatikusan követi az átirányításokat. Együtt megmutatják a teljes átirányítási láncot, és a legtöbb éles környezeti probléma éppen itt található.

Csak az átirányítási helyek megtekintése:

curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" -L https://example.com

Ez akkor hasznos, ha egy átirányítási láncot kell ellenőrizned a teljes fejlécek zaja nélkül. A -w kapcsoló úgy formázza a kimenetet, hogy csak a státuszkódot és a lánc következő URL-jét mutassa.

A curl egyéni fejlécek küldését is lehetővé teszi, ami elengedhetetlen CDN-viselkedés, hitelesítés vagy API-végpontok teszteléséhez:

curl -H "Authorization: Bearer token" -H "Accept: application/json" https://api.example.com

httpie: curl jobb alapértelmezésekkel

A httpie egy Python-eszköz, amely azt teszi, amit a curl, de könnyebben megjegyezhető szintaxissal és könnyebben olvasható kimenettel. Nem helyettesítő — a curl erősebb és szélesebb körben telepített —, de gyors ellenőrzésekhez a httpie gyorsabb.

Fejlécek megtekintése:

http HEAD https://example.com

Átirányítások követése:

http --follow --all https://example.com

A --all kapcsoló az átirányítási lánc minden válaszát megmutatja, nem csak a végsőt. Ez a curl -L -v megfelelője, de a kimenet színezett és könnyebben átfutható.

JSON küldése:

http POST https://api.example.com name=value

A httpie alapértelmezés szerint JSON-t feltételez, ami kevesebb gépelést jelent API-k tesztelésekor. Emellett szépen formázza a választ, így könnyebb észrevenni a hibás fejléceket vagy a váratlan értékeket.

Böngésző DevTools: Network lap

A böngésző Network lapján érdemes kezdened, ha a probléma csak a böngészőben jelentkezik. Ugyanazt az információt mutatja, mint a curl, de megmutatja a böngésző értelmezését is: blokkolt-e egy kérést, hogyan kezelte a gyorsítótárazást, küldött-e cookie-kat.

A teljes kérés- és válaszfejlécek megtekintéséhez kattints bármelyik kérésre a Network lapon, majd nézd meg a Headers szakaszt. A "Raw" nézet pontosan úgy mutatja a fejléceket, ahogy elküldték őket, formázás nélkül.

Az átirányítási láncok megtekintéséhez keresd a 3xx státuszkódú kéréseket. A böngésző a végső kérés alá csoportosítja őket, de kibontva láthatod az egyes lépéseket. Itt találod az átirányítási ciklusokat, a hiányzó Location fejléceket vagy azokat az átirányításokat, amelyek rossz domainre mutatnak.

Az időzítés megtekintéséhez nézd meg bármelyik kérés Timing lapját. Ez megmutatja, mennyi időt töltött a böngésző DNS-kereséssel, TCP-kapcsolattal, TLS-kézfogással és a szerverre várakozással. Ha egy átirányítás lassú, az időzítési lap megmondja, hogy a probléma hálózati késleltetés vagy szerveroldali feldolgozás.

Egy korlát: a böngésző biztonsági okokból elrejt bizonyos fejléceket. A Set-Cookie fejlécek láthatók, de a tényleges cookie-értékek ki vannak takarva. Az Authorization fejlécek néha teljesen rejtve maradnak. Ha ezeket látnod kell, használd a curl eszközt.

mitmproxy: a közbeékelődő proxy

A mitmproxy egy Python-eszköz, amely a böngésződ és a szerver közé ül be, és valós időben mutat meg minden kérést és választ. Összetettebb, mint a curl, de ez az egyetlen eszköz, amely megmutatja, mit küld a böngésző valójában, beleértve azokat a fejléceket is, amelyeket a böngésző automatikusan ad hozzá.

Indítása:

mitmproxy

Ezután állítsd be a böngészőt úgy, hogy a localhost:8080 címet használja HTTP-proxyként. A mitmproxy terminálos felületen mutatja meg az összes kérést. Megvizsgálhatod a fejléceket, szerkesztheted a kéréseket elküldés előtt, vagy újrajátszhatod őket más paraméterekkel.

Ez hasznos olyan problémák hibakereséséhez, amelyek csak a böngészőben fordulnak elő: CORS preflight kérések, cookie-kezelés vagy olyan kérések, amelyek bizonyos fejlécek jelenlétében sikertelenek. Annak tesztelésére is hasznos, hogyan viselkedik a webhelyed vállalati proxy vagy VPN mögött, mert a mitmproxy képes ilyen környezeteket szimulálni.

A hátránya a beállítás összetettsége. Telepítened kell egy gyökértanúsítványt, hogy a mitmproxy el tudja fogni a HTTPS-forgalmat, és be kell állítanod a böngészőt a proxy használatára. Gyors ellenőrzésekhez a curl gyorsabb. Mélyebb hibakereséshez a mitmproxy megéri a beállításra fordított időt.

webpagetest: éles környezeti nézőpont

A WebPageTest egy ingyenes szolgáltatás, amely valódi böngészőkből, különböző helyszínekről tölti be az oldaladat, és megmutatja a teljes HTTP-beszélgetést. Lassabb, mint a curl, de azt mutatja meg, amit a valódi felhasználók tapasztalnak, beleértve a CDN-viselkedést, a DNS-feloldást és a TLS-egyeztetést.

A "Request Headers" és "Response Headers" nézetek pontosan megmutatják, mit küldött és mit kapott a böngésző. A "Waterfall" nézet minden kérés időzítését megmutatja, az átirányításokat is beleértve. Itt találod meg azokat a problémákat, amelyek csak bizonyos régiókban vagy bizonyos hálózatokon jelentkeznek.

A WebPageTest a fő dokumentum átirányítási láncát is megmutatja, és a legtöbb átirányítási probléma itt található. Ha a webhelyed http:// címről https:// címre irányít át, majd www. címről nem www. címre, majd / útvonalról /en/ útvonalra, a WebPageTest mindhárom lépést megmutatja, valamint azt is, mennyi ideig tartottak.

Az ilyen HTTP-alapok ellenőrzését és optimalizálását segítő eszközökhöz a Wux Webtools több segédprogramot kínál, amelyek teljes egészében a böngésződben futnak, köztük fejléc-elemzőket és átirányítás-ellenőrzőket, amelyek azzal védik a magánszférádat, hogy mindent kliensoldalon dolgoznak fel.

Amikor a fejlécek hazudnak

A legnehezebb HTTP-problémák azok, amikor a szerver ellentmondásos fejléceket küld. Egy Cache-Control fejléc azt mondja: no-cache, de egy Expires fejléc szerint az erőforrás egy évig érvényes. Egy Location fejléc relatív URL-re mutat, de a Content-Location fejléc máshová. A böngészőnek el kell döntenie, melyikben bízzon, és a különböző böngészők eltérően döntenek.

Amikor ez történik, a nyers fejléceket abban a sorrendben kell látnod, ahogy a szerver elküldte őket. A curl -v ezt megteszi. A mitmproxy is. A böngésző DevTools eszközei néha olvashatósági okokból átrendezik a fejléceket, ami elrejti a problémát.

Egy másik gyakori eset: a fejléceket nem az alkalmazásod, hanem egy CDN vagy terheléselosztó adja hozzá. Ha gyorsítótárazási problémát keresel, tudnod kell, hogy a Cache-Control fejléc az alkalmazásodból vagy a CDN-ből származik-e. A curl megmutatja a végső eredményt, de nem mondja meg, melyik fejléc honnan jött. Ehhez meg kell kerülnöd a CDN-t (közvetlenül az origin szervert elérve), és össze kell hasonlítanod a fejléceket.

Az átirányítási ciklus problémája

Az átirányítási ciklusok a leggyakoribb HTTP-problémák éles környezetben. Akkor történnek, amikor két szerver nem ért egyet abban, hová kellene mutatnia egy URL-nek: a CDN az origin felé irányít, az origin pedig vissza a CDN felé. Vagy a terheléselosztó HTTP-ről HTTPS-re irányít, de az alkalmazás HTTPS-ről visszairányít HTTP-re, mert nem látja az X-Forwarded-Proto fejlécet.

A hibakereséshez látnod kell a teljes átirányítási láncot, beleértve minden lépésnél a Location fejlécet. A curl -L -v ezt megteszi, de 50 átirányítás után leáll, hogy elkerülje a végtelen ciklusokat. Ha eléred ezt a korlátot, átirányítási ciklusod van.

A javítás általában konfigurációs módosítás: mondd meg az alkalmazásnak, hogy bízzon az X-Forwarded-Proto fejlécben, vagy mondd meg a CDN-nek, hogy ne irányítsa át azokat a kéréseket, amelyek már HTTPS-en érkeznek. De addig nem tudod kijavítani, amíg nem látod a ciklust, a böngésző pedig csak néhány átirányítást mutat meg, mielőtt feladja.

Mit ellenőrizz először

Ha valami elromlik éles környezetben, ebben a sorrendben ellenőrizd:

1. Státuszkód: Azt kaptad, amire számítottál? A 301 végleges, a 302 ideiglenes, a 307 megőrzi a HTTP-metódust. Ha rossz kódot látsz, a probléma az átirányítási konfigurációban van.

1. Location fejléc: A megfelelő helyre mutat? Abszolút URL vagy relatív? A relatív URL-ek az aktuális URL alapján oldódnak fel, ami váratlan eredményekhez vezethet, ha az alap URL nem az, aminek gondolod.

1. Gyorsítótárazási fejlécek: A böngésző gyorsítótárazza az átirányítást? A 301-es átirányítás alapértelmezés szerint gyorsítótárazódik, ami azt jelenti, hogy egy hibásan beállított átirányítás órákra elronthatja a webhelyedet még azután is, hogy kijavítottad. Ellenőrizd a Cache-Control és Expires fejléceket, hogy lásd, meddig fogja a böngésző megjegyezni az átirányítást.

1. CORS-fejlécek: Ha a kérés más originre irányul, elküldi a szerver a megfelelő Access-Control-Allow-Origin fejlécet? Ha nem, a böngésző blokkolja a kérést, és CORS-hibát látsz a konzolban. Ezt csak a szerver válaszfejléceiben lehet kijavítani — a böngészőben nem tudod megkerülni.

1. Időzítés: Mennyi ideig tartott a kérés? Ha lassú, hálózati késleltetésről vagy szerveroldali feldolgozásról van szó? A böngésző DevTools eszközei és a WebPageTest is mutatnak időzítési bontásokat, amelyek megmondják, hová ment el az idő.

Ha mélyebben érdekel, hogyan változott a böngészők viselkedése az adatvédelem és a fejlécek körül, lásd: mi változott a cookie-k terén 2026-ban, és mit érdemes tenni vele, amely a legutóbbi böngészőfrissítések fejlécekre és hozzájárulásra gyakorolt hatásait tárgyalja.

Fő tanulságok

• A curl -L -v megmutatja a teljes átirányítási láncot és az összes fejlécet, böngésző általi értelmezés nélkül
• A böngésző Network lapja megmutatja, mit kezdett a böngésző a válasszal, beleértve a gyorsítótárazási és CORS-döntéseket
• A mitmproxy megmutatja, mit küldött a böngésző, beleértve azokat a fejléceket is, amelyeket a böngésző automatikusan ad hozzá
• A WebPageTest megmutatja, mit tapasztalnak a valódi felhasználók, beleértve a CDN-viselkedést és a regionális különbségeket
• Az átirányítási ciklusok és az ellentmondásos fejlécek a leggyakoribb éles környezeti problémák, és nyers HTTP-vizsgálat nélkül láthatatlanok

FAQ

Q: Miért mutat a curl más fejléceket, mint a böngésző?

A: Mert a böngésző automatikusan ad hozzá fejléceket (User-Agent, Accept, Cookie), és a saját szabályait követi a gyorsítótárazásra és a CORS-ra. A curl csak azt küldi el, amit megadsz neki. Ha látni szeretnéd, mit küld valójában a böngésző, használd a mitmproxy eszközt vagy a böngésző DevTools eszközeit.

Q: Hogyan hibakeressek egy olyan átirányítást, amely csak néhány felhasználónál történik meg?

A: Ellenőrizd, hogy az átirányítás függ-e a felhasználó által küldött fejlécektől: User-Agent, Accept-Language, Cookie, vagy IP-cím (az X-Forwarded-For segítségével). A curl használatával küldd el ugyanazokat a fejléceket, amelyeket a felhasználó küldött, vagy a WebPageTest segítségével töltsd be az oldalt a felhasználó helyéről.

Q: Mi a különbség a 301-es és a 302-es átirányítás között?

A: A 301 végleges, és arra utasítja a böngészőt, hogy gyorsítótárazza az átirányítást (néha örökre). A 302 ideiglenes, és azt jelzi a böngészőnek, hogy ne gyorsítótárazza. Ha nem vagy biztos benne, melyiket használd, használd a 302-t — később bármikor átállíthatod 301-re.

Q: Miért működik az átirányításom curlben, de nem a böngészőben?

A: Valószínűleg azért, mert a böngésző egy régi átirányítást gyorsítótáraz, vagy mert CORS- vagy mixed content szabályok miatt blokkolja az átirányítást. Ellenőrizd a böngésző DevTools konzolját hibákért, és nézd meg a Cache-Control fejléceket, hogy kiderüljön, a böngésző gyorsítótárazott választ használ-e.

Q: Hogyan láthatom a CDN által hozzáadott fejléceket?

A: A curl segítségével érd el a CDN URL-jét, majd a curl segítségével érd el közvetlenül az origin szervert is (a CDN megkerülésével). Hasonlítsd össze a fejléceket. Azok, amelyek csak az első válaszban jelennek meg, a CDN-ből származnak.

<!-- tool-cta:start -->

💡 Próbálja ki ezt: Átirányítási problémák felderítésekor a Redirect Checker végigköveti a teljes láncot, és minden ugrásnál megjeleníti az állapotkódokat és a fejléceket.

<!-- tool-cta:end -->

Sources

• curl documentation — Hivatalos referencia a curl parancssori opcióihoz és viselkedéséhez
• HTTPie documentation — Útmutató az httpie szintaxisához és funkcióihoz
• MDN Web Docs: HTTP redirections — Átfogó magyarázat a HTTP átirányítási státuszkódokról és viselkedésről
• WebPageTest documentation — A WebPageTest eredményeinek és fejléceinek értelmezése