Proxy-Server-Fehler 407, 502, 504 und tunnel failed: Schritt-für-Schritt-Diagnose für Einsteiger

Einleitung: Was Sie aus dieser Anleitung mitnehmen

Wenn Sie mit mobilen Proxys arbeiten, werden Sie früher oder später in den Logs eines Parsers, in der Konsole eines Antidetect-Browsers oder direkt im Werbekonto eine Zeile wie „407 Proxy Authentication Required“, „502 Bad Gateway“, „504 Gateway Timeout“ oder das kurze und erschreckende „tunnel failed“ sehen. Ein Proxy-Server-Fehler wirkt in dem Moment wie eine Blackbox: unklar, ob der Proxy selbst, Ihre Software, die Zielseite oder einfach ein veraltetes Passwort schuld ist. Dieser Leitfaden verwandelt die Blackbox in einen klaren Aktionsplan.

Wir beschränken uns bewusst auf ein Thema: Wir behandeln nur Codes und Meldungen, die der Proxy-Layer zurückgibt. Netzwerk-Timeouts auf Verbindungsebene (wenn überhaupt keine Antwort kommt und der Client das Warten selbst abbricht) werden im Blog separat behandelt und hier nicht wiederholt. Wenn in Ihrem Log genau ein Code oder die Tunnel-Meldung steht, sind Sie hier richtig.

Was Sie am Ende haben werden

• Sie verstehen, was jeder der vier Fehler bedeutet und an welcher Stelle der Kette „Ihre Software – Proxy – Zielseite“ er entsteht.
• Sie lernen, die Fehlerquelle in zwei bis drei Minuten mit dem in jedem System integrierten curl-Werkzeug zu bestimmen.
• Sie erhalten fertige Schritt-für-Schritt-Abläufe für 407, 502, 504 und tunnel failed, die Sie wie eine Checkliste abarbeiten können.
• Sie konfigurieren Ihre Software so, dass sie auf jeden Code richtig reagiert: Manche Fehler sollten wiederholt werden, andere nicht.
• Sie führen ein persönliches Incident-Log, das Ihnen beim nächsten Ausfall Stunden spart.

Für wen dieser Leitfaden ist

Die Anleitung richtet sich an Marketingfachleute, Affiliate-Marketer, Inhaber kleiner Teams und Entwickler, die mobile Proxys nutzen, aber keine Netzwerkingenieure sein müssen. Der Hauptteil ist für Einsteiger gedacht: Jeder Befehl wird erklärt, jede Aktion beschrieben. Für diejenigen, die eigene Skripte schreiben und tiefer einsteigen möchten, gibt es am Ende einen fortgeschrittenen Abschnitt.

Was Sie vorher wissen sollten

Es reicht, ein Terminal oder eine Eingabeaufforderung öffnen, Text hineinkopieren und das Ergebnis lesen zu können. Ein Verständnis davon, was eine IP-Adresse und ein Port sind, hilft, aber wir frischen das kurz auf. Programmiererfahrung ist nicht erforderlich.

Wie viel Zeit Sie benötigen

Das vollständige Lesen und die erste Diagnose dauern 60 bis 120 Minuten. Wenn Sie gerade ein konkretes Problem haben, springen Sie direkt zum passenden Schritt: Für jeden einzelnen Fehler sind 15–25 Minuten inklusive Prüfungen veranschlagt.

Vorbereitung: Werkzeuge und Zugänge

Die Diagnose von Proxy-Layer-Fehlern erfordert keine Installation schwerer Programme. Fast alles ist bereits in Ihrem Betriebssystem vorhanden. Trotzdem sollten Sie sich vorbereiten, damit Sie im Fehlerfall nicht nach Passwörtern suchen oder sich nicht erinnern müssen, wo die Konfiguration liegt.

Benötigte Werkzeuge

1. Terminal oder Eingabeaufforderung. Öffnen Sie unter Windows 10 und 11 das Startmenü, geben Sie „cmd“ oder „PowerShell“ ein und drücken Sie Enter. Öffnen Sie unter macOS „Programme“, dann „Dienstprogramme“, dann „Terminal“. Unter Linux rufen Sie das Terminal normalerweise mit Strg+Alt+T auf.
2. Das curl-Werkzeug. Es ist ab Windows 10 (Build 1803), in macOS und in den meisten Linux-Distributionen integriert. Prüfen Sie: Geben Sie im Terminal curl --version ein und drücken Sie Enter. Es sollte eine Zeile mit der Versionsnummer erscheinen, z. B. „curl 8.x.x“. Wenn stattdessen „Befehl nicht gefunden“ steht, installieren Sie curl über den Paketmanager Ihres Systems.
3. Ein normaler Browser mit Entwicklerwerkzeugen. Jeder moderne Browser eignet sich, bei dem sich mit F12 ein Bereich mit dem Tab „Netzwerk“ öffnet.
4. Ein Texteditor für das Incident-Log. Notepad reicht, aber ein Editor mit Syntaxhervorhebung ist praktischer, um die Struktur der Logs zu sehen.
5. Ihre Arbeitssoftware: Antidetect-Browser, Parser, Werbekonto-Manager oder eigenes Skript. Wir benötigen Zugriff auf die Proxy-Einstellungen und die Logs.

Benötigte Zugänge

• Zugang zum Kundenkonto Ihres Proxy-Anbieters. Für Nutzer von mobileproxy.space ist das die Verwaltungsseite Ihrer Kanäle, auf der Host, Port, Login, Passwort, Authentifizierungstyp und der Link zum IP-Wechsel sichtbar sind.
• Aktuelle Zugangsdaten mindestens eines Proxys: Adresse (Host), Port, Login und Passwort oder eine bestätigte IP für die Authentifizierung per Adresse.
• Kenntnis des verwendeten Protokolls: HTTP(S)-Proxy oder SOCKS5. Diese Information zeigt ebenfalls das Kundenkonto.

Systemanforderungen

Jedes Betriebssystem der letzten acht Jahre. Eine Internetverbindung, über die der Proxy-Host erreichbar ist. Mehr ist nicht nötig.

Backups

Bevor Sie Proxy-Einstellungen in Ihrer Arbeitssoftware ändern, speichern Sie den aktuellen Zustand. Das dauert fünf Minuten und bewahrt Sie vor der Situation, in der Sie einen Fehler „behoben“ und gleichzeitig die funktionierende Konfiguration von zehn Accounts verloren haben.

1. Exportieren Sie im Antidetect-Browser die Profilliste zusammen mit den Proxy-Einstellungen. Normalerweise liegt die Exportfunktion im Profilmenü und erstellt eine CSV- oder JSON-Datei.
2. Kopieren Sie im Parser oder Skript die Konfigurationsdatei in einen separaten Ordner mit Datum im Namen, z. B. „config_backup_2026-03-14“.
3. Kopieren Sie aus dem Kundenkonto die Zugangsdaten aller Kanäle in eine Textdatei. Bewahren Sie diese Datei an einem Ort auf, zu dem Unbefugte keinen Zugang haben.
4. Notieren Sie die aktuelle IP Ihres Computers oder Servers. Sie wird benötigt, wenn Sie die Authentifizierung per IP-Adresse verwenden.

Tipp: Legen Sie eine Textdatei „Proxy-Log“ an und notieren Sie jeden Fehler im Format „Datum, Uhrzeit, Code, Proxy-Host, Zielseite, was getan, was geholfen“. Nach einem Monat haben Sie eine persönliche Wissensdatenbank, die nützlicher ist als jeder Artikel.

Prüfung: Terminal öffnet, curl zeigt eine Version, Sie sind im Kundenkonto eingeloggt und sehen die Zugangsdaten mindestens eines Proxys, die Konfigurations-Backups liegen in einem separaten Ordner. Weiter geht’s.

Grundbegriffe: Wie der Proxy-Layer aufgebaut ist und woher die Codes kommen

Um einen Proxy-Server-Fehler sinnvoll statt durch Ausprobieren zu beheben, müssen Sie den Weg einer Anfrage kennen. Er besteht aus drei Abschnitten, und jeder unserer vier Fehler lebt in einem eigenen Abschnitt.

