Малък набор от инструменти за отстраняване на проблеми с пренасочвания и HTTP заглавки в production

Проблемът с отстраняването на HTTP проблеми в production

Повечето HTTP проблеми са невидими в браузъра. Верига от пренасочвания се проваля безшумно, cache заглавка е сгрешена с един символ, CORS политика блокира заявка без обяснение. Инструментите за разработчици на браузъра ви показват резултата от разговора, но често скриват суровия обмен, който е причинил проблема.

Това е най-важно в production, където не можете да добавите logging или да рестартирате услуги, за да видите какво се е променило. Нужни са ви инструменти, които показват реалния HTTP разговор: request headers, response headers, status codes, redirect targets, timing. Ето петте инструмента, които вършат тази работа надеждно, плюс браузърните техники, които ги допълват.

curl: основата

curl е първият инструмент, към който да посегнете, защото ви показва точно какво е изпратил сървърът, без браузърна интерпретация по средата.

За да видите response headers без body:

curl -I https://example.com

За да следвате пренасочвания и да видите всяка стъпка:

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

Флагът -v (verbose) показва пълната заявка и отговор, включително всички заглавки. Флагът -L следва пренасочванията автоматично. Заедно те ви показват цялата redirect chain, където се крият повечето production проблеми.

За да видите само redirect locations:

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

Това е полезно, когато трябва да проверите верига от пренасочвания без шума на пълните заглавки. Флагът -w форматира изхода така, че да показва само status code и следващия URL във веригата.

curl също ви позволява да изпращате custom headers, което е съществено за тестване на CDN поведение, authentication или API endpoints:

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

httpie: curl с по-добри настройки по подразбиране

httpie е Python инструмент, който прави това, което прави curl, но със синтаксис, който е по-лесен за запомняне, и изход, който е по-лесен за четене. Той не е заместител — curl е по-мощен и по-широко инсталиран — но за бързи проверки httpie е по-бърз.

За да видите заглавки:

http HEAD https://example.com

За да следвате пренасочвания:

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

Флагът --all показва всеки отговор във веригата от пренасочвания, не само финалния. Това е еквивалентът на curl -L -v, но изходът е цветово кодиран и по-лесен за преглеждане.

За да изпратите JSON:

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

httpie приема JSON по подразбиране, което спестява писане, когато тествате APIs. Той също форматира красиво отговора, което улеснява откриването на malformed headers или неочаквани стойности.

Browser DevTools: раздел Network

Разделът Network на браузъра е мястото, откъдето трябва да започнете, ако проблемът се случва само в браузъра. Той ви показва същата информация като curl, но също така показва интерпретацията на браузъра: дали е блокирал заявка, как е обработил кеширането, дали е изпратил cookies.

За да видите пълните request и response headers, кликнете върху която и да е заявка в раздела Network, след това погледнете секцията Headers. Изгледът "Raw" показва заглавките точно както са изпратени, без форматиране.

За да видите redirect chains, търсете заявки с 3xx status codes. Браузърът ги групира под финалната заявка, но можете да ги разгънете, за да видите всяка стъпка. Там ще намерите redirect loops, липсващи Location headers или пренасочвания, които сочат към грешен домейн.

За да видите timing, погледнете раздела Timing за която и да е заявка. Той ви показва колко време е прекарал браузърът за DNS lookup, TCP connection, TLS handshake и чакане на сървъра. Ако дадено пренасочване е бавно, разделът timing ви казва дали проблемът е network latency или server processing.

Едно ограничение: браузърът скрива някои заглавки от съображения за сигурност. Set-Cookie headers са видими, но реалните cookie values са редактирани. Authorization headers понякога са изцяло скрити. Ако трябва да ги видите, използвайте curl.

mitmproxy: прихващащият proxy

mitmproxy е Python инструмент, който застава между браузъра ви и сървъра, показвайки всяка заявка и отговор в реално време. Той е по-сложен от curl, но е единственият инструмент, който показва какво браузърът действително изпраща, включително заглавки, които браузърът добавя автоматично.

За да го стартирате:

mitmproxy

