Ein kleines Toolkit zum Debuggen von Weiterleitungen und HTTP-Headern in Produktion

Das Problem beim Debuggen von HTTP in Produktion

Die meisten HTTP-Probleme sind im Browser unsichtbar. Eine Weiterleitungskette scheitert still, ein Cache-Header ist um ein Zeichen falsch, eine CORS-Richtlinie blockiert eine Anfrage ohne Erklärung. Die Entwicklertools des Browsers zeigen Ihnen das Ergebnis der Konversation, verbergen aber oft den rohen Austausch, der das Problem verursacht hat.

Das ist vor allem in Produktion relevant, wo Sie nicht einfach Logging hinzufügen oder Dienste neu starten können, um zu sehen, was sich geändert hat. Sie brauchen Tools, die Ihnen die tatsächliche HTTP-Konversation zeigen: Request-Header, Response-Header, Statuscodes, Weiterleitungsziele, Timing. Hier sind die fünf Tools, die diese Aufgabe zuverlässig erledigen, plus die Browser-Techniken, die sie ergänzen.

curl: die Grundlage

curl ist das erste Tool, zu dem Sie greifen sollten, weil es genau zeigt, was der Server gesendet hat, ohne Browser-Interpretation dazwischen.

Um Response-Header ohne Body zu sehen:

curl -I https://example.com

Um Weiterleitungen zu folgen und jeden Schritt zu sehen:

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

Das Flag -v (verbose) zeigt den vollständigen Request und die vollständige Response, einschließlich aller Header. Das Flag -L folgt Weiterleitungen automatisch. Zusammen zeigen sie die gesamte Weiterleitungskette, und genau dort liegen viele Produktionsprobleme.

Um nur die Weiterleitungsziele zu sehen:

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

Das ist nützlich, wenn Sie eine Weiterleitungskette prüfen müssen, ohne das Rauschen vollständiger Header. Das Flag -w formatiert die Ausgabe so, dass nur der Statuscode und die nächste URL in der Kette angezeigt werden.

curl ermöglicht außerdem das Senden eigener Header, was für Tests von CDN-Verhalten, Authentifizierung oder API-Endpunkten unverzichtbar ist:

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

httpie: curl mit besseren Defaults

httpie ist ein Python-Tool, das dasselbe tut wie curl, aber mit einer Syntax, die leichter zu merken ist, und einer Ausgabe, die einfacher zu lesen ist. Es ist kein Ersatz — curl ist leistungsfähiger und weiter verbreitet installiert —, aber für schnelle Prüfungen ist httpie schneller.

Um Header zu sehen:

http HEAD https://example.com

Um Weiterleitungen zu folgen:

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

Das Flag --all zeigt jede Response in der Weiterleitungskette, nicht nur die letzte. Das entspricht curl -L -v, aber die Ausgabe ist farbcodiert und leichter zu überfliegen.

Um JSON zu senden:

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

httpie geht standardmäßig von JSON aus, was beim Testen von APIs Tipparbeit spart. Außerdem formatiert es die Response lesbar, sodass fehlerhafte Header oder unerwartete Werte leichter auffallen.

Browser-DevTools: Network-Tab

Der Network-Tab des Browsers ist der richtige Startpunkt, wenn das Problem nur im Browser auftritt. Er zeigt dieselben Informationen wie curl, aber zusätzlich die Interpretation des Browsers: ob er einen Request blockiert hat, wie er Caching behandelt hat, ob er Cookies gesendet hat.

Um die vollständigen Request- und Response-Header zu sehen, klicken Sie im Network-Tab auf einen beliebigen Request und sehen Sie sich dann den Abschnitt Headers an. Die Ansicht "Raw" zeigt die Header genau so, wie sie gesendet wurden, ohne Formatierung.

Um Weiterleitungsketten zu sehen, suchen Sie nach Requests mit 3xx-Statuscodes. Der Browser gruppiert sie unter dem finalen Request, aber Sie können sie aufklappen, um jeden Schritt zu sehen. Dort finden Sie Weiterleitungsschleifen, fehlende Location-Header oder Weiterleitungen, die auf die falsche Domain zeigen.

