--- title: "Proxy-Authentifizierung: User:Pass oder IP-Whitelist" description: "Mit einem Proxy verbinden Sie sich per Benutzername und Passwort oder über erlaubte IPs. Wir vergleichen die Sicherheit, den Fehler 407 und die Wahl." url: https://proxynet.io/de/blog/proxy-authentication-methods date: 2026-09-13 author: "Acar Diveroli" category: "Proxy 101, Anleitungen" lang: de --- # Proxy-Authentifizierung: User:Pass oder IP-Whitelist Wenn Sie einen Proxy kaufen, erhalten Sie eine Adresse und einen Port. Würde der Proxy den Verkehr jedes Nutzers weiterleiten, der sich mit dieser Adresse verbindet, würden andere ihn mitbenutzen. Deshalb prüft jeder kostenpflichtige Proxy, **wer sich verbindet**, bevor er die Verbindung annimmt. Dafür gibt es zwei gängige Wege: Benutzername und Passwort (user:pass) oder eine Liste erlaubter IP-Adressen (IP-Whitelist). In diesem Artikel erklären wir, wie beide Methoden im Hintergrund funktionieren, welche in welcher Situation sicherer und praktischer ist und wie Sie sich mit jeder Methode in cURL, Python und im Browser verbinden. Außerdem betrachten wir die Ursachen des Fehlers `407 Proxy Authentication Required`, der einen großen Teil der Supportanfragen ausmacht, sowie das Problem, das eine dynamische IP-Adresse für die Whitelist verursacht. > **Hinweis: Kurze Antwort** > > Die Authentifizierung mit Benutzername und Passwort funktioniert auf jedem Gerät und in jedem Netz; die Zugangsdaten werden bei jeder Anfrage im Header `Proxy-Authorization` gesendet. Bei einer IP-Whitelist gibt es kein Passwort: Der Proxy nimmt nur Verbindungen von den IP-Adressen an, die Sie in die Liste eingetragen haben. Arbeiten Sie von einem Server mit fester IP-Adresse, ist die Whitelist praktischer; verbinden Sie sich aus verschiedenen Netzen und von verschiedenen Geräten, sind Benutzername und Passwort praktischer. ## Was ist Proxy-Authentifizierung? Bei der Proxy-Authentifizierung prüft der Proxy-Server, ob eine Verbindung zu einem berechtigten Nutzer gehört, bevor er sie weiterleitet. Schlägt die Prüfung fehl, leitet der Proxy die Anfrage nicht an das Ziel weiter. Die beiden Methoden beantworten unterschiedliche Fragen: - **Benutzername und Passwort:** „Kennt der Absender dieser Anfrage die richtigen Zugangsdaten?" - **IP-Whitelist:** „Kommt diese Verbindung von einer erlaubten IP-Adresse?" Bei der ersten Methode steckt die Zugangsinformation in der Anfrage; bei der zweiten ersetzt die Quelle der Verbindung die Identität. Dieser Unterschied bestimmt Übertragbarkeit, Sicherheit und Fehlerbilder beider Methoden. Wie ein Proxy grundsätzlich funktioniert, erklären wir in [Was ist ein Proxy-Server und wie funktioniert er?](/de/blog/what-is-a-proxy-server). ## Wie funktioniert die Verbindung mit Benutzername und Passwort? Bei HTTP-Proxys ist die Authentifizierung mit Benutzername und Passwort Teil des HTTP-Standards. [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110#name-proxy-authorization) definiert den Header `Proxy-Authenticate`, mit dem der Proxy Zugangsdaten anfordert, und den Header `Proxy-Authorization`, mit dem der Client sie sendet. Das gängigste Schema ist **Basic**, definiert in [RFC 7617](https://www.rfc-editor.org/rfc/rfc7617). Bei einer HTTPS-Anfrage läuft der Vorgang so ab: 1. Der Client verbindet sich mit dem Proxy und sendet eine `CONNECT target.com:443`-Anfrage. 2. Enthält die Anfrage keine Zugangsdaten, antwortet der Proxy mit `407 Proxy Authentication Required` und dem Header `Proxy-Authenticate: Basic realm="proxy"`. 3. Der Client fügt Benutzername und Passwort als `user:pass` zusammen, kodiert sie mit Base64 und sendet die Anfrage erneut mit dem Header `Proxy-Authorization: Basic dXNlcjpwYXNz`. 4. Der Proxy prüft die Zugangsdaten. Stimmen sie, verbindet er sich mit dem Ziel und antwortet `200 Connection Established`; stimmen sie nicht, antwortet er erneut mit 407. Die meisten Clients fügen den Header schon beim ersten Versuch hinzu, sodass Schritt 2 in der Praxis entfällt. Browser versuchen es zuerst ohne Header und zeigen bei einer 407-Antwort ein Anmeldefenster. Ein wichtiges Detail: **Base64 ist eine Kodierung, keine Verschlüsselung.** Wer den Header sieht, kann ihn in Sekunden dekodieren und Benutzername und Passwort lesen. Die Verbindung zwischen Client und Proxy ist in den meisten Aufbauten unverschlüsseltes HTTP; die Zugangsdaten reisen auf dieser kurzen Strecke also praktisch im Klartext. Der HTTPS-Tunnel zur Zielseite schützt diesen Header nicht, weil der Header gesendet wird, bevor der Tunnel besteht. Auch SOCKS5-Proxys kennen ein ähnliches Unterverfahren mit Benutzername und Passwort, definiert in RFC 1929; auch dort werden die Zugangsdaten unverschlüsselt gesendet. ## Wie funktioniert eine IP-Whitelist? Bei einer IP-Whitelist enthält die Anfrage überhaupt keine Zugangsdaten. Sie tragen im Kundenpanel eine oder mehrere IP-Adressen als berechtigt ein, und der Proxy-Server vergleicht die Quell-IP jeder eingehenden Verbindung mit dieser Liste. 1. Im Panel tragen Sie die **öffentliche IP-Adresse** des Rechners ein, der den Proxy nutzen soll. 2. Der Client verbindet sich ohne Benutzername und Passwort mit dem Proxy. 3. Der Proxy prüft die Quelladresse der Verbindung. Steht sie auf der Liste, leitet er die Anfrage weiter. 4. Steht die Adresse nicht auf der Liste, wird die Verbindung abgelehnt oder erhält eine 407. Die „öffentliche IP-Adresse" ist hier nicht die lokale Adresse wie `192.168.x.x`, die Sie in den Netzwerkeinstellungen Ihres Computers sehen. Der Proxy sieht die Adresse, mit der Ihr Router oder Server ins Internet geht. Um sie herauszufinden, führen Sie diesen Befehl bei ausgeschaltetem Proxy aus: ```bash curl https://api.ipify.org ``` Der größte Vorteil einer Whitelist ist, dass sie mit Software funktioniert, die keine Zugangsdaten unterstützt. Manche ältere Desktop-Anwendungen, Spiele-Clients und Automatisierungstools bieten in ihren Proxy-Einstellungen nur Felder für Adresse und Port; dann ist die Whitelist die einzige Option. ## Die beiden Methoden im Vergleich | Kriterium | Benutzername und Passwort | IP-Whitelist | |---|---|---| | Womit wird die Identität belegt? | Header `Proxy-Authorization` in der Anfrage | Quell-IP-Adresse der Verbindung | | Verbindung aus verschiedenen Netzen | Problemlos | Die IP jedes Netzes muss eingetragen werden | | Privatanschluss mit dynamischer IP | Problemlos | Die Verbindung bricht ab, wenn sich die IP ändert | | Mehrere Geräte | Alle verbinden sich mit denselben Zugangsdaten | Die Ausgangs-IP jedes Geräts muss eingetragen werden | | Risiko unbefugter Nutzung | Bei geleakten Zugangsdaten von überall nutzbar | Andere Nutzer derselben IP | | Software ohne Unterstützung für Zugangsdaten | Funktioniert nicht | Funktioniert | | Geheimnisse in Code und Konfiguration | Ja, sie müssen sicher gespeichert werden | Keine | | Chrome mit SOCKS5 | Nicht unterstützt | Funktioniert | | Typischer Einsatz | Laptops, verschiedene Netze, Cloud-Funktionen | Server mit fester IP, ältere Software | ## Welche Methode ist sicherer? Eine eindeutige Antwort gibt es nicht; beide Methoden sind anderen Risiken ausgesetzt. **Das Risiko von Benutzername und Passwort ist das Leck.** Eine versehentlich in ein Code-Repository hochgeladene Konfigurationsdatei, ein bei einer Bildschirmfreigabe sichtbarer Befehl oder ein gespeicherter Login im Browser eines gemeinsam genutzten Rechners genügt. Geleakte Zugangsdaten lassen sich von überall auf der Welt nutzen, und diese Nutzung wird Ihrem Konto berechnet. **Das Risiko einer IP-Whitelist ist eine geteilte IP-Adresse.** Mobilfunkanbieter und einige Internetanbieter bringen mit einem Verfahren namens CGNAT viele Kunden über dieselbe öffentliche IP-Adresse ins Netz. Tragen Sie eine solche Adresse in die Liste ein, können sich auch unbekannte Nutzer, die diese Adresse teilen, mit Ihrem Proxy verbinden. Dasselbe gilt für Netze in Cafés, Hotels und Coworking-Spaces. Praktische Regeln: - Arbeiten Sie **von einem Server mit fester IP**, ist eine Whitelist sicherer; Sie tragen keine Geheimnisse im Code. - **Verwenden Sie keine Whitelist über einen Mobilfunkanschluss oder einen Privatanschluss hinter CGNAT.** - **Nutzen Sie Benutzername und Passwort**, schreiben Sie sie nicht in den Code; speichern Sie sie in einer Umgebungsvariablen oder einem Secrets-Manager. - Erlaubt Ihr Panel getrennte Unterbenutzer für verschiedene Aufgaben, nutzen Sie das; ein geleakter Zugang betrifft dann nur eine Aufgabe. ## Beide Methoden mit Beispielen Adressen und Ports in den folgenden Beispielen sind Platzhalter; übernehmen Sie Ihre eigenen Werte aus dem Kundenpanel. ### cURL ```bash # Benutzername und Passwort in der Adresse curl -x "http://user:pass@pr.proxynet.io:8000" https://httpbin.org/ip # Benutzername und Passwort als eigene Option curl -x "http://pr.proxynet.io:8000" -U "user:pass" https://httpbin.org/ip # IP-Whitelist: keine Zugangsdaten curl -x "http://pr.proxynet.io:8000" https://httpbin.org/ip ``` Die Option `-U` (lange Form `--proxy-user`) verringert auch Probleme mit Sonderzeichen, weil das Passwort nicht in der Adresse steht. Weitere cURL-Optionen finden Sie in [Proxy mit cURL verwenden](/de/blog/curl-proxy). ### Python Requests ```python import os from urllib.parse import quote import requests user = os.environ["PROXY_USER"] password = quote(os.environ["PROXY_PASS"], safe="") # kodiert Zeichen wie @, : und / # Benutzername und Passwort proxy = f"http://{user}:{password}@pr.proxynet.io:8000" r = requests.get("https://httpbin.org/ip", proxies={"http": proxy, "https": proxy}, timeout=20) print(r.json()) # IP-Whitelist proxy = "http://pr.proxynet.io:8000" r = requests.get("https://httpbin.org/ip", proxies={"http": proxy, "https": proxy}, timeout=20) print(r.json()) ``` Da die Zugangsdaten aus Umgebungsvariablen gelesen werden, bleibt das Passwort unsichtbar, auch wenn die Code-Datei geteilt wird. Einen rotierenden Python-Aufbau zeigen wir Schritt für Schritt in [Proxys in Python rotieren](/de/blog/how-to-rotate-proxies-in-python). Das Node.js-Gegenstück finden Sie in [Proxys in Node.js verwenden](/de/blog/nodejs-proxy). ### Browser Browser beziehen die Proxy-Adresse aus ihren Einstellungen oder vom Betriebssystem, fragen auf dem Einstellungsbildschirm aber nicht nach Benutzername und Passwort. Antwortet der Proxy bei der ersten Anfrage mit 407, öffnet sich ein Anmeldefenster, in das Sie die Zugangsdaten eingeben. Chrome unterstützt bei SOCKS5-Proxys keine Authentifizierung mit Benutzername und Passwort; für SOCKS5 mit Chrome brauchen Sie eine IP-Whitelist. Die Schritte für Windows und Chrome finden Sie in [Proxy-Einstellungen in Windows und Chrome](/de/blog/windows-chrome-proxy-settings), für Firefox in [Proxy-Einstellungen in Firefox](/de/blog/firefox). Die Einrichtung im API-Testtool beschreibt [Proxy-Einstellungen in Postman](/de/blog/postman-proxy). Wie Sie Desktop-Anwendungen ohne Proxy-Einstellungen umleiten, zeigt [Proxifier](/de/blog/proxifier). ## Warum erscheint der Fehler 407 Proxy Authentication Required? Abschnitt 15.5.8 von RFC 9110 definiert 407 als „der Client muss sich gegenüber dem Proxy authentifizieren". Das Problem liegt also zwischen Ihnen und dem Proxy, nicht bei der Zielseite. Die häufigsten Ursachen sind: 1. **Benutzername oder Passwort sind falsch.** Ein beim Kopieren angehängtes Leerzeichen oder ein Unterschied in der Groß- und Kleinschreibung genügt. 2. **Das Passwort enthält ein nicht kodiertes Sonderzeichen.** In `http://user:p@ss@pr.proxynet.io:8000` hält der Client alles nach dem ersten `@` für den Servernamen. `@` muss als `%40`, `:` als `%3A` und `/` als `%2F` geschrieben werden. 3. **Die IP auf der Whitelist weicht von der IP ab, von der die Verbindung kommt.** Der Router wurde neu gestartet, ein VPN ist noch aktiv, oder Sie verbinden sich im Büro aus einem anderen Netz. 4. **Die Software sendet die Zugangsdaten nicht.** Manche Tools ignorieren den Teil `user:pass@` der Proxy-Adresse und brauchen ein eigenes Feld oder eine eigene Option. 5. **Falsches Protokoll oder falscher Port.** Selbst mit korrekten Zugangsdaten ergibt eine SOCKS5-Verbindung zum HTTP-Port oder umgekehrt einen unverständlichen Fehler. 6. **Das Konto oder der Unterbenutzer ist gesperrt.** Das Guthaben ist aufgebraucht, der Unterbenutzer wurde gelöscht oder das Traffic-Kontingent ist erschöpft. Die ausführliche Ausgabe von cURL hilft bei der Diagnose: ```bash curl -v -x "http://user:pass@pr.proxynet.io:8000" https://httpbin.org/ip 2>&1 | grep -iE "proxy-authorization|< HTTP" ``` Fehlt in der Ausgabe jede `Proxy-Authorization`-Zeile, sendet der Client die Zugangsdaten nicht. Ist die Zeile vorhanden, die Antwort aber `407`, sind die Zugangsdaten falsch oder es gibt ein Problem mit dem Konto. Die Bedeutung von HTTP-Fehlercodes beim Scraping haben wir in [HTTP-Statuscodes beim Web Scraping](/de/blog/http-status-codes-web-scraping) zusammengestellt. In Python kommt diese Antwort als `Tunnel connection failed: 407` an; die anderen Formen derselben Meldung, etwa 403 oder eine abgelehnte Verbindung, behandeln wir in [Max Retries Exceeded With URL](/de/blog/max-retries-exceeded-with-url). ## Was passiert mit einer Whitelist bei dynamischer IP? Bei den meisten Privatanschlüssen ist die öffentliche IP-Adresse nicht fest. Startet der Router neu, bricht die Leitung ab oder vergibt der Anbieter in Abständen neue Adressen, erhalten Sie eine neue IP. Die alte Adresse auf der Whitelist wird ungültig, und der Proxy lehnt die Verbindung ab. Ihre Optionen: - **Auf Benutzername und Passwort umsteigen.** Der geringste Aufwand für Anschlüsse mit dynamischer IP. - **Eine feste IP beim Anbieter buchen.** Eine dauerhafte Lösung, wenn Ihre Arbeit immer aus demselben Netz läuft. - **Die Aufgabe auf einen Server mit fester IP verlegen.** Cloud-Server haben meist eine feste Ausgangsadresse, was für Scraping-Skripte und geplante Aufgaben passt. - **Die Liste automatisch aktualisieren, falls das Panel eine API hat.** Das hängt davon ab, ob der Anbieter eine solche API anbietet. Cloud-Funktionen und automatisch skalierende Container können bei jedem Lauf eine andere Ausgangsadresse erhalten; in diesen Umgebungen lässt sich eine Whitelist meist nicht einsetzen. ## Anwendungsfälle - **Scraping-Skript auf einem Server mit fester IP:** Whitelist, damit kein Passwort im Code steht. Für verschiedene Ausgangs-IPs über eine einzige Adresse wird ein [Rotierender Proxy](https://proxynet.io/de/rotating-proxy) genutzt. - **Ein Team, das aus verschiedenen Netzen arbeitet:** Benutzername und Passwort; noch besser, wenn jedes Mitglied einen eigenen Unterbenutzer erhält. - **Kontoaufgaben mit Sitzung:** meist Benutzername und Passwort; ein [Sticky-Proxy](https://proxynet.io/de/sticky-proxy) für dieselbe IP während der Sitzung, ein [ISP-Proxy](https://proxynet.io/de/static-isp-residential-proxy) für eine langlebige feste Adresse. - **Ältere Desktop-Software ohne Feld für Zugangsdaten:** Die Whitelist ist die einzige Option. - **Chrome mit SOCKS5:** Whitelist, weil Chrome bei SOCKS5 keine Passwortauthentifizierung unterstützt. ## Entscheidungshilfe | Ihre Situation | Empfehlung | |---|---| | Server oder VPS mit fester IP | IP-Whitelist | | Laptop, verschiedene Netze | Benutzername und Passwort | | Privatanschluss mit dynamischer IP | Benutzername und Passwort | | Mobilfunk oder hinter CGNAT | Benutzername und Passwort | | Cloud-Funktion, automatisch skalierender Container | Benutzername und Passwort | | Software ohne Feld für Zugangsdaten | IP-Whitelist | | Chrome mit SOCKS5 | IP-Whitelist | | Sie wollen keine Geheimnisse im Code | IP-Whitelist (bei fester IP) | ## Häufig gestellte Fragen ### Kann ich beide Methoden gleichzeitig nutzen? Das hängt vom Anbieter ab. Viele Anbieter akzeptieren im selben Konto passwortlose Verbindungen von freigegebenen IPs und Verbindungen mit Benutzername und Passwort von anderswo. Die Einstellungen im Panel bestimmen dieses Verhalten. ### Werden Benutzername und Passwort mit meinem Verkehr an die Zielseite gesendet? Nein. Der Header `Proxy-Authorization` ist nur für den Proxy bestimmt; der Proxy gibt ihn nicht an das Ziel weiter. Die Zielseite sieht Ihre Zugangsdaten nicht. ### Wie speichere ich mein Proxy-Passwort sicherer? Schreiben Sie das Passwort nicht in den Quellcode. Nutzen Sie eine Umgebungsvariable, eine `.env`-Datei außerhalb der Versionskontrolle oder den Secrets-Manager Ihrer Plattform. Haben Sie den Verdacht, dass das Passwort geleakt ist, ändern Sie es sofort im Panel. ### Wie viele IPs kann ich auf die Whitelist setzen? Das Limit unterscheidet sich je nach Anbieter und Tarif. Das aktuelle Limit finden Sie in Ihrem Kundenpanel oder beim Support. ### Warum erhalte ich eine 407, obwohl mein Passwort stimmt? Der häufigste Grund sind nicht kodierte Sonderzeichen im Passwort. Der zweithäufigste ist, dass Ihre Software die Zugangsdaten aus der Adresse nicht sendet. Prüfen Sie mit dem `curl -v`-Befehl oben, ob der Header gesendet wird. ### Funktioniert die Whitelist, während ein VPN aktiv ist? Mit aktivem VPN gehen Sie mit der IP-Adresse des VPN-Servers ins Internet. Steht Ihre Heim- oder Büro-IP auf der Whitelist, lehnt der Proxy die Verbindung ab. Schalten Sie entweder das VPN aus oder tragen Sie die Ausgangsadresse des VPN ein; Letzteres ist nicht empfehlenswert, weil andere Nutzer dieselbe VPN-Adresse teilen können. ## Fazit Es gibt zwei Wege, sich gegenüber einem Proxy zu authentifizieren: Benutzername und Passwort, die bei jeder Anfrage im Header `Proxy-Authorization` gesendet werden, oder eine IP-Whitelist, die auf die Quelladresse der Verbindung schaut. Benutzername und Passwort funktionieren in jedem Netz, müssen aber sorgfältig gespeichert werden; eine Whitelist hinterlässt keine Geheimnisse im Code, braucht aber eine feste, nicht geteilte IP-Adresse. Ein 407-Fehler entsteht fast immer durch falsche Zugangsdaten, ein nicht kodiertes Sonderzeichen oder eine veraltete IP auf der Whitelist. Tarife, die beide Methoden unterstützen, finden Sie in unseren [Proxy-Diensten](/de/proxy).