Drei Abschnitte des Anfragewegs

• Client – Proxy. Ihr Browser, Parser oder Skript verbindet sich mit Host und Port des Proxys. In diesem Abschnitt wird die Authentifizierung geprüft. Hier entsteht der Fehler 407 und ein Teil der tunnel failed-Fälle.
• Proxy – Mobilfunknetz – Zielseite. Der Proxy-Server öffnet nach Erhalt Ihrer Anfrage in eigenem Namen eine Verbindung über das Modem mit der SIM-Karte des Betreibers zur gewünschten Website. Hier entstehen 502 und 504.
• Zielseite – Rückweg. Die Antwort der Website läuft über dieselben Knoten zurück. Wenn die Website ihren eigenen Code zurückgibt, z. B. 403 oder 429, ist das kein Proxy-Layer-Fehler, und es ist wichtig, das zu unterscheiden.

Codeklassen einfach erklärt

Ein Antwortcode ist eine dreistellige Zahl, die der Server in der ersten Zeile der Antwort sendet. Die erste Ziffer gibt die Klasse an. Codes 4xx bedeuten „Problem auf Ihrer Seite, korrigieren Sie die Anfrage“. Codes 5xx bedeuten „Problem auf der Serverseite oder dahinter“. Für den Proxy-Layer funktioniert das so:

• 407 Proxy Authentication Required – der Proxy sagt: „Ich weiß nicht, wer du bist, oder deine Daten sind falsch.“ Klasse 4xx: Sie müssen bei sich reparieren.
• 502 Bad Gateway – der Proxy sagt: „Ich habe versucht, weiterzukommen, aber einen Abbruch oder Müll statt einer Antwort erhalten.“ Klasse 5xx: Problem hinter dem Proxy oder im Proxy selbst.
• 504 Gateway Timeout – der Proxy sagt: „Ich habe die vorgegebene Zeit auf eine Antwort des nächsten Knotens gewartet und keine erhalten.“ Das ist ebenfalls 5xx.

Unterschied zwischen Code 504 und Netzwerk-Timeout

Das ist die entscheidende Abgrenzung für den gesamten Artikel. Wenn Sie Code 504 sehen, bedeutet das, dass der Proxy-Server lebt, Ihre Anfrage angenommen hat, selbst auf die Antwort der Website gewartet hat und Ihnen das Scheitern per Code mitteilt. Die Verbindung zwischen Ihnen und dem Proxy funktionierte einwandfrei. Wenn Ihr Client dagegen „connection timed out“ oder „operation timed out“ ohne Code schreibt, kam überhaupt keine Antwort, und die Unterbrechung ging von Ihrer Software aus. Ersteres ist Gegenstand dieses Leitfadens. Letzteres ist ein anderes Thema, das in verwandten Blogartikeln behandelt wird. Ein einfaches Merkmal: Gibt es eine dreistellige Zahl in der Antwort, lesen Sie hier weiter.

Was ist ein Tunnel und warum „fällt“ er

Wenn Sie eine Website über HTTPS durch einen HTTP-Proxy öffnen, sendet der Browser zuerst den speziellen Befehl CONNECT mit Adresse und Zielport an den Proxy. Der Proxy öffnet eine Verbindung zur Website und antwortet mit „200 Connection established“. Danach läuft ein verschlüsselter Strom durch den Proxy, den der Proxy selbst nicht mehr lesen kann. Eine solche Verbindung heißt Tunnel. Wenn der Proxy auf den CONNECT-Befehl mit etwas anderem als 200 antwortet, schreibt der Client „tunnel failed“ und gibt normalerweise den genauen Code an. Das heißt, tunnel failed ist kein eigenständiger Fehler, sondern eine Hülle um einen der Codes.

Zwei Authentifizierungsmethoden

• Login und Passwort. Der Client überträgt sie im Header Proxy-Authorization. Die häufigste Methode und die häufigste Quelle von 407.
• Authentifizierung per IP. Sie geben im Kundenkonto die Adresse Ihres Computers oder Servers an, und der Proxy lässt alle Anfragen von dieser Adresse ohne Passwort durch. Praktisch, aber bricht, wenn sich Ihre IP ändert.

Dienst-Header, an denen man den Antwortenden erkennt

Der Proxy fügt seinen Antworten oft die Header Via, Proxy-Agent oder X-Proxy hinzu. Zielseiten setzen sie nicht. Wenn in einer Antwort mit Code 502 der Header Proxy-Agent steht, wissen Sie sicher, dass der Proxy geantwortet hat. Wenn keine solchen Header vorhanden sind, aber ein Server-Header mit dem Namen des Webservers der Website, dann ist das die Antwort der Website selbst. Dieses Merkmal werden wir aktiv nutzen.

Tipp: Merken Sie sich die Eselsbrücke: „Vierer – suche bei dir, Fünfer – suche hinter dem Proxy, Tunnel – schau, welche Zahl daneben steht.“ Das löst die Hälfte der Fälle ohne weiteres Lesen.

Schritt 1: Feststellen, wer genau den Fehler zurückgegeben hat

Ziel dieses Schritts: In wenigen Minuten genau feststellen, ob der Proxy-Server, die Zielseite oder Ihre eigene Software geantwortet hat, und den vollständigen Antworttext für die weitere Arbeit festhalten.

Anleitung

1. Öffnen Sie das Kundenkonto und kopieren Sie die Zugangsdaten des problematischen Proxys: Host, Port, Login, Passwort. Für das Beispiel nehmen wir an: Host – proxy.example.net, Port – 8080, Login – user1, Passwort – pass1. Ersetzen Sie diese durch Ihre Werte.
2. Öffnen Sie das Terminal.
3. Geben Sie den Befehl ein, ersetzen Sie die Zugangsdaten und die Zieladresse durch Ihre eigenen, und drücken Sie Enter: curl -v -x http://user1:pass1@proxy.example.net:8080 https://example.com/. Der Schalter -v aktiviert die ausführliche Ausgabe, -x legt den Proxy fest.
4. Warten Sie, bis der Befehl beendet ist. Normalerweise dauert das ein bis drei Sekunden. Wenn der Befehl länger als 30 Sekunden „hängt“, drücken Sie Strg+C: Wahrscheinlich liegt ein Netzwerk-Timeout vor, kein Code, und das ist nicht unser Thema.
5. Suchen Sie in der Ausgabe nach Zeilen, die mit dem Zeichen „größer“ beginnen (das ist, was curl gesendet hat) und mit dem Zeichen „kleiner“ (das ist, was als Antwort kam). Die erste Antwortzeile sieht aus wie „HTTP/1.1 407 Proxy Authentication Required“ oder „HTTP/1.1 200 Connection established“.
6. Schauen Sie auf die Zeile mit CONNECT. Wenn direkt danach ein Code ungleich 200 kommt, hat der Proxy den Fehler in der Tunnelphase zurückgegeben. Wenn CONNECT 200 erhalten hat und der Fehlercode später nach den Zeilen zum TLS-Handshake kommt, hat bereits die Zielseite geantwortet.
7. Suchen Sie die Antwort-Header. Das Vorhandensein von Proxy-Agent, Via oder ähnlichen Dienst-Headern weist eindeutig auf den Proxy hin. Ein Server-Header mit dem Namen des Webservers und ein Set-Cookie-Header weisen auf die Zielseite hin.
8. Wiederholen Sie denselben Befehl ohne den Schalter -x, also direkt: curl -v https://example.com/. Wenn die Website mit 200 antwortet und über den Proxy 5xx kommt, ist das Problem im Abschnitt hinter dem Proxy lokalisiert.
9. Wiederholen Sie den Befehl über den Proxy, aber zu einer anderen Website, z. B. zu einer stabilen großen Ressource. Wenn die zweite Website sich öffnet, hängt das Problem mit einer bestimmten Richtung zusammen, nicht mit dem Proxy als Ganzem.
10. Kopieren Sie die gesamte Ausgabe mit Datum und Uhrzeit in das Proxy-Log. Sie werden sie in den nächsten Schritten benötigen.

Alternativer Weg über den Browser

