Et lille værktøjssæt til fejlfinding af omdirigeringer og HTTP-headere i produktion

Problemet med at fejlfinde HTTP i produktion

De fleste HTTP-problemer er usynlige i browseren. En omdirigeringskæde fejler lydløst, en cache-header er forkert med ét tegn, en CORS-politik blokerer en forespørgsel uden forklaring. Browserens developer tools viser dig resultatet af samtalen, men de skjuler ofte den rå udveksling, der forårsagede problemet.

Det betyder mest i produktion, hvor du ikke kan tilføje logging eller genstarte services for at se, hvad der ændrede sig. Du har brug for værktøjer, der viser dig den faktiske HTTP-samtale: request headers, response headers, statuskoder, omdirigeringsmål, timing. Her er de fem værktøjer, der løser den opgave pålideligt, plus de browserteknikker, der supplerer dem.

curl: fundamentet

curl er det første værktøj, du bør gribe efter, fordi det viser dig præcis, hvad serveren sendte, uden browserfortolkning imellem.

For at se response headers uden body:

curl -I https://example.com

For at følge omdirigeringer og se hvert trin:

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

Flaget -v (verbose) viser hele request og response, inklusive alle headere. Flaget -L følger automatisk omdirigeringer. Sammen viser de dig hele omdirigeringskæden, og det er dér, de fleste produktionsproblemer ligger.

For kun at se omdirigeringsplaceringerne:

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

Det er nyttigt, når du skal verificere en omdirigeringskæde uden støjen fra alle headere. Flaget -w formaterer outputtet, så det kun viser statuskoden og den næste URL i kæden.

curl lader dig også sende brugerdefinerede headere, hvilket er afgørende, når du tester CDN-adfærd, autentificering eller API-endpoints:

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

httpie: curl med bedre standardindstillinger

httpie er et Python-værktøj, der gør det samme som curl, men med syntaks, der er lettere at huske, og output, der er lettere at læse. Det er ikke en erstatning — curl er mere kraftfuldt og mere udbredt installeret — men til hurtige tjek er httpie hurtigere.

For at se headere:

http HEAD https://example.com

For at følge omdirigeringer:

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

Flaget --all viser hvert response i omdirigeringskæden, ikke kun det endelige. Det svarer til curl -L -v, men outputtet er farvekodet og lettere at skimme.

For at sende JSON:

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

httpie antager som standard JSON, hvilket sparer indtastning, når du tester API'er. Det pretty-printer også responset, hvilket gør det lettere at få øje på malformed headere eller uventede værdier.

Browser DevTools: fanen Network

Browserens Network-fane er dér, du bør starte, hvis problemet kun opstår i browseren. Den viser dig de samme oplysninger som curl, men den viser dig også browserens fortolkning: om den blokerede en forespørgsel, hvordan den håndterede caching, om den sendte cookies.

For at se de fulde request og response headers skal du klikke på en hvilken som helst request i Network-fanen og derefter kigge i sektionen Headers. "Raw"-visningen viser headerne præcis, som de blev sendt, uden formatering.

For at se omdirigeringskæder skal du kigge efter requests med 3xx-statuskoder. Browseren grupperer dem under den endelige request, men du kan udvide dem for at se hvert trin. Det er her, du finder omdirigeringsloops, manglende Location-headere eller omdirigeringer, der peger på det forkerte domæne.

For at se timing skal du kigge på Timing-fanen for en hvilken som helst request. Den viser dig, hvor lang tid browseren brugte på DNS-opslag, TCP-forbindelse, TLS-handshake og på at vente på serveren. Hvis en omdirigering er langsom, fortæller timing-fanen dig, om problemet er netværkslatens eller serverbehandling.

Én begrænsning: Browseren skjuler nogle headere af sikkerhedsgrunde. Set-Cookie-headere er synlige, men de faktiske cookie-værdier er redigeret væk. Authorization-headere er nogle gange helt skjult. Hvis du har brug for at se dem, skal du bruge curl.

mitmproxy: den interceptende proxy

mitmproxy er et Python-værktøj, der sidder mellem din browser og serveren og viser dig hver request og response i realtid. Det er mere komplekst end curl, men det er det eneste værktøj, der viser dig, hvad browseren faktisk sender, inklusive headere, som browseren automatisk tilføjer.

For at starte det:

mitmproxy

