Un mic set de instrumente pentru depanarea redirecționărilor și a anteturilor HTTP în producție

Problema depanării HTTP în producție

Cele mai multe probleme HTTP sunt invizibile în browser. Un lanț de redirecționări eșuează fără semnalizare, un antet de cache este greșit cu un singur caracter, o politică CORS blochează o cerere fără explicație. Instrumentele pentru dezvoltatori ale browserului îți arată rezultatul conversației, dar adesea ascund schimbul brut care a provocat problema.

Acest lucru contează cel mai mult în producție, unde nu poți adăuga logging sau reporni servicii ca să vezi ce s-a schimbat. Ai nevoie de instrumente care îți arată conversația HTTP reală: anteturi de cerere, anteturi de răspuns, coduri de stare, ținte de redirecționare, timpi. Iată cele cinci instrumente care fac acest lucru în mod fiabil, plus tehnicile de browser care le completează.

curl: fundația

curl este primul instrument la care merită să apelezi, pentru că îți arată exact ce a trimis serverul, fără interpretarea browserului la mijloc.

Pentru a vedea anteturile de răspuns fără corp:

curl -I https://example.com

Pentru a urma redirecționările și a vedea fiecare pas:

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

Flagul -v (verbose) afișează cererea și răspunsul complet, inclusiv toate anteturile. Flagul -L urmează automat redirecționările. Împreună, îți arată întregul lanț de redirecționări, locul în care apar cele mai multe probleme din producție.

Pentru a vedea doar locațiile de redirecționare:

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

Acest lucru este util când trebuie să verifici un lanț de redirecționări fără zgomotul anteturilor complete. Flagul -w formatează ieșirea astfel încât să afișeze doar codul de stare și următorul URL din lanț.

curl îți permite și să trimiți anteturi personalizate, lucru esențial pentru testarea comportamentului CDN, a autentificării sau a endpointurilor API:

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

httpie: curl cu setări implicite mai bune

httpie este un instrument Python care face ceea ce face curl, dar cu o sintaxă mai ușor de reținut și o ieșire mai ușor de citit. Nu este un înlocuitor — curl este mai puternic și instalat mai frecvent — dar pentru verificări rapide, httpie este mai rapid.

Pentru a vedea anteturile:

http HEAD https://example.com

Pentru a urma redirecționările:

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

Flagul --all afișează fiecare răspuns din lanțul de redirecționări, nu doar pe cel final. Este echivalentul lui curl -L -v, dar ieșirea este colorată și mai ușor de parcurs vizual.

Pentru a trimite JSON:

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

httpie presupune JSON în mod implicit, ceea ce reduce tastarea când testezi API-uri. De asemenea, formatează lizibil răspunsul, ceea ce face mai ușor de observat anteturi malformate sau valori neașteptate.

Browser DevTools: fila Network

Fila Network a browserului este locul de unde ar trebui să începi dacă problema apare doar în browser. Îți arată aceleași informații ca curl, dar îți arată și interpretarea browserului: dacă a blocat o cerere, cum a gestionat cache-ul, dacă a trimis cookie-uri.

Pentru a vedea anteturile complete de cerere și răspuns, fă clic pe orice cerere din fila Network, apoi uită-te la secțiunea Headers. Vizualizarea "Raw" arată anteturile exact așa cum au fost trimise, fără formatare.

Pentru a vedea lanțurile de redirecționări, caută cereri cu coduri de stare 3xx. Browserul le grupează sub cererea finală, dar le poți extinde pentru a vedea fiecare pas. Aici vei găsi bucle de redirecționare, anteturi Location lipsă sau redirecționări care indică domeniul greșit.

Pentru a vedea timpii, uită-te la fila Timing pentru orice cerere. Aceasta îți arată cât timp a petrecut browserul pentru DNS lookup, conexiunea TCP, TLS handshake și așteptarea serverului. Dacă o redirecționare este lentă, fila Timing îți spune dacă problema este latența rețelei sau procesarea pe server.

O limitare: browserul ascunde unele anteturi din motive de securitate. Anteturile Set-Cookie sunt vizibile, dar valorile efective ale cookie-urilor sunt redactate. Anteturile Authorization sunt uneori ascunse complet. Dacă trebuie să le vezi, folosește curl.

mitmproxy: proxy-ul de interceptare

mitmproxy este un instrument Python care stă între browserul tău și server, arătându-ți fiecare cerere și răspuns în timp real. Este mai complex decât curl, dar este singurul instrument care îți arată ce trimite browserul de fapt, inclusiv anteturile pe care browserul le adaugă automat.

Pentru a-l porni:

mitmproxy

