Et lite verktøysett for feilsøking av viderekoblinger og HTTP-hoder i produksjon

Problemet med å feilsøke HTTP i produksjon

De fleste HTTP-problemer er usynlige i nettleseren. En viderekoblingskjede feiler stille, et hurtigbufferhode er feil med ett tegn, en CORS-policy blokkerer en forespørsel uten forklaring. Nettleserens utviklerverktøy viser deg resultatet av samtalen, men de skjuler ofte den rå utvekslingen som forårsaket problemet.

Dette betyr mest i produksjon, der du ikke kan legge til logging eller starte tjenester på nytt for å se hva som endret seg. Du trenger verktøy som viser deg den faktiske HTTP-samtalen: forespørselshoder, svarhoder, statuskoder, viderekoblingsmål, tidsbruk. Her er de fem verktøyene som gjør den jobben pålitelig, pluss nettleserteknikkene som utfyller dem.

curl: grunnlaget

curl er det første verktøyet du bør bruke, fordi det viser deg nøyaktig hva serveren sendte, uten nettlesertolkning imellom.

For å se svarhoder uten innholdet:

curl -I https://example.com

For å følge viderekoblinger og se hvert trinn:

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

Flagget -v (verbose) viser hele forespørselen og svaret, inkludert alle hoder. Flagget -L følger viderekoblinger automatisk. Sammen viser de deg hele viderekoblingskjeden, som er der de fleste produksjonsproblemer oppstår.

For å se bare viderekoblingsmålene:

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

Dette er nyttig når du må bekrefte en viderekoblingskjede uten støyen fra fullstendige hoder. Flagget -w formaterer utdataene slik at de bare viser statuskoden og neste URL i kjeden.

curl lar deg også sende egendefinerte hoder, noe som er avgjørende for å teste CDN-atferd, autentisering eller API-endepunkter:

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

httpie: curl med bedre standardvalg

httpie er et Python-verktøy som gjør det curl gjør, men med syntaks som er enklere å huske og utdata som er lettere å lese. Det er ikke en erstatning—curl er kraftigere og mer utbredt installert—men for raske kontroller er httpie raskere.

For å se hoder:

http HEAD https://example.com

For å følge viderekoblinger:

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

Flagget --all viser hvert svar i viderekoblingskjeden, ikke bare det siste. Dette tilsvarer curl -L -v, men utdataene er fargekodet og enklere å skanne.

For å sende JSON:

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

httpie antar JSON som standard, noe som sparer skriving når du tester API-er. Det formaterer også svaret pent, noe som gjør det lettere å oppdage feilformede hoder eller uventede verdier.

Browser DevTools: Network-fanen

Nettleserens Network-fane er der du bør starte hvis problemet bare oppstår i nettleseren. Den viser deg den samme informasjonen som curl, men den viser også nettleserens tolkning: om den blokkerte en forespørsel, hvordan den håndterte hurtigbufring, om den sendte cookies.

For å se hele forespørsels- og svarhodene klikker du på en forespørsel i Network-fanen og ser deretter på Headers-delen. Visningen "Raw" viser hodene nøyaktig slik de ble sendt, uten formatering.

For å se viderekoblingskjeder ser du etter forespørsler med 3xx-statuskoder. Nettleseren grupperer dem under den endelige forespørselen, men du kan utvide dem for å se hvert trinn. Det er her du finner viderekoblingssløyfer, manglende Location-hoder eller viderekoblinger som peker til feil domene.

For å se tidsbruk ser du på Timing-fanen for en forespørsel. Den viser hvor lang tid nettleseren brukte på DNS-oppslag, TCP-tilkobling, TLS-håndtrykk og venting på serveren. Hvis en viderekobling er treg, forteller Timing-fanen deg om problemet er nettverksforsinkelse eller serverbehandling.

Én begrensning: nettleseren skjuler noen hoder av sikkerhetsgrunner. Set-Cookie-hoder er synlige, men de faktiske cookie-verdiene er sladdet. Authorization-hoder er noen ganger helt skjult. Hvis du trenger å se disse, bruk curl.

mitmproxy: den avskjærende proxyen

mitmproxy er et Python-verktøy som sitter mellom nettleseren din og serveren, og viser deg hver forespørsel og hvert svar i sanntid. Det er mer komplekst enn curl, men det er det eneste verktøyet som viser deg hva nettleseren faktisk sender, inkludert hoder nettleseren legger til automatisk.

For å starte det:

mitmproxy

Konfigurer deretter nettleseren til å bruke localhost:8080 som HTTP-proxy. mitmproxy vil vise deg hver forespørsel i et terminalgrensesnitt. Du kan inspisere hoder, redigere forespørsler før de sendes, eller spille av forespørsler på nytt med andre parametere.