Um Timing zu sehen, öffnen Sie für einen Request den Timing-Tab. Dort sehen Sie, wie lange der Browser für DNS-Lookup, TCP-Verbindung, TLS-Handshake und das Warten auf den Server benötigt hat. Wenn eine Weiterleitung langsam ist, zeigt Ihnen der Timing-Tab, ob das Problem Netzwerklatenz oder Serververarbeitung ist.

Eine Einschränkung: Der Browser verbirgt einige Header aus Sicherheitsgründen. Set-Cookie-Header sind sichtbar, aber die tatsächlichen Cookie-Werte werden geschwärzt. Authorization-Header sind manchmal vollständig verborgen. Wenn Sie diese sehen müssen, verwenden Sie curl.

mitmproxy: der abfangende Proxy

mitmproxy ist ein Python-Tool, das zwischen Ihrem Browser und dem Server sitzt und jeden Request und jede Response in Echtzeit zeigt. Es ist komplexer als curl, aber es ist das einzige Tool, das zeigt, was der Browser tatsächlich sendet, einschließlich Headern, die der Browser automatisch hinzufügt.

Zum Starten:

mitmproxy

Konfigurieren Sie anschließend Ihren Browser so, dass er localhost:8080 als HTTP-Proxy verwendet. mitmproxy zeigt Ihnen jeden Request in einer Terminal-Oberfläche. Sie können Header prüfen, Requests vor dem Senden bearbeiten oder Requests mit anderen Parametern erneut abspielen.

Das ist nützlich, um Probleme zu debuggen, die nur im Browser auftreten: CORS-Preflight-Requests, Cookie-Handling oder Requests, die fehlschlagen, wenn bestimmte Header vorhanden sind. Es ist auch hilfreich, um zu testen, wie sich Ihre Website hinter einem Unternehmens-Proxy oder VPN verhält, weil mitmproxy solche Umgebungen simulieren kann.

Der Nachteil ist der Einrichtungsaufwand. Sie müssen ein Root-Zertifikat installieren, damit mitmproxy HTTPS-Traffic abfangen kann, und Sie müssen Ihren Browser für die Nutzung des Proxys konfigurieren. Für schnelle Prüfungen ist curl schneller. Für tiefes Debugging ist mitmproxy die Einrichtungszeit wert.

webpagetest: die Produktionsperspektive

WebPageTest ist ein kostenloser Dienst, der Ihre Seite mit echten Browsern an verschiedenen Standorten lädt und Ihnen die vollständige HTTP-Konversation zeigt. Er ist langsamer als curl, zeigt aber, was echte Nutzer erleben, einschließlich CDN-Verhalten, DNS-Auflösung und TLS-Aushandlung.

Die Ansichten "Request Headers" und "Response Headers" zeigen genau, was der Browser gesendet und empfangen hat. Die Ansicht "Waterfall" zeigt das Timing jedes Requests, einschließlich Weiterleitungen. Hier finden Sie Probleme, die nur in bestimmten Regionen oder in bestimmten Netzwerken auftreten.

WebPageTest zeigt außerdem die Weiterleitungskette für das Hauptdokument, und dort liegen viele Weiterleitungsprobleme. Wenn Ihre Website von http:// zu https://, dann von www. zu non-www. und dann von / zu /en/ weiterleitet, zeigt WebPageTest alle drei Schritte und wie lange jeder davon gedauert hat.

Für Tools, die Ihnen helfen, diese HTTP-Grundlagen zu validieren und zu optimieren, bietet Wux Webtools mehrere Utilities, die vollständig in Ihrem Browser laufen, darunter Header-Analyzer und Redirect-Checker, die Ihre Privatsphäre respektieren, indem sie alles clientseitig verarbeiten.

Wenn Header lügen