Wenn die Arbeit im Terminal unbequem ist, öffnen Sie den Browser mit dem konfigurierten Proxy, drücken Sie F12, wechseln Sie zum Tab „Netzwerk“, aktivieren Sie das Kontrollkästchen „Protokoll beibehalten“, und laden Sie die Seite neu. Suchen Sie in der Liste der Anfragen die Zeile mit einem roten Code, klicken Sie darauf und prüfen Sie im Tab „Header“ den Block „Response Headers“. Die Logik ist dieselbe: Suchen Sie nach den Dienst-Headern des Proxys. Der Nachteil ist, dass der Browser oft Details der CONNECT-Phase verbirgt; daher ist das Terminal bei tunnel failed vorzuziehen.

Achtung: Der Befehl mit dem Schalter -v gibt Login und Passwort des Proxys im Klartext aus. Fügen Sie diese Ausgabe nicht in öffentliche Chats, Support-Tickets oder Screenshots ein, ohne das Passwort durch Sternchen zu ersetzen.

Tipp: Fügen Sie dem Befehl den Schalter -sS zusammen mit -o und der Angabe eines leeren Geräts hinzu, um den Bildschirm nicht mit dem Antworttext zu überladen: curl -sS -v -o /dev/null -x http://user1:pass1@proxy.example.net:8080 https://example.com/. Verwenden Sie unter Windows anstelle von /dev/null den Wert NUL.

Erwartetes Ergebnis

Im Log ist ein Eintrag mit der vollständigen Antwort erschienen, und Sie können sicher eines von drei Dingen sagen: „Der Proxy hat in der Authentifizierungsphase geantwortet“, „Der Proxy hat in der Phase der Ansprache der Website geantwortet“ oder „Die Website selbst hat geantwortet“. Das leitet Sie zu Schritt 2, 3–4 oder außerhalb dieses Artikels.

Mögliche Probleme

• Der Befehl meldet „Could not resolve proxy“. Tippfehler im Host. Vergleichen Sie zeichenweise mit dem Kundenkonto.
• Der Befehl meldet „Failed to connect to proxy“. Der Port ist geschlossen oder falsch. Das ist ein Transportproblem, kein Code; prüfen Sie den Port und versuchen Sie einen anderen Kanal.
• Die Ausgabe bricht in der TLS-Zeile ohne Code ab. Das bedeutet, der Tunnel ist aufgebaut, aber die Website hat nicht innerhalb der von Ihrem Client vorgegebenen Zeit geantwortet. Verwechseln Sie das nicht mit 504: Kein Code bedeutet, das ist nicht unser Fall.

Prüfung: Sie können den Antwortenden und den genauen Code oder die genaue Phrase nennen, und die curl-Ausgabezeile ist im Log gespeichert.

Schritt 2: Fehler 407 Proxy Authentication Required beheben

Ziel dieses Schritts: Erreichen, dass der Proxy auf den CONNECT-Befehl mit „200 Connection established“ statt 407 antwortet, und die Ursache verstehen, damit der Fehler nicht zurückkommt.

Warum 407 auftritt

Der Proxy hat Ihre Anmeldedaten nicht akzeptiert. Es gibt meist sechs Ursachen, die wir nach aufsteigender Komplexität prüfen: Tippfehler, Sonderzeichen im Passwort, Änderung Ihrer IP bei Authentifizierung per Adresse, abgelaufene Laufzeit des Kanals, Software überträgt die Daten gar nicht, veraltete Daten im Browser-Cache.

Anleitung

1. Öffnen Sie das Kundenkonto und suchen Sie den problematischen Kanal. Stellen Sie sicher, dass seine Laufzeit nicht abgelaufen und der Status aktiv ist. Wenn die Laufzeit abgelaufen ist, verlängern Sie sie und wiederholen Sie die Anfrage nach einer Minute; in diesem Fall ist nichts weiter zu tun.
2. Prüfen Sie, welcher Authentifizierungstyp für den Kanal aktiviert ist: Login und Passwort oder per IP-Adresse. Viele Panels erlauben, beide gleichzeitig zu aktivieren.
3. Wenn die Authentifizierung per IP aktiviert ist, ermitteln Sie die aktuelle externe Adresse Ihres Computers oder Servers. Öffnen Sie im Browser ohne Proxy einen Dienst, der Ihre IP anzeigt, und vergleichen Sie mit der im Kundenkonto hinterlegten Adresse. Heimprovider und Mobilfunkbetreiber ändern die Adresse oft nach einem Router-Neustart. Wenn die Adressen abweichen, aktualisieren Sie sie im Kundenkonto und warten Sie ein bis zwei Minuten: Änderungen werden nicht sofort wirksam.
4. Wenn Login und Passwort verwendet werden, kopieren Sie sie erneut aus dem Kundenkonto, ohne sie abzutippen. Fügen Sie sie in den curl-Befehl aus Schritt 1 ein und starten Sie. Die Hälfte der 407-Fälle endet hier.
5. Schauen Sie sich das Passwort an. Wenn es Zeichen wie @, :, /, #, ?, % oder Leerzeichen enthält, müssen sie bei der Übertragung in der Adresszeile kodiert werden. Das @-Zeichen wird zu %40, der Doppelpunkt zu %3A, die Raute zu %23, das Prozentzeichen zu %25. Zum Beispiel wird das Passwort p@ss:1 in der URL als p%40ss%3A1 geschrieben. Um die Kodierung zu vermeiden, übergeben Sie die Daten mit einem separaten Schalter: curl -v -x proxy.example.net:8080 --proxy-user user1:p@ss:1 https://example.com/. Hier kümmert sich curl selbst um die Zeichen.
6. Wenn curl durchläuft, Ihre Arbeitssoftware aber weiterhin 407 erhält, liegt das Problem in der Software selbst. Öffnen Sie ihre Proxy-Einstellungen. Prüfen Sie, ob Login und Passwort in separaten Feldern eingegeben sind und nicht an die Adresse angehängt, wenn das Programm das nicht erwartet. Prüfen Sie, ob am Ende des Passworts ein Leerzeichen steht: Das entsteht oft beim Kopieren.
7. Öffnen Sie im Antidetect-Browser die Einstellungen eines bestimmten Profils, nicht die globalen Einstellungen. Viele Nutzer ändern das Passwort in der allgemeinen Proxy-Liste, aber das Profil speichert weiterhin eine alte Kopie. Speichern Sie den Proxy im Profil erneut und starten Sie das Profil neu.
8. Wenn der Browser alte Daten gespeichert hat und keine neuen abfragt, löschen Sie die gespeicherten Passwörter für diesen Host in den Browsereinstellungen oder erstellen Sie ein neues Profil zum Testen.
9. Achten Sie auf den Header Proxy-Authenticate in der 407-Antwort. Wenn dort „Basic“ steht, erwartet der Proxy ein normales Login-Passwort-Paar. Wenn ein anderes Schema angegeben ist, muss Ihre Software es unterstützen; für mobile Proxys wird fast immer Basic verwendet, und eine Abweichung bedeutet einen Fehler in den Einstellungen des Proxy-Typs.
10. Wiederholen Sie die curl-Anfrage und stellen Sie sicher, dass auf CONNECT nun 200 kommt.

Achtung: Versuchen Sie nicht, 407 durch massenhaftes Wiederholen von Anfragen zu „lösen“. Manche Proxy-Server blockieren die Adresse nach einer Reihe fehlgeschlagener Authentifizierungen vorübergehend, und Sie erhalten ein zusätzliches Problem obendrauf. Eine Prüfung, eine Korrektur, eine Prüfung.

Tipp: Wenn Sie mehrere Dutzend Kanäle haben, speichern Sie sie in einer Tabelle, in der Login und Passwort in separaten Spalten stehen und daneben eine Spalte mit dem bereits URL-kodierten Passwort. So verwechseln Sie nie, welche Variante wohin gehört.

Erwartetes Ergebnis

In der curl-Ausgabe ist die Antwortzeile auf CONNECT nun „HTTP/1.1 200 Connection established“, die Website liefert Inhalte. In Ihrer Arbeitssoftware laufen die Anfragen durch. Im Log ist die Ursache notiert: Tippfehler, Kodierung, IP-Änderung, Ablauf oder Cache.