Apoi configurează browserul să folosească localhost:8080 ca proxy HTTP. mitmproxy îți va arăta fiecare cerere într-o interfață de terminal. Poți inspecta anteturile, modifica cererile înainte să fie trimise sau reda cereri cu parametri diferiți.

Acest lucru este util pentru depanarea problemelor care apar doar în browser: cereri CORS preflight, gestionarea cookie-urilor sau cereri care eșuează când anumite anteturi sunt prezente. Este util și pentru a testa cum se comportă site-ul tău în spatele unui proxy corporate sau al unui VPN, deoarece mitmproxy poate simula aceste medii.

Dezavantajul este complexitatea configurării. Trebuie să instalezi un certificat root pentru ca mitmproxy să poată intercepta traficul HTTPS și trebuie să configurezi browserul să folosească proxy-ul. Pentru verificări rapide, curl este mai rapid. Pentru depanare profundă, mitmproxy merită timpul de configurare.

webpagetest: perspectiva din producție

WebPageTest este un serviciu gratuit care îți încarcă pagina din browsere reale, aflate în locații diferite, și îți arată conversația HTTP completă. Este mai lent decât curl, dar îți arată ce experimentează utilizatorii reali, inclusiv comportamentul CDN, rezoluția DNS și negocierea TLS.

Vizualizările "Request Headers" și "Response Headers" îți arată exact ce a trimis și ce a primit browserul. Vizualizarea "Waterfall" îți arată temporizarea fiecărei cereri, inclusiv redirecționările. Aici vei găsi probleme care apar doar în anumite regiuni sau pe anumite rețele.

WebPageTest îți arată și lanțul de redirecționări pentru documentul principal, locul în care apar cele mai multe probleme de redirecționare. Dacă site-ul tău redirecționează de la http:// la https://, apoi de la www. la non-www., apoi de la / la /en/, WebPageTest îți arată toți cei trei pași și cât a durat fiecare.

Pentru instrumente care te ajută să validezi și să optimizezi aceste elemente fundamentale HTTP, Wux Webtools oferă mai multe utilitare care rulează integral în browserul tău, inclusiv analizatoare de anteturi și verificatoare de redirecționări care îți respectă confidențialitatea procesând totul client-side.

Când anteturile mint

Cele mai dificile probleme HTTP sunt cele în care serverul trimite anteturi contradictorii. Un antet Cache-Control spune no-cache, dar un antet Expires spune că resursa este validă timp de un an. Un antet Location indică un URL relativ, dar antetul Content-Location indică altundeva. Browserul trebuie să ghicească în care să aibă încredere, iar browsere diferite ghicesc diferit.

Când se întâmplă acest lucru, trebuie să vezi anteturile brute în ordinea în care le-a trimis serverul. curl -v face asta. La fel și mitmproxy. DevTools ale browserului reordonează uneori anteturile pentru lizibilitate, ceea ce ascunde problema.

O altă problemă frecventă: anteturi adăugate de un CDN sau de un load balancer, nu de aplicația ta. Dacă depanezi o problemă de caching, trebuie să știi dacă antetul Cache-Control a venit din aplicația ta sau din CDN. curl îți arată rezultatul final, dar nu îți spune de unde a venit fiecare antet. Pentru asta, trebuie să ocolești CDN-ul (lovind direct serverul origin) și să compari anteturile.

Problema buclelor de redirecționare

Buclele de redirecționare sunt cea mai comună problemă HTTP în producție. Apar când două servere nu sunt de acord asupra destinației către care ar trebui să indice un URL: CDN-ul redirecționează către origin, origin redirecționează înapoi către CDN. Sau load balancerul redirecționează HTTP către HTTPS, dar aplicația redirecționează HTTPS înapoi către HTTP pentru că nu vede antetul X-Forwarded-Proto.

Pentru a depana acest lucru, trebuie să vezi întregul lanț de redirecționări, inclusiv antetul Location la fiecare pas. curl -L -v face asta, dar se oprește după 50 de redirecționări pentru a preveni buclele infinite. Dacă atingi această limită, ai o buclă de redirecționare.

Remedierea este de obicei o modificare de configurare: spune-i aplicației să aibă încredere în antetul X-Forwarded-Proto sau spune-i CDN-ului să nu mai redirecționeze cererile care sunt deja HTTPS. Dar nu o poți remedia până nu vezi bucla, iar browserul nu îți va arăta mai mult de câteva redirecționări înainte să renunțe.

Ce să verifici mai întâi

Când ceva se strică în producție, verifică aceste lucruri în ordine:

1. Codul de stare: Este cel la care te așteptai? Un 301 este permanent, un 302 este temporar, un 307 păstrează metoda HTTP. Dacă vezi codul greșit, problema este în configurarea redirecționării.