Dette er nyttig for å feilsøke problemer som bare skjer i nettleseren: CORS-preflight-forespørsler, cookie-håndtering eller forespørsler som feiler når bestemte hoder er til stede. Det er også nyttig for å teste hvordan nettstedet ditt oppfører seg bak en bedriftsproxy eller VPN, fordi mitmproxy kan simulere slike miljøer.

Ulempen er kompleksiteten i oppsettet. Du må installere et rotsertifikat slik at mitmproxy kan avskjære HTTPS-trafikk, og du må konfigurere nettleseren til å bruke proxyen. For raske kontroller er curl raskere. For dyp feilsøking er mitmproxy verdt oppsettstiden.

webpagetest: produksjonsperspektivet

WebPageTest er en gratis tjeneste som laster siden din fra ekte nettlesere på ulike steder og viser deg hele HTTP-samtalen. Den er tregere enn curl, men den viser deg hva virkelige brukere opplever, inkludert CDN-atferd, DNS-oppløsning og TLS-forhandling.

Visningene "Request Headers" og "Response Headers" viser deg nøyaktig hva nettleseren sendte og mottok. Visningen "Waterfall" viser tidsbruken for hver forespørsel, inkludert viderekoblinger. Det er her du finner problemer som bare oppstår i bestemte regioner eller på bestemte nettverk.

WebPageTest viser deg også viderekoblingskjeden for hoveddokumentet, som er der de fleste viderekoblingsproblemer oppstår. Hvis nettstedet ditt viderekobler fra http:// til https://, deretter fra www. til ikke-www., og deretter fra / til /en/, viser WebPageTest deg alle tre trinnene og hvor lang tid hvert tok.

For verktøy som hjelper deg å validere og optimalisere disse HTTP-grunnprinsippene, tilbyr Wux Webtools flere verktøy som kjører helt i nettleseren din, inkludert hodeanalysatorer og viderekoblingssjekkere som respekterer personvernet ditt ved å behandle alt på klientsiden.

Når hoder lyver

De vanskeligste HTTP-problemene er de der serveren sender motstridende hoder. Et Cache-Control-hode sier no-cache, men et Expires-hode sier at ressursen er gyldig i et år. Et Location-hode peker til en relativ URL, men Content-Location-hodet peker et annet sted. Nettleseren må gjette hvilket den skal stole på, og ulike nettlesere gjetter ulikt.

Når dette skjer, må du se de rå hodene i den rekkefølgen serveren sendte dem. curl -v gjør dette. Det gjør også mitmproxy. Nettleserens DevTools omorganiserer noen ganger hoder for lesbarhet, noe som skjuler problemet.

Et annet vanlig problem: hoder som legges til av en CDN eller lastbalanserer, ikke av applikasjonen din. Hvis du feilsøker et hurtigbufferproblem, må du vite om Cache-Control-hodet kom fra appen din eller fra CDN-en. curl viser deg sluttresultatet, men forteller deg ikke hvor hvert hode kom fra. For det må du omgå CDN-en (ved å treffe opprinnelsesserveren direkte) og sammenligne hodene.

Problemet med viderekoblingssløyfer

Viderekoblingssløyfer er det vanligste HTTP-problemet i produksjon. De oppstår når to servere er uenige om hvor en URL skal peke: CDN-en viderekobler til opprinnelsen, opprinnelsen viderekobler tilbake til CDN-en. Eller lastbalansereren viderekobler HTTP til HTTPS, men appen viderekobler HTTPS tilbake til HTTP fordi den ikke ser X-Forwarded-Proto-hodet.

For å feilsøke dette må du se hele viderekoblingskjeden, inkludert Location-hodet ved hvert trinn. curl -L -v gjør dette, men den stopper etter 50 viderekoblinger for å forhindre uendelige sløyfer. Hvis du treffer den grensen, har du en viderekoblingssløyfe.

Løsningen er vanligvis en konfigurasjonsendring: be appen stole på X-Forwarded-Proto-hodet, eller be CDN-en slutte å viderekoble forespørsler som allerede er HTTPS. Men du kan ikke fikse det før du ser sløyfen, og nettleseren vil ikke vise deg mer enn noen få viderekoblinger før den gir opp.

Hva du bør sjekke først

Når noe feiler i produksjon, sjekk dette i rekkefølge:

1. Statuskode: Er den som forventet? En 301 er permanent, en 302 er midlertidig, en 307 bevarer HTTP-metoden. Hvis du ser feil kode, ligger problemet i viderekoblingskonfigurasjonen din.

