Inhalt des Artikels

Proxy-Fehler wirken erschreckend durch ihre Plötzlichkeit. Gerade hat die Anfrage noch funktioniert, und jetzt sehen Sie ein rätselhaftes 407, 502 oder die Meldung Tunnelverbindung fehlgeschlagen. Die gute Nachricht: Hinter jedem dieser Fehler steckt eine verständliche und logische Ursache. Diese Anleitung bringt Ihnen bei, diese Meldungen wie ein offenes Buch zu lesen.

Einleitung: Warum diese Anleitung und was Sie bekommen

Die Arbeit mit Proxys ähnelt einem Telefongespräch über einen Übersetzer. Ihr Client spricht mit dem Proxy, der Proxy spricht mit der Zielwebsite, und die Antwort läuft denselben Weg zurück. Wenn etwas kaputtgeht, ist es wichtig zu verstehen, an welcher Stelle genau das Problem aufgetreten ist. Genau darum geht es in dieser Anleitung.

Was Sie am Ende bekommen:

  • Die Fähigkeit, sofort einen Proxy-Fehler von einem Fehler der Zielwebsite zu unterscheiden.
  • Verständnis dafür, was die Codes 407, 502, 504, 403 und die Meldung Tunnelverbindung fehlgeschlagen bedeuten.
  • Die Fertigkeit, die Ausgabe des Befehls curl -v Zeile für Zeile mit klarer Trennung der Abschnitte Client-Proxy-Server zu lesen.
  • Fertige Diagnosebeispiele mit curl, Python requests und Node.js mit echten Fehlertexten.
  • Eine Tabelle zur Schnelldiagnose Symptom-Ursache-Prüfung, die Sie ausdrucken und griffbereit halten können.

Für wen diese Anleitung ist. Sie ist für alle geschrieben, die gerade erst mit Proxys anfangen, enthält aber auch fortgeschrittene Details für erfahrene Entwickler und Automatisierungsspezialisten. Wenn Sie Parser einrichten, mit Multi-Accounting arbeiten oder einfach verstehen wollen, warum Ihr Skript plötzlich keine Daten mehr bekommt, ist dieses Material für Sie.

Was Sie vorher wissen sollten. Ein grundlegendes Verständnis davon, was eine URL, ein Port und eine HTTP-Anfrage sind, reicht aus. Tiefe Netzwerkkenntnisse sind nicht erforderlich. Alle Begriffe erklären wir im Laufe der Anleitung in einfachen Worten.

Wie viel Zeit Sie brauchen. Für das erste Durchlesen benötigen Sie etwa 30-40 Minuten. Das Nachvollziehen der Beispiele am eigenen Projekt dauert weitere 20-30 Minuten. Danach wird die Diagnose eines typischen Fehlers bei Ihnen ein bis zwei Minuten dauern.

Wichtige Klarstellung zum Thema. In dieser Anleitung behandeln wir ausschließlich Fehler der Proxy-Schicht selbst. Der Code 429 (zu viele Anfragen) und Strategien für Wiederholungsversuche werden hier nicht behandelt, weil das ein großes eigenes Thema mit eigener Logik und eigenen Ansätzen ist. Für 429 braucht es separates Material zu Retries und Limits. Hier konzentrieren wir uns streng auf die Diagnose von Störungen der Proxy-Verbindung.

Vorbereitung: Werkzeuge und Zugänge

Bevor wir mit der Diagnose beginnen, stellen wir ein Werkzeugset zusammen. Alles davon ist kostenlos und läuft auf jedem Betriebssystem.

Notwendige Werkzeuge

  1. Installieren Sie curl. Auf den meisten Linux- und macOS-Systemen ist es bereits vorhanden. Prüfen Sie mit dem Befehl curl --version. Wenn Sie eine Versionsnummer sehen, ist alles bereit.
  2. Unter Windows ist curl ab modernen Versionen Teil des Systems. Öffnen Sie PowerShell und geben Sie denselben Prüfbefehl ein.
  3. Installieren Sie Python Version 3.10 oder neuer, wenn Sie die Beispiele mit requests planen. Prüfen Sie mit dem Befehl python --version.
  4. Installieren Sie die Bibliothek requests mit dem Befehl pip install requests im Terminal.
  5. Installieren Sie Node.js Version 20 oder neuer für die JavaScript-Beispiele. Prüfen Sie mit dem Befehl node --version.

Was Sie vorbereiten sollten

  • Ihre Proxy-Daten: Hostadresse, Port, Login und Passwort, falls erforderlich.
  • Eine Test-Zieladresse, die Sie ansprechen werden. Für Tests ist eine einfache Website praktisch, die Informationen über die Anfrage zurückgibt.
  • Einen Texteditor, um Logs und Diagnosenotizen zu speichern.

Tipp: Legen Sie eine separate Textdatei mit dem Namen diagnostic-notes an. Notieren Sie dort jeden Befehl und sein Ergebnis. Das rettet Sie, wenn Sie nach einer halben Stunde vergessen haben, was Sie bereits geprüft haben.

⚠️ Achtung: Speichern Sie niemals Login und Passwort für den Proxy in öffentlichen Chats, öffentlichen Repositories oder Screenshots. Ein Leck dieser Daten gibt Fremden Zugriff auf Ihren Datenverkehr. Bewahren Sie sie in einem sicheren Passwortmanager auf.

✅ Prüfung: An diesem Punkt sollten drei Versionsprüfbefehle erfolgreich ausgeführt werden: curl, python und node. Wenn mindestens einer nicht funktioniert, kehren Sie zur Installation des entsprechenden Werkzeugs zurück.

Grundbegriffe einfach erklärt

Damit die Diagnose bewusst abläuft, klären wir einige Schlüsselbegriffe. Überspringen Sie diesen Abschnitt nicht, auch wenn die Begriffe bekannt erscheinen.

Was ein Proxy wirklich ist

Ein Proxy ist ein Vermittler zwischen Ihrem Programm und der Zielwebsite. Ihre Anfrage erreicht zuerst den Proxy, und der Proxy leitet sie weiter. Die Antwort läuft denselben Weg zurück. Wegen dieser Vermittlung kann jeder Fehler an drei Stellen auftreten: bei Ihrem Client, beim Proxy selbst oder bei der Zielwebsite.

Die wichtigste Trennung: Client, Proxy, Server

Merken Sie sich die drei Glieder der Kette. Das erste Glied ist Ihr Client, also das Programm, das die Anfrage sendet. Das zweite Glied ist der Proxy, der Vermittler. Das dritte Glied ist der Zielserver, also die Website, die Sie erreichen wollen. Die gesamte Diagnose läuft auf die Frage hinaus: An welchem der drei Glieder ist die Störung aufgetreten?

HTTP-Codes in zwei Worten

Websites und Proxys antworten mit numerischen Codes. Codes mit 4 (zum Beispiel 407, 403) bedeuten normalerweise ein Problem auf der Seite der Anfrage oder des Zugriffs. Codes mit 5 (502, 504) bedeuten ein Problem auf der Seite des Servers oder des Vermittlers. Aber hier gibt es eine tückische Feinheit: Den Code 502 kann sowohl die Zielwebsite als auch der Proxy selbst senden. Sie zu unterscheiden ist eines der Hauptziele dieser Anleitung.

