Inhalt des Artikels

Du sendest eine Anfrage mit der Methode POST, inklusive Body und Autorisierungs-Header – und auf dem Server kommt ein leerer GET ohne einen einzigen benutzerdefinierten Header an. Kommt dir das bekannt vor? Wenn du mit Proxys und automatisierten Anfragen arbeitest, wirst du früher oder später auf dieses Verhalten stoßen. Es ist kein Bug in deinem Code und auch keine Fehlfunktion des Proxeon-Proxys. Es ist eine normale, in der Spezifikation vorgesehene Mechanik von HTTP-Redirects, die man einfach verstehen und kontrollieren können muss.

In diesem Guide schauen wir uns an, warum sich die Methode einer Anfrage bei einem Redirect ändern kann und Header verschwinden. Du lernst den Unterschied zwischen den Codes 301, 302, 307 und 308 kennen, erfährst, wie sich verschiedene HTTP-Clients standardmäßig verhalten, und bekommst praktische Beispiele, wie du automatische Weiterleitungen deaktivierst und sie stattdessen manuell verarbeitest. Alles mit echtem Code, ohne Schnickschnack.

Einleitung: Die Anfrage geht als POST raus, kommt aber als GET an – wer ist schuld?

Stell dir eine typische Aufgabe vor. Du sendest eine POST-Anfrage an einen Login-Endpunkt über einen Proxy. Der Server antwortet mit einem Weiterleitungscode und einer neuen Adresse. Dein HTTP-Client folgt dieser Adresse automatisch. Aber er tut das als GET, ohne den Body der Anfrage und ohne den Authorization-Header. Das Ergebnis: Der Zielserver bekommt nicht das, was du gesendet hast, und die Logik bricht auseinander.

Wer ist schuld? Formal niemand. Dieses Verhalten liegt in der historischen Umsetzung der Codes 301 und 302 begründet. Früher haben Browser und Bibliotheken bei diesen Codes fast immer die Methode auf GET geändert. Das wurde zum De-facto-Standard und hat sich so etabliert. Später wurden die Codes 307 und 308 eingeführt, um Entwicklern die Möglichkeit zu geben, Methode und Body zu behalten. Darauf gehen wir weiter unten genauer ein.

Was du am Ende können wirst

Nach der Lektüre dieses Guides kannst du Redirects in jedem gängigen HTTP-Client souverän steuern. Du kannst vorhersagen, was mit Methode und Body passiert. Du lernst, wie du kritische Header bei Weiterleitungen behältst. Und du kannst komplexe Redirect-Ketten, die über einen Proxy laufen, effektiv debuggen.

Für wen dieser Guide gedacht ist

  • Für Entwickler, die Parser, Integrationen und Automatisierungen über Proxys schreiben.
  • Für QA-Ingenieure, die APIs und Webszenarien testen.
  • Für DevOps, die den Proxy-Verkehr einrichten und verwalten.
  • Für alle, die sich schon einmal gefragt haben, warum aus POST ein GET wird.

Was du bereits wissen solltest

Grundlegendes Verständnis von HTTP: Was sind Methoden, Header, Body und Statuscodes. Du solltest in der Lage sein, Befehle im Terminal auszuführen. Idealerweise hast du erste Erfahrung mit Python oder JavaScript. Falls nicht, keine Sorge – die wichtigsten Begriffe erklären wir in einem eigenen Abschnitt einfach und verständlich.

Wie viel Zeit du einplanen solltest

Für gründliches Lesen und das Nachvollziehen aller Beispiele solltest du etwa 60 Minuten einplanen. Wenn du nur ein spezifisches Problem lösen willst, nutze das Inhaltsverzeichnis und springe direkt zum passenden Abschnitt.

Vorbereitung: Werkzeuge und Zugänge

Bevor du mit den Beispielen arbeitest, bereite deine Umgebung vor. Das dauert nicht lange, aber danach läuft alles reibungslos.

Notwendige Werkzeuge

  1. Installiere curl in Version 7.88 oder neuer. Überprüfe das mit curl --version im Terminal.
  2. Installiere Python in Version 3.10 oder neuer. Überprüfe das mit python --version.
  3. Installiere die Python-Bibliotheken: Führe pip install requests httpx aus.
  4. Installiere Node.js in Version 20 oder neuer, wenn du axios und fetch testen möchtest. Überprüfe das mit node --version.
  5. Installiere axios mit npm install axios in einem Testordner deines Projekts.

Zugang zum Proxy

Für die Praxis benötigst du funktionierende Proxeon-Proxys. Halte die Verbindungsdaten bereit: Serveradresse, Port, Benutzername und Passwort. Bewahre sie an einem sicheren Ort auf. Wir werden sie in die Codebeispiele einsetzen.

Tipp: Speichere die Zugangsdaten für den Proxy niemals direkt im Code. Nutze Umgebungsvariablen. Zum Beispiel im Terminal: export PROXY_URL=http://user:pass@host:port. Im Code liest du dann diesen Wert aus der Umgebung. So verhinderst du, dass Geheimnisse versehentlich ins Repository geraten.

Systemanforderungen

Jeder moderne Computer mit Windows 10 oder neuer, macOS 12 oder neuer oder einem aktuellen Linux-Distribut ist geeignet. Besondere Hardwareanforderungen gibt es nicht: HTTP-Anfragen belasten das System kaum.

