En liten verktygslåda för att felsöka omdirigeringar och HTTP-headers i produktion

Problemet med att felsöka HTTP i produktion

De flesta HTTP-problem är osynliga i webbläsaren. En omdirigeringskedja misslyckas tyst, en cache-header är fel med ett enda tecken, en CORS-policy blockerar en begäran utan förklaring. Webbläsarens utvecklarverktyg visar resultatet av konversationen, men de döljer ofta det råa utbytet som orsakade problemet.

Det här är viktigast i produktion, där du inte kan lägga till loggning eller starta om tjänster för att se vad som ändrats. Du behöver verktyg som visar den faktiska HTTP-konversationen: request headers, response headers, statuskoder, omdirigeringsmål och timing. Här är de fem verktygen som gör jobbet tillförlitligt, plus webbläsarteknikerna som kompletterar dem.

curl: grunden

curl är det första verktyget att ta fram eftersom det visar exakt vad servern skickade, utan någon webbläsartolkning däremellan.

För att se response headers utan body:

curl -I https://example.com

För att följa omdirigeringar och se varje steg:

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

Flaggan -v (verbose) visar hela request och response, inklusive alla headers. Flaggan -L följer omdirigeringar automatiskt. Tillsammans visar de hela omdirigeringskedjan, vilket är där de flesta produktionsproblem finns.

För att bara se omdirigeringsplatserna:

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

Det här är användbart när du behöver verifiera en omdirigeringskedja utan bruset från fullständiga headers. Flaggan -w formaterar utdatan så att den bara visar statuskoden och nästa URL i kedjan.

curl låter dig också skicka anpassade headers, vilket är nödvändigt för att testa CDN-beteende, autentisering eller API-endpoints:

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

httpie: curl med bättre standardinställningar

httpie är ett Python-verktyg som gör det curl gör, men med syntax som är lättare att komma ihåg och utdata som är lättare att läsa. Det är inte en ersättare — curl är kraftfullare och mer allmänt installerat — men för snabba kontroller är httpie snabbare.

För att se headers:

http HEAD https://example.com

För att följa omdirigeringar:

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

Flaggan --all visar varje response i omdirigeringskedjan, inte bara den sista. Det motsvarar curl -L -v, men utdatan är färgkodad och lättare att skanna.

För att skicka JSON:

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

httpie utgår från JSON som standard, vilket sparar skrivande när du testar API:er. Det snyggformaterar också svaret, vilket gör det lättare att upptäcka felaktigt formade headers eller oväntade värden.

Browser DevTools: Network-fliken

Webbläsarens Network-flik är där du bör börja om problemet bara uppstår i webbläsaren. Den visar samma information som curl, men den visar också webbläsarens tolkning: om den blockerade en begäran, hur den hanterade cachelagring och om den skickade cookies.

För att se fullständiga request och response headers klickar du på en begäran i Network-fliken och tittar sedan i avsnittet Headers. Vyn ”Raw” visar headers exakt som de skickades, utan formatering.

För att se omdirigeringskedjor letar du efter requests med 3xx-statuskoder. Webbläsaren grupperar dem under den slutliga begäran, men du kan expandera dem för att se varje steg. Det är här du hittar omdirigeringsloopar, saknade Location-headers eller omdirigeringar som pekar på fel domän.

För att se timing tittar du på fliken Timing för valfri begäran. Den visar hur lång tid webbläsaren lade på DNS-uppslagning, TCP-anslutning, TLS-handshake och väntan på servern. Om en omdirigering är långsam visar timing-fliken om problemet är nätverkslatens eller serverbearbetning.

En begränsning: webbläsaren döljer vissa headers av säkerhetsskäl. Set-Cookie-headers är synliga, men de faktiska cookie-värdena maskeras. Authorization-headers döljs ibland helt. Om du behöver se dem använder du curl.

mitmproxy: den avlyssnande proxyn

mitmproxy är ett Python-verktyg som sitter mellan din webbläsare och servern och visar varje request och response i realtid. Det är mer komplext än curl, men det är det enda verktyget som visar vad webbläsaren faktiskt skickar, inklusive headers som webbläsaren lägger till automatiskt.

För att starta det:

mitmproxy

Konfigurera sedan webbläsaren att använda localhost:8080 som HTTP-proxy. mitmproxy visar varje request i ett terminalgränssnitt. Du kan inspektera headers, redigera requests innan de skickas eller spela upp requests igen med andra parametrar.