Der Unterschied zwischen HTTP und HTTPS über einen Proxy

Wenn Sie eine normale Website über HTTP ansprechen, sieht der Proxy die gesamte Anfrage. Wenn Sie eine gesicherte Website über HTTPS ansprechen, kann der Proxy den Inhalt nicht lesen. Stattdessen bittet der Client den Proxy mit dem speziellen Befehl CONNECT, einen gesicherten Tunnel zu erstellen. Genau deshalb erscheint die Meldung Tunnelverbindung fehlgeschlagen nur bei HTTPS. Das schauen wir uns separat und ausführlich an.

Tipp: Behalten Sie ein einfaches Bild im Kopf. Der Client klopft beim Proxy an. Der Proxy entscheidet, ob er ihn durchlässt. Dann klopft der Proxy bei der Website an. Die Website entscheidet, ob sie antwortet. Der Fehler tritt an dem Klopfen auf, das gescheitert ist.

Schritt 1: Wie Sie einen Proxy-Fehler von einem Fehler der Zielwebsite unterscheiden

Ziel dieses Schritts: Lernen, in wenigen Sekunden zu verstehen, wer schuld ist – der Proxy oder die Website. Das ist die grundlegende Fähigkeit, mit der jede Diagnose beginnt.

Das Hauptprinzip der Trennung

Die entscheidende Frage lautet: Ist Ihre Anfrage bis zur Zielwebsite gelangt oder beim Proxy hängengeblieben? Wenn die Anfrage beim Proxy hängengeblieben ist, ist die Proxy-Schicht schuld. Wenn die Anfrage bis zur Website gelangt ist und die Website geantwortet hat, liegt das Problem auf der Seite der Website.

  1. Sehen Sie sich den Fehlercode und den Meldungstext an.
  2. Bestimmen Sie, wer diese Antwort gesendet hat: der Proxy oder der Server. Darüber verrät der Antwort-Header und der Inhalt etwas.
  3. Wenn im Fehlertext direkt das Wort Proxy, tunnel oder der Name des Proxy-Programms erwähnt wird, ist fast sicher die Proxy-Schicht schuld.
  4. Wenn die Antwort eine gewohnte HTML-Seite der Zielwebsite mit ihrem Logo und Design enthält, ist die Anfrage bis zur Website gelangt.

Drei schnelle Anzeichen für einen Proxy-Fehler

  • Code 407. Diesen Code gibt es nur bei einem Proxy. Die Zielwebsite sendet ihn nie. Sie sehen 407 – dann sind Sie sicher auf der Proxy-Schicht.
  • Text Tunnelverbindung fehlgeschlagen oder Received HTTP code von einem Proxy. Solche Formulierungen erzeugt der Vermittler.
  • Sofortige Verbindungsverweigerung. Wenn die Anfrage fast sofort scheitert, noch bevor sie die Website hätte erreichen können, liegt das Problem wahrscheinlich zwischen Client und Proxy.

Tipp: Führen Sie einen Kontrollversuch durch. Senden Sie dieselbe Anfrage direkt ohne Proxy. Wenn es direkt funktioniert, aber über den Proxy nicht, liegt das Problem in der Proxy-Schicht oder in ihrer Interaktion mit der Website. Das schließt die Hälfte der Hypothesen in einer Minute aus.

Beispiel mit curl für eine schnelle Prüfung

Führen Sie die Anfrage über den Proxy mit ausführlicher Ausgabe aus. Der Befehl sieht so aus: curl -v -x http://login:passwort@host:port https://beispiel-website. Das Flag -v zeigt den gesamten Dialog. Das Flag -x legt den Proxy fest. Achten Sie auf Zeilen, die mit Pfeilen und Sternchen beginnen. Darüber geht es ausführlich in einem separaten Schritt zum Lesen von Logs.

⚠️ Achtung: Ziehen Sie niemals Schlussfolgerungen aus einer einzigen Anfrage an eine instabile Website. Wiederholen Sie die Anfrage zwei- bis dreimal. Eine einmalige Netzstörung kann wie ein Proxy-Fehler aussehen, obwohl der Proxy nichts dafür kann.

✅ Prüfung: Sie sollten für jede Fehlermeldung die Frage beantworten können: Hat das der Proxy oder die Website gesendet? Wenn Sie das können, gehen Sie weiter. Wenn Sie noch unsicher sind, kehren Sie zu den drei schnellen Anzeichen oben zurück.

Schritt 2: Fehler 407 Proxy Authentication Required

Ziel dieses Schritts: Lernen, den häufigsten Autorisierungsfehler am Proxy zu beheben und zu verstehen, worin er sich vom ähnlichen Code 401 unterscheidet.

Was 407 bedeutet und wie er sich von 401 unterscheidet

Der Code 407 sagt wörtlich Folgendes: Der Proxy verlangt, dass Sie sich mit Login und Passwort vorstellen, aber Sie haben das nicht getan oder falsch gemacht. Der entscheidende Unterschied zu 401: Den Code 401 sendet die Zielwebsite, wenn sie selbst eine Autorisierung verlangt. Den Code 407 sendet der Proxy. Wenn Sie 407 sehen, sind Sie nicht einmal bis zur Website gelangt – Sie wurden vom Vermittler am Eingang gestoppt.

An welchen Stellen genau Login und Passwort verloren gehen

Meistens gehen die Daten an drei Stellen verloren.

  1. Login und Passwort werden im Befehl überhaupt nicht übergeben. Der Client klopft anonym beim Proxy an, und der Proxy weist ihn ab.
  2. Die Daten werden übergeben, aber mit einem Tippfehler. Ein zusätzliches Leerzeichen oder das falsche Tastaturlayout – und die Autorisierung schlägt fehl.
  3. Die Daten werden korrekt übergeben, aber das Passwort enthält Sonderzeichen, die die Struktur der Verbindungszeichenfolge zerstören. Das ist die tückischste Ursache.

Sonderzeichen im Passwort und URL-Kodierung

Die Verbindungszeichenfolge zum Proxy sieht so aus: Login Doppelpunkt Passwort At-Zeichen Host Doppelpunkt Port. Das Problem ist, dass Doppelpunkt, At-Zeichen, Schrägstrich und andere Zeichen innerhalb dieser Zeichenfolge eine spezielle Bedeutung haben. Wenn Ihr Passwort zum Beispiel ein At-Zeichen oder einen Doppelpunkt enthält, versteht das Programm es falsch und bricht die Zeichenfolge an der falschen Stelle ab.

Die Lösung heißt URL-Kodierung. Sonderzeichen werden durch einen Code aus Prozentzeichen und zwei Ziffern oder Buchstaben ersetzt. Zum Beispiel wird das At-Zeichen zu Prozent vierzig, der Doppelpunkt wird zu Prozent drei A, der Schrägstrich wird zu Prozent zwei F, das Leerzeichen wird zu Prozent zwanzig.

  1. Finden Sie alle Sonderzeichen in Ihrem Passwort.
  2. Ersetzen Sie jedes durch seinen URL-Code.
  3. Setzen Sie die Verbindungszeichenfolge mit dem kodierten Passwort neu zusammen.
  4. Wiederholen Sie die Anfrage.