⚠️ Achtung: Wenn du auf einem Produktionsserver testest, erstelle zuerst einen separaten Test-Code-Zweig oder ein separates Testskript. Experimentiere nicht direkt in der Produktion mit der Redirect-Logik – eine Änderung des Verhaltens kann die Autorisierung brechen und dazu führen, dass Anfragen an die falsche Stelle gehen.

✅ Überprüfung: An diesem Punkt sollten die Versionsabfragen für curl, Python und Node.js erfolgreich funktionieren und die Proxeon-Proxydaten in einer Umgebungsvariable gespeichert sein.

Grundbegriffe einfach erklärt

Damit wir uns gut verstehen, klären wir die wichtigsten Begriffe. Auch wenn du sie kennst, schadet eine Auffrischung nicht.

Was ist ein Redirect?

Ein Redirect, also eine Weiterleitung, ist eine Antwort des Servers, die dem Client sagt: Die gesuchte Ressource gibt es hier nicht, schau an einer anderen Adresse vorbei. Der Server sendet einen Statuscode aus der 3xx-Familie und den Header Location mit der neuen Adresse. Der Client liest diesen Header und sendet eine neue Anfrage an die Zieladresse.

Was sind Methode und Body einer Anfrage?

Die Methode ist die Art der Aktion. GET fordert Daten an, POST sendet Daten an den Server, PUT aktualisiert, DELETE löscht. Der Body ist die Nutzlast, die du mit POST oder PUT sendest. Zum Beispiel ein JSON mit Benutzername und Passwort bei der Anmeldung.

Was sind Header?

Header sind Metadaten einer Anfrage. Sie übertragen zusätzliche Informationen: Datentyp (Content-Type), Autorisierung (Authorization), User-Agent oder eigene Service-Felder. Bei einem Redirect kann ein Teil der Header erhalten bleiben, ein anderer Teil kann verloren gehen. Genau das bringt oft die Logik durcheinander.

Was bedeutet automatische Weiterleitung?

Automatische Weiterleitung bedeutet: Dein HTTP-Client folgt der Adresse aus dem Location-Header von selbst, ohne dass du eingreifen musst. Die meisten Clients machen das standardmäßig. Praktisch, aber riskant: Du verlierst die Kontrolle darüber, was mit Methode, Body und Headern zwischen den Schritten passiert.

Welche Rolle spielt der Proxy?

Der Proxeon-Proxy sitzt zwischen deinem Client und dem Zielserver. Er leitet deine Anfrage weiter und gibt die Antwort zurück. Bei einem Redirect leitet der Proxy einfach den Statuscode und den Location-Header weiter. Über den Sprung entscheidet dein Client. Wichtiger Punkt: Wenn du einen Proxy-Pool mit Rotation nutzt, können verschiedene Schritte der Redirect-Kette über verschiedene IP-Adressen laufen. Dazu kommen wir später noch einmal.

Tipp: Merke dir diese einfache Regel: Ein Proxy ändert die Methode einer Anfrage bei einem Redirect nicht. Die Methode ändert dein HTTP-Client gemäß den Regeln der Statuscode-Behandlung. Suche die Ursache also in den Einstellungen deines Clients, nicht im Proxy.

Schritt 1: Die vier Codes verstehen – 301 und 302 gegen 307 und 308

Ziel dieses Abschnitts: Du lernst, sicher zu erkennen, was mit Methode und Body bei jedem der vier Weiterleitungscodes passiert.

Das ist das Fundament dieses Guides. Wenn du den Unterschied zwischen diesen Codes verinnerlichst, ist die halbe Miete schon drin.

Code 301 – Permanente Weiterleitung

Bedeutet, dass die Ressource dauerhaft umgezogen ist. Historisch gesehen ändern Clients bei einem 301 die Methode von POST auf GET und verwerfen den Body. Formal verlangt die Spezifikation das nicht, aber so hat es sich in der Praxis etabliert, und fast alle Clients machen es aus Gründen der Abwärtskompatibilität.

Code 302 – Temporäre Weiterleitung

Bedeutet, dass die Ressource vorübergehend unter einer anderen Adresse erreichbar ist. Das Verhalten ähnelt dem 301: In der Praxis wird aus POST ein GET, der Body geht verloren. Genau dieser Code 302 ist meistens schuld an der Situation aus der Einleitung.

Code 307 – Temporäre Weiterleitung mit Methodenerhalt

Dieser Code wurde speziell eingeführt, um das Problem des Methodenwechsels zu lösen. Bei einem 307 muss der Client die ursprüngliche Methode und den Body beibehalten. Hast du POST gesendet, kommt POST an. Hast du einen Body gesendet, wird er weitergeleitet. Das ist das temporäre Gegenstück zu 302, aber ohne die Überraschung beim Methodenwechsel.

Code 308 – Permanente Weiterleitung mit Methodenerhalt

Das permanente Gegenstück zu 301, aber mit Beibehaltung von Methode und Body. Hast du POST gesendet, kommt POST an. Das ist der vorhersehbarste Code für die Weiterleitung von POST-Anfragen.

Übersichtstabelle zum Verhalten