След това конфигурирайте браузъра си да използва localhost:8080 като HTTP proxy. mitmproxy ще ви показва всяка заявка в терминален интерфейс. Можете да инспектирате заглавки, да редактирате заявки преди да бъдат изпратени или да повторите заявки с различни параметри.

Това е полезно за отстраняване на проблеми, които се случват само в браузъра: CORS preflight requests, обработка на cookies или заявки, които се провалят, когато са налице определени заглавки. Полезно е и за тестване как се държи сайтът ви зад corporate proxy или VPN, защото mitmproxy може да симулира тези среди.

Недостатъкът е сложността на настройката. Трябва да инсталирате root certificate, за да може mitmproxy да прихваща HTTPS traffic, и трябва да конфигурирате браузъра си да използва proxy. За бързи проверки curl е по-бърз. За дълбоко отстраняване на проблеми mitmproxy си струва времето за настройка.

webpagetest: production перспектива

WebPageTest е безплатна услуга, която зарежда страницата ви от реални браузъри на различни локации и ви показва пълния HTTP разговор. Тя е по-бавна от curl, но показва какво преживяват реалните потребители, включително CDN поведение, DNS resolution и TLS negotiation.

Изгледите "Request Headers" и "Response Headers" ви показват точно какво е изпратил и получил браузърът. Изгледът "Waterfall" показва timing на всяка заявка, включително пренасочванията. Там ще намерите проблеми, които се случват само в определени региони или в определени мрежи.

WebPageTest също ви показва redirect chain за основния документ, където се намират повечето проблеми с пренасочвания. Ако сайтът ви пренасочва от http:// към https://, след това от www. към non-www., а после от / към /en/, WebPageTest ви показва и трите стъпки и колко време е отнела всяка.

За инструменти, които ви помагат да валидирате и оптимизирате тези HTTP основи, Wux Webtools предлага няколко помощни инструмента, които работят изцяло във вашия браузър, включително анализатори на заглавки и проверяващи инструменти за пренасочвания, които уважават поверителността ви, като обработват всичко client-side.

Когато заглавките лъжат

Най-трудните HTTP проблеми са тези, при които сървърът изпраща противоречиви заглавки. Заглавка Cache-Control казва no-cache, но заглавка Expires казва, че ресурсът е валиден за една година. Заглавка Location сочи към относителен URL, но заглавката Content-Location сочи някъде другаде. Браузърът трябва да прецени на кое да се довери, а различните браузъри преценяват различно.

Когато това се случи, трябва да видите суровите заглавки в реда, в който сървърът ги е изпратил. curl -v прави това. mitmproxy също. DevTools на браузъра понякога пренарежда заглавките за по-добра четимост, което скрива проблема.

Друг често срещан проблем: заглавки, добавени от CDN или load balancer, а не от вашето приложение. Ако отстранявате проблем с кеширане, трябва да знаете дали заглавката Cache-Control идва от приложението ви или от CDN. curl ви показва финалния резултат, но не ви казва откъде идва всяка заглавка. За това трябва да заобиколите CDN (като ударите origin server директно) и да сравните заглавките.

Проблемът с redirect loop

Redirect loops са най-често срещаният HTTP проблем в production. Те се случват, когато два сървъра не са съгласни къде трябва да сочи даден URL: CDN пренасочва към origin, origin пренасочва обратно към CDN. Или load balancer пренасочва HTTP към HTTPS, но приложението пренасочва HTTPS обратно към HTTP, защото не вижда заглавката X-Forwarded-Proto.

За да отстраните това, трябва да видите пълната redirect chain, включително заглавката Location на всяка стъпка. curl -L -v прави това, но спира след 50 пренасочвания, за да предотврати безкрайни цикли. Ако достигате този лимит, имате redirect loop.

Поправката обикновено е промяна в конфигурацията: кажете на приложението да се доверява на заглавката X-Forwarded-Proto или кажете на CDN да спре да пренасочва заявки, които вече са HTTPS. Но не можете да го поправите, докато не видите цикъла, а браузърът няма да ви покаже повече от няколко пренасочвания, преди да се откаже.

Какво да проверите първо

Когато нещо се счупи в production, проверете тези неща в този ред:

1. Status code: Такъв ли е, какъвто очаквате? 301 е permanent, 302 е temporary, 307 запазва HTTP method. Ако виждате грешен код, проблемът е в конфигурацията на пренасочванията.