Tipp: Kodieren Sie das Passwort nicht manuell, wenn es komplex ist. In Python gibt es eine Funktion zur Kodierung aus dem Modul urllib.parse namens quote. Übergeben Sie ihr das Passwort, und sie gibt eine sichere Version zurück. Das schließt Fehler durch manuelle Eingabe aus.

Beispiel mit curl

Der echte Fehlertext bei falscher Autorisierung sieht so aus: curl (56) Received HTTP code 407 from proxy after CONNECT. Oder bei einer HTTP-Website: HTTP 407 Proxy Authentication Required. Der richtige Befehl mit Autorisierung: curl -v --proxy-user login:passwort -x http://host:port https://beispiel-website. Die Verwendung des Flags --proxy-user ist oft zuverlässiger, als die Daten direkt in die Adresse zu schreiben, weil curl selbst die Zeichen korrekt verarbeitet.

Beispiel mit Python requests

In requests wird der Proxy über ein Dictionary festgelegt. Die Schlüssel sind http und https, die Werte sind Verbindungszeichenfolgen. Wenn das Passwort Sonderzeichen enthält, wickeln Sie es in die Funktion quote. Ein typischer Fehler in der Antwort des Objekts: response.status_code gibt 407 zurück, und im Text wird Proxy Authentication Required erwähnt. Prüfen Sie gerade den Statuscode, nicht nur den Text.

Beispiel mit Node.js

In Node wird bei der Verwendung populärer Clients der Proxy über einen speziellen Agenten festgelegt. Der echte Fehler sieht aus wie ein Objekt mit dem Feld statusCode gleich 407 oder wie ein abgelehntes Promise mit einer Meldung über einen Tunnel-Autorisierungsfehler. Stellen Sie sicher, dass Sie den Autorisierungs-Header des Proxys senden und nicht den Autorisierungs-Header der Website – das sind verschiedene Dinge.

⚠️ Achtung: Der Autorisierungs-Header für den Proxy und der Autorisierungs-Header für die Website sind zwei verschiedene Header. Der eine heißt Proxy-Authorization, der andere Authorization. Wenn Sie sie verwechseln, bekommen Sie entweder 407 vom Proxy oder 401 von der Website. Prüfen Sie, welchen Header Ihre Bibliothek sendet.

✅ Prüfung: Nach der Korrektur der Autorisierung sollte der Antwortcode von 407 auf einen anderen wechseln. Selbst wenn die Website mit ihrem eigenen Fehler antwortet, ist das bereits ein Fortschritt: Sie haben den Proxy passiert und die Website erreicht.

Schritt 3: Fehler 502 vom Proxy

Ziel dieses Schritts: Lernen zu verstehen, wann 502 ein Problem der Zielwebsite bedeutet und wann eine Störung des Proxy-Kanals selbst.

Was 502 bedeutet

Der Code 502 heißt Bad Gateway, also schlechtes Gateway. Er sagt, dass der Vermittler versucht hat, das nächste Glied anzusprechen, aber eine unklare oder abgebrochene Antwort erhalten hat. Das Problem ist, dass 502 in zwei völlig verschiedenen Situationen kommen kann, und äußerlich sehen sie ähnlich aus.

Wenn der Zielhost schuld ist

Erste Situation: Der Proxy hat sich erfolgreich mit der Zielwebsite verbunden, aber die Website hat Müll zurückgegeben, die Verbindung abgebrochen oder selbst keine Antwort von ihrem Backend erhalten. In diesem Fall hat der Proxy gewissenhaft 502 an Sie weitergegeben als Feststellung: Ich bin bis zur Website gelangt, aber die Website hat schlecht geantwortet.

  1. Senden Sie dieselbe Anfrage direkt ohne Proxy.
  2. Wenn die Website direkt ebenfalls 502 antwortet oder hängt, ist die Website schuld, nicht der Proxy.
  3. In diesem Fall ist es nutzlos, den Proxy zu wechseln. Das Problem liegt auf der Seite des Ziels.

Wenn der Kanal selbst schuld ist

Zweite Situation: Der Proxy selbst ist instabil, sein übergeordneter Kanal ist abgebrochen, oder der Proxy konnte nicht einmal eine normale Verbindung zur Website herstellen. Dann ist 502 ein Zeichen für einen kranken Vermittler.

  1. Senden Sie eine Anfrage durch denselben Proxy an eine garantiert stabile Website.
  2. Wenn auch die stabile Website 502 zurückgibt, liegt das Problem im Proxy-Kanal.
  3. Versuchen Sie einen anderen Proxy oder einen anderen Knoten, falls Sie einen haben.

Tipp: Die Methode der Kreuzprüfung funktioniert zuverlässig. Ändern Sie jeweils eine Variable auf einmal. Fixieren Sie zuerst den Proxy und ändern Sie die Website. Dann fixieren Sie die Website und ändern Sie den Proxy. Die Schnittmenge der Ergebnisse zeigt den Schuldigen.

Echte Fehlertexte

Bei curl sehen Sie eine HTTP-Antwort mit dem Code 502 und oft eine HTML-Seite mit der Aufschrift Bad Gateway. Manchmal ist in den Antwort-Headern ein Hinweis sichtbar, welcher Server geantwortet hat. In Python requests ist das response.status_code gleich 502. In Node ist das Feld statusCode gleich 502. Achten Sie auf den Antwortkörper: Eine gestaltete Seite der Zielwebsite zeigt, dass die Anfrage bis zur Website gelangt ist, während eine knappe technische Seite oft vom Proxy stammt.

⚠️ Achtung: Beschuldigen Sie den Proxy nicht vorschnell beim ersten 502. Zielwebsites geben 502 sehr häufig zurück, besonders unter Last. Führen Sie immer eine Kontrollanfrage direkt durch, bevor Sie die Proxy-Einstellungen ändern.

✅ Prüfung: Sie sollten anhand der Ergebnisse zweier Kreuzanfragen sicher sagen können: Dieses 502 kommt von der Website oder vom Proxy. Wenn es noch nicht klappt, wiederholen Sie beide Kontrollanfragen und vergleichen Sie die Ergebnisse.

Schritt 4: Fehler 504 und Timeouts

Ziel dieses Schritts: Lernen, zwei grundlegend verschiedene Arten von Timeout zu unterscheiden und sie im Client richtig einzustellen.

Was 504 bedeutet

Der Code 504 heißt Gateway Timeout, also das Gateway hat nicht auf eine Antwort gewartet. Er sagt, dass der Vermittler zu lange auf eine Antwort vom nächsten Glied gewartet hat und aufgegeben hat. Aber um zu verstehen, wo genau die Zeit hängengeblieben ist, muss man zwei Arten von Timeout trennen.

Connect timeout versus read timeout