Mögliche Probleme

• Code 407 kommt zweimal: zuerst auf CONNECT, dann innerhalb des Tunnels. Das ist ein Zeichen dafür, dass die Software die Daten nur in einer Phase sendet. Aktualisieren Sie das Programm oder aktivieren Sie darin die Option zur Übertragung der Authentifizierung bei CONNECT.
• Das Kundenkonto sagt, die IP sei hinzugefügt, aber 407 bleibt. Sie arbeiten wahrscheinlich über ein Unternehmensnetz oder einen Server mit mehreren ausgehenden Adressen. Prüfen Sie die Adresse genau von der Maschine aus, von der die Anfragen kommen.
• Bei Ihnen funktioniert es, bei einem Kollegen mit denselben Daten nicht. Bei Authentifizierung per IP ist das zu erwarten: Der Kollege hat eine andere Adresse. Wechseln Sie zu Login und Passwort oder fügen Sie eine zweite IP hinzu.

Prüfung: Drei aufeinanderfolgende Anfragen über curl und über die Arbeitssoftware liefen ohne 407 durch, die Ursache ist im Log notiert.

Schritt 3: Fehler 502 Bad Gateway vom Proxy verstehen und beheben

Ziel dieses Schritts: Kurzzeitige Störungen beim IP-Wechsel von einem anhaltenden Problem mit der Richtung oder dem Kanal unterscheiden und für jeden Fall die richtige Reaktion wählen.

Warum der Proxy 502 zurückgibt

Der Proxy hat Ihre Anfrage angenommen, versucht, eine Verbindung weiter aufzubauen, und einen Abbruch, eine Ablehnung oder eine unlesbare Antwort erhalten. Bei mobilen Proxys sind die typischen Ursachen: Das Modem hat in diesem Moment die IP-Adresse gewechselt oder sich im Netz des Betreibers neu registriert; die Zielseite hat die Verbindung zurückgesetzt; auf der Proxy-Seite konnte der Domainname der Website nicht aufgelöst werden; der Kanal ist mit zu vielen gleichzeitigen Streams überlastet; die Website ist für alle nicht erreichbar.

Anleitung

1. Notieren Sie die genaue Uhrzeit des 502-Auftretens mit Sekunden. Das ist wichtig für den nächsten Punkt.
2. Öffnen Sie im Kundenkonto die Historie der IP-Wechsel für diesen Kanal oder erinnern Sie sich, ob eine automatische Rotation nach Zeitplan aktiviert ist. Wenn die Rotation in denselben Sekunden wie der Fehler stattgefunden hat, liegt normales Verhalten vor: Während des Adresswechsels erhalten Anfragen für zwei bis zehn Sekunden 502. Die Lösung ist, die Anfrage nach einer Pause zu wiederholen.
3. Warten Sie zehn Sekunden und wiederholen Sie den curl-Befehl aus Schritt 1. Wenn die Antwort 200 geworden ist, notieren Sie im Log „502 im Moment der Rotation“ und gehen Sie zur Einrichtung der Wiederholungen in Schritt 6 über.
4. Wenn 502 hartnäckig wiederkehrt, prüfen Sie eine andere Website über denselben Proxy. Öffnet sie sich, liegt das Problem in der Richtung. Öffnet sie sich nicht, liegt das Problem im Kanal.
5. Für ein Problem in der Richtung: Öffnen Sie die Zielseite direkt ohne Proxy. Wenn sie auch direkt nicht erreichbar ist oder 5xx liefert, ist der Proxy unschuldig: Die Website liegt darnieder. Wenn direkt alles funktioniert, trennt die Website wahrscheinlich Verbindungen von Adressen dieses Betreibers. Wechseln Sie die IP über den Link im Kundenkonto und wiederholen Sie. Wenn das nicht hilft, versuchen Sie einen Kanal eines anderen Betreibers oder einer anderen Region.
6. Für ein Problem im Kanal: Prüfen Sie im Kundenkonto den Status der Hardware. Viele Anbieter haben eine Statusanzeige für das Modem. Roter oder gelber Status bedeutet, dass der Kanal wiederhergestellt wird, und Sie können nur warten oder auf einen Reservekanal wechseln.
7. Prüfen Sie die Last. Schauen Sie in Ihrer Software, wie viele gleichzeitige Streams über diesen Kanal laufen. Ein Mobilfunkkanal hat eine begrenzte Bandbreite, und bei Dutzenden parallelen Verbindungen beginnt der Proxy, einen Teil der Anfragen genau mit 502 abzulehnen. Reduzieren Sie die Parallelität um die Hälfte und wiederholen Sie den Test.
8. Prüfen Sie, ob es mit DNS zusammenhängt. Führen Sie eine Anfrage an die Website über die IP-Adresse statt über die Domain aus, wenn die Website das zulässt, oder wechseln Sie zum Schema socks5h, bei dem der Proxy die Namen auflöst, und vergleichen Sie das Ergebnis. Wenn über den Namen 502 kommt und über die IP alles funktioniert, liegt es an der Namensauflösung auf der Proxy-Seite; teilen Sie dem Anbieter den genauen Domainnamen mit.
9. Wenn nichts innerhalb von 15 Minuten geholfen hat, sammeln Sie die Ausgabe von curl -v, die Uhrzeit, den Kanalhost, die Zieldomain und senden Sie sie an den Support des Anbieters. Richtig gesammelte Informationen verkürzen die Lösung von einem Tag auf eine Stunde.

Tipp: Synchronisieren Sie bei Rotation nach Zeitplan die Pausen in Ihrer Software im Voraus mit dem Intervall des IP-Wechsels. Wenn die Adresse alle 5 Minuten wechselt, lassen Sie den Parser zu Beginn jeder Fünfminutenperiode 15 Sekunden pausieren. Die Zahl der 502 fällt fast auf null, ohne eine einzige Zeile komplexen Code.

Erwartetes Ergebnis

Sie wissen genau, zu welcher Kategorie Ihr 502 gehört: Moment der Rotation, bestimmte Richtung, Kanalüberlastung, Hardware-Ausfall oder Nichtverfügbarkeit der Website. Für die ersten drei haben Sie eine Korrektur, für die letzten beiden das Verständnis, worauf Sie warten und wem Sie schreiben müssen.

Mögliche Probleme

• 502 kommt nur bei großen Dateien. Die Website schließt die Verbindung wegen langsamer Auslieferungsgeschwindigkeit. Reduzieren Sie die Größe der angeforderten Daten oder verwenden Sie einen Kanal mit besserer Abdeckung.
• 502 kommt von der Website, nicht vom Proxy. Prüfen Sie die Header: Wenn dort der Server der Website steht und kein Proxy-Agent, ist das ein interner Fehler der Website; wiederholen Sie später.
• 502 wechselt ohne erkennbare Logik mit 200 ab. Klassisches Zeichen einer Kanalüberlastung. Reduzieren Sie die Parallelität bis zu einem stabilen Ergebnis.

Prüfung: Zehn aufeinanderfolgende Anfragen mit zwei Sekunden Pause über den problematischen Kanal an eine stabile Website liefern 200, oder Sie haben ein Ticket beim Support mit allen Daten in der Hand.

Schritt 4: Code 504 Gateway Timeout bearbeiten

Ziel dieses Schritts: Verstehen, an welchem Abschnitt hinter dem Proxy Zeit verloren geht, und den Anteil der 504 auf ein akzeptables Maß senken, ohne den Code mit einem Client-Netzwerk-Timeout zu verwechseln.

Was 504 vom Proxy genau bedeutet

Der Proxy-Server hat selbst ein internes Limit für das Warten auf eine Antwort der Website. Wenn die Website nicht innerhalb dieses Limits antwortet, beendet der Proxy das Warten und teilt Ihnen das ehrlich per Code 504 mit. Ihr Client hat die Verbindung dabei nicht abgebrochen, die Antwort ist angekommen. Deshalb ist es wichtig, dass das Wartezeitlimit in Ihrer Software größer ist als das Limit des Proxys: Sonst sehen Sie einen Netzwerk-Timeout ohne Code und können nicht verstehen, was passiert.