Die schwierigsten HTTP-Probleme sind jene, bei denen der Server widersprüchliche Header sendet. Ein Cache-Control-Header sagt no-cache, aber ein Expires-Header sagt, dass die Ressource ein Jahr lang gültig ist. Ein Location-Header zeigt auf eine relative URL, aber der Content-Location-Header zeigt woanders hin. Der Browser muss erraten, welchem Header er vertraut, und verschiedene Browser raten unterschiedlich.

Wenn das passiert, müssen Sie die rohen Header in der Reihenfolge sehen, in der der Server sie gesendet hat. curl -v tut das. mitmproxy ebenfalls. Die DevTools des Browsers ordnen Header manchmal für bessere Lesbarkeit neu an, wodurch das Problem verborgen wird.

Ein weiteres häufiges Problem: Header, die von einem CDN oder Load Balancer hinzugefügt werden, nicht von Ihrer Anwendung. Wenn Sie ein Caching-Problem debuggen, müssen Sie wissen, ob der Cache-Control-Header von Ihrer App oder vom CDN kommt. curl zeigt Ihnen das Endergebnis, sagt Ihnen aber nicht, woher jeder Header stammt. Dafür müssen Sie das CDN umgehen (indem Sie den Origin-Server direkt ansprechen) und die Header vergleichen.

Das Problem mit Weiterleitungsschleifen

Weiterleitungsschleifen sind das häufigste HTTP-Problem in Produktion. Sie entstehen, wenn zwei Server sich uneinig sind, wohin eine URL zeigen soll: Das CDN leitet zum Origin weiter, der Origin leitet zurück zum CDN. Oder der Load Balancer leitet HTTP zu HTTPS weiter, aber die App leitet HTTPS zurück zu HTTP, weil sie den X-Forwarded-Proto-Header nicht sieht.

Um das zu debuggen, müssen Sie die vollständige Weiterleitungskette sehen, einschließlich des Location-Headers bei jedem Schritt. curl -L -v tut das, stoppt aber nach 50 Weiterleitungen, um Endlosschleifen zu vermeiden. Wenn Sie dieses Limit erreichen, haben Sie eine Weiterleitungsschleife.

Die Behebung ist meist eine Konfigurationsänderung: der App sagen, dass sie dem X-Forwarded-Proto-Header vertrauen soll, oder dem CDN sagen, dass es Requests, die bereits HTTPS sind, nicht weiterleiten soll. Aber Sie können es nicht beheben, bevor Sie die Schleife sehen, und der Browser zeigt Ihnen nur wenige Weiterleitungen, bevor er aufgibt.

Was Sie zuerst prüfen sollten

Wenn in Produktion etwas bricht, prüfen Sie diese Punkte in dieser Reihenfolge:

1. Statuscode: Ist er der erwartete? Ein 301 ist permanent, ein 302 ist temporär, ein 307 behält die HTTP-Methode bei. Wenn Sie den falschen Code sehen, liegt das Problem in Ihrer Weiterleitungskonfiguration.

1. Location-Header: Zeigt er an die richtige Stelle? Ist es eine absolute URL oder eine relative? Relative URLs werden gegen die aktuelle URL aufgelöst, was unerwartete Ergebnisse erzeugen kann, wenn die Basis-URL nicht die ist, die Sie erwarten.

1. Cache-Header: Cached der Browser die Weiterleitung? Eine 301-Weiterleitung wird standardmäßig gecached, was bedeutet, dass eine falsch konfigurierte Weiterleitung Ihre Website noch Stunden nach der Behebung beschädigen kann. Prüfen Sie die Cache-Control- und Expires-Header, um zu sehen, wie lange der Browser sich die Weiterleitung merkt.

1. CORS-Header: Wenn der Request cross-origin ist, sendet der Server den richtigen Access-Control-Allow-Origin-Header? Wenn nicht, blockiert der Browser den Request, und Sie sehen einen CORS-Fehler in der Konsole. Die Response-Header des Servers sind der einzige Ort, an dem Sie das beheben können — im Browser lässt es sich nicht umgehen.