Es gibt zwei völlig verschiedene Momente des Wartens.

  • Connect timeout – das ist die Zeit für den Aufbau der Verbindung selbst. Der Client versucht, den Proxy zu erreichen, oder der Proxy die Website. Wenn die Verbindung nicht innerhalb der vorgegebenen Zeit aufgebaut wird, greift der connect timeout. Das ist normalerweise ein Zeichen dafür, dass die Adresse nicht erreichbar oder der Port geschlossen ist.
  • Read timeout – das ist die Wartezeit auf die Antwort, nachdem die Verbindung bereits aufgebaut ist. Die Verbindung besteht, die Anfrage ist raus, aber es kommen keine Daten. Das ist normalerweise ein Zeichen dafür, dass die Website lange nachdenkt oder bei der Verarbeitung hängt.

Wie Sie sie im Client trennen

Die richtige Diagnose beginnt mit der getrennten Einstellung dieser beiden Timeouts. Dann verstehen Sie sofort, an welcher Phase die Zeit hängengeblieben ist.

  1. In curl verwenden Sie das Flag --connect-timeout, um die Zeit für den Verbindungsaufbau zu begrenzen. Separat begrenzt das Flag --max-time die Gesamtzeit der gesamten Operation.
  2. In Python requests kann der Parameter timeout als Tupel aus zwei Zahlen übergeben werden. Die erste Zahl ist der connect timeout, die zweite der read timeout. Zum Beispiel timeout aus fünf und dreißig Sekunden.
  3. In Node gibt es in den meisten Clients separate Einstellungen für die Verbindungszeit und die Wartezeit auf die Antwort. Setzen Sie sie auf verschiedene Werte, damit Sie sehen, welcher ausgelöst wurde.

Wie Sie das Ergebnis lesen

Wenn der connect timeout ausgelöst wurde, haben Sie nicht einmal eine Verbindung aufgebaut. Prüfen Sie die Erreichbarkeit des Proxys und die Richtigkeit des Ports. Wenn der read timeout ausgelöst wurde, bestand die Verbindung, aber die Antwort kam nicht rechtzeitig. Prüfen Sie, ob die Website überlastet ist und ob Ihre Anfrage zu schwer ist.

Tipp: Setzen Sie den connect timeout klein, etwa fünf Sekunden. Der Verbindungsaufbau geschieht entweder schnell oder gar nicht. Den read timeout setzen Sie mit Puffer, weil manche Seiten ehrlich länger für die Antwort brauchen.

⚠️ Achtung: Ein zu kleiner read timeout führt zu falschen Fehlern. Sie brechen normale, aber langsame Antworten ab und denken, der Proxy sei kaputt. Prüfen Sie immer, ob Sie nicht selbst ein zu strenges Limit gesetzt haben.

Echte Fehlertexte

In curl sieht der connect timeout wie die Meldung Connection timed out nach stderr aus. In Python requests ist das die Ausnahme ConnectTimeout für die Verbindung und ReadTimeout für die Antwort. Gerade der Name der Ausnahme sagt Ihnen sofort, welche Phase gescheitert ist. In Node sehen Sie einen Fehler mit dem Code ETIMEDOUT oder eine separate Meldung über die Überschreitung der Antwortzeit.

✅ Prüfung: Nach der Einstellung getrennter Timeouts sollten Sie im Fehler eine klare Angabe erhalten: Das ist ein Verbindungs-Timeout oder ein Lese-Timeout. Wenn Sie nur das allgemeine Wort timeout ohne nähere Angabe sehen, sind die Timeouts noch nicht getrennt.

Schritt 5: Fehler Tunnelverbindung fehlgeschlagen und die CONNECT-Methode

Ziel dieses Schritts: Verstehen, warum dieser Fehler nur bei gesicherten Websites auftritt und wie man ihn diagnostiziert.

Warum der Fehler nur bei HTTPS kommt

Wenn Sie eine normale HTTP-Website ansprechen, leitet der Proxy einfach Ihre Anfrage weiter. Wenn Sie aber eine HTTPS-Website ansprechen, ist der Inhalt verschlüsselt, und der Proxy kann ihn nicht lesen. Deshalb sendet der Client zuerst den speziellen Befehl CONNECT mit der Adresse der Website an den Proxy. Dieser Befehl bedeutet die Bitte: Bitte baue mir einen gesicherten Tunnel zu dieser Adresse, ich werde direkt durch dich mit der Website kommunizieren.

Wenn der Proxy aus irgendeinem Grund den Tunnel nicht aufbauen konnte, gibt er den Fehler Tunnelverbindung fehlgeschlagen zurück. Bei normalem HTTP gibt es diesen Befehl nicht, deshalb gibt es diesen Fehler bei HTTP nicht. Das ist Ihr wichtigstes Erkennungsmerkmal.

Hauptursachen für das Scheitern des Tunnels

  • Der Proxy konnte sich nicht mit der Zieladresse verbinden. Möglicherweise ist die Website nicht erreichbar oder der Port geschlossen.
  • Der Proxy verbietet die CONNECT-Methode zu dieser Adresse oder diesem Port. Manche Proxys erlauben nur bestimmte Ports.
  • Die Autorisierung ist fehlgeschlagen. In diesem Fall sehen Sie oft die Kombination: zuerst der CONNECT-Versuch, dann der Code 407.
  • Der Proxy ist überlastet oder sein übergeordneter Kanal ist im Moment des Tunnelaufbaus abgebrochen.

Wie Sie diagnostizieren

  1. Führen Sie curl -v zu einer HTTPS-Adresse aus und suchen Sie in der Ausgabe die Zeile mit CONNECT. Sie zeigt den Moment der Tunnelanfrage.
  2. Sehen Sie, welche Antwort auf CONNECT kam. Eine Antwort mit dem Code 200 bedeutet, dass der Tunnel aufgebaut ist. Jeder andere Code bedeutet ein Scheitern.
  3. Wenn Sie daneben 407 sehen, liegt das Problem in der Autorisierung, nicht im Tunnel selbst. Kehren Sie zum Schritt über 407 zurück.
  4. Wenn Sie eine Verbindungsverweigerung sehen, konnte der Proxy die Website nicht erreichen.

Tipp: Prüfen Sie, dass Sie gerade einen erlaubten Port ansprechen. Klassische Ports für gesicherte Verbindungen sind normalerweise erlaubt, während viele Proxys ungewöhnliche Ports blockieren. Der Wechsel auf einen Standardport löst das Problem oft sofort.

Echte Fehlertexte

In curl ist das eine Meldung wie curl (56) Received HTTP code von einem Proxy after CONNECT oder direkt Tunnelverbindung fehlgeschlagen. In Python requests ist das die Ausnahme ProxyError mit einer eingebetteten Meldung über einen fehlgeschlagenen Tunnel. In Node ist das ein Fehler mit dem Text, dass die Tunnelverbindung nicht aufgebaut werden konnte, oft mit Angabe des Statuscodes vom Proxy.

⚠️ Achtung: Verwechseln Sie das Scheitern des Tunnels nicht mit einem Zertifikatsfehler. Wenn der Tunnel aufgebaut ist, aber dann das gesicherte Zertifikat der Website bemängelt wird, ist das bereits ein anderes Problem, das nicht mit der Proxy-Schicht zusammenhängt. Achten Sie darauf, an welcher Phase genau der Fehler aufgetreten ist: vor der Antwort auf CONNECT oder danach.