Anleitung

1. Prüfen Sie das Wartezeitlimit in Ihrer Software. In den meisten Programmen heißt es timeout, „Antwortzeit“ oder „Read timeout“. Wenn es kleiner als 30 Sekunden ist, stellen Sie es vorübergehend auf 60. Das ist ein Diagnoseschritt: Sie müssen den Code vom Proxy abwarten.
2. Messen Sie die Zeit bis zur Antwort über den Proxy. Führen Sie aus: curl -sS -o /dev/null -w "%{http_code} %{time_connect} %{time_starttransfer} %{time_total}" -x http://user1:pass1@proxy.example.net:8080 https://example.com/. Der Schalter -w gibt vier Zahlen aus: Code, Zeit bis zur Verbindung, Zeit bis zum ersten Byte und Gesamtzeit in Sekunden.
3. Führen Sie denselben Befehl ohne den Schalter -x aus. Vergleichen Sie die Zeit bis zum ersten Byte. Wenn die Website direkt in 0,4 Sekunden antwortet und über den Proxy in 8 Sekunden, ist die Verzögerung im Abschnitt „Proxy – Website“ groß, und 504 wird bei jeder Schwankung des Mobilfunknetzes auftreten.
4. Prüfen Sie, bei welcher Anfrage 504 auftritt. Machen Sie eine Anfrage mit der Methode HEAD, die den Seitentext nicht lädt: curl -I -x http://user1:pass1@proxy.example.net:8080 https://example.com/. Wenn HEAD durchläuft und GET der Seite 504 liefert, liegt das Problem in der Größe oder langsamen Generierung der Seite, nicht in der Verbindung als solcher.
5. Wechseln Sie die IP des Kanals über den Link im Kundenkonto. Das Mobilfunknetz ist heterogen: Eine Adresse kann auf eine überlastete Basisstation treffen, eine andere auf eine freie. Wiederholen Sie die Messung. Wenn die Zeit um ein Vielfaches gefallen ist, fügen Sie in Ihre Software die Regel ein: Bei 504 zuerst die IP wechseln, dann die Anfrage wiederholen.
6. Prüfen Sie die Schwere der Zielseite. Manche Websites liefern eine Antwort erst nach langen serverseitigen Operationen. Wenn Ihr Ziel bestimmte Daten sind, versuchen Sie, eine leichtere Adresse auf derselben Website anzusprechen: eine API, die mobile Version, eine Seite ohne Sortierparameter.
7. Wenn 504 nur bei einer bestimmten Domain und nur über Kanäle eines Betreibers auftritt, notieren Sie das im Log und verteilen Sie die Arbeit mit dieser Domain auf Kanäle eines anderen Betreibers.
8. Setzen Sie das Wartezeitlimit in Ihrer Software auf den Arbeitswert zurück, aber nun bewusst: Es sollte etwas größer sein als die typische Antwortzeit über den Proxy und kleiner, als Sie im Rahmen der Aufgabe warten möchten. Für die meisten Szenarien sind das 30–45 Sekunden.

Achtung: Stellen Sie das Wartezeitlimit in Ihrer Software nicht „zur Sicherheit“ auf mehrere Minuten und lassen Sie es nicht dauerhaft so. Ein hängender Stream blockiert einen Platz in der Warteschlange, und ein Dutzend hängender Streams erzeugt den Eindruck, der Proxy funktioniere nicht, obwohl das Problem in einer langsamen Website liegt.

Tipp: Fügen Sie dem Log Ihrer Software eine Spalte „Zeit bis zum ersten Byte“ hinzu. Daran sehen Sie, ob der Kanal allmählich degradiert oder abrupt einbricht. Ein allmählicher Anstieg bedeutet Überlastung oder schlechte Abdeckung, ein plötzlicher Einbruch weist eher auf Rotation oder einen Betreiberausfall hin.

Erwartetes Ergebnis

Sie kennen die typische Antwortzeit über jeden Kanal, haben das Limit in Ihrer Software über das Proxy-Limit gesetzt, und 504 sind zu einem seltenen Ereignis geworden, auf das eine automatische Reaktion eingerichtet ist.

Mögliche Probleme

• Sie haben das Limit erhöht und statt 504 nun einen Netzwerk-Timeout erhalten. Das bedeutet, der Proxy wartet länger als gedacht, oder die Verbindung zum Proxy selbst ist instabil. Das liegt außerhalb der Codes; sehen Sie sich verwandte Materialien zu Timeouts an.
• 504 nur zu bestimmten Stunden. Abendlicher Lastspitzen im Mobilfunknetz. Verlegen Sie schwere Aufgaben auf die Nacht oder den Morgen.
• 504 bei der ersten Anfrage an eine neue Website, danach alles schnell. Erstmalige Namensauflösung und Verbindungsaufbau auf der Proxy-Seite. Fügen Sie eine aufwärmende Anfrage vor der Hauptserie hinzu.

Prüfung: Eine Serie von zwanzig Anfragen an eine Arbeitswebsite zeigt eine Zeit bis zum ersten Byte in einem vorhersehbaren Bereich und höchstens ein bis zwei 504, und die Software wechselt bei 504 die IP und wiederholt die Anfrage.

Schritt 5: Fehler tunnel failed beheben

Ziel dieses Schritts: Lernen, die Zahl neben der Phrase tunnel failed zu lesen, sie mit der tatsächlichen Ursache zu verknüpfen und Einstellungen für Protokoll, Port und Proxy-Typ zu korrigieren.

Wie es aussieht und was es bedeutet

In curl sieht die Meldung so aus: „CONNECT tunnel failed, response 407“. In Browsern und Antidetect-Lösungen können es Phrasen wie „Proxy tunnel failed“, „Unable to establish tunnel“ oder „Tunnel connection failed“ sein. Gemeinsam ist eines: Der Client hat den CONNECT-Befehl gesendet, und der Proxy hat nicht mit 200 geantwortet. Die Zahl daneben ist genau der Code, und die Arbeit damit reduziert sich auf die vorherigen Schritte plus einige Sonderfälle, die nur in der Tunnelphase auftreten.

Anleitung

1. Starten Sie curl mit dem Schalter -v gegen eine HTTPS-Adresse und suchen Sie die Zeile mit tunnel failed. Notieren Sie die Zahl nach dem Wort response.
2. Wenn es 407 ist, kehren Sie zu Schritt 2 zurück. Der Unterschied liegt nur in einem Punkt: Stellen Sie sicher, dass die Software die Authentifizierung genau in der CONNECT-Phase überträgt. In älteren Versionen mancher Programme wirkt das Kontrollkästchen „Proxy-Authentifizierung“ nur auf HTTP-Anfragen, und der Tunnel geht ohne Passwort raus.
3. Wenn es 502 oder 504 ist, kehren Sie zu den Schritten 3 und 4 zurück. Der Proxy konnte keine Verbindung mit Port 443 der Website öffnen oder hat nicht darauf gewartet.
4. Wenn es 403 ist, hat der Proxy sich geweigert, einen Tunnel zum angegebenen Port oder Host zu öffnen. Prüfen Sie, mit welchem Port Sie sich verbinden. Mobile Proxys erlauben normalerweise Tunnel auf 443 und einige verbreitete Ports. Wenn Ihr Dienst auf einem nicht standardmäßigen Port lauscht, klären Sie im Kundenkonto oder beim Anbieter, ob er erlaubt ist.
5. Wenn es 400 ist, hat der Proxy den Befehl nicht verstanden. Die häufigste Ursache: Sie haben einen SOCKS5-Proxy als HTTP angegeben oder umgekehrt. Öffnen Sie das Kundenkonto und prüfen Sie, welches Protokoll und welcher Port vergeben sind. Bei vielen Anbietern haben HTTP und SOCKS5 unterschiedliche Ports desselben Kanals.
6. Korrigieren Sie das Schema im Befehl. Verwenden Sie für SOCKS5: curl -v -x socks5h://user1:pass1@proxy.example.net:1080 https://example.com/. Der Buchstabe h in socks5h bedeutet, dass der Proxy die Domainnamen auflöst, nicht Ihr Computer. Für mobile Proxys ist das die bevorzugte Variante.
7. Wenn Sie im Antidetect-Browser sind, öffnen Sie die Proxy-Einstellungen des Profils und suchen Sie die Auswahlliste für den Typ: HTTP, HTTPS, SOCKS5. Wählen Sie den im Kundenkonto angegebenen und prüfen Sie den Port. Starten Sie nach dem Speichern das Profil vollständig neu, nicht nur die Registerkarte aktualisieren.
8. Wenn neben tunnel failed keine Zahl steht, sondern nur die Phrase, aktivieren Sie in der Software die erweiterte Protokollierung oder reproduzieren Sie die Situation über curl, um den Code zu erhalten.
9. Prüfen Sie, ob Ihre Software versucht, eine TLS-Verbindung mit dem Proxy selbst aufzubauen. Manche Programme verschlüsseln bei Auswahl des Typs „HTTPS“ nicht nur den Datenverkehr zur Website, sondern auch die Verbindung zum Proxy. Wenn der Proxy das nicht unterstützt, erhalten Sie tunnel failed oder einen Handshake-Fehler. Wechseln Sie zum Typ „HTTP“ für die Verbindung zum Proxy: Der Datenverkehr zur Website bleibt trotzdem innerhalb des Tunnels verschlüsselt.
10. Wiederholen Sie den Test und stellen Sie sicher, dass CONNECT 200 erhält und die Seite lädt.

