Malá sada nástrojů pro ladění přesměrování a HTTP hlaviček v produkci

Problém s laděním HTTP v produkci

Většina HTTP problémů je v prohlížeči neviditelná. Řetězec přesměrování selže tiše, cache hlavička je chybná o jediný znak, zásada CORS zablokuje požadavek bez vysvětlení. Vývojářské nástroje v prohlížeči ukážou výsledek komunikace, ale často skryjí surovou výměnu, která problém způsobila.

Nejvíc na tom záleží v produkci, kde nemůžete přidat logování ani restartovat služby, abyste zjistili, co se změnilo. Potřebujete nástroje, které ukážou skutečnou HTTP komunikaci: hlavičky požadavku, hlavičky odpovědi, stavové kódy, cíle přesměrování, časování. Tady je pět nástrojů, které tuto práci dělají spolehlivě, plus techniky v prohlížeči, které je doplňují.

curl: základ

curl je první nástroj, po kterém sáhnout, protože ukáže přesně to, co server odeslal, bez interpretace prohlížeče mezi tím.

Chcete-li vidět hlavičky odpovědi bez těla:

curl -I https://example.com

Chcete-li následovat přesměrování a vidět každý krok:

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

Přepínač -v (verbose) ukáže celý požadavek i odpověď, včetně všech hlaviček. Přepínač -L automaticky následuje přesměrování. Dohromady ukážou celý řetězec přesměrování, což je místo, kde žije většina produkčních problémů.

Chcete-li vidět jen cíle přesměrování:

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

To se hodí, když potřebujete ověřit řetězec přesměrování bez šumu kompletních hlaviček. Přepínač -w formátuje výstup tak, aby zobrazil jen stavový kód a další URL v řetězci.

curl také umožňuje posílat vlastní hlavičky, což je zásadní pro testování chování CDN, autentizace nebo API endpointů:

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

httpie: curl s lepšími výchozími hodnotami

httpie je nástroj v Pythonu, který dělá to, co curl, ale se syntaxí, která se snáze pamatuje, a s výstupem, který se snáze čte. Není to náhrada — curl je výkonnější a častěji nainstalovaný — ale pro rychlé kontroly je httpie rychlejší.

Chcete-li vidět hlavičky:

http HEAD https://example.com

Chcete-li následovat přesměrování:

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

Přepínač --all ukáže každou odpověď v řetězci přesměrování, nejen tu konečnou. Je to obdoba curl -L -v, ale výstup je barevně zvýrazněný a snáze se v něm orientuje.

Chcete-li poslat JSON:

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

httpie ve výchozím nastavení předpokládá JSON, což šetří psaní při testování API. Odpověď také pěkně formátuje, takže je snazší odhalit chybně vytvořené hlavičky nebo neočekávané hodnoty.

Browser DevTools: karta Network

Karta Network v prohlížeči je místo, kde začít, pokud se problém děje jen v prohlížeči. Ukáže stejné informace jako curl, ale zároveň ukáže interpretaci prohlížeče: zda požadavek zablokoval, jak naložil s cachováním, zda odeslal cookies.

Chcete-li vidět celé hlavičky požadavku a odpovědi, klikněte na libovolný požadavek na kartě Network a podívejte se do sekce Headers. Zobrazení "Raw" ukazuje hlavičky přesně tak, jak byly odeslány, bez formátování.

Chcete-li vidět řetězce přesměrování, hledejte požadavky se stavovými kódy 3xx. Prohlížeč je seskupuje pod konečný požadavek, ale můžete je rozbalit a vidět každý krok. Tady najdete smyčky přesměrování, chybějící hlavičky Location nebo přesměrování mířící na špatnou doménu.

Chcete-li vidět časování, podívejte se u libovolného požadavku na kartu Timing. Ta ukazuje, jak dlouho prohlížeč strávil vyhledáním DNS, navázáním TCP spojení, TLS handshake a čekáním na server. Pokud je přesměrování pomalé, karta Timing řekne, zda je problém v latenci sítě, nebo ve zpracování na serveru.

Jedno omezení: prohlížeč z bezpečnostních důvodů skrývá některé hlavičky. Hlavičky Set-Cookie jsou viditelné, ale skutečné hodnoty cookies jsou začerněné. Hlavičky Authorization jsou někdy skryté úplně. Pokud je potřebujete vidět, použijte curl.

mitmproxy: zachytávací proxy

mitmproxy je nástroj v Pythonu, který stojí mezi vaším prohlížečem a serverem a v reálném čase ukazuje každý požadavek i odpověď. Je složitější než curl, ale je to jediný nástroj, který ukáže, co prohlížeč skutečně odesílá, včetně hlaviček, které prohlížeč přidává automaticky.

Spuštění:

mitmproxy