✅ Prüfung: Sie sollten in der curl-Ausgabe die Zeile mit der Antwort auf CONNECT finden und anhand ihres Codes verstehen, ob der Tunnel aufgebaut wurde oder nicht. Antwort 200 – der Tunnel steht. Ein anderer Code – suchen Sie die Ursache des Scheiterns.

Schritt 6: Fehler 403 vom Proxy

Ziel dieses Schritts: Lernen zu erkennen, wann 403 vom Proxy wegen Limits, Geografie oder verbotenem Port gesendet wird.

Was 403 im Kontext eines Proxys bedeutet

Der Code 403 heißt Forbidden, also verboten. Normalerweise sendet die Zielwebsite diesen Code, wenn sie den Zugriff sperrt. Aber auch der Proxy kann 403 senden, wenn er selbst entscheidet, Ihre Anfrage nicht durchzulassen. Die Aufgabe ist zu verstehen, wer genau das Verbot verhängt hat.

Drei Ursachen für 403 vom Proxy

  • Limits. Der Proxy kann die Anzahl der Anfragen, das Verkehrsvolumen oder die Zahl gleichzeitiger Verbindungen begrenzen. Bei Überschreitung gibt er 403 als Verweigerung der Bedienung zurück.
  • Geografische Beschränkung. Manche Proxys erlauben den Zugriff nur auf bestimmte Regionen oder verbieten umgekehrt bestimmte Richtungen. Eine Anfrage in eine gesperrte Richtung erhält 403.
  • Verbotener Port. Der Proxy kann nur Standardports erlauben. Der Zugriff auf einen ungewöhnlichen Port endet in einer Verweigerung.

Wie Sie 403 vom Proxy von 403 der Website unterscheiden

  1. Sehen Sie sich den Antwortkörper an. Eine gestaltete Seite der Zielwebsite mit ihrem Design bedeutet, dass die Website das Verbot verhängt hat.
  2. Eine knappe technische Seite oder die Erwähnung des Proxys im Text bedeutet, dass der Vermittler das Verbot verhängt hat.
  3. Senden Sie dieselbe Anfrage direkt. Wenn die Website direkt 403 zurückgibt und über den Proxy ebenfalls, ist die Website schuld.
  4. Wenn die Website direkt öffnet, aber über den Proxy 403 zurückgibt, suchen Sie die Ursache in den Limits oder Beschränkungen des Proxys.

Tipp: Prüfen Sie die Dokumentation oder das Verwaltungspanel Ihres Proxys auf Limits. Oft sieht man im persönlichen Bereich, ob der Traffic aufgebraucht oder das Anfragelimit erreicht ist. Das ist der schnellste Weg, die Ursache zu bestätigen.

⚠️ Achtung: Versuchen Sie nicht, die Limits des Proxys mit trickreichen Methoden zu umgehen. Wenn Sie an die Beschränkung Ihres Tarifs gestoßen sind, ist die richtige Lösung, den Tarif zu erweitern oder die Anzahl der Anfragen zu optimieren. Die Umgehung technischer Beschränkungen des Dienstes verstößt gegen die Nutzungsbedingungen.

Echte Fehlertexte

In curl ist das eine HTTP-Antwort 403 Forbidden mit einem Körper, der die Quelle verrät. In Python requests ist das response.status_code gleich 403. In Node ist das statusCode gleich 403. Analysieren Sie immer den Antwortkörper zusammen mit dem Code, weil gerade der Körper den wahren Urheber des Verbots enthüllt.

✅ Prüfung: Sie sollten anhand des Antwortkörpers und des Ergebnisses der direkten Anfrage bestimmen, wer 403 gesendet hat. Wenn es der Proxy ist – prüfen Sie Limits, Geo und Port. Wenn es die Website ist – liegt die Ursache nicht in der Proxy-Schicht.

Schritt 7: Verbindungsabbruch ohne Antwort – connection reset und EOF

Ziel dieses Schritts: Lernen, die rätselhaftesten Fälle zu diagnostizieren, in denen es überhaupt keine Antwort gibt und die Verbindung einfach abbricht.

Was das für Fehler sind

Manchmal erhalten Sie überhaupt keinen HTTP-Code. Stattdessen bricht die Verbindung plötzlich ab. Es gibt zwei typische Erscheinungen.

  • Connection reset. Wörtlich – die Verbindung wurde zurückgesetzt. Eine der Seiten hat den Kanal abrupt geschlossen, ohne den Austausch abzuschließen. Als hätte der Gesprächspartner mitten im Satz den Hörer aufgelegt.
  • EOF, unexpected end of file. Wörtlich – unerwartetes Ende der Daten. Der Client wartete auf die Fortsetzung der Antwort, aber der Datenstrom endete plötzlich.

Was Sie zuerst ansehen sollten

  1. Bestimmen Sie den Moment des Abbruchs. Geschah er vor der Antwort auf CONNECT, während der Übertragung der Anfrage oder während des Empfangs der Antwort? Die Ausgabe von curl -v zeigt die letzte erfolgreiche Zeile vor dem Abbruch.
  2. Wenn der Abbruch ganz am Anfang geschah, beim Verbinden mit dem Proxy, liegt das Problem wahrscheinlich im Proxy selbst oder im Netzweg zu ihm.
  3. Wenn der Abbruch nach dem Aufbau des Tunnels geschah, während der Kommunikation mit der Website, liegt das Problem wahrscheinlicher auf der Seite der Website oder in einem instabilen Kanal.
  4. Wiederholen Sie die Anfrage mehrmals. Ein stabil wiederkehrender Abbruch spricht für eine systemische Ursache. Ein zufälliger – für eine vorübergehende Netzinstabilität.

Häufige Ursachen

  • Der Proxy ist überlastet und schließt überzählige Verbindungen zwangsweise.
  • Der übergeordnete Kanal des Proxys ist instabil und bricht ab.
  • Die Zielwebsite schließt die Verbindung wegen eigener Beschränkungen.
  • Netzwerkprobleme zwischen den Gliedern der Kette.

Tipp: Führen Sie bei zufälligen Abbrüchen Statistik. Senden Sie zum Beispiel zwanzig Anfragen hintereinander und zählen Sie, wie viele abgebrochen sind. Wenn eine von zwanzig abbricht, ist das eine tolerierbare Instabilität. Wenn die Hälfte, gibt es ein systemisches Problem, das gelöst werden muss.

Echte Fehlertexte

In curl ist das Connection reset by peer oder Empty reply from server. In Python requests ist das die Ausnahme ConnectionError mit einer eingebetteten Meldung über den Verbindungsabbruch. In Node ist das ein Fehler mit dem Code ECONNRESET. Diese Meldungen enthalten gerade deshalb keinen HTTP-Code, weil der HTTP-Austausch nicht normal abgeschlossen wurde.

⚠️ Achtung: Ein Abbruch ohne Antwort ist leicht mit einem Timeout zu verwechseln. Der Unterschied besteht darin, dass beim Timeout der Client selbst das Warten beendet, während beim Reset die andere Seite den Kanal aktiv schließt. Achten Sie auf den Fehlertext: Das Wort reset weist auf einen aktiven Reset hin, das Wort timeout auf das Ablaufen des Wartens.

