Residential-Proxy-Authentifizierung: 407- und Anmeldedatenfehler beheben

Jede Anfrage liefert 407 Proxy Authentication Required, nichts erreicht das Ziel, und die Zugangsdaten sehen im Panel korrekt aus. Es ist eines der häufigsten Support-Tickets in dieser Produktkategorie und zugleich eines der am schnellsten zu lösenden, weil die Anzahl der Dinge, die einen 407 verursachen können, klein ist und sie sich in einer festen Reihenfolge ausschließen lassen.

Hier ist, was der Statuscode tatsächlich bedeutet, welche Ursachen es sich zu prüfen lohnt, in welcher Reihenfolge man sie prüfen sollte, und welche client-spezifischen Fehler einen 407 erzeugen, selbst wenn die Zugangsdaten korrekt sind.

Was ein 407 tatsächlich ist

Ein 407 kommt vom Proxy, nicht von der Seite, die Sie erreichen wollen. Es ist die Art des Proxys zu sagen, dass die Anfrage ohne akzeptable Zugangsdaten angekommen ist, und es ist das Äquivalent zu einem 401 von einem Ursprungsserver, nur auf Proxy-Ebene. Diese Unterscheidung ist wichtig für die Fehlersuche: Ein 407 bedeutet, dass Ihr Traffic das Gateway erreicht hat und das Gateway ihn abgelehnt hat. Die Konnektivität ist in Ordnung. Die Authentifizierung nicht.

Es bedeutet auch, dass die Zielseite überhaupt nicht beteiligt ist. Wenn Sie 407er erhalten, wird nichts, was Sie an Headern, User Agents, Rendering oder Timing ändern, helfen, weil Ihre Anfrage den Proxy nie verlassen hat.

Die drei Ursachen, die man zuerst prüfen sollte

Bei einem Gateway, bei dem das Targeting im Benutzernamen ausgedrückt wird, ist fast jeder 407 eine von drei Sachen.

Die Zugangsdaten sind falsch. Ein Tippfehler, ein versehentliches Leerzeichen, das aus einem Dashboard kopiert wurde, oder Zugangsdaten aus einem anderen Produkt. Proxy-Zugangsdaten sind normalerweise nicht dieselben wie Ihr Account-Login, was eine überraschend häufige Verwechslung ist.

Ein Flag im erweiterten Benutzernamen ist fehlerhaft formatiert. Das ist die Ursache, die man übersieht, und sie ist spezifisch für Gateways, die Targeting im Benutzernamen kodieren. Wenn Ihr Benutzername Flags für Land, Stadt, Session oder TTL trägt, macht ein nicht erkannter Wert den gesamten Benutzernamen unparsbar, und das Gateway lehnt ihn als Authentifizierungsfehler ab statt als Targeting-Fehler. Ein falsch geschriebener Ländercode, ein Stadt-Slug im falschen Format, eine Session-ID mit unzulässigen Zeichen oder ein ttl ohne begleitendes sid landen alle hier. Die Zugangsdaten sind einwandfrei; der Benutzername-String ist es nicht.

Das Passwort wurde geändert. Wenn jemand es im Panel neu generiert hat, liefert jeder Client, der noch den alten Wert hat, einen 407, bis er aktualisiert wird. Das ist der klassische Fall, bei dem es auf einer Maschine funktioniert und auf einer anderen fehlschlägt.

Die Diagnosereihenfolge

Arbeiten Sie diese Liste von oben nach unten ab und stoppen Sie, wenn es funktioniert, denn der Schritt, der das Problem behebt, identifiziert die Ursache.

Eins: Alle Flags entfernen und die bloßen Zugangsdaten testen. Dieser eine Schritt trennt ein Zugangsdatenproblem von einem Flag-Problem und sollte immer zuerst durchgeführt werden.

# bare username, no targeting flags at all
curl -x customer-USERNAME:PASSWORD@p.shifter.io:443 https://ipinfo.io/json

Wenn das funktioniert, sind Ihre Zugangsdaten in Ordnung und der Fehler liegt bei den Flags. Wenn es weiterhin 407 zurückgibt, sind die Zugangsdaten selbst falsch, und keine Menge an Flag-Korrekturen wird helfen.