Det här är användbart för att felsöka problem som bara uppstår i webbläsaren: CORS preflight requests, cookie-hantering eller requests som misslyckas när vissa headers finns med. Det är också användbart för att testa hur din webbplats beter sig bakom en företagsproxy eller VPN, eftersom mitmproxy kan simulera sådana miljöer.

Nackdelen är komplexiteten i installationen. Du behöver installera ett root certificate så att mitmproxy kan avlyssna HTTPS-trafik, och du behöver konfigurera webbläsaren att använda proxyn. För snabba kontroller är curl snabbare. För djup felsökning är mitmproxy värt tiden det tar att sätta upp.

webpagetest: produktionsperspektivet

WebPageTest är en kostnadsfri tjänst som laddar din sida från riktiga webbläsare på olika platser och visar hela HTTP-konversationen. Den är långsammare än curl, men den visar vad verkliga användare upplever, inklusive CDN-beteende, DNS-upplösning och TLS-förhandling.

Vyerna ”Request Headers” och ”Response Headers” visar exakt vad webbläsaren skickade och tog emot. Vyn ”Waterfall” visar timingen för varje request, inklusive omdirigeringar. Det är här du hittar problem som bara uppstår i vissa regioner eller på vissa nätverk.

WebPageTest visar också omdirigeringskedjan för huvuddokumentet, vilket är där de flesta omdirigeringsproblem finns. Om din webbplats omdirigerar från http:// till https://, sedan från www. till icke-www., och sedan från / till /en/, visar WebPageTest alla tre steg och hur lång tid varje steg tog.

För verktyg som hjälper dig att validera och optimera dessa HTTP-grunder erbjuder Wux Webtools flera verktyg som körs helt i din webbläsare, inklusive header-analysverktyg och omdirigeringskontroller som respekterar din integritet genom att behandla allt på klientsidan.

När headers ljuger

De svåraste HTTP-problemen är de där servern skickar motsägelsefulla headers. En Cache-Control-header säger no-cache, men en Expires-header säger att resursen är giltig i ett år. En Location-header pekar på en relativ URL, men Content-Location-headern pekar någon annanstans. Webbläsaren måste gissa vilken den ska lita på, och olika webbläsare gissar olika.

När detta händer behöver du se de råa headers i den ordning servern skickade dem. curl -v gör detta. Det gör även mitmproxy. Webbläsarens DevTools ordnar ibland om headers för läsbarhet, vilket döljer problemet.

Ett annat vanligt problem: headers som läggs till av ett CDN eller en lastbalanserare, inte av din applikation. Om du felsöker ett cacheproblem behöver du veta om Cache-Control-headern kom från din app eller från CDN:et. curl visar slutresultatet, men det talar inte om var varje header kom ifrån. För det behöver du kringgå CDN:et (genom att träffa origin-servern direkt) och jämföra headers.

Problemet med omdirigeringsloopar

Omdirigeringsloopar är det vanligaste HTTP-problemet i produktion. De uppstår när två servrar inte är överens om vart en URL ska peka: CDN:et omdirigerar till origin, origin omdirigerar tillbaka till CDN:et. Eller så omdirigerar lastbalanseraren HTTP till HTTPS, men appen omdirigerar HTTPS tillbaka till HTTP eftersom den inte ser X-Forwarded-Proto-headern.

För att felsöka detta behöver du se hela omdirigeringskedjan, inklusive Location-headern vid varje steg. curl -L -v gör detta, men den stannar efter 50 omdirigeringar för att förhindra oändliga loopar. Om du når den gränsen har du en omdirigeringsloop.

Lösningen är oftast en konfigurationsändring: säg åt appen att lita på X-Forwarded-Proto-headern, eller säg åt CDN:et att sluta omdirigera requests som redan är HTTPS. Men du kan inte åtgärda det förrän du ser loopen, och webbläsaren visar inte mer än några få omdirigeringar innan den ger upp.

Vad du ska kontrollera först

När något går sönder i produktion, kontrollera detta i ordning:

1. Statuskod: Är den vad du förväntade dig? En 301 är permanent, en 302 är tillfällig, en 307 bevarar HTTP-metoden. Om du ser fel kod ligger problemet i din omdirigeringskonfiguration.