✅ Prüfung: Sie sollten anhand der letzten Zeile der curl-Ausgabe bestimmen, an welcher Phase die Verbindung abgebrochen ist. Das grenzt den Kreis der Verdächtigen sofort auf ein oder zwei Glieder ein.

Schritt 8: Praxis – curl -v Zeile für Zeile lesen

Ziel dieses Schritts: Lernen, in der curl-Ausgabe die Grenze zwischen Client, Proxy und Server zu sehen. Das ist die Krönung dieser Anleitung.

Was die Symbole am Zeilenanfang bedeuten

Die Ausgabe von curl -v verwendet spezielle Symbole am Anfang jeder Zeile, und das ist Ihr wichtigster Schlüssel zum Verständnis.

  • Ein Sternchen am Zeilenanfang bedeutet eine Informationsmeldung von curl selbst. Das sind Kommentare des Clients darüber, was er tut: Verbindung aufbauen, Tunnel bauen, Zertifikat prüfen.
  • Ein Pfeil nach rechts bedeutet Daten, die der Client an den Proxy oder Server sendet. Das ist die ausgehende Anfrage.
  • Ein Pfeil nach links bedeutet Daten, die der Client als Antwort erhält. Das ist die eingehende Antwort.

Wo die Grenze Client-Proxy-Server verläuft

Betrachten wir den typischen Weg zu einer gesicherten Website über einen Proxy. Zuerst meldet curl mit einem Sternchen, dass er sich mit dem Proxy unter der angegebenen Adresse und dem Port verbindet. Das ist der Abschnitt Client-Proxy. Dann kommt ein ausgehender Pfeil mit dem Befehl CONNECT – der Client bittet den Proxy, einen Tunnel zu bauen. Danach ein eingehender Pfeil mit der Antwort auf CONNECT – das ist die Antwort des Proxys. Wenn der Code 200 ist, ist der Tunnel aufgebaut, und die Grenze verschiebt sich: Danach läuft der gesamte Austausch bereits Client-Server durch den Tunnel.

Analyse eines echten Logs

Stellen Sie sich vor, Sie sehen die folgende Sequenz. Eine Zeile mit Sternchen: Ich verbinde mich mit der Adresse des Proxys und dem Port. Das bedeutet, der Client hat den Proxy gefunden. Die nächste Zeile mit Sternchen: Verbindung mit dem Proxy hergestellt. Ausgezeichnet, der erste Abschnitt ist geschafft. Dann ein ausgehender Pfeil: CONNECT zur Adresse der Zielwebsite. Der Client hat den Tunnel angefordert. Dann ein eingehender Pfeil: Antwort auf CONNECT mit einem Code. Hier ist die entscheidende Weggabelung.

  1. Wenn der Antwortcode auf CONNECT 200 ist, ist der Tunnel aufgebaut. Lesen Sie weiter.
  2. Wenn der Code 407 ist, verlangt der Proxy eine Autorisierung. Das Problem liegt in der Proxy-Schicht, Abschnitt Client-Proxy. Gehen Sie zum Schritt über 407.
  3. Wenn die Zeile Tunnelverbindung fehlgeschlagen lautet, konnte der Proxy den Tunnel nicht aufbauen. Die Ursache liegt zwischen Proxy und Website.

Nehmen wir an, der Tunnel ist aufgebaut. Danach kommen Sternchen über die Prüfung der gesicherten Verbindung mit der Website. Das ist bereits der Abschnitt Client-Server. Dann ein ausgehender Pfeil mit der eigentlichen Anfrage: Anfragezeile und Header. Beachten Sie: Bis zu diesem Moment hat die Website Ihre Anfrage überhaupt nicht gesehen, sie war mit dem Aufbau des Tunnels beschäftigt. Und schließlich ein eingehender Pfeil mit dem Antwortcode der Website. Hier beginnt die Verantwortungszone der Zielwebsite.

Wie Sie das für die Diagnose anwenden

  1. Finden Sie die Zeile des Verbindungsaufbaus mit dem Proxy. Wenn sie fehlt oder einen Fehler enthält, liegt das Problem zwischen Client und Proxy.
  2. Finden Sie die Antwort auf CONNECT. Bestimmen Sie anhand ihres Codes, ob die Proxy-Schicht passiert wurde.
  3. Finden Sie den eingehenden Pfeil mit der Antwort der Website. Wenn er vorhanden ist, sind Sie bis zur Website gelangt, und jeder Fehler hier gehört bereits zur Zone der Website.
  4. Die letzte Zeile vor dem Abbruch verrät immer, an welchem Abschnitt alles kaputtgegangen ist.

Tipp: Lesen Sie die Ausgabe von oben nach unten wie die Chronik einer Reise der Anfrage. Jede Zeile ist ein Schritt des Weges. Sobald Sie zur Zeile mit dem Fehler oder Abbruch gelangen, sehen Sie sich die vorherige erfolgreiche Zeile an. Sie zeigt das letzte lebende Glied.

⚠️ Achtung: Das Flag -v zeigt Header, einschließlich der Autorisierungszeile des Proxys. Wenn Sie das Log mit jemandem zur Hilfe teilen, streichen Sie unbedingt die Zeile mit den Autorisierungsdaten. Sonst geben Sie Ihr Login und Passwort preis.

✅ Prüfung: Nehmen Sie ein beliebiges eigenes curl -v Log und markieren Sie es: Wo ist der Abschnitt Client-Proxy, wo ist die Antwort auf CONNECT, wo beginnt die Zone der Website. Wenn Sie diese Grenzen sicher ziehen, haben Sie die wichtigste Diagnosefähigkeit gemeistert.

Schritt 9: Tabelle zur Schnelldiagnose Symptom-Ursache-Prüfung

Ziel dieses Schritts: Ein fertiges Nachschlagewerk erhalten, das Sie im Moment jedes Fehlers zur Hand nehmen können.

Wie Sie die Tabelle verwenden

Finden Sie Ihr Symptom in der ersten Spalte. Lesen Sie die wahrscheinliche Ursache. Führen Sie die Aktion aus der dritten Spalte zuerst aus – sie bestätigt oder widerlegt die Ursache mit größter Wahrscheinlichkeit.

Symptom: Code 407

Wahrscheinliche Ursache: Die Autorisierungsdaten des Proxys wurden nicht übergeben oder sind falsch, oder Sonderzeichen im Passwort haben die Verbindungszeichenfolge zerstört. Was zuerst prüfen: die Richtigkeit von Login und Passwort sowie die URL-Kodierung der Sonderzeichen im Passwort.

Symptom: Tunnelverbindung fehlgeschlagen bei HTTPS

Wahrscheinliche Ursache: Der Proxy konnte den Tunnel zur Website nicht aufbauen, möglicherweise wegen eines verbotenen Ports oder der Nichtverfügbarkeit der Website. Was zuerst prüfen: die Antwort auf CONNECT in der Ausgabe von curl -v und die Erlaubtheit des Zielports.

Symptom: Code 502

Wahrscheinliche Ursache: schlechte Antwort vom nächsten Glied, schuld ist entweder die Website oder ein instabiler Proxy-Kanal. Was zuerst prüfen: die Kreuzanfrage – dieselbe Website direkt und derselbe Proxy an eine stabile Website.

Symptom: Code 504