Poté nastavte prohlížeč tak, aby používal localhost:8080 jako HTTP proxy. mitmproxy ukáže každý požadavek v terminálovém rozhraní. Můžete prohlížet hlavičky, upravovat požadavky před odesláním nebo opakovat požadavky s jinými parametry.

To je užitečné pro ladění problémů, které se dějí jen v prohlížeči: CORS preflight požadavky, zacházení s cookies nebo požadavky, které selhávají, když jsou přítomné určité hlavičky. Hodí se také pro testování, jak se váš web chová za firemní proxy nebo VPN, protože mitmproxy dokáže taková prostředí simulovat.

Nevýhodou je složitější nastavení. Musíte nainstalovat kořenový certifikát, aby mitmproxy mohlo zachytávat HTTPS provoz, a musíte nastavit prohlížeč tak, aby proxy používal. Pro rychlé kontroly je curl rychlejší. Pro hluboké ladění se čas věnovaný nastavení mitmproxy vyplatí.

webpagetest: pohled z produkce

WebPageTest je bezplatná služba, která načte vaši stránku ze skutečných prohlížečů v různých lokalitách a ukáže celou HTTP komunikaci. Je pomalejší než curl, ale ukáže, co zažívají skuteční uživatelé, včetně chování CDN, překladu DNS a vyjednávání TLS.

Zobrazení "Request Headers" a "Response Headers" ukazují přesně to, co prohlížeč odeslal a přijal. Zobrazení "Waterfall" ukazuje časování každého požadavku, včetně přesměrování. Tady najdete problémy, které se dějí jen v určitých regionech nebo na určitých sítích.

WebPageTest také ukazuje řetězec přesměrování pro hlavní dokument, což je místo, kde žije většina problémů s přesměrováním. Pokud váš web přesměrovává z http:// na https://, potom z www. na non-www. a potom z / na /en/, WebPageTest ukáže všechny tři kroky i to, jak dlouho každý trval.

Pro nástroje, které vám pomohou ověřit a optimalizovat tyto HTTP základy, Wux Webtools nabízí několik utilit, které běží celé ve vašem prohlížeči, včetně analyzátorů hlaviček a kontrol přesměrování, které respektují vaše soukromí tím, že vše zpracovávají na straně klienta.

Když hlavičky lžou

Nejtěžší HTTP problémy jsou ty, kde server posílá protichůdné hlavičky. Hlavička Cache-Control říká no-cache, ale hlavička Expires říká, že zdroj je platný rok. Hlavička Location míří na relativní URL, ale hlavička Content-Location míří jinam. Prohlížeč musí odhadnout, které z nich věřit, a různé prohlížeče hádají různě.

Když se to stane, potřebujete vidět surové hlavičky v pořadí, v jakém je server odeslal. curl -v to umí. mitmproxy také. DevTools v prohlížeči někdy hlavičky kvůli čitelnosti přerovnají, čímž problém skryjí.

Další běžný problém: hlavičky, které přidává CDN nebo load balancer, ne vaše aplikace. Pokud ladíte problém s cachováním, potřebujete vědět, zda hlavička Cache-Control přišla z vaší aplikace, nebo z CDN. curl ukáže konečný výsledek, ale neřekne, odkud která hlavička přišla. K tomu je potřeba obejít CDN (přímým zásahem origin serveru) a hlavičky porovnat.

Problém smyček přesměrování

Smyčky přesměrování jsou nejběžnější HTTP problém v produkci. Vznikají, když se dva servery neshodnou, kam má URL mířit: CDN přesměruje na origin, origin přesměruje zpět na CDN. Nebo load balancer přesměruje HTTP na HTTPS, ale aplikace přesměruje HTTPS zpět na HTTP, protože nevidí hlavičku X-Forwarded-Proto.

Pro ladění potřebujete vidět celý řetězec přesměrování, včetně hlavičky Location v každém kroku. curl -L -v to umí, ale po 50 přesměrováních se zastaví, aby zabránil nekonečným smyčkám. Pokud narážíte na tento limit, máte smyčku přesměrování.

Oprava je obvykle změna konfigurace: říct aplikaci, aby důvěřovala hlavičce X-Forwarded-Proto, nebo říct CDN, aby přestala přesměrovávat požadavky, které už jsou HTTPS. Opravit to ale nemůžete, dokud smyčku neuvidíte, a prohlížeč vám neukáže víc než několik přesměrování, než to vzdá.

Co zkontrolovat jako první

Když se něco v produkci rozbije, kontrolujte v tomto pořadí:

1. Stavový kód: Je takový, jaký jste očekávali? 301 je trvalé, 302 je dočasné, 307 zachovává HTTP metodu. Pokud vidíte špatný kód, problém je v konfiguraci přesměrování.