Hier ist eine textliche Beschreibung der Tabelle, damit du das Bild im Kopf hast.

  • 301: permanent. Die Methode POST wird in der Praxis zu GET geändert. Der Body wird verworfen. GET bleibt GET.
  • 302: temporär. Die Methode POST wird in der Praxis zu GET geändert. Der Body wird verworfen. GET bleibt GET.
  • 307: temporär. Die Methode bleibt vollständig erhalten. Der Body bleibt erhalten. POST bleibt POST.
  • 308: permanent. Die Methode bleibt vollständig erhalten. Der Body bleibt erhalten. POST bleibt POST.

⚠️ Achtung: Verlass dich nicht darauf, dass alle Server die Spezifikation strikt einhalten. Manche alten Systeme senden 302, obwohl logisch ein 307 nötig wäre, und erwarten trotzdem, dass die Methode erhalten bleibt. Überprüfe immer das tatsächliche Verhalten, nicht nur den Code. Teste an einem echten Endpunkt.

Tipp: Wenn du deinen eigenen Server entwickelst und möchtest, dass POST-Anfragen nach einem Redirect POST bleiben, verwende die Codes 307 oder 308. Das erspart deinen Clients unangenehme Überraschungen und unnötiges Debugging.

✅ Überprüfung: Du kannst anhand des Statuscodes sofort sagen, ob Methode und Body erhalten bleiben. Bei 307 und 308: ja. Bei 301 und 302: in der Praxis nein.

Schritt 2: Was beim Sprung verloren geht – Authorization, Custom-Header, Cookies

Ziel dieses Abschnitts: Du verstehst, welche Daten bei einem Redirect verschwinden und warum, um ihren Erhalt rechtzeitig einzuplanen.

Der Methodenwechsel ist nicht das einzige Problem. Selbst bei den Codes 307 und 308, bei denen die Methode erhalten bleibt, können Header verloren gehen. Wir schauen uns die drei wichtigsten Verluste an.

Verlust des Authorization-Headers bei Domainwechsel

Das ist das häufigste und heimtückischste Problem. Aus Sicherheitsgründen entfernen die meisten HTTP-Clients den Authorization-Header bei einem Redirect auf eine andere Domain. Die Logik dahinter: Wenn du dich auf Seite A anmeldest, soll dein geheimes Token nicht automatisch an Seite B gehen, auf die du weitergeleitet wirst. Sonst könnte ein Angreifer einen Redirect einrichten und deine Zugangsdaten abgreifen.

Die Folge: Du sendest eine Anfrage mit korrektem Token, der Client folgt dem Redirect auf eine andere Domain, aber ohne Authorization. Der Zielserver antwortet, dass du nicht angemeldet bist. Logisch, aber nicht unbedingt offensichtlich.

Tipp: Wenn du die Autorisierung wirklich auf eine andere Domain übertragen musst, mach das bewusst und manuell. Deaktiviere die automatische Weiterleitung, prüfe, wohin genau der Location-Header führt, stelle sicher, dass es sich um eine vertrauenswürdige Adresse handelt, und füge den Authorization-Header erst dann manuell in die neue Anfrage ein.

Verlust von Custom-Headern

Deine eigenen Header – zum Beispiel Service-Felder wie X-Request-Id oder X-Client-Version – verhalten sich bei automatischer Weiterleitung je nach Client unterschiedlich. Manche Bibliotheken übernehmen sie, andere verwerfen sie. Darauf solltest du dich nicht verlassen. Ist ein Header für die Logik kritisch, kontrolliere seine Übertragung manuell.

Verlust von Cookies mit Flags

Cookies haben Flags, die ihre Übertragung einschränken. Das Flag Secure erlaubt die Übertragung nur über eine verschlüsselte Verbindung. Das Flag Domain begrenzt die Domains, an die das Cookie gesendet wird. Das Flag SameSite regelt die Übertragung bei Seitenwechseln. Wenn der Redirect dich auf eine Domain oder ein Protokoll führt, das nicht zu den Flags des Cookies passt, wird das Cookie schlicht nicht gesendet.

Zum Beispiel: Ein Cookie mit Secure-Flag wird nicht gesendet, wenn der Redirect plötzlich auf eine unverschlüsselte Adresse führt. Ein Cookie mit Domain-Beschränkung wird nicht an eine fremde Domain gesendet. Das ist aus Sicherheitssicht korrekt, muss aber berücksichtigt werden.

⚠️ Achtung: Versuche niemals, Sicherheitsflags von fremden Cookies zu entfernen oder Authorization an nicht vertrauenswürdige Domains zu senden, nur um es bequemer zu haben. Diese Mechanismen schützen deine Zugangsdaten. Umgehe sie nur in einer Infrastruktur, die du vollständig kontrollierst, und mit vollem Verständnis der Konsequenzen.

✅ Überprüfung: Du kennst die drei Klassen von Verlusten bei Redirects: Authorization-Header bei Domainwechsel, Custom-Header und Cookies mit einschränkenden Flags. Du weißt, dass du jeden von ihnen nur durch bewusstes manuelles Vorgehen wiederherstellen kannst.

Schritt 3: Standardverhalten verschiedener Clients

Ziel dieses Abschnitts: Du erfährst, wie sich jeder gängige HTTP-Client standardmäßig verhält, um nicht über Abweichungen zu stolpern.

Die größte Falle: Alle Clients verhalten sich standardmäßig unterschiedlich. Wir schauen uns die fünf häufigsten an.