Konfigurer derefter din browser til at bruge localhost:8080 som HTTP-proxy. mitmproxy viser dig hver request i en terminalgrænseflade. Du kan inspicere headere, redigere requests, før de sendes, eller afspille requests igen med andre parametre.

Det er nyttigt til fejlfinding af problemer, der kun opstår i browseren: CORS preflight requests, cookie-håndtering eller requests, der fejler, når bestemte headere er til stede. Det er også nyttigt til at teste, hvordan dit site opfører sig bag en corporate proxy eller VPN, fordi mitmproxy kan simulere disse miljøer.

Ulempen er opsætningskompleksitet. Du skal installere et rodcertifikat, så mitmproxy kan intercept HTTPS-trafik, og du skal konfigurere din browser til at bruge proxyen. Til hurtige tjek er curl hurtigere. Til dyb fejlfinding er mitmproxy opsætningstiden værd.

webpagetest: produktionsperspektivet

WebPageTest er en gratis service, der indlæser din side fra rigtige browsere forskellige steder og viser dig den fulde HTTP-samtale. Den er langsommere end curl, men den viser dig, hvad rigtige brugere oplever, inklusive CDN-adfærd, DNS-opløsning og TLS-forhandling.

Visningerne "Request Headers" og "Response Headers" viser dig præcis, hvad browseren sendte og modtog. "Waterfall"-visningen viser dig timingen for hver request, inklusive omdirigeringer. Det er her, du finder problemer, der kun opstår i bestemte regioner eller på bestemte netværk.

WebPageTest viser dig også omdirigeringskæden for hoveddokumentet, hvilket er dér, de fleste omdirigeringsproblemer ligger. Hvis dit site omdirigerer fra http:// til https://, derefter fra www. til ikke-www., og derefter fra / til /en/, viser WebPageTest dig alle tre trin, og hvor lang tid hvert trin tog.

For værktøjer, der hjælper dig med at validere og optimere disse HTTP-grundelementer, tilbyder Wux Webtools flere utilities, der kører helt i din browser, inklusive headeranalysatorer og omdirigeringstjekkere, der respekterer dit privatliv ved at behandle alt client-side.

Når headere lyver

De sværeste HTTP-problemer er dem, hvor serveren sender modstridende headere. En Cache-Control-header siger no-cache, men en Expires-header siger, at ressourcen er gyldig i et år. En Location-header peger på en relativ URL, men Content-Location-headeren peger et andet sted hen. Browseren skal gætte, hvilken den skal stole på, og forskellige browsere gætter forskelligt.

Når det sker, skal du se de rå headere i den rækkefølge, serveren sendte dem. curl -v gør dette. Det gør mitmproxy også. Browserens DevTools omrokerer nogle gange headere for læsbarhedens skyld, hvilket skjuler problemet.

Et andet almindeligt problem: headere, der tilføjes af et CDN eller en load balancer, ikke af din applikation. Hvis du fejlfinder et cachingproblem, skal du vide, om Cache-Control-headeren kom fra din app eller fra CDN'et. curl viser dig det endelige resultat, men det fortæller dig ikke, hvor hver header kom fra. Til det skal du omgå CDN'et (ved at ramme origin-serveren direkte) og sammenligne headerne.

Problemet med omdirigeringsloops

Omdirigeringsloops er det mest almindelige HTTP-problem i produktion. De opstår, når to servere er uenige om, hvor en URL skal pege hen: CDN'et omdirigerer til origin, origin omdirigerer tilbage til CDN'et. Eller load balanceren omdirigerer HTTP til HTTPS, men appen omdirigerer HTTPS tilbage til HTTP, fordi den ikke ser X-Forwarded-Proto-headeren.

For at fejlfinde dette skal du se hele omdirigeringskæden, inklusive Location-headeren ved hvert trin. curl -L -v gør dette, men det stopper efter 50 omdirigeringer for at forhindre uendelige loops. Hvis du rammer den grænse, har du et omdirigeringsloop.

Løsningen er normalt en konfigurationsændring: Fortæl appen, at den skal stole på X-Forwarded-Proto-headeren, eller fortæl CDN'et, at det skal stoppe med at omdirigere requests, der allerede er HTTPS. Men du kan ikke løse det, før du ser loopet, og browseren viser dig ikke mere end nogle få omdirigeringer, før den giver op.

Hvad du skal tjekke først

Når noget går i stykker i produktion, skal du tjekke disse i rækkefølge:

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