1. Antetul Location: Indică locul corect? Este un URL absolut sau unul relativ? URL-urile relative sunt rezolvate în raport cu URL-ul curent, ceea ce poate produce rezultate neașteptate dacă URL-ul de bază nu este cel pe care îl crezi.

1. Anteturile de cache: Browserul pune în cache redirecționarea? O redirecționare 301 este pusă în cache implicit, ceea ce înseamnă că o redirecționare configurată greșit îți poate strica site-ul timp de ore întregi chiar și după ce o repari. Verifică anteturile Cache-Control și Expires pentru a vedea cât timp își va aminti browserul redirecționarea.

1. Anteturile CORS: Dacă cererea este cross-origin, serverul trimite antetul Access-Control-Allow-Origin corect? Dacă nu, browserul va bloca cererea și vei vedea o eroare CORS în consolă. Anteturile de răspuns ale serverului sunt singurul loc unde se poate remedia asta — nu poți ocoli problema în browser.

1. Timpul: Cât a durat cererea? Dacă este lentă, este vorba de latența rețelei sau de procesarea pe server? DevTools ale browserului și WebPageTest îți arată ambele defalcări ale timpilor care îți spun unde s-a dus timpul.

Pentru o privire mai aprofundată asupra felului în care comportamentul browserelor s-a schimbat în jurul confidențialității și al anteturilor, vezi ce s-a schimbat pentru cookie-uri în 2026 și ce să faci în privința asta, care acoperă implicațiile asupra anteturilor și consimțământului ale actualizărilor recente ale browserelor.

Idei principale

• curl -L -v îți arată întregul lanț de redirecționări și toate anteturile, fără interpretarea browserului
• Fila Network a browserului îți arată ce a făcut browserul cu răspunsul, inclusiv deciziile de caching și CORS
• mitmproxy îți arată ce a trimis browserul, inclusiv anteturile pe care browserul le adaugă automat
• WebPageTest îți arată ce experimentează utilizatorii reali, inclusiv comportamentul CDN și diferențele regionale
• Buclele de redirecționare și anteturile contradictorii sunt cele mai frecvente probleme din producție și sunt invizibile fără inspectarea HTTP brută

FAQ

Q: De ce curl afișează anteturi diferite față de browser?

A: Pentru că browserul adaugă anteturi automat (User-Agent, Accept, Cookie) și își urmează propriile reguli pentru caching și CORS. curl trimite doar ceea ce îi spui să trimită. Pentru a vedea ce trimite browserul de fapt, folosește mitmproxy sau DevTools ale browserului.

Q: Cum depanez o redirecționare care se întâmplă doar pentru unii utilizatori?

A: Verifică dacă redirecționarea depinde de anteturile trimise de utilizator: User-Agent, Accept-Language, Cookie sau adresa IP (prin X-Forwarded-For). Folosește curl pentru a trimite aceleași anteturi pe care le-a trimis utilizatorul sau folosește WebPageTest pentru a încărca pagina din locația utilizatorului.

Q: Care este diferența dintre redirecționările 301 și 302?

A: Un 301 este permanent și îi spune browserului să pună în cache redirecționarea (uneori pentru totdeauna). Un 302 este temporar și îi spune browserului să nu o pună în cache. Dacă nu ești sigur pe care să îl folosești, folosește 302 — îl poți schimba oricând în 301 mai târziu.

Q: De ce redirecționarea mea funcționează în curl, dar nu în browser?

A: Probabil pentru că browserul pune în cache o redirecționare veche sau pentru că browserul blochează redirecționarea din cauza regulilor CORS sau de conținut mixt. Verifică consola DevTools a browserului pentru erori și verifică anteturile Cache-Control pentru a vedea dacă browserul folosește un răspuns din cache.

Q: Cum văd anteturile pe care le adaugă un CDN?

A: Folosește curl pentru a accesa URL-ul CDN, apoi folosește din nou curl pentru a accesa direct serverul origin (ocolind CDN-ul). Compară anteturile. Cele care apar doar în primul răspuns au venit de la CDN.

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

💡 Încercați asta: Când investigați probleme de redirecționare, Redirect Checker urmărește întregul lanț și afișează codurile de stare și anteturile la fiecare pas.

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

Surse

• documentația curl — Referința oficială pentru opțiunile în linie de comandă și comportamentul curl
• documentația HTTPie — Ghid pentru sintaxa și funcționalitățile httpie
• MDN Web Docs: redirecționări HTTP — Explicație cuprinzătoare a codurilor de stare și comportamentului redirecționărilor HTTP
• documentația WebPageTest — Cum să interpretezi rezultatele și anteturile WebPageTest