Wahrscheinliche Ursache: Die Wartezeit ist abgelaufen, es gilt zu verstehen – die der Verbindung oder die der Antwort. Was zuerst prüfen: getrennte connect timeout und read timeout, um zu sehen, welche Phase sich verzögert hat.

Symptom: Code 403 über den Proxy

Wahrscheinliche Ursache: Limits des Proxys, geografische Beschränkung oder verbotener Port. Was zuerst prüfen: den Antwortkörper auf die Quelle des Verbots und das Verwaltungspanel des Proxys auf aufgebrauchte Limits.

Symptom: connection reset oder ECONNRESET

Wahrscheinliche Ursache: Eine der Seiten hat die Verbindung zwangsweise geschlossen, oft ein überlasteter Proxy oder ein instabiler Kanal. Was zuerst prüfen: die Phase des Abbruchs anhand der letzten Zeile von curl -v und die Wiederholbarkeit des Problems über eine Serie von Anfragen.

Symptom: EOF, empty reply

Wahrscheinliche Ursache: Der Datenstrom brach ab, bevor die Antwort zu Ende war. Was zuerst prüfen: an welchem Abschnitt der Abbruch geschah – vor oder nach der Antwort auf CONNECT.

Symptom: connect timeout

Wahrscheinliche Ursache: Eine Verbindung kann nicht aufgebaut werden, die Adresse ist nicht erreichbar oder der Port geschlossen. Was zuerst prüfen: die Erreichbarkeit der Proxy-Adresse und die Richtigkeit des Ports.

Symptom: read timeout

Wahrscheinliche Ursache: Die Verbindung besteht, aber die Antwort kommt nicht, die Website verarbeitet lange oder hängt. Was zuerst prüfen: ob Ihr read timeout nicht zu klein ist und ob die Website nicht überlastet ist.

Tipp: Drucken Sie diese Tabelle aus oder speichern Sie sie in Ihren Notizen. Im Moment eines echten Fehlers unter Druck vergisst man leicht die Logik. Ein fertiges Nachschlagewerk spart Nerven und Zeit.

✅ Prüfung: Gehen Sie mit der Tabelle jede Ihrer letzten Fehler durch. Für jeden sollten Sie die erste Prüfaktion kennen.

Ergebnisprüfung: Checkliste für Diagnostiker

Stellen Sie sicher, dass Sie alle Schlüsselfertigkeiten beherrschen. Gehen Sie die Checkliste durch.

  • Sie können in Sekunden sagen, wer den Fehler gesendet hat – der Proxy oder die Website.
  • Sie verstehen den Unterschied zwischen 407 und 401 und können die Autorisierung beheben, einschließlich Sonderzeichen im Passwort.
  • Sie unterscheiden 502 von der Website und 502 vom Proxy durch Kreuzprüfung.
  • Sie trennen connect timeout und read timeout und wissen, was jeder bedeutet.
  • Sie verstehen, warum Tunnelverbindung fehlgeschlagen nur bei HTTPS vorkommt, und können die Antwort auf CONNECT lesen.
  • Sie erkennen die drei Ursachen für 403 vom Proxy: Limits, Geo und Port.
  • Sie diagnostizieren Verbindungsabbrüche anhand der Phase, in der sie aufgetreten sind.
  • Sie lesen die Ausgabe von curl -v Zeile für Zeile und ziehen die Grenzen Client-Proxy-Server.

Wie Sie sich selbst testen

  1. Nehmen Sie drei echte Logs mit verschiedenen Fehlern.
  2. Bestimmen Sie für jedes das schuldige Glied in einer Minute.
  3. Nennen Sie die erste Prüfaktion laut Tabelle.
  4. Wenn Sie alle drei geschafft haben, ist die Diagnose gemeistert.

✅ Prüfung: Der Erfolgsindikator ist, dass Sie beim Anblick eines Proxy-Fehlers nicht mehr in Panik geraten, sondern ihn ruhig nach den Gliedern der Kette auseinandernehmen.

Typische Fehler und Lösungen

Problem: Ich wechsle bei jedem Fehler sofort den Proxy

Ursache: Es fehlt die Gewohnheit zur Kreuzprüfung. Lösung: Führen Sie immer eine Kontrollanfrage direkt und an eine stabile Website durch, bevor Sie die Einstellungen ändern. Die Hälfte der Fehler liegt auf der Seite der Website.

Problem: Das Passwort mit At-Zeichen bricht die Verbindung

Ursache: Das Sonderzeichen ist nicht kodiert und zerreißt die Zeichenfolge. Lösung: Wenden Sie die URL-Kodierung auf das Passwort an oder verwenden Sie einen separaten Autorisierungsparameter, statt die Daten in die Adresse zu schreiben.

Problem: Ich verwechsle 407 und 401

Ursache: Ich unterscheide nicht zwischen Proxy-Autorisierung und Website-Autorisierung. Lösung: Merken Sie sich – 407 kommt immer vom Proxy, 401 immer von der Website. Prüfen Sie, welchen Header Sie senden: Proxy-Authorization oder Authorization.

Problem: Ein zu strenger Timeout bricht normale Anfragen ab

Ursache: Der read timeout ist zu klein gesetzt. Lösung: Trennen Sie connect- und read-Timeout, geben Sie dem read Puffer für langsame Seiten.

Problem: Tunnelverbindung fehlgeschlagen bei einem ungewöhnlichen Port

Ursache: Der Proxy verbietet CONNECT zu diesem Port. Lösung: Verwenden Sie einen Standardport für gesicherte Verbindungen oder klären Sie die Liste der erlaubten Ports beim Proxy.

Problem: Ich sehe 502 und denke, der Proxy ist tot

Ursache: Ich habe nicht geprüft, wer 502 gesendet hat. Lösung: Kreuzprüfung. Oft kommt 502 von einer überlasteten Zielwebsite, und der Proxy ist intakt.

Problem: Ich habe Login und Passwort im Log preisgegeben

Ursache: Ich habe die Ausgabe von curl -v ohne Bereinigung geteilt. Lösung: Streichen Sie immer die Autorisierungszeile, bevor Sie das Log jemandem senden, und ändern Sie nach Möglichkeit die kompromittierten Daten.

Problem: Ich halte einen Verbindungsabbruch für einen Timeout

Ursache: Ich unterscheide reset und timeout nicht. Lösung: Achten Sie auf den Fehlertext. Reset – aktives Schließen durch die andere Seite, timeout – Ablauf Ihres Wartens. Das sind verschiedene Ursachen.

Zusätzliche Möglichkeiten für Fortgeschrittene

Dauerhaftes Logging

Richten Sie die Speicherung ausführlicher Logs aller Proxy-Anfragen in Ihrer Anwendung ein. Dann haben Sie bei einem Fehler bereits eine Historie und müssen das Problem nicht neu reproduzieren. Notieren Sie den Antwortcode, die Abbruchphase und die Ausführungszeit.

Automatische Fehlerklassifizierung

Im Code kann man eine Funktion anlegen, die anhand des Ausnahmetyps und des Antwortcodes den Fehler sofort dem richtigen Glied zuordnet. Zum Beispiel ConnectTimeout – Verbindungsabschnitt, ReadTimeout – Antwortabschnitt, ProxyError mit Tunnel – Proxy-Schicht. Das beschleunigt die Reaktion in automatisierten Systemen.