Zwei: Flags einzeln wieder hinzufügen. Zuerst Land, dann Stadt oder ASN, dann Session und TTL. Das Flag, das den 407 wieder einführt, ist das fehlerhafte, und Sie wissen jetzt genau, welchen Wert Sie prüfen müssen.

curl -x customer-USERNAME-country-us:PASSWORD@p.shifter.io:443 https://ipinfo.io/json
curl -x customer-USERNAME-country-us-city-new_york:PASSWORD@p.shifter.io:443 https://ipinfo.io/json
curl -x customer-USERNAME-country-us-city-new_york-sid-abc123:PASSWORD@p.shifter.io:443 https://ipinfo.io/json

Achten Sie auf die Formate: Ländercodes sind zweistellige ISO-Codes, sodass uk ein häufiger Fehler ist, bei dem gb korrekt wäre. Stadt-Slugs verwenden Unterstriche statt Leerzeichen oder Bindestriche, wie in new_york. Und ttl ist nur gültig zusammen mit sid, sodass ein TTL allein ungültig ist. Die vollständige Syntax finden Sie in den Gateway- und Authentifizierungsdokumenten, und die Targeting-Optionen werden behandelt in City-Level-Targeting und ASN-Targeting.

Drei: Das Passwort erneut aus dem Panel kopieren. Wenn die bloßen Zugangsdaten bei Schritt eins fehlgeschlagen sind, nehmen Sie das Passwort direkt aus dem Panel statt aus Ihren Notizen oder einer Konfigurationsdatei, und prüfen Sie speziell auf ein nachgestelltes Leerzeichen, ein typografisches Anführungszeichen aus einem Dokument oder eine abgeschnittene Einfügung.

Vier: Den Wert überall ausrollen. Wenn es lokal funktioniert, aber nicht in der Produktion, haben Sie eine veraltete Kopie in einer Umgebungsvariable, einem Secrets-Manager, einem Container-Image oder einer CI-Konfiguration. Das ist ein Deployment-Problem, kein Proxy-Problem.

Fehler, die wie ein 407 aussehen, es aber nicht sind

Diese zu unterscheiden erspart viel vergebliche Mühe, weil jeder eine andere Lösung hat.

Ein 502 bei diesem Gateway bedeutet, dass zu diesem Zeitpunkt keine Adressen Ihrem Filter entsprachen. Das ist ein Targeting-Problem, kein Auth-Problem: Ihre Zugangsdaten wurden akzeptiert, und dann war für die angeforderte Kombination nichts verfügbar. Erweitern Sie den Filter, gehen Sie von Stadt zu Land über, oder lockern Sie ein streng passendes Flag.

Ein 509 bedeutet, dass das Plan-Bandwidth-Kontingent erschöpft ist und Overage deaktiviert ist. Die Authentifizierung war erfolgreich; Ihnen fehlt Kontingent. Entsprechende Hinweise zur Dimensionierung finden Sie unter monatliche Bandbreite schätzen.

Connection refused bedeutet, dass Sie das Gateway nie erreicht haben, meist weil Sie auf einen veralteten portbasierten Host zeigen statt auf den aktuellen Endpunkt, oder weil der Egress aus Ihrem Netzwerk blockiert ist. Testen Sie die reine Konnektivität mit nc -vz p.shifter.io 443, bevor Sie ein Auth-Problem annehmen.

Ein 403 oder eine Challenge-Seite vom Ziel bedeutet, dass die Authentifizierung einwandfrei funktioniert hat und die Seite Sie abgelehnt hat, was ein völlig anderes Problem ist, das unter Blockierungen vermeiden behandelt wird.

Client-spezifische Fehler, die einen 407 erzeugen

Manchmal sind sowohl die Zugangsdaten als auch die Flags korrekt, und der Client ist schuld.

Sonderzeichen im Passwort. Wenn das Passwort Zeichen enthält, die in einer URL eine Bedeutung haben, @, :, #, / oder %, dann bricht das direkte Einbetten in eine Proxy-URL das Parsing, und die Zugangsdaten kommen verstümmelt an. Kodieren Sie es percent-encoded.

import requests
from urllib.parse import quote

user = "customer-USERNAME-country-us"
pwd  = quote("p@ss:word/123", safe="")      # encode before embedding
PROXY = f"http://{user}:{pwd}@p.shifter.io:443"

r = requests.get("https://ipinfo.io/json",
                 proxies={"http": PROXY, "https": PROXY}, timeout=15)