curl

Standardmäßig folgt curl Redirects überhaupt nicht. Er zeigt dir nur die Antwort mit dem 3xx-Code und dem Location-Header. Um die automatische Weiterleitung zu aktivieren, musst du explizit das Flag -L hinzufügen. Das macht curl sehr vorhersehbar: Du weißt immer, dass ohne Flag keine versteckten Sprünge passieren.

Beispiel für eine Anfrage ohne Weiterleitung:

curl -i -x $PROXY_URL https://example.com/redirect

Das Flag -i zeigt die Antwort-Header, das Flag -x setzt den Proxy. Du siehst den Code und den Location-Header, aber es findet kein Sprung statt.

requests (Python)

Die Bibliothek requests folgt Redirects standardmäßig automatisch. Dabei ändert sie bei den Codes 301, 302 und 303 die Methode von POST auf GET. Bei 307 und 308 bleibt die Methode erhalten. Du kannst die automatische Weiterleitung mit dem Parameter allow_redirects=False deaktivieren.

httpx (Python)

Interessanterweise folgt httpx standardmäßig KEINEN Redirects, anders als requests. Das ist eine bewusste Entscheidung, damit der Entwickler explizit eine Wahl trifft. Um Weiterleitungen zu aktivieren, übergibst du follow_redirects=True. Dieses Verhalten ähnelt eher der Philosophie von curl.

axios (JavaScript, Node.js)

In Node.js folgt axios standardmäßig automatisch Redirects. Du kannst das mit dem Parameter maxRedirects einschränken oder deaktivieren. Setzt du maxRedirects: 0, ist die automatische Weiterleitung aus, und axios liefert je nach Konfiguration einen Fehler oder die Antwort mit dem Redirect-Code.

fetch (Browser und Node.js)

Der Standard-fetch folgt Redirects standardmäßig automatisch. Du steuerst das mit dem Parameter redirect, der drei Werte annimmt: follow – folgen, manual – nicht folgen und eine undurchsichtige Antwort zurückgeben, error – Redirect als Fehler behandeln.

Tipp: Merke dir zwei Gruppen: curl und httpx folgen standardmäßig NICHT – du entscheidest selbst. requests, axios und fetch folgen standardmäßig. Wenn du Code zwischen diesen Werkzeugen überträgst, prüfe unbedingt die Redirect-Einstellung, sonst bricht die Logik still und leise.

⚠️ Achtung: Unterschiedliches Standardverhalten ist die häufigste Ursache für rätselhafte Bugs beim Umschreiben von Skripten von einem Client auf einen anderen. Ein Skript mit requests lief, du hast es auf httpx übertragen, und plötzlich kommt statt der finalen Antwort ein 302-Code. Der Grund: httpx folgt nicht automatisch. Gib die Redirect-Einstellung immer explizit an.

✅ Überprüfung: Du kannst aus dem Gedächtnis das Standardverhalten für curl, requests, httpx, axios und fetch nennen und kennst den Parameter zur Steuerung von Redirects in jedem dieser Clients.

Schritt 4: Manuelle Steuerung von Redirects – wann sie der einzige richtige Weg ist

Ziel dieses Abschnitts: Du lernst, die automatische Weiterleitung zu deaktivieren und jeden Schritt eines Redirects selbst zu verarbeiten, mit voller Kontrolle über Methode, Body und Header.

Automatische Weiterleitung ist bequem, aber in drei Situationen schädlich, dann ist manuelle Steuerung gefragt:

  1. Wenn du den Authorization-Header bei einem Domainwechsel erhalten musst.
  2. Wenn du genau wissen willst, über welchen Proxy und welche IP jeder Schritt der Kette gelaufen ist.
  3. Wenn der Server mit 302 antwortet, obwohl logisch ein 307 nötig wäre, und du die POST-Methode manuell beibehalten willst.

Automatische Weiterleitung deaktivieren: curl

Bei curl ist das einfach: Füge das Flag -L nicht hinzu. Der Client zeigt dir die erste Antwort. Danach liest du selbst den Location-Header und sendest die nächste Anfrage:

curl -i -x $PROXY_URL "https://example.com/login"

Lies den Location-Header aus der Ausgabe und sende dann die nächste Anfrage manuell, mit den benötigten Headern:

curl -i -x $PROXY_URL -H "Authorization: Bearer TOKEN" "https://example.com/next"

Automatische Weiterleitung deaktivieren: requests

Hier verwendest du den Parameter allow_redirects=False und verarbeitest die Kette in einer Schleife:

import os, requests; proxies = {"http": os.environ["PROXY_URL"], "https": os.environ["PROXY_URL"]}; url = "https://example.com/login"; method = "POST"; body = {"user": "a", "pass": "b"}; headers = {"Authorization": "Bearer TOKEN"}; 
for _ in range(5): 
r = requests.request(method, url, json=body, headers=headers, proxies=proxies, allow_redirects=False); 
if r.status_code not in (301, 302, 303, 307, 308): break; 
loc = r.headers["Location"]; 
if r.status_code in (301, 302, 303): method = "GET"; body = None; 
url = loc

Beachte: In dieser Schleife entscheidest du selbst, ob du die Methode änderst, und du entscheidest selbst, ob du den Authorization-Header behältst. Genau das ist die Stärke der manuellen Verarbeitung.

