Der Zugang zu einem kostenpflichtigen Proxy-Dienst wird auf eine von zwei Arten freigeschaltet: Entweder senden Sie bei jeder Anfrage Benutzername und Passwort , oder Sie hinterlegen Ihre öffentliche IP-Adresse im Panel des Anbieters und erstellen eine Whitelist (Liste erlaubter Adressen). Beide lösen dasselbe Problem – „stammt diese Verbindung wirklich vom Abonnenten?" – haben im Alltag aber sehr unterschiedliche Folgen.
In diesem Beitrag behandeln wir, wie beide Verfahren auf Protokollebene funktionieren, welches in welchem Szenario das richtige ist und welchen Fehlercodes Sie begegnen werden.
Methode 1: Benutzername und Passwort
Bei diesem Verfahren werden die Anmeldedaten bei jeder Verbindung an den Proxy gesendet. Das Format hängt vom Protokoll ab:
- HTTP-Proxy:
Proxy-Authorization: Basic <base64(kullanici:sifre)>Header wird hinzugefügt. - SOCKS5: Es erfolgt die in RFC 1929 definierte Username/Password-Unteraushandlung; Benutzername und Passwort werden in binärer Form gesendet.
Auf HTTP-Seite läuft es so ab: Der Client sendet die Anfrage ohne Anmeldedaten, der Proxy 407 Proxy Authentication Required antwortet damit, der Client ergänzt die Anmeldedaten und wiederholt die Anfrage.
Die meisten Clients erledigen diese zwei Runden automatisch. curl und Browser ergänzen bei einem 407 die Anmeldedaten und wiederholen die Anfrage; einfache HTTP-Bibliotheken versuchen es dagegen manchmal nicht erneut und melden direkt einen Fehler.
Basic Das Verfahren verschlüsseltdie Anmeldedaten nicht, es kodiert sie lediglich mit Base64. Base64 ist eine umkehrbare Kodierung. Deshalb hängt die Vertraulichkeit der Anmeldedaten davon ab, dass die Verbindung zum Proxy selbst sicher ist.
Methode 2: IP-Whitelist
Im Whitelist-Modell gibt es kein Passwort. Sie tragen Ihre eigene öffentliche IP-Adresse im Panel des Anbieters ein; der Proxy akzeptiert dann nur Verbindungen von dieser Adresse. Da keine Anmeldedaten übertragen werden, wird die Client-Seite sehr einfach: curl -x http://proxy.example.com:8080 https://example.com .
Die entscheidende Frage bei diesem Modell lautet: Ist Ihre öffentliche IP-Adresse statisch? Bei den meisten Heimanschlüssen ist die IP dynamisch und ändert sich beim Neustart des Routers. Ändert sie sich, wird die Whitelist ungültig und alle Verbindungen werden abgelehnt.
Die Entscheidung läuft weitgehend auf die Frage hinaus: „Haben Sie eine statische IP?" Für Automatisierungen auf einem Server eignet sich die Whitelist, für mobile Nutzung Benutzername/Passwort.
Welches Verfahren in welchem Szenario?
Scraper oder Bot auf einem Server
Die IP Ihres VPS ist statisch; wählen Sie die Whitelist. Anmeldedaten werden nicht in den Code oder in Umgebungsvariablen eingebettet, die Angriffsfläche für Lecks schrumpft. Automatisierungsszenarien ist dies unsere empfohlene Voreinstellung.
Manuelle Nutzung vom Laptop
Wenn Sie zwischen Büro, Zuhause und Café wechseln, ändert sich die IP ständig. Nutzen Sie Benutzername/Passwort; das funktioniert aus jedem Netzwerk problemlos.
Gemeinsame Nutzung im Team
Wenn Sie wissen müssen, wer wie viel Traffic verbraucht hat, legen Sie pro Person ein eigenes Benutzerkonto an. Bei der Whitelist erscheint das gesamte Team unter einer einzigen Identität.
Mehrere Profile mit einem Antidetect-Browser
Wenn jedem Profil eine andere Ausgangs-IP zugewiesen werden soll, ist Benutzername/Passwort zwingend; denn die Session-Auswahl wird meist im Benutzernamen kodiert (etwa user-session-a1).
Einbettung der Session-Information in den Benutzernamen
In Residential-Pools gibt es ein verbreitetes Muster: Der Benutzername ist nicht nur eine Identität, sondern trägt zugleich einen Befehl . Zum Beispiel:
Das Trennzeichen und die Parameternamen unterscheiden sich von Anbieter zu Anbieter. Maßgeblich ist die Dokumentation in Ihrem Panel; das Format hier dient nur der Veranschaulichung der Struktur.
Der Vorteil dieses Designs ist, dass clientseitig kein einziger API-Aufruf nötig ist: Sie wechseln Land oder Session, indem Sie den Benutzernamen ändern. Der Nachteil ist, dass die Anmeldedaten länger werden und Tippfehler zu stillen Verhaltensänderungen führen. Die Logik von Rotating Proxys behandeln wir in unserem Beitrag ausführlich, ebenso die Auswirkungen dieses Modells auf die Session-Verwaltung.
Häufige Fehler
Der Unterschied zwischen 407 und 403 ist entscheidend: 407 heißt „weise dich aus", 403 dagegen „ich habe deine Identität gesehen, du hast keine Berechtigung".
Die Sonderzeichen-Falle
Wenn Sie die Anmeldedaten im URL-Format schreiben, geraten manche Zeichen im Passwort mit dem Trennzeichen durcheinander. http://user:p@ss@ip:8080 In diesem Ausdruck wird das zweite @ für das Trennzeichen gehalten und die Verbindung kommt nicht zustande. Die Lösung ist die Prozentkodierung:
| Zeichen | Kodierte Form | Zeichen | Kodierte Form |
|---|---|---|---|
@ | %40 | / | %2F |
: | %3A | # | %23 |
? | %3F | % | %25 |
Ein robusterer Ansatz ist, die Anmeldedaten nicht in die URL einzubetten, sondern sie den dafür vorgesehenen Feldern des Clients zu übergeben. Python requests, Node undici und die Option von curl --proxy-user unterstützen dies.
Die Anmeldedaten aus einer Umgebungsvariablen zu lesen statt sie in den Code einzubetten, verhindert ein Durchsickern in die Versionskontrolle und erleichtert zugleich die Rotation.
Was ändert sich aus Sicherheitssicht?
Beide Verfahren bergen unterschiedliche Risiken. Im Modell Benutzername/Passwort kann das Geheimnis gestohlen werden: Eine in eine Logdatei geratene Befehlszeile, eine in die Versionskontrolle gerutschte Konfigurationsdatei oder ein Screenshot genügen. Im Whitelist-Modell gibt es kein Geheimnis, dafür besteht das Risiko der IP-Teilung : Jeder im selben Büronetzwerk kann Ihren Proxy unwissentlich mitbenutzen.
Die robusteste Konfiguration ist die Kombination beider: Grenzen Sie die Quelle per Whitelist ein und ergänzen Sie zusätzlich Benutzername/Passwort. Die meisten Unternehmensanbieter unterstützen dieses Hybridmodell. Wenn Sie beim Thema Datenschutz wissen möchten, was der Proxy sieht, Ist ein Proxy sicher bietet unser Beitrag einen umfassenden Rahmen; für Lecktests DNS Leak und WebRTC Leak können Sie unsere Tools nutzen.
Praktische Regeln für die Verwaltung von Anmeldedaten
- Nutzen Sie Umgebungsvariablenund schreiben Sie die Daten nicht in den Code.
- Legen Sie für jede Umgebung eigene Anmeldedaten an: Entwicklung, Test und Produktion sollten nicht dasselbe Passwort teilen.
- Definieren Sie Kontingente und Limits; durchgesickerte Anmeldedaten sollen keinen unbegrenzten Traffic verbrauchen.
- Rotieren Sie regelmäßig; wechseln Sie die Daten unbedingt, wenn jemand das Team verlässt.
- Maskieren Sie sie in den Logs; die Debug-Ausgabe soll das Passwort nicht im Klartext schreiben.
Zusammenfassung
Die IP-Whitelist ist auf Servern mit statischer IP die sauberste Lösung mit dem geringsten Leckrisiko. Benutzername und Passwort wiederum sind bei mobiler Nutzung und in Szenarien mit mehreren Sessions unverzichtbar. Für die Entscheidung genügt es, die Fragen „Ist meine IP statisch?", „Wie viele Personen werden sie nutzen?" und „Muss ich Session-Parameter senden?" zu beantworten. Zum Testen Ihrer Konfiguration können Sie Ob ein Datacenter-Proxy ausreicht, haengt vom Schutzniveau des Ziels ab — und das laesst sich messen. Nehmen Sie die direkte Verbindung als Referenz und testen Sie vergleichend mit derselben Rate; waehlen Sie die Stufe anhand der Erfolgsquote. Eine Logik zur gestuften Hochstufung aufzubauen und pro Ziel Statistiken zu sammeln, minimiert sowohl die Kosten als auch den Geschwindigkeitsverlust. Zum Einstieg koennen Sie nutzen und Ihre Ausgangs-IP mit Meine IP-Adresse verifizieren.