print(r.status_code, r.text[:120])

Proxy-Auth mit Ziel-Auth verwechseln. curl -U setzt Proxy-Zugangsdaten; -u setzt Zugangsdaten für die Zielseite. Das Senden Ihrer Proxy-Zugangsdaten als Authorization-Header bewirkt nichts, weil Proxy-Auth im Proxy-Authorization-Header übertragen wird, und die meisten Clients setzen diesen automatisch, wenn die Zugangsdaten in der Proxy-URL enthalten sind.

Zugangsdaten fallen bei HTTPS weg. Einige Client-Konfigurationen setzen den Proxy nur für HTTP, sodass einfache Anfragen authentifizieren und HTTPS-Anfragen nicht. Setzen Sie beide Einträge, wie im Python-Beispiel oben.

Umgebungsvariablen, die nicht das sind, was Sie denken. HTTP_PROXY und HTTPS_PROXY, die in einem Shell-Profil, einem Dockerfile oder einem CI-Runner gesetzt sind, können das, was Ihr Code übergibt, unbemerkt überschreiben, sodass eine Anwendung sich gegen einen völlig anderen Proxy-String authentifiziert als den in Ihrem Quellcode. Geben Sie beim Debuggen die effektive Proxy-Konfiguration aus, statt dem Code zu vertrauen.

Eine Bibliothek, die keine präventive Proxy-Auth sendet. Ein paar HTTP-Clients warten darauf, herausgefordert zu werden, bevor sie Zugangsdaten senden, und handhaben die Challenge fehlerhaft, insbesondere bei bestimmten Tunneling-Setups. Wenn ein bloßes curl funktioniert und Ihre Anwendung nicht, liegt der Unterschied beim Client, nicht beim Gateway. Die funktionierenden Konfigurationen für gängige Stacks finden Sie unter Residential-Proxies mit Python verwenden.

Umgang mit 407 im Produktionscode

Ein betrieblicher Hinweis: Ein 407 ist ein endgültiger Fehler, kein vorübergehender. Ihn erneut zu versuchen ist sinnlos, weil die Zugangsdaten beim nächsten Versuch genauso falsch sein werden, und eine Retry-Schleife gegen einen Auth-Fehler verbrennt nur Bandbreite und kann von außen wie ein Credential-Stuffing-Muster aussehen. Klassifizieren Sie ihn als endgültig, schlagen Sie laut Alarm, und benachrichtigen Sie, was die Klassifizierungsdisziplin in Retry und Backoff ist.

Das Rotieren von Zugangsdaten verdient einen Deployment-Plan statt eines Panel-Klicks, da jeder Client, der den alten Wert hält, im Moment der Rotation zu scheitern beginnt. Aktualisieren Sie zuerst den Secret-Store, rollen Sie die Clients aus, und rotieren Sie dann.

Fazit

Ein 407 bedeutet, dass Ihre Anfrage das Gateway erreicht hat und das Gateway die Zugangsdaten abgelehnt hat, sodass die Zielseite irrelevant ist und die Konnektivität nachgewiesen ist. Testen Sie zuerst die bloßen Zugangsdaten ohne Flags, denn dieser eine Schritt teilt das Problem in zwei Hälften, fügen Sie dann Flags einzeln wieder hinzu, um das fehlerhafte zu finden, und denken Sie daran, dass ein falscher Ländercode oder eine TTL ohne Session den gesamten Benutzernamen unparsbar macht. Kopieren Sie das Passwort erneut aus dem Panel, wenn der bloße Test fehlgeschlagen ist, und prüfen Sie auf veraltete Werte in Umgebungsvariablen und Secret-Stores, wenn es an einem Ort funktioniert und an einem anderen nicht. Schließen Sie die Doppelgänger aus: 502 ist ein leerer Filter, 509 ist Bandbreite, Connection refused ist der falsche Host, und ein 403 von der Seite ist überhaupt kein Auth-Problem. Und versuchen Sie einen 407 niemals erneut.

Die vollständige Syntaxreferenz finden Sie in den Gateway- und Authentifizierungsdokumenten, und das Produkt selbst ist Residential Proxies, wo dieselben Zugangsdaten über jedes Land, jede Stadt und jeden Session-Modus hinweg funktionieren, mit Pro-GB-Preisgestaltung.