Automatische Weiterleitung deaktivieren: httpx

Da httpx standardmäßig nicht folgt, musst du nur follow_redirects nicht aktivieren. Die Logik der Schleife ist analog zu requests: Code prüfen, Location lesen, Entscheidungen über Methode und Header treffen, nächste Anfrage senden.

Automatische Weiterleitung deaktivieren: axios

Bei axios setzt du maxRedirects: 0. Bei einem Redirect-Code wirft axios in Node.js einen Fehler, in dessen response-Objekt du Status und Header findest. Aus dem Location-Header nimmst du die neue Adresse und erstellst die nächste Anfrage selbst.

Automatische Weiterleitung deaktivieren: fetch

Bei fetch übergibst du redirect: "manual". Dann folgt fetch nicht und gibt eine Antwort zurück, aus der du die nötigen Daten für den nächsten Schritt liest.

Tipp: Bei manueller Verarbeitung protokolliere bei jedem Schritt vier Dinge: ursprüngliche URL, erhaltener Code, Wert von Location und Methode der nächsten Anfrage. Das macht aus einer undurchsichtigen Kette eine klare Sequenz, die sich leicht lesen und debuggen lässt.

⚠️ Achtung: Bei manueller Verarbeitung bist du selbst für die Sicherheit verantwortlich. Bevor du den Authorization-Header an eine neue Adresse aus Location weitergibst, prüfe, ob die Domain zu deiner vertrauenswürdigen Infrastruktur gehört. Blind Geheimnisse an jede Adresse aus Location zu kopieren, ist eine ernste Sicherheitslücke.

✅ Überprüfung: Du hast eine funktionierende manuelle Verarbeitung in mindestens einem Client, die eine Redirect-Kette korrekt durchläuft und wichtige Header nur für vertrauenswürdige Domains beibehält.

Schritt 5: Tiefenbegrenzung und Schutz vor Schleifen

Ziel dieses Abschnitts: Du schützt deinen Code vor Endlos-Redirects und verhinderst, dass eine Schleife deine Anwendung aufhängt.

Manchmal sind Server falsch konfiguriert, und Adresse A führt zu Adresse B, B führt zurück zu A. Wenn dein Client ohne Begrenzung folgt, läuft er in eine Endlosschleife. Bei manueller Verarbeitung droht dieselbe Gefahr: Eine Schleife ohne Zähler läuft ewig.

Anzahl der Weiterleitungen begrenzen

Setze immer eine maximale Tiefe. Ein vernünftiger Wert liegt zwischen fünf und zehn Sprüngen. Mehr kommt in normalen Szenarien kaum vor.

  • Bei curl: Flag --max-redirs 10 zusammen mit -L.
  • Bei requests: Die Bibliothek begrenzt die Tiefe selbst, aber in deiner manuellen Schleife verwende range(10).
  • Bei httpx: Parameter max_redirects bei aktivierten Weiterleitungen.
  • Bei axios: Parameter maxRedirects mit der gewünschten Zahl.
  • Bei fetch: Zähle die Sprünge bei manueller Verarbeitung selbst in der Schleife.

Schutz vor Schleifen durch Verfolgen besuchter Adressen

Ein zuverlässiger Trick: Speichere alle bereits besuchten URLs in einer Menge. Prüfe vor jedem Sprung, ob du diese Adresse schon einmal besucht hast. Wenn ja, brich die Kette mit einem Fehler ab. Das fängt auch komplexe Schleifen mit mehreren Adressen zuverlässig ab.

seen = set(); 
while url and url not in seen: 
seen.add(url); 
r = requests.request(method, url, headers=headers, proxies=proxies, allow_redirects=False); 
if r.status_code not in (301,302,303,307,308): break; 
url = r.headers["Location"]

Tipp: Kombiniere beide Techniken: sowohl das harte Limit für die Anzahl als auch die Menge der besuchten Adressen. Das Limit schützt vor langen Ketten, die Menge vor Schleifen. Zusammen ergibt das einen vollständigen Schutz.

✅ Überprüfung: Dein Code endet garantiert bei jeder Redirect-Kette, auch wenn der Server eine Endlosschleife erzeugt. Er erreicht entweder die finale Antwort oder bricht mit einer verständlichen Fehlermeldung über Überschreitung der Tiefe oder Erkennung einer Schleife ab.

Schritt 6: Redirects und IP-Wechsel – warum die Kette über einen anderen Proxy läuft

Ziel dieses Abschnitts: Du verstehst, wie Proxy-Rotation mit Redirects zusammenspielt, und verhinderst, dass Schritte der Kette über verschiedene IP-Adressen laufen.

Das ist ein subtiler und oft unterschätzter Punkt. Wenn du einen Proxeon-Proxy-Pool mit IP-Rotation nutzt, ist es wichtig zu verstehen, auf welcher Ebene der Adresswechsel passiert.

Warum Schritte über verschiedene IPs laufen können

Stell dir vor, deine Rotation ist so eingestellt, dass die IP bei jeder neuen Verbindung wechselt. Bei automatischer Weiterleitung kann der Client für den nächsten Schritt einen neuen Verbindungsaufbau starten. Wenn die Rotation zwischen den Schritten eine neue IP ausgibt, geht die erste Anfrage von einer Adresse aus, der Sprung über Location aber von einer anderen. Für viele Server sieht das verdächtig aus: Die Anmeldung hat ein Client begonnen, fortgesetzt hat sie scheinbar ein anderer.