1. Timing: Wie lange hat der Request gedauert? Wenn er langsam ist, liegt es an Netzwerklatenz oder Serververarbeitung? Die DevTools des Browsers und WebPageTest zeigen beide Timing-Aufschlüsselungen, die Ihnen sagen, wo die Zeit geblieben ist.

Für einen tieferen Blick darauf, wie sich Browser-Verhalten rund um Datenschutz und Header verändert hat, lesen Sie was sich 2026 bei Cookies geändert hat und was Sie dagegen tun können. Der Beitrag behandelt die Header- und Consent-Auswirkungen aktueller Browser-Updates.

Key Takeaways

• curl -L -v zeigt die vollständige Weiterleitungskette und alle Header, ohne Browser-Interpretation
• Der Network-Tab des Browsers zeigt, was der Browser mit der Response gemacht hat, einschließlich Caching- und CORS-Entscheidungen
• mitmproxy zeigt, was der Browser gesendet hat, einschließlich Headern, die der Browser automatisch hinzufügt
• WebPageTest zeigt, was echte Nutzer erleben, einschließlich CDN-Verhalten und regionaler Unterschiede
• Weiterleitungsschleifen und widersprüchliche Header sind die häufigsten Produktionsprobleme, und ohne rohe HTTP-Inspektion sind sie unsichtbar

FAQ

Q: Warum zeigt curl andere Header als der Browser?

A: Weil der Browser Header automatisch hinzufügt (User-Agent, Accept, Cookie) und eigene Regeln für Caching und CORS befolgt. curl sendet nur, was Sie ihm zu senden sagen. Um zu sehen, was der Browser tatsächlich sendet, verwenden Sie mitmproxy oder die DevTools des Browsers.

Q: Wie debugge ich eine Weiterleitung, die nur bei einigen Nutzern auftritt?

A: Prüfen Sie, ob die Weiterleitung von Headern abhängt, die der Nutzer sendet: User-Agent, Accept-Language, Cookie oder IP-Adresse (über X-Forwarded-For). Verwenden Sie curl, um dieselben Header zu senden, die der Nutzer gesendet hat, oder nutzen Sie WebPageTest, um die Seite vom Standort des Nutzers zu laden.

Q: Was ist der Unterschied zwischen 301- und 302-Weiterleitungen?

A: Ein 301 ist permanent und weist den Browser an, die Weiterleitung zu cachen (manchmal dauerhaft). Ein 302 ist temporär und weist den Browser an, sie nicht zu cachen. Wenn Sie nicht sicher sind, was Sie verwenden sollen, nehmen Sie 302 — Sie können es später immer noch auf 301 ändern.

Q: Warum funktioniert meine Weiterleitung in curl, aber nicht im Browser?

A: Wahrscheinlich, weil der Browser eine alte Weiterleitung cached oder weil der Browser die Weiterleitung aufgrund von CORS- oder Mixed-Content-Regeln blockiert. Prüfen Sie die DevTools-Konsole des Browsers auf Fehler und prüfen Sie die Cache-Control-Header, um zu sehen, ob der Browser eine gecachte Response verwendet.

Q: Wie sehe ich die Header, die ein CDN hinzufügt?

A: Verwenden Sie curl, um die CDN-URL aufzurufen, und anschließend erneut curl, um den Origin-Server direkt aufzurufen (unter Umgehung des CDNs). Vergleichen Sie die Header. Diejenigen, die nur in der ersten Response erscheinen, stammen vom CDN.

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

💡 Probieren Sie dies aus: Wenn Sie Weiterleitungsprobleme verfolgen, zeichnet Redirect Checker die gesamte Kette nach und zeigt bei jedem Schritt die Statuscodes und Header an.

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

Quellen

• curl documentation — Offizielle Referenz für curl-Kommandozeilenoptionen und Verhalten
• HTTPie documentation — Leitfaden zu httpie-Syntax und Funktionen
• MDN Web Docs: HTTP redirections — Umfassende Erklärung von HTTP-Weiterleitungsstatuscodes und ihrem Verhalten
• WebPageTest documentation — Wie WebPageTest-Ergebnisse und Header zu interpretieren sind