Tipp: Machen Sie zwei kurze Testanfragen zu einem Teil Ihrer täglichen Routine: eine an eine Adresse über HTTP, die zweite an dieselbe Adresse über HTTPS. Wenn die erste durchläuft und die zweite mit tunnel failed scheitert, wissen Sie in einer Sekunde, dass es am Tunnel liegt, nicht an der Authentifizierung oder am Kanal.

Erwartetes Ergebnis

Die Phrase tunnel failed ist aus den Logs verschwunden, für jeden Kanal sind der richtige Typ und Port notiert, und in der Software ist keine überflüssige Verschlüsselung der Proxy-Verbindung aktiviert.

Mögliche Probleme

• Der Tunnel wird aufgebaut, aber dann kommt ein Zertifikatsfehler. Das ist nicht mehr der Proxy-Layer: die Website oder Ihr System-Zertifikatsspeicher. Prüfen Sie Datum und Uhrzeit auf dem Computer.
• Funktioniert in curl, funktioniert nicht in der Software mit denselben Daten. Die Software verwendet ein anderes Schema oder fügt einen eigenen Präfix hinzu. Studieren Sie ihre Dokumentation zum Format der Proxy-Zeile.
• tunnel failed nur für eine Website. Die Website verwendet einen nicht standardmäßigen Port; kehren Sie zum Punkt über 403 zurück.

Prüfung: Eine HTTPS-Anfrage über curl und über die Arbeitssoftware liefert 200 auf CONNECT, Typ und Port für alle Kanäle sind in der Tabelle notiert.

Schritt 6: Die richtige Reaktion der Software auf jeden Code einrichten

Ziel dieses Schritts: Dass Proxy-Server-Fehler automatisch behandelt werden: Manche werden mit Pause wiederholt, andere lösen sofort einen Alarm aus, und Sie erhalten verständliche Logs statt eines Stroms roter Zeilen.

Prinzip: Nicht alle Fehler sind gleich

Eine Anfrage bei 407 zu wiederholen ist sinnlos: Das Passwort wird durch Wiederholung nicht richtig. Bei 502 im Moment der Rotation ist Wiederholen notwendig: In fünf Sekunden funktioniert alles. Bei 504 ist Wiederholen besser nach einem IP-Wechsel. Diese drei Regeln bilden die Grundlage einer gesunden Fehlerbehandlung.

Anleitung für fertige Software

1. Öffnen Sie die Einstellungen des Parsers oder Account-Managers und suchen Sie den Bereich für Wiederholungen. Er kann „Retries“, „Wiederholungsversuche“, „Fehlerbehandlung“ heißen.
2. Stellen Sie die Anzahl der Wiederholungen für 5xx auf 3 und die Anfangspause zwischen ihnen auf 5 Sekunden mit Verdopplung: 5, 10, 20 Sekunden. Dieses Wachstum der Pausen heißt exponentielle Verzögerung und verhindert, dass Ihre Software einen überlasteten Kanal zusätzlich belastet.
3. Wenn die Software eine Liste von Codes für die Wiederholung zulässt, geben Sie 502 und 504 an. Fügen Sie 407 nicht hinzu.
4. Suchen Sie die Einstellung für die Aktion bei 407. Wenn es keine gibt, setzen Sie die Anzahl der Wiederholungen im allgemeinen Bereich auf ein Minimum und aktivieren Sie Benachrichtigungen über fehlgeschlagene Anfragen. Ihr Ziel ist, 407 in den ersten Minuten zu sehen, nicht nach einem Tag Stillstand.
5. Suchen Sie das Feld für den Link zum IP-Wechsel, falls vorhanden. Fügen Sie dort den Link aus dem Kundenkonto für den entsprechenden Kanal ein und aktivieren Sie die Option „IP bei Fehler wechseln“ oder „Rotation bei Fehler“.
6. Begrenzen Sie die Anzahl gleichzeitiger Streams pro mobilem Kanal. Beginnen Sie mit 3–5 und erhöhen Sie, solange der Anteil der 502 unter einem Prozent bleibt.
7. Aktivieren Sie ein ausführliches Log mit Speicherung des Antwortcodes und der Header. Stellen Sie sicher, dass im Log der Unterschied zwischen dem Code vom Proxy und dem Code von der Website sichtbar ist: Viele Programme zeigen das in einer separaten Spalte „Proxy-Status“.
8. Speichern Sie die Einstellungen, starten Sie die Software neu und führen Sie eine Testserie von 50 Anfragen durch.

Anleitung für ein eigenes Skript

Wenn Sie Code schreiben, ist die Logik dieselbe. In Pseudocode mit Python und der Bibliothek requests sieht es so aus:

proxies = {"http": "socks5h://user1:pass1@proxy.example.net:1080", "https": "socks5h://user1:pass1@proxy.example.net:1080"} for attempt in range(3): r = session.get(url, proxies=proxies, timeout=45) if r.status_code == 407: alert("auth failed") break if r.status_code in (502, 504): rotate_ip() sleep(5 * 2 ** attempt) continue break

Achten Sie auf drei Punkte. Erstens: Bei 407 verlassen wir die Schleife sofort und senden eine Benachrichtigung. Zweitens: Bei 502 und 504 wechseln wir zuerst die IP, dann warten wir eine wachsende Pause. Drittens: Der Wert timeout ist so gewählt, dass wir den Code vom Proxy abwarten, statt die Verbindung früher abzubrechen.

Achtung: In manchen Bibliotheken kommt der Fehler in der CONNECT-Phase nicht als Antwort mit Code, sondern als Ausnahme mit Text, der tunnel failed und die Zahl enthält. Fangen Sie solche Ausnahmen separat ab und extrahieren Sie den Code aus dem Text, sonst funktioniert Ihre Wiederholungslogik nicht.

Tipp: Zählen Sie die Anteile der Codes pro Kanal über einen Tag und geben Sie sie in einer einfachen Tabelle aus. Ein Kanal, dessen 5xx stabil über denen der anderen liegt, sollte zuerst geprüft werden, auch wenn er formal funktioniert.

Erwartetes Ergebnis

Die Software wiederholt Anfragen bei 502 und 504 automatisch mit wachsender Pause und IP-Wechsel, meldet 407 sofort, begrenzt die Anzahl der Streams und führt ein Log mit Trennung der Codes von Proxy und Website.

Mögliche Probleme