Was dabei kaputtgeht

  • Sessions, die an eine IP gebunden sind, brechen ab. Der Server sieht, dass die Fortsetzung von einer anderen Adresse kommt, und setzt die Session zurück.
  • Cookies, die für eine bestimmte Session ausgestellt wurden, werden nicht mehr akzeptiert.
  • Logik, die innerhalb einer Kette eine einzige Quelle erwartet, wird instabil.

Wie du eine Session auf einer IP hältst

Der Schlüssel liegt darin, die IP für die gesamte Dauer der Kette zu fixieren. Proxeon unterstützt einen Stick-Session-Modus, bei dem dieselbe IP für einen bestimmten Zeitraum gehalten wird. Nutze diesen Modus für Szenarien, in denen die Integrität der Redirect-Kette wichtig ist.

  1. Wähle in den Verbindungseinstellungen den Stick-Session-Modus anstelle der Rotation bei jeder Anfrage.
  2. Lege die Haltedauer der IP so fest, dass sie für die gesamte Kette ausreicht.
  3. Im Code verwende für alle Schritte eine einzige Client-Session: Bei requests ist das ein Objekt requests.Session(), bei httpx ein httpx.Client().
  4. Stelle sicher, dass du die Verbindung wiederverwendest und nicht bei jedem Schritt eine neue erstellst.

Tipp: Für die Integrität einer Redirect-Kette solltest du immer ein einziges Client-Session-Objekt erstellen und alle Schritte darüber laufen lassen. Das wiederverwendet die Verbindung, behält Cookies zwischen den Anfragen und verringert die Wahrscheinlichkeit, mitten in der Kette auf eine andere IP zu wechseln.

⚠️ Achtung: Verwechsle Stick-Session nicht mit unbegrenztem Halten einer IP. Lege eine vernünftige Haltedauer fest, die genau für die Dauer der Operation reicht. Denke daran: Die Arbeit mit Proxys muss immer im Rahmen der Gesetze und der Regeln der Ressourcen erfolgen, mit denen du interagierst.

✅ Überprüfung: Die gesamte Redirect-Kette läuft über dieselbe IP, die Session bricht nicht ab, Cookies werden bei jedem Schritt akzeptiert. Das kannst du überprüfen, indem du bei jedem Schritt einen Dienst abfragst, der deine aktuelle IP anzeigt, und sicherstellst, dass sie sich nicht ändert.

Schritt 7: Debugging – die gesamte Kette und Codes Schritt für Schritt sehen

Ziel dieses Abschnitts: Du bekommst ein vollständiges Bild der Redirect-Kette, um genau zu wissen, wo Methode oder Header verloren gehen.

Blindes Debugging ist das Schlimmste, was du bei Redirects tun kannst. Hier sind Werkzeuge, die die Kette sichtbar machen.

Vollständiges Log in curl

Das Flag -v aktiviert den ausführlichen Modus. Du siehst jede Anfrage, jede Antwort, alle Header und alle Sprünge. Mit -L zeigt curl die gesamte Kette auf einmal.

curl -v -L --max-redirs 10 -x $PROXY_URL "https://example.com/login"

Lies die Ausgabe von oben nach unten. Zeilen, die mit dem Zeichen „größer als“ beginnen, sind das, was zum Server geht. Zeilen mit dem Zeichen „kleiner als“ sind das, was als Antwort zurückkommt. So siehst du, bei welchem Schritt ein Header verloren gegangen ist.

Redirect-Verlauf in requests

Wenn du die automatische Weiterleitung aktiviert lässt, hat die finale Antwort das Attribut history – eine Liste aller Zwischenantworten. Gehe sie durch und gib Code und URL jedes Schritts aus:

r = requests.post(url, json=body, proxies=proxies); 
for h in r.history: print(h.status_code, h.url); 
print("final", r.status_code, r.url)

Redirect-Verlauf in httpx

Bei aktiviertem follow_redirects hat die httpx-Antwort ebenfalls eine Eigenschaft history. Die Logik ist dieselbe: Durchlaufen und Code sowie URL jeder Zwischenantwort ausgeben.

Debugging in axios und fetch

Bei axios protokolliere bei manueller Verarbeitung jede Antwort selbst in der Schleife. Bei fetch mit dem Modus manual gibst du bei jedem Schritt Status und Location-Header aus. Eine eingebaute Verlaufsliste gibt es hier nicht, daher ist manuelles Logging dein wichtigstes Werkzeug.

Tipp: Führe ein einheitliches Log-Format für einen Schritt ein: Schrittnummer, Methode, URL, Antwortcode, Location, Vorhandensein von Authorization. Ein solches tabellarisches Log zeigt sofort, wo genau die Methode zu GET wurde oder das Token verschwunden ist. Das spart Stunden beim Debuggen.

Worauf du in den Logs achten solltest

  • Den Moment, in dem die Methode in der ausgehenden Anfrage zu GET wird. Das ist ein Zeichen für den Code 301, 302 oder 303.
  • Den Schritt, an dem der Authorization-Header verschwindet. Meistens ist das ein Domainwechsel.
  • Den Wechsel von Domain oder Protokoll im Location-Wert – genau dort gehen Cookies mit Flags verloren.
  • Sich wiederholende Adressen – ein Zeichen für eine Schleife.