1. Hlavička Location: Míří na správné místo? Je to absolutní URL, nebo relativní? Relativní URL se vyhodnocují vůči aktuální URL, což může vést k neočekávaným výsledkům, pokud základní URL není taková, jak si myslíte.

1. Cache hlavičky: Cachuje prohlížeč přesměrování? Přesměrování 301 se ve výchozím nastavení cachuje, což znamená, že špatně nakonfigurované přesměrování může rozbít web na hodiny i poté, co ho opravíte. Zkontrolujte hlavičky Cache-Control a Expires, abyste viděli, jak dlouho si prohlížeč přesměrování zapamatuje.

1. CORS hlavičky: Pokud je požadavek cross-origin, posílá server správnou hlavičku Access-Control-Allow-Origin? Pokud ne, prohlížeč požadavek zablokuje a v konzoli uvidíte chybu CORS. Hlavičky odpovědi serveru jsou jediné místo, kde to opravit — v prohlížeči to obejít nejde.

1. Časování: Jak dlouho požadavek trval? Pokud je pomalý, jde o latenci sítě, nebo zpracování na serveru? DevTools v prohlížeči i WebPageTest ukazují rozpad časování, který řekne, kam čas zmizel.

Pro hlubší pohled na to, jak se chování prohlížečů posunulo kolem soukromí a hlaviček, viz co se v roce 2026 změnilo u cookies a co s tím dělat, kde se probírají dopady nedávných aktualizací prohlížečů na hlavičky a souhlas.

Hlavní poznatky

• curl -L -v ukáže celý řetězec přesměrování a všechny hlavičky, bez interpretace prohlížeče
• Karta Network v prohlížeči ukáže, co prohlížeč s odpovědí udělal, včetně rozhodnutí o cachování a CORS
• mitmproxy ukáže, co prohlížeč odeslal, včetně hlaviček, které prohlížeč přidává automaticky
• WebPageTest ukáže, co zažívají skuteční uživatelé, včetně chování CDN a regionálních rozdílů
• Smyčky přesměrování a protichůdné hlavičky jsou nejběžnější produkční problémy a bez kontroly surového HTTP jsou neviditelné

FAQ

Otázka: Proč curl ukazuje jiné hlavičky než prohlížeč?

Odpověď: Protože prohlížeč automaticky přidává hlavičky (User-Agent, Accept, Cookie) a řídí se vlastními pravidly pro cachování a CORS. curl posílá jen to, co mu řeknete. Chcete-li vidět, co prohlížeč skutečně odesílá, použijte mitmproxy nebo DevTools v prohlížeči.

Otázka: Jak ladit přesměrování, které se děje jen některým uživatelům?

Odpověď: Zkontrolujte, zda přesměrování nezávisí na hlavičkách, které uživatel posílá: User-Agent, Accept-Language, Cookie nebo IP adresa (přes X-Forwarded-For). Použijte curl k odeslání stejných hlaviček, jaké poslal uživatel, nebo použijte WebPageTest k načtení stránky z lokality uživatele.

Otázka: Jaký je rozdíl mezi přesměrováním 301 a 302?

Odpověď: 301 je trvalé a říká prohlížeči, aby si přesměrování uložil do cache (někdy navždy). 302 je dočasné a říká prohlížeči, aby ho necachoval. Pokud si nejste jistí, které použít, použijte 302 — později ho vždy můžete změnit na 301.

Otázka: Proč moje přesměrování funguje v curl, ale ne v prohlížeči?

Odpověď: Pravděpodobně proto, že prohlížeč cachuje staré přesměrování, nebo proto, že přesměrování blokuje kvůli pravidlům CORS nebo mixed content. Zkontrolujte konzoli DevTools v prohlížeči, zda neobsahuje chyby, a zkontrolujte hlavičky Cache-Control, abyste zjistili, zda prohlížeč nepoužívá cachovanou odpověď.

Otázka: Jak zobrazit hlavičky, které přidává CDN?

Odpověď: Použijte curl na URL CDN a potom použijte curl znovu přímo na origin server (s obejitím CDN). Porovnejte hlavičky. Ty, které se objeví jen v první odpovědi, přišly z CDN.

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

💡 Vyzkoušejte toto: Při řešení problémů s přesměrováním Redirect Checker sleduje celý řetězec a zobrazuje stavové kódy a hlavičky při každém kroku.

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

Zdroje

• dokumentace curl — Oficiální reference možností příkazové řádky curl a jeho chování
• dokumentace HTTPie — Průvodce syntaxí a funkcemi httpie
• MDN Web Docs: HTTP redirections — Komplexní vysvětlení stavových kódů HTTP přesměrování a jejich chování
• dokumentace WebPageTest — Jak interpretovat výsledky a hlavičky ve WebPageTest