• Die Software wiederholt auch 407, wodurch der Proxy die Adresse vorübergehend blockiert. Deaktivieren Sie Wiederholungen für 4xx vollständig oder reduzieren Sie die Gesamtzahl der Wiederholungen auf eine.
• Nach Aktivierung der Rotation bei Fehler ändert sich die IP zu oft. Führen Sie ein Mindestintervall zwischen Wechseln ein, z. B. 60 Sekunden, damit eine Serie von 502 nicht fünf Rotationen hintereinander auslöst.
• Das Log wächst auf Gigabytes. Schreiben Sie Header nur für Antworten mit Fehlercodes, für 200 speichern Sie eine Zeile.

Prüfung: Die Testserie von 50 Anfragen endete ohne manuellen Eingriff, im Log sind Wiederholungen mit Pausen von 5, 10, 20 Sekunden für 5xx sichtbar, und bei Eingabe eines falschen Passworts stoppte die Software und gab eine 407-Benachrichtigung aus.

Ergebnisprüfung: Checkliste und Tests

Gehen Sie die Liste durch und haken Sie jeden Punkt ab. Wenn auch nur einer nicht erfüllt ist, kehren Sie zum entsprechenden Schritt zurück.

Checkliste

• Der curl-Befehl mit dem Schalter -v wird ausgeführt, und Sie können in der Ausgabe die Antwortzeile auf CONNECT und die Dienst-Header des Proxys finden.
• Für jeden Kanal sind in der Tabelle Host, Port, Protokolltyp, Authentifizierungsmethode und das kodierte Passwort notiert.
• Bei Authentifizierung per IP stimmt die aktuelle Adresse Ihrer Maschine mit der im Kundenkonto überein.
• Eine HTTPS-Anfrage über jeden Kanal erhält 200 auf CONNECT.
• Die typische Zeit bis zum ersten Byte über jeden Kanal ist gemessen, und das Wartezeitlimit in der Software übersteigt sie mit Reserve.
• In der Software sind Wiederholungen nur für 502 und 504 eingerichtet, mit Pausen von 5, 10, 20 Sekunden und IP-Wechsel vor der Wiederholung.
• Bei 407 stoppt die Software und benachrichtigt.
• Die Anzahl der Streams pro Kanal ist begrenzt, und der Anteil der 5xx in der Testserie liegt unter einem Prozent.
• Das Incident-Log wird geführt und enthält mindestens einen vollständig analysierten Eintrag.

Wie man testet

1. Geben Sie absichtlich ein falsches Passwort ein und starten Sie eine Anfrage. Erwartet: 407 in curl und eine Benachrichtigung in der Software ohne Serie von Wiederholungen.
2. Geben Sie das richtige Passwort zurück und starten Sie 30 Anfragen an eine stabile Website mit einer Sekunde Pause. Erwartet: alle 200 oder höchstens ein 5xx mit erfolgreicher Wiederholung.
3. Drücken Sie während der Serie den Link zum IP-Wechsel im Kundenkonto. Erwartet: ein bis zwei 502 im Log, dann automatische Wiederholung und Fortsetzung der Serie.
4. Geben Sie in den Einstellungen den Typ SOCKS5 für einen Kanal an, der als HTTP ausgegeben wurde, und machen Sie eine Anfrage. Erwartet: tunnel failed oder ein Protokollfehler, den Sie in einer Sekunde erkennen. Stellen Sie den richtigen Typ wieder her.

Indikatoren für erfolgreiche Ausführung

Der Anteil der Proxy-Layer-Fehler in Arbeitsserien übersteigt ein bis zwei Prozent nicht, jeder Fehler ist nach Code klassifiziert, und keiner erfordert manuellen Eingriff außer 407. Die Reaktionszeit auf 407 liegt in Minuten, nicht in Stunden.

Typische Fehler und Lösungen

Problem: 407 nach jedem Router-Neustart

Ursache: Authentifizierung per IP, aber der Provider vergibt eine dynamische Adresse.

Lösung: Wechseln Sie zur Authentifizierung per Login und Passwort oder aktivieren Sie beide Methoden gleichzeitig. Wenn Sie unbedingt die IP benötigen, beantragen Sie beim Provider eine statische Adresse.

Problem: Passwort korrekt, aber 407 im Browser, während curl durchläuft

Ursache: Der Browser oder das Antidetect-Browser-Profil hat alte Daten im Cache.

Lösung: Speichern Sie den Proxy in den Einstellungen des konkreten Profils erneut und starten Sie das Profil neu; löschen Sie bei Bedarf die gespeicherten Passwörter für den Proxy-Host.

Problem: 502 genau alle N Minuten

Ursache: Fällt mit dem Intervall der automatischen IP-Rotation zusammen.

Lösung: Synchronisieren Sie die Pausen der Software mit dem Rotationsplan oder wechseln Sie zur IP-Änderung per Link zu günstigen Momenten zwischen den Aufgaben.

Problem: 502 bei vielen Streams, bei wenigen ist alles gut

Ursache: Überlastung des Mobilfunkkanals.

Lösung: Reduzieren Sie die Parallelität auf 3–5 Streams pro Kanal und verteilen Sie die Last auf mehrere Kanäle.

Problem: 504 nur auf einer Website, andere sind schnell

Ursache: Die Website generiert die Seite langsam oder beschränkt Adressen mobiler Betreiber.

Lösung: Verwenden Sie leichtere Adressen der Website, wechseln Sie die IP vor der Wiederholung, verlegen Sie bei anhaltendem Problem die Arbeit mit dieser Website auf einen Kanal eines anderen Betreibers.

Problem: Statt 504 kommt nun ein Abbruch ohne Code

Ursache: Das Wartezeitlimit in der Software ist kleiner als das interne Limit des Proxys.

Lösung: Erhöhen Sie das Limit in der Software auf einen Wert, bei dem Sie den Code noch erhalten, normalerweise 30–60 Sekunden.

Problem: tunnel failed, response 400

Ursache: Der SOCKS5-Port ist als HTTP-Proxy angegeben oder umgekehrt.

Lösung: Vergleichen Sie Typ und Port mit dem Kundenkonto; verwenden Sie für SOCKS5 das Schema socks5h, für HTTP das Schema http.

Problem: tunnel failed, response 403 auf einen nicht standardmäßigen Port

Ursache: Der Proxy erlaubt keine Tunnel auf diesen Port.

Lösung: Klären Sie die Liste der erlaubten Ports beim Anbieter und stellen Sie den Zieldienst nach Möglichkeit auf Port 443 um.

Problem: Code 502 oder 504 kommt mit einem Server-Header der Website

Ursache: Das ist die Antwort der Website selbst, nicht des Proxy-Layers: Die Website hat Probleme mit ihren eigenen internen Diensten.

Lösung: Warten Sie und wiederholen Sie später; ein Proxy-Wechsel hilft nicht.

Zusätzliche Möglichkeiten für fortgeschrittene Nutzer

Wenn die grundlegende Diagnose beherrscht wird, machen die folgenden Techniken die Arbeit mit Proxy-Layer-Fehlern nahezu automatisch.

Manuelle Übertragung des Autorisierungs-Headers

Manchmal ist es nützlich zu prüfen, wie der Proxy auf einen bestimmten Header reagiert. Kodieren Sie das Paar Login:Passwort mit einem lokalen Werkzeug in Base64 und übergeben Sie den Header selbst: curl -v -x proxy.example.net:8080 -H "Proxy-Authorization: Basic dXNlcjE6cGFzczE=" http://example.com/. Diese Methode funktioniert für normale HTTP-Anfragen und hilft zu verstehen, ob der Proxy die Daten überhaupt akzeptiert, unabhängig davon, wie Ihre Software sie bildet. Verwenden Sie für CONNECT den Schalter --proxy-header statt -H.

Namensauflösung auf der Proxy-Seite

Das Schema socks5h und der HTTP-Tunnel übergeben den Domainnamen an den Proxy-Server, statt ihn lokal aufzulösen. Das bietet zwei Vorteile: Die Website sieht eine Anfrage, die vollständig aus dem Mobilfunknetz kommt, und Sie vermeiden Abweichungen, wenn Ihr lokaler DNS eine Adresse liefert und das Betreibernetz eine andere. Wenn Sie 502 nur bei lokaler Auflösung sehen, löst der Wechsel zu socks5h das Problem oft ohne Kontakt zum Anbieter.