1. Location-header: Pekar den på rätt plats? Är det en absolut URL eller en relativ? Relativa URL:er löses mot den aktuella URL:en, vilket kan ge oväntade resultat om bas-URL:en inte är vad du tror att den är.

1. Cache-headers: Cachelagrar webbläsaren omdirigeringen? En 301-omdirigering cachelagras som standard, vilket innebär att en felkonfigurerad omdirigering kan förstöra din webbplats i timmar även efter att du åtgärdat den. Kontrollera Cache-Control- och Expires-headers för att se hur länge webbläsaren kommer ihåg omdirigeringen.

1. CORS-headers: Om begäran är cross-origin, skickar servern rätt Access-Control-Allow-Origin-header? Om inte blockerar webbläsaren begäran, och du ser ett CORS-fel i konsolen. Serverns response headers är den enda platsen där detta kan åtgärdas — du kan inte kringgå det i webbläsaren.

1. Timing: Hur lång tid tog begäran? Om den är långsam, beror det på nätverkslatens eller serverbearbetning? Webbläsarens DevTools och WebPageTest visar båda timinguppdelningar som talar om vart tiden tog vägen.

För en djupare titt på hur webbläsarbeteende har förändrats kring integritet och headers, se vad som ändrades för cookies 2026 och vad du bör göra åt det, som täcker header- och samtyckesimplikationerna av de senaste webbläsaruppdateringarna.

Viktiga slutsatser

• curl -L -v visar hela omdirigeringskedjan och alla headers, utan webbläsartolkning
• Webbläsarens Network-flik visar vad webbläsaren gjorde med svaret, inklusive cachelagring och CORS-beslut
• mitmproxy visar vad webbläsaren skickade, inklusive headers som webbläsaren lägger till automatiskt
• WebPageTest visar vad verkliga användare upplever, inklusive CDN-beteende och regionala skillnader
• Omdirigeringsloopar och motsägelsefulla headers är de vanligaste produktionsproblemen, och de är osynliga utan rå HTTP-inspektion

FAQ

Q: Varför visar curl andra headers än webbläsaren?

A: Därför att webbläsaren lägger till headers automatiskt (User-Agent, Accept, Cookie) och följer sina egna regler för cachelagring och CORS. curl skickar bara det du säger åt det att skicka. För att se vad webbläsaren faktiskt skickar, använd mitmproxy eller webbläsarens DevTools.

Q: Hur felsöker jag en omdirigering som bara uppstår för vissa användare?

A: Kontrollera om omdirigeringen beror på headers som användaren skickar: User-Agent, Accept-Language, Cookie eller IP-adress (via X-Forwarded-For). Använd curl för att skicka samma headers som användaren skickade, eller använd WebPageTest för att ladda sidan från användarens plats.

Q: Vad är skillnaden mellan 301- och 302-omdirigeringar?

A: En 301 är permanent och säger åt webbläsaren att cachelagra omdirigeringen (ibland för alltid). En 302 är tillfällig och säger åt webbläsaren att inte cachelagra den. Om du inte är säker på vilken du ska använda, använd 302 — du kan alltid ändra den till 301 senare.

Q: Varför fungerar min omdirigering i curl men inte i webbläsaren?

A: Förmodligen för att webbläsaren cachelagrar en gammal omdirigering, eller för att webbläsaren blockerar omdirigeringen på grund av CORS- eller mixed content-regler. Kontrollera webbläsarens DevTools-konsol för fel och kontrollera Cache-Control-headers för att se om webbläsaren använder ett cachelagrat svar.

Q: Hur ser jag vilka headers ett CDN lägger till?

A: Använd curl för att träffa CDN-URL:en, och använd sedan curl igen för att träffa origin-servern direkt (och kringgå CDN:et). Jämför headers. De som bara visas i det första svaret kom från CDN:et.

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

💡 Prova detta: När du felsöker omdirigeringsproblem spårar Redirect Checker hela kedjan och visar statuskoderna och headerna vid varje hopp.

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

Källor

• curl documentation — Officiell referens för curl-kommandoradsalternativ och beteende
• HTTPie documentation — Guide till httpie-syntax och funktioner
• MDN Web Docs: HTTP redirections — Omfattande förklaring av HTTP-statuskoder för omdirigering och deras beteende
• WebPageTest documentation — Hur du tolkar WebPageTest-resultat och headers