---
title: "HTTP 407 Proxy Authentication Required beheben"
description: "HTTP 407 heißt: Der Proxy will Benutzername und Passwort, bevor er Ihre Anfrage weiterleitet. Lösungen für fehlende Zugangsdaten, %40, Chrome und NTLM."
url: https://proxynet.io/de/blog/http-407-proxy-authentication-required
date: 2026-10-07
author: "Acar Diveroli"
category: "Anleitungen, Proxy 101"
lang: de
---

# HTTP 407 Proxy Authentication Required beheben

Sie tragen einen frisch gekauften Proxy in cURL ein, und die Antwort lautet `407 Proxy Authentication Required`. Dieselben drei Ziffern erscheinen in Python als `Tunnel connection failed: 407`, in Git als `The requested URL returned error: 407` und in Chrome als Anmeldefenster, das immer wieder aufgeht. Alle haben eine Ursache: Ihre Anfrage hat die Website nie erreicht. Der Proxy dazwischen hat sie am Tor angehalten.

Dieser Beitrag erklärt, was 407 im HTTP-Standard bedeutet, worin der Unterschied zu 401 liegt und was am Tor fehlt. Danach geht es durch die Stellen, an denen der Fehler auftritt: falsche oder fehlende Zugangsdaten bei einem gekauften Proxy, eine geänderte Heim-IP bei IP-Autorisierung, ein Sonderzeichen im Passwort, Chrome, das die Form `user:pass@` ablehnt, NTLM- und Kerberos-Proxys in Firmennetzen und die Stelle, an der die Zugangsdaten in cURL, Python, Node.js, npm, pip, Git und Docker hingehören. Alle Codebeispiele haben wir am 7. Oktober 2026 gegen einen lokalen Test-Proxy ausgeführt, der Benutzername und Passwort verlangt.

> **Hinweis: Kurzantwort**
>
> HTTP 407 Proxy Authentication Required bedeutet, dass der Proxy, der Ihre Anfrage weiterleitet, Benutzername und Passwort verlangt und die Anfrage entweder keine oder falsche Zugangsdaten enthielt. Der Fehler kommt vom Proxy, nicht von der Website; der Header `Proxy-Authenticate: Basic realm="…"` in der Antwort sagt, welches Verfahren er erwartet. Die Lösung ist der richtige Header `Proxy-Authorization`: `-U user:pass` in cURL, `proxies={"https": "http://user:pass@host:port"}` in Python Requests, ein `ProxyAgent` mit `token` in Node und `page.authenticate()` statt der Adresse in Chrome und Puppeteer. Ein Sonderzeichen wie `@` im Passwort wird in einer URL als `%40` geschrieben; wenn Sie IP-Autorisierung nutzen, prüfen Sie, ob die im Panel gespeicherte Adresse heute noch Ihre IP ist.

## Was bedeutet HTTP 407 Proxy Authentication Required?