Automatisierung über die API des Anbieters

mobileproxy.space bietet eine programmatische Schnittstelle zum IP-Wechsel und zum Abrufen des Kanalstatus. Bauen Sie den Aufruf des IP-Wechsels in den 504-Handler ein und die Statusprüfung des Kanals in den Handler für anhaltende 502. Dann entscheidet das Skript selbst, ob es die Anfrage über denselben Kanal wiederholt oder auf einen Reservekanal wechselt. Ein einfacher Algorithmus: Drei 502 hintereinander in einer Minute – Status abfragen, wenn der Kanal in Ordnung ist, IP wechseln, wenn nicht – den Kanal für fünf Minuten als nicht verfügbar markieren und zum nächsten wechseln.

Trennung der Metriken von Proxy und Website

Legen Sie im Monitoring-System zwei getrennte Metriken an: Codes, die mit Proxy-Headern kamen, und Codes, die ohne sie kamen. Die erste Metrik spricht für die Gesundheit Ihrer Proxy-Infrastruktur, die zweite für das Verhalten der Zielseiten. Solange sie vermischt sind, suchen Sie einen Proxy-Server-Fehler dort, wo keiner ist, und umgekehrt.

Kanalpool mit Gewichten

Weisen Sie jedem Kanal ein Gewicht zu, das bei jedem 5xx sinkt und sich mit der Zeit langsam erholt. Verteilen Sie die Anfragen proportional zu den Gewichten. Dieser Ansatz verlagert die Last automatisch von einem problematischen Betreiber oder einer Region weg und bringt sie zurück, wenn der Kanal sich erholt, ohne einen einzigen manuellen Wechsel.

HAR-Export aus dem Browser

Für komplexe Fälle öffnen Sie im Antidetect-Browser den Tab Netzwerk, reproduzieren den Fehler und wählen „Save all as HAR“. Die Datei enthält alle Anfrage- und Antwort-Header, einschließlich Phasen, die im normalen Programm-Log nicht sichtbar sind. Entfernen Sie vor dem Senden an den Support aus der Datei die Werte von Proxy-Authorization und Cookies.

Optimierung der Wartezeitlimits

Sammeln Sie eine Woche lang Statistiken über die Zeit bis zum ersten Byte pro Kanal und Richtung. Setzen Sie das Wartezeitlimit in der Software auf den 95. Perzentilwert plus 10 Sekunden. Ein solches Limit bricht selten lebende Anfragen ab und gibt gleichzeitig Streams bei echten Hängern schnell frei.

FAQ: Häufige Fragen zur Diagnose

Wie erkenne ich, ob 502 vom Proxy oder von der Website kam?

Schauen Sie sich die Antwort-Header an. Wenn Proxy-Agent, Via oder andere Dienst-Header des Proxys vorhanden sind und kein Set-Cookie und Server der Website, ist die Antwort vom Proxy. Zusätzlich: Wenn der Code direkt als Antwort auf CONNECT kam, ist es definitiv der Proxy.

Sollte man die Anfrage bei 407 wiederholen?

Nein. Die Anmeldedaten werden durch Wiederholung nicht richtig, und eine Reihe fehlgeschlagener Versuche kann zu einer vorübergehenden Blockierung Ihrer Adresse auf der Proxy-Seite führen. Korrigieren Sie die Daten und wiederholen Sie einmal.

Warum funktioniert alles in curl, aber nicht in meiner Software?

Meist bildet die Software die Proxy-Zeile anders, kodiert Sonderzeichen im Passwort nicht, verwendet einen anderen Protokolltyp oder überträgt die Authentifizierung nicht bei CONNECT. Vergleichen Sie die genaue Zeile aus den Software-Einstellungen zeichenweise mit dem funktionierenden curl-Befehl.

Wie gibt man ein Passwort mit Sonderzeichen richtig ein?

Kodieren Sie in der Adresszeile: @ als %40, : als %3A, # als %23, % als %25, Leerzeichen als %20. In separaten Login- und Passwortfeldern geben Sie das Passwort ohne Kodierung ein.

Worin unterscheidet sich 504 von einem Timeout, über den in anderen Artikeln geschrieben wird?

504 ist ein Code, den der Proxy selbst zurückgegeben hat, nachdem er sein eigenes Wartezeitlimit für die Website abgewartet hat. Ein Timeout ohne Code bedeutet, dass Ihr Client die Verbindung abgebrochen hat, ohne etwas zu erhalten. Sie werden unterschiedlich behandelt, deshalb sind sie in verschiedenen Materialien aufgeführt.

Wie viele Streams kann man über einen mobilen Kanal laufen lassen?

Es gibt keine universelle Zahl. Beginnen Sie mit 3–5 und erhöhen Sie, solange der Anteil der 502 unter einem Prozent bleibt. Für schwere Seiten ist die Zahl kleiner, für leichte API-Anfragen größer.

Muss man bei jedem Fehler die IP wechseln?

Bei 504 und anhaltenden 502 – ja, das ist die erste Aktion. Bei 407 – nein, ein IP-Wechsel beeinflusst die Authentifizierung nicht. Führen Sie ein Mindestintervall zwischen Wechseln ein, damit eine Fehlerserie keine Lawine von Rotationen auslöst.

Was sollte man an den Support senden, um das Problem schneller zu lösen?

Die vollständige Ausgabe von curl -v mit durch Sternchen ersetztem Passwort, die genaue Uhrzeit mit Sekunden und Zeitzone, Host und Port des Kanals, die Zieldomain, den Authentifizierungstyp und das Ergebnis einer direkten Anfrage ohne Proxy. Mit diesem Paket antwortet der Support normalerweise schon in der ersten Nachricht.

Kann man HTTPS für die Verbindung zum Proxy selbst verwenden?

Nur wenn der Anbieter das ausdrücklich unterstützt. In den meisten Fällen läuft die Verbindung zum Proxy bei mobilen Proxys über normales HTTP oder SOCKS5, und die Verschlüsselung des Datenverkehrs zur Website übernimmt der Tunnel. Das Einschalten zusätzlicher Verschlüsselung zum Proxy führt zu tunnel failed oder einem Handshake-Fehler.

Fazit

Sie haben den Weg von einer unverständlichen roten Zeile im Log zu einem vollständigen Diagnosesystem zurückgelegt. Jetzt können Sie feststellen, wer genau geantwortet hat, lesen 407 als Signal, die Anmeldedaten und die Authentifizierungsmethode zu prüfen, 502 als Zeichen eines Fehlers hinter dem Proxy oder im Moment der Rotation, 504 als ehrlichen Bericht des Proxys über eine langsame Website und tunnel failed als Hülle um einen dieser Codes mit einem Hinweis in Form einer Zahl. Ihre Software wiederholt nicht mehr sinnlos und gibt bei einem vorübergehenden Problem nicht auf.

Was als Nächstes zu tun ist

1. Führen Sie mindestens einen Monat lang ein Incident-Log. Schon nach zwei Wochen werden Sie wiederkehrende Muster bemerken und ihre Ursachen beseitigen.
2. Überprüfen Sie wöchentlich die Anteile der Codes pro Kanal und verteilen Sie die Last neu.
3. Automatisieren Sie den IP-Wechsel und die Statusprüfung über die API des Anbieters, damit routinehafte 5xx ohne Sie gelöst werden.
4. Studieren Sie die verwandten Blogmaterialien zu Netzwerk-Timeouts und zum Verhalten von Zielseiten, um die verbleibenden zwei Abschnitte des Anfragewegs abzudecken.

Wohin man sich entwickeln kann

Die nächste Stufe ist der Aufbau eines eigenen Kanalpools mit Gewichten und Monitoring, in dem ein Proxy-Server-Fehler kein Grund zur Panik mehr ist, sondern ein Punkt im Diagramm, den das System selbst verarbeitet. Alle Werkzeuge dafür haben Sie bereits: das Verständnis der Codes, curl, das Kundenkonto des Anbieters und die Gewohnheit, alles aufzuschreiben. Gute Arbeit und stabile 200.