✅ Überprüfung: Du kannst die vollständige Kette der Weiterleitungen mit Codes und URLs für jeden Client ausgeben und genau den Schritt benennen, an dem sich die Methode geändert oder ein Header verloren wurde.

Ergebnisprüfung: Checkliste

Gehe diese Liste durch. Wenn alle Punkte erfüllt sind, hast du Redirects vollständig unter Kontrolle.

  1. Du kennst das Verhalten von Methode und Body für die Codes 301, 302, 307 und 308.
  2. Du verstehst, warum der Authorization-Header bei einem Domainwechsel verschwindet.
  3. Du kennst das Standardverhalten von curl, requests, httpx, axios und fetch.
  4. Du hast ein funktionierendes Beispiel für das Deaktivieren der automatischen Weiterleitung.
  5. Du hast eine funktionierende Schleife zur manuellen Verarbeitung einer Kette.
  6. Dein Code ist durch Limit und Menge besuchter Adressen vor Endlosschleifen geschützt.
  7. Du nutzt bei Bedarf die Stick-Session von Proxeon für die Integrität der Kette.
  8. Du kannst die vollständige Kette der Weiterleitungen in den Logs ausgeben.

So testest du

Nimm einen Test-Endpunkt, der auf eine POST-Anfrage mit Code 302 antwortet. Schicke ihn durch die automatische Weiterleitung und stelle fest, dass die Methode zu GET wird. Danach schicke ihn durch die manuelle Verarbeitung mit Methodenerhalt und stelle fest, dass POST am Ziel ankommt. Der Unterschied im Verhalten ist der Beweis, dass du alles unter Kontrolle hast.

✅ Überprüfung: Beide Szenarien – automatische Weiterleitung und manuelle Verarbeitung – liefern ein vorhersehbares, erklärbares Ergebnis statt eines Zufalls.

Typische Fehler und Lösungen

Wir schauen uns die häufigsten Stolperfallen und ihre Lösungen an.

Fehler 1: POST wird zu GET

Ursache: Der Server hat den Code 301 oder 302 zurückgegeben, und der Client hat nach historischer Regel die Methode geändert. Lösung: Wenn du den Server kontrollierst, sende 307 oder 308. Wenn nicht, deaktiviere die automatische Weiterleitung und wiederhole die Anfrage manuell mit der richtigen Methode.

Fehler 2: Authorization-Header verschwindet

Ursache: Der Redirect führt zu einer anderen Domain, und der Client entfernt das Geheimnis aus Sicherheitsgründen. Lösung: Überprüfe die Domain aus Location, und wenn sie vertrauenswürdig ist, füge den Authorization-Header der nächsten Anfrage manuell hinzu.

Fehler 3: Skript lief mit requests, bricht aber mit httpx

Ursache: httpx folgt standardmäßig keinen Redirects, requests schon. Lösung: Setze bei httpx explizit follow_redirects=True oder stelle überall auf manuelle Verarbeitung um, damit das Verhalten übereinstimmt.

Fehler 4: Anwendung hängt in einer Kette

Ursache: Endlosschleife von Redirects ohne Begrenzung der Tiefe. Lösung: Füge ein Limit für die Anzahl der Sprünge und eine Menge besuchter Adressen hinzu, wie in Schritt 5 gezeigt.

Fehler 5: Session bricht mitten in der Kette ab

Ursache: Schritte der Kette liefen über verschiedene IPs wegen Proxy-Rotation. Lösung: Aktiviere die Stick-Session von Proxeon und verwende für alle Schritte ein einziges Client-Session-Objekt.

Fehler 6: Cookie wird nach dem Redirect nicht gesendet

Ursache: Die Flags Secure, Domain oder SameSite passen nicht zur neuen Adresse. Lösung: Prüfe Protokoll und Domain in Location und stelle sicher, dass sie zu den Cookie-Flags passen. Entferne Sicherheitsflags nicht aus Bequemlichkeit.

Fehler 7: curl folgt dem Redirect nicht

Ursache: Das Flag -L wurde vergessen. Lösung: Füge -L für die automatische Weiterleitung hinzu oder lasse es für manuelle Kontrolle weg – je nach Aufgabe.

Weitere Möglichkeiten und Optimierung

Wenn die Grundlagen sitzen, lohnt es sich, Ordnung zu schaffen und die Zuverlässigkeit zu erhöhen.

Ein einheitliches Modul für Redirect-Verarbeitung

Verteile die Logik nicht über den Code. Fasse die Verarbeitung der Kette in einer Funktion zusammen, mit Parametern: Liste vertrauenswürdiger Domains, maximale Tiefe, Satz von Codes für Methodenerhalt. So ist das Verhalten im gesamten Projekt einheitlich.

Weiße Liste für Domains mit Authorization

Führe eine explizite Liste von Domains ein, an die der Authorization-Header bei einem Redirect gesendet werden darf. Alles außerhalb der Liste erhält niemals das Geheimnis. Das macht die Sicherheit steuerbar statt zufällig.

Metriken für Ketten