Ein 407 ist der Proxy, der sagt: „Beweisen Sie, wer Sie sind, bevor ich das weiterleite.“ Der HTTP-Standard, [RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html#section-15.5.8), definiert den Code in Abschnitt 15.5.8: 407 ähnelt 401, zeigt aber an, dass sich der Client authentifizieren muss, um für diese Anfrage einen Proxy zu nutzen. Der Proxy muss einen Header `Proxy-Authenticate` mit einer für diesen Proxy gültigen Challenge senden, und der Client darf die Anfrage mit einem neuen oder ersetzten Header `Proxy-Authorization` wiederholen.

In der Praxis läuft der Austausch zwischen diesen beiden Headern. Der Proxy nennt das Verfahren mit `Proxy-Authenticate: Basic realm="x"`; bei Basic, dem mit Abstand häufigsten Verfahren, verbindet der Client Benutzername und Passwort zu `user:pass`, kodiert die Zeichenkette mit Base64 und fügt `Proxy-Authorization: Basic dXNlcjpwYXNz` hinzu. Base64 ist keine Verschlüsselung; wer `dXNlcjpwYXNz` dekodiert, liest `user:pass`. Die Zugangsdaten verlassen sich also auf ein vertrauenswürdiges Netz oder auf TLS auf dem Weg zum Proxy.

Ein Detail des Standards hilft beim Debuggen: `Proxy-Authorization` wird vom ersten Proxy verbraucht, der den Header erhält, und nicht an die Website weitergeleitet. Der Proxy sieht Ihr Passwort, die Website nicht. Stehen in einem Firmennetz mehrere Proxys hintereinander, verlangt jeder seine eigenen Zugangsdaten, und der Wert `realm` in `Proxy-Authenticate` verrät, welcher den 407 gesendet hat.

## Was ist der Unterschied zwischen 407 und 401?

Die beiden Codes führen denselben Mechanismus bei zwei verschiedenen Parteien aus. 401 Unauthorized ist die Website, die Zugangsdaten verlangt: Die Antwort enthält `WWW-Authenticate`, der Client antwortet mit `Authorization`, und das Problem liegt zwischen Ihnen und der Website. Bei einem 407 findet derselbe Dialog mit dem Proxy statt, über `Proxy-Authenticate` und `Proxy-Authorization`, und die Website hat die Anfrage gar nicht gesehen.

Diese Unterscheidung entscheidet, wo Sie suchen. Nach einem 401 prüfen Sie Ihr Konto, Ihren API-Schlüssel oder Ihr Token auf der Website. Nach einem 407 spielt nichts auf der Website eine Rolle; Benutzername, Passwort oder IP-Liste im Proxy-Panel oder das Konto, das Ihnen die Netzwerkverwaltung gegeben hat, sind der Ort des Problems. Beides kann auch nacheinander auftreten: Erst wird der Proxy mit einem 407 passiert, dann liefert die Website einen 401.

## Wie entsteht ein 407 Schritt für Schritt?

Um den Ablauf zu beobachten, haben wir in Node.js einen Test-Proxy mit 40 Zeilen geschrieben. Er beantwortet jede Anfrage, deren Header `Proxy-Authorization` nicht zu `user:pass` passt, mit einem 407 und `Proxy-Authenticate: Basic realm="x"`, leitet passende Anfragen weiter, wendet dieselbe Regel auf den `CONNECT`-Tunnel für HTTPS an und protokolliert jede Anfrage. Für eine HTTPS-Seite las sich das Protokoll so:

1. Der Client sendet `CONNECT site.com:443` an den Proxy und bittet um einen Tunnel zur Website. Bei einer `http://`-Adresse sendet er die Anfrage selbst (`GET http://site.com/ …`).
2. Hat die Anfrage kein `Proxy-Authorization`, liefert der Proxy `407 Proxy Authentication Required` mit `Proxy-Authenticate: Basic realm="x"` und öffnet nichts. Die Protokollzeile lautet `CONNECT site.com:443 Proxy-Authorization: (keine)`.
3. Der Client fügt den Header hinzu und wiederholt die Anfrage: `Proxy-Authorization: Basic dXNlcjpwYXNz`. Viele Werkzeuge tun das schon beim ersten Versuch; cURL mit `-U` wartet nie auf den 407.
4. Der Proxy prüft den Wert. Stimmt er, öffnet er den Tunnel und liefert `200 Connection Established`; ab hier fließt der TLS-Verkehr durch den Tunnel. Stimmt er nicht, wiederholt er Schritt 2; ein falsches und ein fehlendes Passwort sind für einen Proxy derselbe 407.
5. Die Website sieht die Anfrage erst jetzt und gibt ihre eigene Antwort (200, 404, 401 …). Die Header, die sie erhalten hat, enthielten kein `Proxy-Authorization`; der Proxy hat es verbraucht.

Mit cURL ist der erste Schritt dieses Ablaufs in einem einzigen Befehl sichtbar. Für eine einfache HTTP-Adresse bekam eine Anfrage ohne Zugangsdaten diese Antwort:

```bash
curl -i -x http://pr.proxynet.io:8000 http://example.com/
```

```text
HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="x"
Connection: close
```

Bei einer HTTPS-Adresse meldet cURL stattdessen einen eigenen Fehler: `curl: (56) CONNECT tunnel failed, response 407`. Beides ist derselbe fehlende Header.

## Warum tritt der Fehler 407 auf?

Die Ursachen zerfallen in zwei Gruppen: die Zugangsdaten eines Proxys, den Sie gekauft haben, und die Zugangsdaten des Proxys, den Ihr Netz betreibt. Der Fehlertext ist in beiden Fällen identisch; der Ort der Lösung nicht.

| Ursache | Symptom | Lösung |
|---|---|---|
| Zugangsdaten werden nie gesendet | Keine Zeile `Proxy-Authorization`, 407 bei der ersten Anfrage | Die Proxy-Zugangsdaten-Option des Werkzeugs nutzen (`-U`, `proxies=`, `token`) |
| Benutzername oder Passwort falsch | Header vorhanden, trotzdem 407 | Aus dem Panel kopieren; Leerzeichen und Groß-/Kleinschreibung prüfen |
| `@`, `:` oder `#` im Passwort | URL-Fehler „bad hostname“ oder 407 | In der URL als `%40`, `%3A`, `%23` kodieren oder eine separate Option nutzen |
| IP-Autorisierung, Heim-IP geändert | Gestrige Einrichtung scheitert heute | Neue IP im Panel eintragen oder auf Benutzername und Passwort wechseln |
| Chrome ignoriert `user:pass@` in der Adresse | `ERR_NO_SUPPORTED_PROXIES` oder ein Anmeldefenster | `page.authenticate()` in Puppeteer, das Anmeldefenster im Browser |
| Firmen-Proxy will NTLM oder Kerberos | `Proxy-Authenticate: Negotiate` oder `NTLM` | Domänenkonto mit `--proxy-negotiate`; NTLM ist in cURL-Builds seit 8.20 abgeschaltet |
| Eine Kette von Proxys | Das Anmeldefenster kommt immer wieder | Jeder Proxy will eigene Zugangsdaten; das Netzwerkteam fragen |

## Wie beheben Sie einen 407 bei einem gekauften Proxy?

Die meisten 407 entstehen aus einer kleinen Lücke zwischen dem, was Sie aus dem Panel kopiert haben, und dem Format, das das Werkzeug erwartet. Prüfen Sie zuerst, ob die Zugangsdaten überhaupt gesendet werden: Zeigt `curl -v` keine Zeile `> Proxy-Authorization:`, liegt das Problem am Format. Ist die Zeile da und die Antwort trotzdem 407, ist der Wert falsch oder das Konto hat ein Problem; in unserem Test beantwortete der Proxy ein falsches Passwort genauso wie gar keines.

**Sonderzeichen.** Eine Proxy-Adresse ist eine URL der Form `http://user:pass@host:port`, und in einer URL trennt das Zeichen `@` die Benutzerinformationen vom Host. Lautet Ihr Passwort `p@ss`, enthält die Adresse zwei `@`-Zeichen; cURL 8.5 lehnte sie mit `curl: (5) Unsupported proxy syntax … Bad hostname` ab. Mit `%40` anstelle des `@` (`http://user:p%40ss@host:port`) dekodierte der Proxy `user:p@ss`, und die Anfrage ging durch. Nutzen Sie `%3A` für `:`, `%23` für `#` und `%2F` für `/`. Python Requests akzeptierte auch die unkodierte Adresse, weil es die URL am letzten `@` trennte, aber die Kodierung funktioniert in jedem Werkzeug gleich. Optionen, die die Zugangsdaten außerhalb der URL entgegennehmen (`curl -U "user:p@ss"`, `HTTPProxyAuth("user", "p@ss")` in Requests), brauchen keine Kodierung; beide kamen mit dem rohen Passwort durch.

**IP-Autorisierung.** Haben Sie im Panel statt eines Passworts Ihre IP-Adresse hinterlegt, schaut der Proxy auf die Adresse, von der die Verbindung kommt. An einem Heimanschluss ändert sich die öffentliche IP, wenn der Router neu startet oder der Anbieter seinen Adresspool rotiert, und die gestern funktionierende Einrichtung liefert heute 407. Vergleichen Sie Ihre aktuelle IP mit der im Panel gespeicherten Adresse. Ändert sich Ihre Adresse oft, ist Benutzername und Passwort die Methode mit weniger Überraschungen; unser [Leitfaden zur Proxy-Authentifizierung](/de/blog/proxy-authentication-methods) vergleicht beide.

**Sitzungsparameter.** Parameter, die für Sticky Sessions oder die Länderwahl an den Benutzernamen angehängt werden, etwa `user-session-abc-country-tr`, sind Teil des Benutzernamens; ein Tippfehler oder ein nicht unterstützter Parameter kommt bei manchen Anbietern als 407 zurück. Versuchen Sie zuerst ein schlichtes `user:pass` und fügen Sie die Parameter einzeln wieder hinzu. In einem [Residential-Proxy](https://proxynet.io/de/residential-proxy)-Tarif legen sie Sitzungsdauer und Ausgangsland fest, deshalb spart es Zeit, einen Parameterfehler von einem Passwortfehler zu trennen.

## Wie beheben Sie einen 407 bei einem Firmen-Proxy?

Im Netz eines Unternehmens oder einer Universität haben nicht Sie den Proxy eingerichtet; das Betriebssystem bezieht ihn aus einer automatischen Konfigurationsdatei (PAC) oder einer Gruppenrichtlinie, und die Zugangsdaten sind meist Ihr Domänenkonto. Diese Proxys verlangen statt Basic oft `Proxy-Authenticate: Negotiate` (Kerberos) oder `NTLM`. Browser und Office nutzen das Windows-Konto, mit dem Sie angemeldet sind, und kommen stillschweigend durch; Kommandozeilenwerkzeuge und Skripte tun das nicht und liefern 407.

cURL lässt Sie das Verfahren wählen: `--proxy-negotiate -U :` nutzt die Identität der Sitzung für Kerberos, und `--proxy-anyauth` wählt aus dem Angebot des Proxys eine passende Methode. In unserem Test sendete cURL mit `--proxy-anyauth` zuerst eine Anfrage ohne Zugangsdaten, las den 407 und sein `Proxy-Authenticate: Basic` und wiederholte dann mit Basic; ein Umlauf mehr, aber nützlich, wenn Sie nicht wissen, was der Proxy erwartet. NTLM ist ein eigenes Thema. Seit [Version 8.20.0](https://curl.se/ch/8.20.0.html) (29. April 2026) schaltet das curl-Projekt NTLM im Build standardmäßig ab und plant, es ganz zu entfernen; als Gründe nennt es die schwache Kryptografie des Verfahrens, seine Unverträglichkeit mit HTTP/2 und HTTP/3 und Microsofts eigene Abkündigung von NTLM. Mit cURL 8.20 oder neuer funktioniert `--proxy-ntlm` in den meisten Distributionen nicht mehr; akzeptiert der Proxy nur NTLM, bitten Sie das Netzwerkteam, Negotiate zu aktivieren. Unser cURL 8.5 sendete mit `--proxy-ntlm` noch die erste NTLM-Nachricht; unser Test-Proxy, der nur Basic kennt, antwortete erneut mit 407.

**Das Anmeldefenster, das sich unter Windows immer wieder öffnet.** Die Proxy-Einstellungen von Windows speichern nur die Adresse, keinen Benutzernamen und kein Passwort; jede Anwendung fragt selbst nach Zugangsdaten, wenn sie einen 407 erhält. Schließt sich das Fenster und öffnet sich sofort wieder, wurden die Zugangsdaten abgelehnt: Nach einer kürzlichen Passwortänderung probiert die Windows-Anmeldeinformationsverwaltung (Credential Manager) das gespeicherte alte Passwort weiter, bis Sie es löschen. Ein älterer Microsoft-Supporthinweis beschreibt eine weitere Ursache: Stehen mehrere Proxys, die NTLM verlangen, hintereinander, wird der erste passiert, der zweite liefert 407, und das Fenster erscheint erneut; die vorgeschlagene Lösung ist, Negotiate mit Kerberos zu aktivieren, was Aufgabe des Netzwerkteams ist.

## Warum zeigen Chrome und Puppeteer den 407 anders?

Chrome verwendet keinen Benutzernamen und kein Passwort, die in die Proxy-Adresse geschrieben sind. [Chromiums Proxy-Dokumentation](https://chromium.googlesource.com/chromium/src/+/HEAD/net/docs/proxy.md) sagt das klar: Der Browser implementiert keine in die Proxy-Einstellungen eingebetteten Zugangsdaten, und die Proxy-Authentifizierung läuft über den normalen Ablauf, also das Anmeldefenster nach einem 407. HTTP-Proxys unterstützen Basic, Digest, Negotiate und NTLM; SOCKS5 unterstützt gar keine Authentifizierung. `user:pass@` in `--proxy-server` zu schreiben bewirkt daher nichts. Im Test für unseren Puppeteer-Beitrag am 6. Oktober lehnte Chrome 154 den ganzen Wert mit `net::ERR_NO_SUPPORTED_PROXIES` ab; wurden die Zugangsdaten nirgends angegeben, scheiterte die erste Navigation mit `net::ERR_INVALID_AUTH_CREDENTIALS`. Der 407 erreicht den Nutzer in dieser Version nie; Chrome verwandelt ihn in einen eigenen Fehlercode.

Die Lösung ist, die Zugangsdaten dort abzulegen, wo die Antwort des Browsers auf den 407 gebaut wird. In Puppeteer ist das `page.authenticate()`, und der Aufruf muss vor dem ersten `page.goto()` stehen:

```js
import puppeteer from "puppeteer";

const browser = await puppeteer.launch({
  args: ["--proxy-server=http://pr.proxynet.io:8000"], // keine Zugangsdaten in der Adresse
});
const page = await browser.newPage();
await page.authenticate({ username: "user", password: "pass" }); // die Antwort auf den 407
await page.goto("https://httpbin.org/ip");
```

Laut Puppeteer-Dokumentation schaltet der Aufruf im Hintergrund das Abfangen von Anfragen ein und wird mit `null` wieder abgeschaltet. Die Zugangsdaten gehören zum Browserkontext, nicht zur Seite; jede Seite im selben Kontext verwendet den zuerst eingegebenen Wert. In einem Chrome, das Sie von Hand bedienen, tippen Sie sie in das Fenster, das nach dem 407 aufgeht.

## Wie übergeben Sie Proxy-Zugangsdaten in den einzelnen Werkzeugen?

Jedes Werkzeug nimmt die Zugangsdaten an einer anderen Stelle entgegen. Alle Beispiele liefen über den lokalen Test-Proxy; die Adresse zeigen wir als `pr.proxynet.io:8000`, die Zugangsdaten als `user:pass`.

**cURL.** Die Zugangsdaten kommen in die Adresse oder in eine separate Option; `-U` und `--proxy-user` sind dasselbe. cURL nutzt standardmäßig Basic und sendet die Zugangsdaten bei der ersten Anfrage.

```bash
# Zugangsdaten in einer separaten Option: keine Kodierung für Sonderzeichen nötig
curl -x http://pr.proxynet.io:8000 -U user:pass https://httpbin.org/ip

# Zugangsdaten in der Adresse: %40 für @, %3A für :
curl -x http://user:p%40ss@pr.proxynet.io:8000 https://httpbin.org/ip

# sehen, welches Verfahren der Proxy erwartet
curl -v -x http://pr.proxynet.io:8000 https://httpbin.org/ip 2>&1 | grep -i proxy-auth
```

Umgebungsvariablen nehmen dieselbe Adresse: `export HTTPS_PROXY=http://user:pass@pr.proxynet.io:8000`, dazu `HTTP_PROXY` für einfaches HTTP und `NO_PROXY` für Hosts, die ausgenommen werden. Die übrigen Proxy-Optionen von cURL stehen in unserem [Leitfaden zu cURL mit Proxy](/de/blog/curl-proxy).

**Python Requests.** Die Zugangsdaten kommen in die Adresse im Dictionary `proxies` oder in `HTTPProxyAuth`, das den Header `Proxy-Authorization` hinzufügt. Die Requests-Dokumentation definiert die Form `http://user:password@host/` und warnt, dass es ein Sicherheitsrisiko ist, Benutzername und Passwort in einer Umgebungsvariablen oder einer versionierten Datei zu speichern.

```python
import requests
from requests.auth import HTTPProxyAuth

PROXY = "http://user:pass@pr.proxynet.io:8000"
proxies = {"http": PROXY, "https": PROXY}

r = requests.get("https://httpbin.org/ip", proxies=proxies, timeout=15)
print(r.status_code, r.json())

# Zugangsdaten getrennt von der Adresse: keine Kodierung für Sonderzeichen nötig
auth = HTTPProxyAuth("user", "pass")
r = requests.get("https://httpbin.org/ip", proxies={"https": "http://pr.proxynet.io:8000"}, auth=auth, timeout=15)
```

Beide Wege passierten in unserem Test mit Requests 2.34 den Proxy. Die Form des Fehlers hängt vom Ziel ab: Bei einer HTTPS-Adresse warf eine Anfrage ohne Zugangsdaten `requests.exceptions.ProxyError` mit `Tunnel connection failed: 407 Proxy Authentication Required` in der Meldung; bei einer einfachen HTTP-Adresse gab es keine Ausnahme, `r.status_code` war 407, und `r.headers["Proxy-Authenticate"]` enthielt die Challenge. Ein Skript, das nur Ausnahmen abfängt, übersieht den 407 bei HTTP-Adressen; es braucht eine Prüfung `r.status_code == 407`. `HTTPProxyAuth` fügt nur den Header `Proxy-Authorization` hinzu; die Anmeldung bei der Website selbst läuft über `HTTPBasicAuth`. Um eine Reihe von POST-Anfragen über eine Sitzung zu schicken, ergänzen Sie `proxies` in der `Session`-Einrichtung aus unserem [Leitfaden zu Requests mit POST und JSON](/de/blog/python-requests-post-json).

**Node.js und undici.** Das eingebaute `fetch` von Node geht mit der Klasse `ProxyAgent` aus undici durch einen Proxy. Die Zugangsdaten kommen in `uri` oder als fertiger Header-Wert in die Option `token`; die [undici-Dokumentation zu ProxyAgent](https://undici.nodejs.org/#/docs/api/ProxyAgent) beschreibt beides und merkt an, dass Zugangsdaten in der URI URL-dekodiert werden, bevor sie Base64-kodiert werden.

```js
import { fetch, ProxyAgent } from "undici";

const agent = new ProxyAgent({
  uri: "http://pr.proxynet.io:8000",
  token: `Basic ${Buffer.from("user:pass").toString("base64")}`, // der Wert für Proxy-Authorization
});

const res = await fetch("https://httpbin.org/ip", { dispatcher: agent });
console.log(res.status, await res.json());
```

Mit undici 8.10 lieferten `token` und eine `uri` mit `user:p%40ss` dasselbe Ergebnis. Eine Anfrage ohne Zugangsdaten scheiterte mit `TypeError: fetch failed`; der wahre Grund stand in `error.cause` als `InvalidArgumentError: Proxy Authentication Required (407)`, und bei einer HTTPS-Adresse hieß es nur `Request was cancelled.` Node liest Proxy-Umgebungsvariablen auch nicht von sich aus: Mit gesetztem `HTTPS_PROXY` verband sich `fetch` weiterhin direkt. Die in Node 22.21 und 24.0 eingeführte Variable `NODE_USE_ENV_PROXY=1` schaltet das ein; in unserem Test funktionierte sie mit einer Experimental-Warnung.

**npm, pip, Git und Docker.** Alle vier akzeptieren dasselbe Adressformat mit den Zugangsdaten in der Adresse.

```bash
# npm: dauerhafte Einstellung (die Umgebungsvariable HTTPS_PROXY wird ebenfalls gelesen)
npm config set proxy http://user:pass@pr.proxynet.io:8000
npm config set https-proxy http://user:pass@pr.proxynet.io:8000

# pip: --proxy für einen Befehl, proxy = in pip.conf dauerhaft
pip install --proxy http://user:pass@pr.proxynet.io:8000 requests

# Git: Format [protocol://][user[:password]@]proxyhost[:port]
git config --global http.proxy http://user:pass@pr.proxynet.io:8000
git config --global http.proxyAuthMethod basic   # anyauth, basic, digest, negotiate, ntlm
```

Beim Docker-Client kommt die Einstellung in das Objekt `proxies.default` (`httpProxy`, `httpsProxy`, `noProxy`) in `~/.docker/config.json`; Dockers Dokumentation merkt an, dass diese Werte im Klartext in der Konfiguration des Containers gespeichert werden und über die Remote-API lesbar sind. In unserem Test meldete Git ohne Zugangsdaten `fatal: unable to access '…': The requested URL returned error: 407` und kam mit ihnen durch. pip versteckte den 407 in seiner Standardausgabe hinter `Could not find a version that satisfies the requirement`; die wahre Ursache erschien mit `pip -vvv`: `407 Client Error: Proxy Authentication Required`.

| Werkzeug | So zeigt es einen 407 | Wohin die Zugangsdaten gehören |
|---|---|---|
| cURL | `CONNECT tunnel failed, response 407` | `-U user:pass` oder die Adresse |
| Python Requests | `ProxyError` bei HTTPS, `status_code == 407` bei HTTP | Adresse in `proxies=` oder `HTTPProxyAuth` |
| Node undici | `fetch failed`, Grund in `cause` | `ProxyAgent` `token` oder `uri` |
| Chrome / Puppeteer | `ERR_INVALID_AUTH_CREDENTIALS`, ein Anmeldefenster | `page.authenticate()` |
| Git | `The requested URL returned error: 407` | Adresse in `http.proxy` |
| pip | Nur mit `-vvv` | `--proxy` oder `pip.conf` |

## Wie verhindert eine feste IP den 407?

Bei IP-Autorisierung ist die häufigste Ursache eines 407 eine geänderte Adresse. Von einer festen öffentlichen IP wie einem Cloud-Server oder einer Büroleitung füllen Sie die Liste einmal und tragen kein Passwort im Code; von einem Heimanschluss oder aus wechselnden Netzen verursacht Benutzername und Passwort weniger Unterbrechungen.

Stabilität zählt auch auf der Seite des Proxys. In einem [ISP-Proxy](https://proxynet.io/de/static-isp-residential-proxy)-Tarif ändert sich die Ausgangs-IP nicht, sodass eine einzige Adresse in die Freigabeliste der Website oder eines Firmensystems kommt und auch an diesem Ende kein Problem mit Zugangsdaten entsteht.

## Häufige Fehler

- **Den Fehler auf der Website suchen.** Eine 407-Anfrage hat die Website nie erreicht; ihr Konto, ihre Cookies oder ihr API-Schlüssel ändern nichts am Ergebnis.
- **Ein unkodiertes Passwort in die URL schreiben.** Ein Passwort mit `@` zerstört die Adresse; nutzen Sie `%40` oder eine separate Option für die Zugangsdaten.
- **`user:pass@` in das Chrome-Flag setzen.** Chromium ignoriert es; nutzen Sie `page.authenticate()` in Puppeteer und das Anmeldefenster von Hand.
- **Nur Ausnahmen abfangen.** Requests wirft bei einer einfachen HTTP-Adresse nichts und liefert ein Antwortobjekt mit 407; prüfen Sie den Statuscode.
- **Der alten IP vertrauen.** Bei IP-Autorisierung passt die gestrige Einrichtung vielleicht nicht zur heutigen Adresse.
- **Zugangsdaten in Skripte oder Repositories schreiben.** Sowohl die Requests- als auch die Docker-Dokumentation nennen das ein Risiko; nutzen Sie eine Umgebungsvariable für die Sitzung oder einen Secrets-Manager.
- **Nach cURL 8.20 NTLM erwarten.** NTLM ist im Build abgeschaltet; bitten Sie bei Firmen-Proxys um Negotiate (Kerberos).

## Entscheidungshilfe

| Ihre Situation | Was zu tun ist |
|---|---|
| Kein `Proxy-Authorization` in `curl -v` | Zugangsdaten mit `-U` oder in der Adresse ergänzen |
| Header vorhanden, trotzdem 407 | Passwort erneut aus dem Panel kopieren; schlichtes `user:pass` probieren |
| `@`, `:` oder `#` im Passwort | `%40`, `%3A`, `%23` in der URL oder eine separate Option für die Zugangsdaten |
| IP-Autorisierung, Adresse geändert | Neue IP im Panel; bei häufigem Wechsel auf Benutzername und Passwort umstellen |
| Chrome oder Puppeteer | `page.authenticate()`; keine Zugangsdaten im Flag |
| Firmennetz, `Proxy-Authenticate: Negotiate` | `--proxy-negotiate -U :` oder das Domänenkonto; Kerberos statt NTLM |
| Anmeldefenster unter Windows verschwindet nicht | Altes Passwort in der Anmeldeinformationsverwaltung löschen; das Netzwerkteam nach verketteten Proxys fragen |

## Häufige Fragen

### Was bedeutet der Fehler HTTP 407?

Er bedeutet, dass der Proxy Zugangsdaten verlangt, bevor er Ihre Anfrage weiterleitet, und dass die Anfrage keine oder falsche enthielt. Der Header `Proxy-Authenticate` in der Antwort nennt das erwartete Verfahren; die Lösung ist ein Header `Proxy-Authorization` mit dem richtigen Wert.

### Was ist der Unterschied zwischen 407 und 401?

Bei einem 401 verlangt die Website Zugangsdaten, über `WWW-Authenticate` und `Authorization`; bei einem 407 verlangt sie der Proxy dazwischen, über `Proxy-Authenticate` und `Proxy-Authorization`. Eine Anfrage, die einen 407 erhalten hat, ist nie bei der Website angekommen.

### Warum bekomme ich 407, obwohl mein Proxy-Passwort richtig ist?

Drei häufige Ursachen: Ein Sonderzeichen im Passwort ist in der URL nicht kodiert, das Werkzeug liest keine Zugangsdaten aus der Adresse (so arbeitet Chrome), oder das Konto ist im Modus IP-Autorisierung und Ihre aktuelle Adresse steht nicht auf der Liste. Prüfen Sie mit `curl -v`, ob überhaupt eine Zeile `Proxy-Authorization` gesendet wird.

### Wie schreibe ich ein Passwort mit @-Zeichen in die Proxy-Adresse?

Ersetzen Sie `@` durch `%40`: `http://user:p%40ss@host:port`. Nach derselben Logik nutzen Sie `%3A` für `:` und `%23` für `#`. Separate Optionen wie `-U "user:p@ss"` in cURL oder `HTTPProxyAuth("user", "p@ss")` in Requests brauchen keine Kodierung.

### Wo gebe ich Benutzername und Passwort für den Proxy in Chrome ein?

Die Proxy-Einstellungen von Chrome haben kein Feld für den Benutzernamen, und der Browser ignoriert den Teil `user:pass@` einer Adresse. Sie tippen die Zugangsdaten in das Fenster, das nach dem ersten 407 aufgeht; in Automatisierungswerkzeugen wie Puppeteer ersetzt `page.authenticate({ username, password })` dieses Fenster.

### Ich bekomme 407 am Firmen-Proxy. Was soll ich tun?

Der Proxy will höchstwahrscheinlich NTLM oder Kerberos (Negotiate) und erwartet Ihr Domänenkonto. Probieren Sie `--proxy-negotiate -U :` in cURL; da NTLM in cURL-Builds ab 8.20 abgeschaltet ist, bitten Sie das Netzwerkteam, für einen Proxy, der nur NTLM akzeptiert, Negotiate zu aktivieren.

## Fazit

HTTP 407 Proxy Authentication Required sagt, dass der Proxy, der Ihre Anfrage weiterleitet, Zugangsdaten verlangt; die Website weiß davon nichts. Die Lösung ist in jedem Werkzeug derselbe Header mit dem richtigen Wert: `-U` in cURL, die Adresse in `proxies=` oder `HTTPProxyAuth` in Requests, `token` in undici, `page.authenticate()` in Puppeteer und die Adresse `http://user:pass@host:port` in npm, pip, Git und Docker. Ein `@` im Passwort wird zu `%40`, IP-Autorisierung braucht Ihre aktuelle Adresse auf der Liste, und Firmennetze sprechen Negotiate statt Basic, mit NTLM, das in cURL-Builds seit 8.20 abgeschaltet ist. Tarife, die mit Benutzername und Passwort oder mit einer IP-Liste arbeiten, finden Sie bei unseren [Proxy-Diensten](/de/proxy).