1. Location header: Сочи ли към правилното място? Абсолютен URL ли е или относителен? Relative URLs се разрешават спрямо текущия URL, което може да доведе до неочаквани резултати, ако base URL не е това, което мислите.

1. Cache headers: Браузърът кешира ли пренасочването? 301 redirect се кешира по подразбиране, което означава, че неправилно конфигурирано пренасочване може да счупи сайта ви за часове дори след като го поправите. Проверете заглавките Cache-Control и Expires, за да видите колко дълго браузърът ще помни пренасочването.

1. CORS headers: Ако заявката е cross-origin, изпраща ли сървърът правилната заглавка Access-Control-Allow-Origin? Ако не, браузърът ще блокира заявката и ще видите CORS грешка в конзолата. Response headers на сървъра са единственото място, където това може да се поправи — не можете да го заобиколите в браузъра.

1. Timing: Колко време отне заявката? Ако е бавна, проблемът network latency ли е или server processing? DevTools на браузъра и WebPageTest и двете показват timing breakdowns, които ви казват къде е отишло времето.

За по-задълбочен поглед към това как поведението на браузърите се промени около privacy и headers, вижте какво се промени за cookies през 2026 и какво да направите по въпроса, където са разгледани последиците за заглавките и consent от последните актуализации на браузърите.

Основни изводи

• curl -L -v ви показва пълната redirect chain и всички headers, без браузърна интерпретация
• Разделът Network на браузъра ви показва какво браузърът направи с отговора, включително решения за caching и CORS
• mitmproxy ви показва какво браузърът изпрати, включително заглавки, които браузърът добавя автоматично
• WebPageTest ви показва какво преживяват реалните потребители, включително CDN поведение и регионални разлики
• Redirect loops и противоречивите headers са най-често срещаните production проблеми и са невидими без инспекция на суров HTTP

FAQ

Q: Защо curl показва различни заглавки от браузъра?

A: Защото браузърът добавя заглавки автоматично (User-Agent, Accept, Cookie) и следва собствените си правила за caching и CORS. curl изпраща само това, което му кажете да изпрати. За да видите какво браузърът действително изпраща, използвайте mitmproxy или DevTools на браузъра.

Q: Как да отстраня проблем с пренасочване, което се случва само при някои потребители?

A: Проверете дали пренасочването зависи от заглавки, които потребителят изпраща: User-Agent, Accept-Language, Cookie или IP адрес (чрез X-Forwarded-For). Използвайте curl, за да изпратите същите заглавки, които е изпратил потребителят, или използвайте WebPageTest, за да заредите страницата от локацията на потребителя.

Q: Каква е разликата между 301 и 302 redirects?

A: 301 е permanent и казва на браузъра да кешира пренасочването (понякога завинаги). 302 е temporary и казва на браузъра да не го кешира. Ако не сте сигурни кое да използвате, използвайте 302 — винаги можете да го смените на 301 по-късно.

Q: Защо пренасочването ми работи в curl, но не и в браузъра?

A: Вероятно защото браузърът кешира старо пренасочване или защото браузърът блокира пренасочването заради CORS или mixed content правила. Проверете конзолата на DevTools на браузъра за грешки и проверете заглавките Cache-Control, за да видите дали браузърът използва кеширан отговор.

Q: Как да видя заглавките, които добавя CDN?

A: Използвайте curl, за да ударите CDN URL, след това използвайте curl отново, за да ударите origin server директно (заобикаляйки CDN). Сравнете заглавките. Тези, които се появяват само в първия отговор, идват от CDN.

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

💡 Опитайте това: Когато търсите причините за проблеми с пренасочванията, Redirect Checker проследява цялата верига и показва кодовете на състоянието и заглавките при всяка стъпка.

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

Източници

• curl documentation — Официална справка за опциите от командния ред и поведението на curl
• HTTPie documentation — Ръководство за синтаксиса и функциите на httpie
• MDN Web Docs: HTTP redirections — Подробно обяснение на HTTP redirect status codes и поведение
• WebPageTest documentation — Как да интерпретирате резултатите и заглавките от WebPageTest