Sammle Statistiken: durchschnittliche Kettenlänge, Anteil der Anfragen mit Redirects, Codes, die am häufigsten vorkommen. Ein anormaler Anstieg der Kettenlänge ist ein frühes Warnsignal für Probleme auf der Zielserverseite.

Tipp: Richte eine Warnung ein, wenn eine Kette mehr als drei Sprünge umfasst. In den meisten korrekten Szenarien reichen ein bis zwei. Ein plötzlicher Anstieg ist ein Grund, zu prüfen, was sich auf der Zielressource geändert hat.

FAQ: Häufige Fragen zur Redirect-Verarbeitung

Warum wird POST zu GET, obwohl ich nichts geändert habe?

Weil der Server den Code 301 oder 302 zurückgegeben hat und dein Client nach historischer Regel die Methode auf GET geändert hat. Um das zu vermeiden, brauchst du Code 307 oder 308 oder eine manuelle Verarbeitung.

Ändert ein Proxy die Methode bei einem Redirect?

Nein. Proxeon und jeder korrekte Proxy leiten nur Status und Location weiter. Über die Änderung der Methode entscheidet dein HTTP-Client. Die Ursache liegt also in den Einstellungen des Clients.

Wie behalte ich den Authorization-Header bei einem Domainwechsel?

Nur manuell. Deaktiviere die automatische Weiterleitung, prüfe die Domain aus Location, stelle sicher, dass sie vertrauenswürdig ist, und füge den Authorization-Header der nächsten Anfrage selbst hinzu.

Welchen Code sollte ich für die Weiterleitung von POST verwenden?

Code 307 für temporäre und 308 für permanente Weiterleitungen. Beide erhalten Methode und Body der Anfrage und ersparen Clients Überraschungen.

Warum verhält sich dasselbe Skript bei requests und httpx unterschiedlich?

Weil requests standardmäßig Redirects folgt, httpx aber nicht. Gib die Weiterleitungseinstellung immer explizit an, damit das Verhalten übereinstimmt.

Wie schütze ich mich vor Endlosschleifen bei Redirects?

Setze ein hartes Limit für die Anzahl der Sprünge und führe eine Menge bereits besuchter Adressen. Wenn eine Adresse wiederholt wird oder das Limit überschritten ist, brich die Kette mit einem Fehler ab.

Warum bricht die Session mitten in der Redirect-Kette ab?

Wahrscheinlich liefen Schritte über verschiedene IPs wegen der Rotation. Aktiviere die Stick-Session von Proxeon und verwende für alle Schritte ein einziges Client-Session-Objekt.

Warum wird ein Cookie nach dem Sprung nicht gesendet?

Wegen fehlender Übereinstimmung der Flags Secure, Domain oder SameSite mit der neuen Adresse. Prüfe Protokoll und Domain in Location. Sicherheitsflags darfst du nicht entfernen.

Wie sehe ich die gesamte Kette der Weiterleitungen?

Bei curl verwende -v -L. Bei requests und httpx schau dir das Attribut history der finalen Antwort an. Bei axios und fetch protokolliere jeden Schritt manuell.

Kann ich Redirects vollständig deaktivieren?

Ja. Bei curl füge -L nicht hinzu, bei requests setze allow_redirects=False, bei httpx aktiviere follow_redirects nicht, bei axios setze maxRedirects: 0, bei fetch gib redirect: "manual" an.

Fazit

Jetzt hast du ein vollständiges und praktisches Bild davon, wie du mit Redirects über Proxys arbeitest. Du hast verstanden, warum aus POST ein GET wird, und weißt, dass nicht der Proxy schuld ist, sondern die historischen Regeln zur Behandlung der Codes 301 und 302. Du kennst den Unterschied zwischen 301, 302, 307 und 308 und kannst den richtigen Code wählen. Du weißt, welche Daten beim Sprung verloren gehen: Authorization bei Domainwechsel, Custom-Header und Cookies mit Sicherheitsflags.

Du hast das Standardverhalten von curl, requests, httpx, axios und fetch kennengelernt und wirst bei der Code-Übertragung nicht mehr überrascht. Du hast funktionierende Beispiele zum Deaktivieren der automatischen Weiterleitung und zur manuellen Verarbeitung der Kette mit voller Kontrolle über Methode und Header. Du kannst dich vor Schleifen schützen und eine Session auf einer IP halten – mit der Stick-Session von Proxeon. Und schließlich kannst du Ketten debuggen und jeden Schritt sehen.

Was du als Nächstes tun solltest: Baue ein einheitliches Modul zur Redirect-Verarbeitung mit einer weißen Liste von Domains für Authorization und konfigurierbarer Tiefe. Füge Metriken für die Kettenlänge hinzu. Teste deine realen Szenarien mit manueller Verarbeitung und vergleiche sie mit der automatischen Weiterleitung – so findest du versteckte Stellen, an denen Daten verloren gehen.

Mach weiter mit dem Netzwerk-Stack: Beschäftige dich tiefer mit dem Lebenszyklus von Cookies, den Feinheiten von TLS-Verbindungen und der Wiederverwendung von Verbindungen. Jede dieser Fähigkeiten macht deine Arbeit mit dem Proxeon-Proxy noch zuverlässiger und vorhersehbarer. Viel Erfolg bei der Arbeit und saubere, transparente Anfrage-Ketten!