Sammlung von Stabilitätsstatistiken

Führen Sie Metriken: Anteil erfolgreicher Anfragen, Anteil Abbrüche, durchschnittliche Antwortzeit. Eine plötzliche Verschlechterung der Metriken weist früher auf ein Problem hin, als Sie es manuell erleben.

Tipp: Trennen Sie die Metriken nach Gliedern. Zählen Sie separat Fehler beim Verbindungsaufbau und Fehler in der Antwortphase. So sehen Sie sofort, was genau degradiert – der Zugang zum Proxy oder die Kommunikation mit den Websites.

⚠️ Achtung: Verwandeln Sie die automatische Verarbeitung nicht in endlose Wiederholungen derselben Anfrage. Die Logik der Wiederholungsversuche ist ein separates großes Thema mit eigenen Regeln, das unter anderem mit dem Code 429 zusammenhängt. Ihm ist separates Material gewidmet, und es lohnt sich, es separat zu studieren.

FAQ: Häufige Fragen zur Diagnose

Wie erkenne ich schnell, dass der Proxy schuld ist und nicht mein Code?

Senden Sie dieselbe Anfrage direkt ohne Proxy. Wenn es direkt funktioniert, aber über den Proxy nicht, liegt das Problem in der Proxy-Schicht oder in ihrer Interaktion mit der Website. Das schließt die Hälfte der Hypothesen in einer Minute aus.

Warum bekomme ich 407, obwohl ich das richtige Passwort eingegeben habe?

Wahrscheinlich enthält das Passwort Sonderzeichen, die die Verbindungszeichenfolge zerstören. Wenden Sie die URL-Kodierung auf das Passwort an oder übergeben Sie die Daten über einen separaten Autorisierungsparameter statt in der Adresse.

Bedeutet Code 502 immer, dass der Proxy kaputt ist?

Nein. 502 kann auch die Zielwebsite senden, wenn sie selbst schlecht geantwortet hat. Führen Sie eine Kreuzprüfung durch: dieselbe Website direkt und derselbe Proxy an eine stabile Website. Die Schnittmenge der Ergebnisse zeigt den Schuldigen.

Worin unterscheidet sich connect timeout von read timeout?

Der connect timeout ist das Warten auf den Verbindungsaufbau. Der read timeout ist das Warten auf die Antwort, nachdem die Verbindung bereits aufgebaut ist. Trennen Sie sie im Client, und Sie sehen sofort, welche Phase sich verzögert hat.

Warum kommt Tunnelverbindung fehlgeschlagen nur bei HTTPS?

Weil der Client bei gesicherten Websites den Proxy bittet, mit dem Befehl CONNECT einen Tunnel zu bauen. Bei normalem HTTP gibt es diesen Befehl nicht. Wenn der Tunnel nicht aufgebaut wurde, kommt dieser Fehler, und er ist nur bei HTTPS möglich.

Wie unterscheide ich 403 vom Proxy von 403 von der Website?

Sehen Sie sich den Antwortkörper an. Eine gestaltete Seite der Website bedeutet ein Verbot der Website. Eine technische Seite oder die Erwähnung des Proxys bedeutet ein Verbot des Vermittlers. Bestätigen Sie es mit einer direkten Anfrage an die Website.

Was tun bei zufälligen Verbindungsabbrüchen?

Bestimmen Sie zuerst die Wiederholbarkeit: Senden Sie eine Serie von Anfragen und zählen Sie den Anteil der Abbrüche. Einzelne Abbrüche – tolerierbare Netzinstabilität. Massenhafte Abbrüche – ein systemisches Problem des Proxys oder des Kanals.

Wie teile ich ein curl -v Log sicher zur Hilfe?

Streichen Sie unbedingt die Zeile mit der Proxy-Autorisierung und alle sensiblen Header vor dem Senden. Sonst geben Sie Login und Passwort preis. Im Zweifelsfall ändern Sie die kompromittierten Daten.

Warum brechen meine normalen Anfragen manchmal durch Timeout ab?

Wahrscheinlich ist der read timeout zu streng gesetzt, und Sie brechen langsame, aber funktionierende Antworten ab. Erhöhen Sie den read timeout mit Puffer, und lassen Sie den connect timeout klein.

Wo kann ich über Code 429 und Wiederholungsversuche lesen?

Code 429 und Retry-Strategien sind ein separates großes Thema, das nicht direkt mit Störungen der Proxy-Schicht zusammenhängt. Ihm ist separates Material gewidmet, studieren Sie es getrennt von der Diagnose der Proxy-Fehler.

Fazit: Was Sie gemeistert haben und wohin Sie sich weiterentwickeln können

Herzlichen Glückwunsch. Sie haben den Weg von der Ratlosigkeit angesichts rätselhafter Codes bis zur sicheren schrittweisen Diagnose zurückgelegt. Erinnern wir uns, was jetzt in Ihrem Arsenal ist.

Zusammenfassung der ausgeführten Aktionen. Sie haben gelernt, die Kette in drei Glieder zu teilen – Client, Proxy und Server – und zu bestimmen, wo genau der Fehler aufgetreten ist. Sie haben sich mit dem Code 407 und der Proxy-Autorisierung befasst, einschließlich der tückischen Sonderzeichen im Passwort. Sie haben die zwiespältige Natur von 502 und die Methode der Kreuzprüfung verstanden. Sie haben die Trennung von connect- und read-Timeout bei 504 gemeistert. Sie haben sich mit der CONNECT-Methode und dem Fehler Tunnelverbindung fehlgeschlagen bei HTTPS befasst. Sie haben gelernt, die drei Ursachen für 403 vom Proxy zu erkennen und Verbindungsabbrüche anhand der Phase zu diagnostizieren. Und schließlich haben Sie die wichtigste Fähigkeit gemeistert – das Lesen der Ausgabe von curl -v Zeile für Zeile mit genauer Ziehung der Grenzen zwischen den Gliedern.

Was Sie als Nächstes tun sollten. Festigen Sie die Fähigkeit in der Praxis. Jedes Mal, wenn Sie auf einen Proxy-Fehler stoßen, raten Sie nicht, sondern zerlegen Sie ihn ruhig mit Hilfe der Diagnosetabelle nach Gliedern. Nach einer Woche solcher Praxis wird die Diagnose automatisch.

Wohin Sie sich entwickeln können. Der nächste logische Schritt ist das Studium des Themas Code 429 und kluger Strategien für Wiederholungsversuche, dem separates Material gewidmet ist. Vertiefen Sie sich dann in die automatische Fehlerklassifizierung im Code und die Sammlung von Stabilitätsmetriken. Das macht Sie von einem Menschen, der Brände löscht, zu einem Ingenieur, der Probleme im Voraus erkennt.

Tipp: Speichern Sie diese Anleitung und die Diagnosetabelle in Ihren Lesezeichen. Kehren Sie bei jedem neuen Fehler zu ihnen zurück, bis die Logik Ihre zweite Natur wird. Sicherheit in der Diagnose kommt gerade durch Wiederholung. Sie schaffen das.