1. Location-header: Peger den det rigtige sted hen? Er det en absolut URL eller en relativ? Relative URL'er opløses i forhold til den aktuelle URL, hvilket kan give uventede resultater, hvis basis-URL'en ikke er den, du tror, den er.

1. Cache-headere: Cacher browseren omdirigeringen? En 301-omdirigering caches som standard, hvilket betyder, at en fejlkonfigureret omdirigering kan ødelægge dit site i timevis, selv efter du har rettet den. Tjek Cache-Control- og Expires-headerne for at se, hvor længe browseren vil huske omdirigeringen.

1. CORS-headere: Hvis forespørgslen er cross-origin, sender serveren så den rigtige Access-Control-Allow-Origin-header? Hvis ikke, blokerer browseren forespørgslen, og du vil se en CORS-fejl i konsollen. Serverens response headers er det eneste sted at rette dette — du kan ikke omgå det i browseren.

1. Timing: Hvor lang tid tog forespørgslen? Hvis den er langsom, er det så netværkslatens eller serverbehandling? Browserens DevTools og WebPageTest viser begge timingopdelinger, der fortæller dig, hvor tiden blev brugt.

For et dybere kig på, hvordan browseradfærd har ændret sig omkring privatliv og headere, se hvad der ændrede sig for cookies i 2026, og hvad du skal gøre ved det, som dækker header- og samtykkeimplikationerne af nyere browseropdateringer.

Vigtigste pointer

• curl -L -v viser dig hele omdirigeringskæden og alle headere, uden browserfortolkning
• Browserens Network-fane viser dig, hvad browseren gjorde med responset, inklusive caching- og CORS-beslutninger
• mitmproxy viser dig, hvad browseren sendte, inklusive headere, som browseren automatisk tilføjer
• WebPageTest viser dig, hvad rigtige brugere oplever, inklusive CDN-adfærd og regionale forskelle
• Omdirigeringsloops og modstridende headere er de mest almindelige produktionsproblemer, og de er usynlige uden rå HTTP-inspektion

FAQ

Q: Hvorfor viser curl andre headere end browseren?

A: Fordi browseren automatisk tilføjer headere (User-Agent, Accept, Cookie) og følger sine egne regler for caching og CORS. curl sender kun det, du beder den om at sende. For at se, hvad browseren faktisk sender, skal du bruge mitmproxy eller browserens DevTools.

Q: Hvordan fejlfinder jeg en omdirigering, der kun sker for nogle brugere?

A: Tjek, om omdirigeringen afhænger af headere, brugeren sender: User-Agent, Accept-Language, Cookie eller IP-adresse (via X-Forwarded-For). Brug curl til at sende de samme headere, som brugeren sendte, eller brug WebPageTest til at indlæse siden fra brugerens placering.

Q: Hvad er forskellen på 301- og 302-omdirigeringer?

A: En 301 er permanent og fortæller browseren, at den skal cache omdirigeringen (nogle gange for altid). En 302 er midlertidig og fortæller browseren, at den ikke skal cache den. Hvis du ikke er sikker på, hvilken du skal bruge, så brug 302 — du kan altid ændre den til 301 senere.

Q: Hvorfor virker min omdirigering i curl, men ikke i browseren?

A: Sandsynligvis fordi browseren cacher en gammel omdirigering, eller fordi browseren blokerer omdirigeringen på grund af CORS- eller mixed content-regler. Tjek browserens DevTools-konsol for fejl, og tjek Cache-Control-headerne for at se, om browseren bruger et cached response.

Q: Hvordan ser jeg de headere, et CDN tilføjer?

A: Brug curl til at ramme CDN-URL'en, og brug derefter curl igen til at ramme origin-serveren direkte (uden om CDN'et). Sammenlign headerne. Dem, der kun optræder i det første response, kom fra CDN'et.

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

💡 Prøv dette: Når du jagter omdirigeringsproblemer, sporer Redirect Checker hele kæden og viser statuskoderne og headerne ved hvert hop.

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

Kilder

• curl documentation — Officiel reference til curl-kommandolinjeindstillinger og adfærd
• HTTPie documentation — Guide til httpie-syntaks og funktioner
• MDN Web Docs: HTTP redirections — Omfattende forklaring af HTTP-statuskoder for omdirigering og deres adfærd
• WebPageTest documentation — Sådan fortolker du WebPageTest-resultater og headere