1. Location-hode: Peker det til riktig sted? Er det en absolutt URL eller en relativ? Relative URL-er løses mot den gjeldende URL-en, noe som kan gi uventede resultater hvis base-URL-en ikke er det du tror den er.

1. Hurtigbufferhoder: Hurtigbufrer nettleseren viderekoblingen? En 301-viderekobling hurtigbufres som standard, noe som betyr at en feilkonfigurert viderekobling kan ødelegge nettstedet ditt i timevis selv etter at du har fikset den. Sjekk Cache-Control- og Expires-hodene for å se hvor lenge nettleseren vil huske viderekoblingen.

1. CORS-hoder: Hvis forespørselen går på tvers av opphav, sender serveren riktig Access-Control-Allow-Origin-hode? Hvis ikke, vil nettleseren blokkere forespørselen, og du vil se en CORS-feil i konsollen. Serverens svarhoder er det eneste stedet dette kan fikses—du kan ikke omgå det i nettleseren.

1. Tidsbruk: Hvor lang tid tok forespørselen? Hvis den er treg, skyldes det nettverksforsinkelse eller serverbehandling? Nettleserens DevTools og WebPageTest viser begge tidsinndelinger som forteller deg hvor tiden gikk.

For en dypere gjennomgang av hvordan nettleseratferd har endret seg rundt personvern og hoder, se hva som endret seg for cookies i 2026 og hva du bør gjøre med det, som dekker hode- og samtykkeimplikasjonene av nylige nettleseroppdateringer.

Viktigste punkter

• curl -L -v viser deg hele viderekoblingskjeden og alle hoder, uten nettlesertolkning
• Nettleserens Network-fane viser deg hva nettleseren gjorde med svaret, inkludert beslutninger om hurtigbufring og CORS
• mitmproxy viser deg hva nettleseren sendte, inkludert hoder nettleseren legger til automatisk
• WebPageTest viser deg hva virkelige brukere opplever, inkludert CDN-atferd og regionale forskjeller
• Viderekoblingssløyfer og motstridende hoder er de vanligste produksjonsproblemene, og de er usynlige uten rå HTTP-inspeksjon

FAQ

Q: Hvorfor viser curl andre hoder enn nettleseren?

A: Fordi nettleseren legger til hoder automatisk (User-Agent, Accept, Cookie) og følger sine egne regler for hurtigbufring og CORS. curl sender bare det du ber den sende. For å se hva nettleseren faktisk sender, bruk mitmproxy eller nettleserens DevTools.

Q: Hvordan feilsøker jeg en viderekobling som bare skjer for noen brukere?

A: Sjekk om viderekoblingen avhenger av hoder brukeren sender: User-Agent, Accept-Language, Cookie eller IP-adresse (via X-Forwarded-For). Bruk curl til å sende de samme hodene som brukeren sendte, eller bruk WebPageTest til å laste siden fra brukerens plassering.

Q: Hva er forskjellen mellom 301- og 302-viderekoblinger?

A: En 301 er permanent og ber nettleseren hurtigbufre viderekoblingen (noen ganger for alltid). En 302 er midlertidig og ber nettleseren ikke hurtigbufre den. Hvis du er usikker på hvilken du skal bruke, bruk 302—du kan alltid endre den til 301 senere.

Q: Hvorfor fungerer viderekoblingen min i curl, men ikke i nettleseren?

A: Sannsynligvis fordi nettleseren hurtigbufrer en gammel viderekobling, eller fordi nettleseren blokkerer viderekoblingen på grunn av CORS eller regler for blandet innhold. Sjekk nettleserens DevTools-konsoll for feil, og sjekk Cache-Control-hodene for å se om nettleseren bruker et hurtigbufret svar.

Q: Hvordan ser jeg hodene en CDN legger til?

A: Bruk curl til å treffe CDN-URL-en, og bruk deretter curl igjen til å treffe opprinnelsesserveren direkte (utenom CDN-en). Sammenlign hodene. De som bare vises i det første svaret, kom fra CDN-en.

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

💡 Prøv dette: Når du sporer viderekoblingsproblemer, sporer Redirect Checker hele kjeden og viser statuskodene og headerne ved hvert hopp.

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

Kilder

• curl documentation — Offisiell referanse for curl-kommandolinjevalg og atferd
• HTTPie documentation — Veiledning til httpie-syntaks og funksjoner
• MDN Web Docs: HTTP redirections — Omfattende forklaring av HTTP-statuskoder for viderekobling og atferd
• WebPageTest documentation — Slik tolker du WebPageTest-resultater og hoder