--- title: "PowerShell-Proxy-Einstellungen: Invoke-WebRequest mit Proxy" description: "Invoke-WebRequest mit -Proxy und -ProxyCredential aufrufen oder beides in $PSDefaultParameterValues setzen. Dazu 5.1 vs. 7, Umgebungsvariablen, 407, SOCKS5." url: https://proxynet.io/de/blog/powershell-proxy date: 2026-11-07 author: "Acar Diveroli" category: "Anleitungen, Integration" lang: de --- # PowerShell-Proxy-Einstellungen: Invoke-WebRequest mit Proxy Ein Skript, das auf Ihrem Laptop problemlos lief, zieht auf einen Server um, oder es soll jetzt eine Preisliste so lesen, wie ein Besucher aus einem anderen Land sie sieht, und jeder `Invoke-WebRequest`-Aufruf muss über einen Proxy hinausgehen. PowerShell hat die Parameter dafür. Sie verhalten sich nur in Windows PowerShell 5.1 und PowerShell 7 unterschiedlich, und die häufigste Abkürzung, `user:pass@` in die Proxy-Adresse zu schreiben, scheitert in 5.1 mit einem 407, ohne zu sagen, warum. Dieser Artikel behandelt `-Proxy` und `-ProxyCredential`, Zugangsdaten ohne Eingabeaufforderung, einen Proxy für jeden Aufruf, Umgebungsvariablen und den System-Proxy von Windows, SOCKS5, ein Download-Skript mit Wiederholungen und die genauen Fehlertexte. Jedes 5.1-Beispiel wurde unter Windows PowerShell 5.1 (Build 26100) gegen einen lokalen Proxy ausgeführt, der Benutzername und Passwort verlangt. PowerShell 7 war auf dem Testrechner nicht installiert; sein Verhalten stammt daher aus der Dokumentation von Microsoft und ist als solches gekennzeichnet. > **Hinweis: Kurzantwort** > > Ergänzen Sie `Invoke-WebRequest` oder `Invoke-RestMethod` um `-Proxy "http://pr.proxynet.io:8000"` und `-ProxyCredential $cred`, wobei `$cred` ein `PSCredential`-Objekt aus Benutzername und Passwort des Proxys ist. Soll der Proxy für jeden Aufruf einer Sitzung gelten, tragen Sie dieselben zwei Werte in `$PSDefaultParameterValues` ein. Windows PowerShell 5.1 ignoriert `HTTP_PROXY` und `HTTPS_PROXY`, ignoriert `user:pass@` in der Proxy-Adresse und kann kein SOCKS5; PowerShell 7 liest die Variablen und akzeptiert ab 7.2 `socks5://`. ## Windows PowerShell 5.1 oder PowerShell 7: Warum ist das wichtig? Die beiden Versionen schicken Webanfragen über unterschiedliche HTTP-Stacks, deshalb kann dieselbe Proxy-Einstellung in der einen funktionieren und in der anderen ignoriert werden. Windows PowerShell 5.1 ist Teil von Windows und nutzt die .NET-Framework-Klasse `HttpWebRequest`; PowerShell 7 ist ein eigener Download und nutzt `HttpClient`. `$PSVersionTable.PSVersion` sagt Ihnen, unter welcher Version ein Skript läuft. | Verhalten | Windows PowerShell 5.1 | PowerShell 7.x | |---|---|---| | `-Proxy`, `-ProxyCredential` | Ja | Ja | | `HTTP_PROXY`, `HTTPS_PROXY`, `NO_PROXY` | Ignoriert | Gelesen seit 7.0 | | Proxy ohne Angabe | Internetoptionen des Benutzers | Variablen, dann Benutzereinstellungen | | Schalter `-NoProxy` | Nein | Seit 6.0 | | SOCKS5-Adresse | Nein | 7.2 und neuer | | Aliase `curl` und `wget` | Zeigen auf `Invoke-WebRequest` | Entfernt | | Eingebaute Wiederholungen | Nein | `-MaximumRetryCount` | Die Spalte 5.1 ist das, was wir beobachtet haben; die Spalte 7.x folgt der [Invoke-WebRequest-Referenz für PowerShell 7.5](https://learn.microsoft.com/de-de/powershell/module/microsoft.powershell.utility/invoke-webrequest?view=powershell-7.5). ## Wie schickt Invoke-WebRequest eine Anfrage über einen Proxy? 1. **PowerShell löst den Hostnamen des Proxys auf**, nicht den des Ziels, und öffnet eine TCP-Verbindung zum Proxy-Port. 2. **Bei einem `http://`-Ziel schickt es die ganze URL an den Proxy** (`GET http://httpbin.org/ip HTTP/1.1`). Der Proxy holt die Seite und reicht sie weiter, er kann die Anfrage also lesen. 3. **Bei einem `https://`-Ziel schickt es `CONNECT httpbin.org:443`.** Sobald der Proxy mit `200 Connection Established` antwortet, läuft der TLS-Handshake mit der Website in diesem Tunnel; der Proxy sieht nur Hostname und Port. 4. **Zugangsdaten gehen erst nach einer Aufforderung hinaus.** Der erste Versuch trägt keinen `Proxy-Authorization`-Header, der Proxy antwortet mit `407` und `Proxy-Authenticate: Basic`, und .NET wiederholt die Anfrage mit dem Header. Der [Statuscode 407](https://www.rfc-editor.org/rfc/rfc9110.html#section-15.5.8) und die Aufforderung sind in RFC 9110 definiert; 5.1 authentifiziert nicht vorab, deshalb hat unser Test-Proxy jeden erfolgreichen Aufruf als dieses Paar protokolliert: ```text 11:02:56 407 GET http://httpbin.org/ip (no Proxy-Authorization) 11:02:56 GET http://httpbin.org/ip user=user ``` 5. **Das Ziel antwortet an die Exit-IP des Proxys.** Das Cmdlet gibt ein Objekt mit `StatusCode`, `Headers` und `Content` zurück; in 5.1 wird ein Status außerhalb von 2xx stattdessen zu einem abbrechenden Fehler. ## Wie nutzen Sie Invoke-WebRequest mit einem Proxy? Erstellen Sie ein Objekt mit den Zugangsdaten und übergeben Sie dem Cmdlet die Proxy-Adresse und das Objekt: ```powershell $pass = ConvertTo-SecureString "pass" -AsPlainText -Force $cred = New-Object System.Management.Automation.PSCredential ("user", $pass) $r = Invoke-WebRequest -UseBasicParsing -Uri "https://httpbin.org/ip" ` -Proxy "http://pr.proxynet.io:8000" -ProxyCredential $cred $r | Select-Object StatusCode, StatusDescription | Format-List $r.Content ``` ```text StatusCode : 200 StatusDescription : OK { "origin": "203.0.113.42" } ``` httpbin.org/ip gibt die Adresse zurück, von der die Anfrage kam; ein funktionierender Proxy zeigt dort also seine Exit-IP statt Ihrer. Der Wert von `-Proxy` ist eine URI und behält das Schema `http://` auch bei HTTPS-Zielen: Es beschreibt die Verbindung zum Proxy, während die Seite im CONNECT-Tunnel verschlüsselt bleibt. Beide Parameter sind auf der [Invoke-WebRequest-Seite für Windows PowerShell 5.1](https://learn.microsoft.com/de-de/powershell/module/microsoft.powershell.utility/invoke-webrequest?view=powershell-5.1) dokumentiert. **Ergänzen Sie in 5.1 immer `-UseBasicParsing`.** Ohne den Schalter parst das Cmdlet das HTML über die Engine des Internet Explorers, und seit Microsofts Sicherheitsupdate vom Dezember 2025 für CVE-2025-54100 fragt es vorher nach einer Bestätigung, die ein geplantes Skript nicht geben kann. In unserem Lauf scheiterte ein Aufruf ohne den Schalter mit `Object reference not set to an instance of an object.` PowerShell 7 beherrscht nur Basic Parsing und ignoriert den Schalter. `Invoke-RestMethod` nimmt dieselben Proxy-Parameter und gibt statt eines Antwortobjekts geparstes JSON zurück: ```powershell $ip = Invoke-RestMethod -Uri "https://api.ipify.org?format=json" ` -Proxy "http://pr.proxynet.io:8000" -ProxyCredential $cred $ip.ip ``` Bei den Residential- und Mobile-Produkten von Proxynet trägt der Benutzername Land, Stadt und Sitzung, die Sie im Endpoint-Generator des Panels gewählt haben; der Befehl bleibt also gleich, welchen Ausgang Sie auch wählen. ## Wie übergeben Sie die Zugangsdaten für den Proxy? Das Proxy-Passwort reist in einem `PSCredential`-Objekt, nie in der Adresse. `Get-Credential` fragt interaktiv danach; ein Skript baut das Objekt wie oben aus einem Secure String. Microsofts Seite zu `ConvertTo-SecureString` warnt, dass ein Klartext-Passwort auf der Befehlszeile in Ereignisprotokollen und im Befehlsverlauf landet; lesen Sie es daher aus einer Umgebungsvariablen oder einem Geheimnisspeicher: ```powershell $pass = ConvertTo-SecureString $env:PROXY_PASS -AsPlainText -Force $cred = New-Object System.Management.Automation.PSCredential ($env:PROXY_USER, $pass) ``` Drei Details aus unseren Tests: - **`user:pass@` in `-Proxy` wird in 5.1 ignoriert.** `-Proxy "http://user:pass@pr.proxynet.io:8000"` ohne `-ProxyCredential` endete mit `(407) Proxy Authentication Required`; im Proxy-Log kamen keine Zugangsdaten an. - **Sonderzeichen brauchen keine Kodierung.** Ein Passwort `p@ss:w#rd` kam über `PSCredential` unverändert an, wo die URL-Form `%40`, `%3A` und `%23` gebraucht hätte. - **Eine Websitzung behält den Proxy.** Nach `-Proxy ... -SessionVariable s` ging ein zweiter Aufruf nur mit `-WebSession $s` wieder über den Proxy; das Sitzungsobjekt speichert den Proxy neben den Cookies. `-ProxyUseDefaultCredentials` schickt stattdessen das Windows-Konto des aktuellen Benutzers, für Firmen-Proxys, die gegen die Domäne authentifizieren; laut Dokumentation lässt es sich nicht mit `-ProxyCredential` kombinieren. Hier ungetestet: Unser Proxy spricht nur Basic. Das Passwort entfällt ganz, wenn die IP des Rechners im Proxy-Panel freigegeben ist: `-Proxy "http://pr.proxynet.io:8000"` ist dann die ganze Einstellung. Proxynet akzeptiert bis zu 10 IPs auf der Whitelist, was zu geplanten Jobs auf einem Server mit fester Adresse passt. ## Wie setzen Sie den Proxy für jeden Befehl? `$PSDefaultParameterValues` ist eine Hashtabelle mit Schlüsseln der Form `Cmdlet:Parameter`, die PowerShell immer dann anwendet, wenn Sie den Parameter weglassen. Zwei Einträge pro Cmdlet genügen: ```powershell $PSDefaultParameterValues["Invoke-WebRequest:Proxy"] = "http://pr.proxynet.io:8000" $PSDefaultParameterValues["Invoke-WebRequest:ProxyCredential"] = $cred $PSDefaultParameterValues["Invoke-RestMethod:Proxy"] = "http://pr.proxynet.io:8000" $PSDefaultParameterValues["Invoke-RestMethod:ProxyCredential"] = $cred Invoke-RestMethod -Uri "https://api.ipify.org?format=json" # geht durch den Proxy ``` Die Schlüssel akzeptieren Platzhalter, `"Invoke-*:Proxy"` deckt also beide Cmdlets in einer Zeile ab; beide Formen funktionierten in unserem Test. Die Tabelle ist in jeder neuen Sitzung leer, sofern die Zeilen nicht in `$PROFILE` stehen, und ein Skript, das unter einem anderen Konto läuft, sieht Ihr Profil nie. Schreiben Sie die Parameter deshalb in allem, was Sie weitergeben, explizit aus. Ein einzelner direkter Aufruf mit `-Proxy $null` scheitert mit `The cmdlet cannot run because the following parameter is missing: Proxy`, solange ein Standardwert für `ProxyCredential` existiert. Schalten Sie die Tabelle stattdessen kurz ab: `$PSDefaultParameterValues["Disabled"] = $true`, den Aufruf ausführen, wieder auf `$false` setzen. In unserem Test ging der Aufruf mit `Disabled` direkt hinaus und der nächste wieder über den Proxy. ## Liest PowerShell HTTP_PROXY und HTTPS_PROXY? Windows PowerShell 5.1 nicht. Mit gesetztem `$env:HTTP_PROXY` und `$env:HTTPS_PROXY` und ohne `-Proxy`-Parameter ging unsere Anfrage direkt zum Ziel; der Proxy hat sie nie gesehen. `curl.exe`, `git` und `pip` auf demselben Rechner halten sich an die Variablen, daher die Verwirrung. PowerShell 7 liest sie laut seiner Dokumentation: Seit 7.0 beziehen die Cmdlets ihren Standard-Proxy aus .NETs `HttpClient.DefaultProxy`, das unter Windows zuerst `HTTP_PROXY`, `HTTPS_PROXY`, `ALL_PROXY` und die Ausnahmeliste `NO_PROXY` liest und auf die Proxy-Einstellungen des Benutzers zurückfällt, wenn die Variablen leer sind. ```powershell # Nur PowerShell 7; 5.1 ignoriert diese Variablen $env:HTTPS_PROXY = "http://pr.proxynet.io:8000" $env:NO_PROXY = "localhost,127.0.0.1,.internal.example" Invoke-WebRequest -Uri "https://httpbin.org/ip" # per Proxy Invoke-WebRequest -Uri "https://httpbin.org/ip" -NoProxy # direkt, nur dieser Aufruf ``` Zugangsdaten gehören weiterhin in `-ProxyCredential`, pro Aufruf oder über `$PSDefaultParameterValues`, genau wie in 5.1. ## Was ist mit dem System-Proxy von Windows und netsh winhttp? Ohne `-Proxy` fällt 5.1 auf den Proxy aus den Internetoptionen des aktuellen Benutzers zurück, die Einstellung, die Windows unter Einstellungen, Netzwerk und Internet, Proxy zeigt. Die Dokumentation des .NET Framework hält fest, dass `WebRequest.DefaultWebProxy` zuerst die Konfigurationsdatei der Anwendung liest und sonst den Proxy aus den Internetoptionen des Benutzers. Ein Skript, das plötzlich über einen unerwarteten Proxy hinausgeht, folgt meist dieser Einstellung; wo sie liegt, zeigt [Proxy-Einstellungen in Windows und Chrome](/de/blog/windows-chrome-proxy-settings). Windows führt einen zweiten Proxy-Speicher für WinHTTP, die HTTP-Bibliothek von Diensten und Systemkomponenten. Er wird mit `netsh winhttp` verwaltet und betrifft die PowerShell-Cmdlets nicht, die .NET nutzen. Die Befehle unten stammen aus Microsofts netsh-Referenz und wurden hier nicht ausgeführt, weil sie eine rechnerweite Einstellung ändern: ```text netsh winhttp show proxy netsh winhttp set proxy proxy-server="pr.proxynet.io:8000" bypass-list="*.internal.example" netsh winhttp import proxy source=ie netsh winhttp reset proxy ``` `set proxy` nimmt einen Server und eine durch Semikolons getrennte Ausnahmeliste, sonst nichts. Einen Proxy, der Benutzername und Passwort verlangt, konfigurieren Sie deshalb besser pro Skript mit `-ProxyCredential` oder machen ihn mit einer IP-Whitelist passwortfrei. ## Wie nutzen Sie den Proxy aus .NET-Klassen in einem Skript? Skripte, die `System.Net.WebClient` oder `HttpWebRequest` direkt aufrufen, sehen `-Proxy` nicht; sie lesen das prozessweite `WebRequest.DefaultWebProxy`. Einmal gesetzt, leitet es diese Klassen und in 5.1 jedes `Invoke-WebRequest` ohne eigenes `-Proxy` über den Proxy: ```powershell $proxy = New-Object System.Net.WebProxy("http://pr.proxynet.io:8000") $proxy.Credentials = New-Object System.Net.NetworkCredential("user", "pass") $proxy.BypassList = @("^http://intranet\.example\.") [System.Net.WebRequest]::DefaultWebProxy = $proxy (New-Object System.Net.WebClient).DownloadString("https://api.ipify.org") ``` Die Einstellung lebt nur in diesem PowerShell-Prozess. `BypassList` enthält reguläre Ausdrücke, die gegen die volle URL geprüft werden; in unserem Test wurde das Intranet-Muster umgangen, der öffentliche Host nicht. Eine Regel von `WebProxy` hat uns eine Stunde gekostet: **Anfragen an `localhost` oder `127.0.0.1` nutzen nie einen Proxy.** `IsBypassed` gab für beide `True` zurück, selbst mit `BypassProxyOnLocal` auf `False`, deshalb ging jeder Test gegen einen lokalen Webserver direkt hinaus und sah aus, als funktionierte der Proxy. Testen Sie gegen eine öffentliche Adresse oder geben Sie dem lokalen Server einen Hostnamen mit einem Punkt. ## Unterstützt Invoke-WebRequest SOCKS5? In Windows PowerShell 5.1 nicht. `-Proxy "socks5://pr.proxynet.io:1080"` bricht mit `The ServicePointManager does not support proxies with the socks5 scheme.` ab, und eine `https://`-Proxy-Adresse scheitert genauso; 5.1 spricht mit Proxys also nur über reines HTTP. PowerShell 7.2 und neuer laufen auf .NET 6 oder höher, und Microsofts [Ankündigung zum Netzwerk in .NET 6](https://devblogs.microsoft.com/dotnet/dotnet-6-networking-improvements/) dokumentiert die Unterstützung von SOCKS4, SOCKS4a und SOCKS5 in `HttpClient` über eine `socks5://`-Proxy-Adresse. Die Cmdlet-Referenz erwähnt SOCKS nicht, und wir konnten 7 hier nicht ausführen; behandeln Sie `-Proxy "socks5://pr.proxynet.io:1080"` daher als etwas, das Sie auf Ihrer Version prüfen. Unter 5.1 ist der praktische Weg das echte cURL, das Windows 10 und 11 mitbringen: `curl.exe -x "socks5h://user:pass@pr.proxynet.io:1080" https://httpbin.org/ip`, mit `socks5h`, damit der Proxy den Hostnamen auflöst. Die Optionen erklärt [cURL mit Proxy verwenden](/de/blog/curl-proxy); setzen Sie anstelle von 1080 den SOCKS5-Port ein, den Ihr Endpoint-Generator anzeigt. ## Beispiel: eine URL-Liste mit Wiederholungen über einen Proxy abrufen Das Skript lädt eine Liste von URLs über den Proxy, wiederholt vorübergehende Fehler mit wachsender Pause, bricht bei einem 407 sofort ab und gibt pro URL eine Zeile aus. Es braucht nur Windows PowerShell 5.1: ```powershell # fetch.ps1: jede URL der Liste per Proxy, mit Wiederholungen $ErrorActionPreference = "Stop" $ProxyUri = "http://pr.proxynet.io:8000" $ProxyCred = New-Object System.Management.Automation.PSCredential ( "user", (ConvertTo-SecureString "pass" -AsPlainText -Force)) $urls = @( "https://httpbin.org/ip", "https://httpbin.org/status/503", "https://httpbin.org/status/404", "https://httpbin.org/headers" ) $retryCodes = 408, 429, 500, 502, 503, 504 function Get-WithRetry { param([string]$Url, [int]$Attempts = 4) for ($i = 1; $i -le $Attempts; $i++) { $sw = [System.Diagnostics.Stopwatch]::StartNew() try { $r = Invoke-WebRequest -UseBasicParsing -Uri $Url -Proxy $ProxyUri -ProxyCredential $ProxyCred -TimeoutSec 30 return [pscustomobject]@{ Url = $Url; Status = $r.StatusCode; Attempts = $i; Ms = $sw.ElapsedMilliseconds; Bytes = $r.RawContentLength } } catch [System.Net.WebException] { $code = 0 if ($_.Exception.Response) { $code = [int]$_.Exception.Response.StatusCode } if ($code -eq 407) { throw "Proxy refused the credentials (407). Check user:pass or the IP whitelist." } if (($code -in $retryCodes -or $code -eq 0) -and $i -lt $Attempts) { $wait = [math]::Pow(2, $i - 1) # 1, 2, 4 Sekunden Write-Warning "$Url -> $code ($($_.Exception.Status)); retry $i in $wait s" Start-Sleep -Seconds $wait continue } return [pscustomobject]@{ Url = $Url; Status = $code; Attempts = $i; Ms = $sw.ElapsedMilliseconds; Bytes = 0 } } } } $results = foreach ($u in $urls) { Get-WithRetry -Url $u } $results | Format-Table -AutoSize ``` In unserem Lauf antwortete die Adresse `/status/503` zweimal mit 503, wurde nach 1 und 2 Sekunden wiederholt und war beim dritten Versuch erfolgreich, weil sich der Testserver erholt; der 404 kam ohne Wiederholung zurück: ```text WARNING: https://httpbin.org/status/503 -> 503 (ProtocolError); retry 1 in 1 s WARNING: https://httpbin.org/status/503 -> 503 (ProtocolError); retry 2 in 2 s Url Status Attempts Ms Bytes --- ------ -------- -- ----- https://httpbin.org/ip 200 1 34 55 https://httpbin.org/status/503 200 3 11 65 https://httpbin.org/status/404 404 1 3 0 https://httpbin.org/headers 200 1 10 250 ``` Drei Entscheidungen zählen. `$_.Exception.Response.StatusCode` ist die einzige Stelle, an der 5.1 den Status einer gescheiterten Anfrage preisgibt, weil ein 4xx oder 5xx geworfen statt zurückgegeben wird. Ein `$code` von `0` bedeutet gar keine Antwort, etwa ein Timeout, und wird ebenfalls wiederholt. `-TimeoutSec 30` begrenzt einen Versuch; der Standardwert 0 wartet unbegrenzt. PowerShell 7 hat `-MaximumRetryCount 3 -RetryIntervalSec 2` eingebaut, und laut Dokumentation setzt ein 429 mit `Retry-After` das Intervall außer Kraft. Jedes `Invoke-WebRequest` öffnet eine eigene Verbindung zum Proxy, ein rotierendes Gateway gibt also jedem Aufruf eine andere Exit-IP. Ein Login mit mehreren Folgeseiten braucht das Gegenteil: Eine Sticky-Sitzung im Benutzernamen hält auf einem [Residential-Proxy](https://proxynet.io/de/residential-proxy) 1 bis 60 Minuten lang dieselbe IP, während `-SessionVariable` die Cookies auf Ihrer Seite behält. ## Wo kommen PowerShell-Proxy-Skripte zum Einsatz? Geplante Aufgaben sind der übliche Ort: Ein nächtlicher Job prüft Preis und Lagerbestand Ihrer eigenen Angebote so, wie ein Käufer aus einem anderen Land sie sieht, ein Überwachungsskript ruft Ihre Website aus mehreren Regionen ab und schlägt bei falscher Währung oder Sprache Alarm, ein Build-Agent hinter einem Firmen-Proxy installiert Module darüber. Eine Partner-API, die nur eine Adresse zulässt, wird aus einem Job erreicht, dessen Ausgang sich nie ändert; ein [ISP-Proxy](https://proxynet.io/de/static-isp-residential-proxy) gibt diesem Job eine dedizierte IP, die Neustarts übersteht. ## Häufige PowerShell-Proxy-Fehler und ihre Lösung Die Meldungen, wie Windows PowerShell 5.1 sie mit englischer Oberfläche ausgibt; auf einem deutschen oder türkischen Windows ist der .NET-Anteil des Texts lokalisiert. - **`The remote server returned an error: (407) Proxy Authentication Required.`** Kein `-ProxyCredential`, Zugangsdaten in der Adresse, ein falsches Passwort oder eine IP, die auf der Whitelist fehlt. `$_.Exception.Response.StatusCode.value__` liefert in einem `catch`-Block `407`; die Ursachen sind in [HTTP 407 Proxy Authentication Required beheben](/de/blog/http-407-proxy-authentication-required) gesammelt. - **`Unable to connect to the remote server`** mit `Status : ConnectFailure`. Falscher Proxy-Port, eine Firewall dazwischen oder der Proxy ist nicht erreichbar. - **`The proxy name could not be resolved: 'pr.proxynet.io'`**. Ein Tippfehler im Hostnamen oder kein DNS; die Meldung nennt den Proxy, nicht das Ziel. - **`The operation has timed out.`** `-TimeoutSec` ist kürzer, als Proxy und Ziel brauchen; unser 2-Sekunden-Limit gegen eine 5-Sekunden-Seite hat sie erzeugt. - **`The ServicePointManager does not support proxies with the socks5 scheme.`** Eine `socks5://`- oder `https://`-Proxy-Adresse in 5.1; nutzen Sie `http://`, PowerShell 7.2+ oder `curl.exe`. - **`A parameter cannot be found that matches parameter name 'x'.`** Ein cURL-Befehl, der in 5.1 eingetippt wurde, wo `curl` ein Alias von `Invoke-WebRequest` ist; schreiben Sie `curl.exe`. - **`Object reference not set to an instance of an object.`** Ein 5.1-Aufruf ohne `-UseBasicParsing` in einem Skript. - **`The cmdlet cannot run because the following parameter is missing: Proxy.`** `-Proxy $null`, während `$PSDefaultParameterValues` noch ein `ProxyCredential` hält; nutzen Sie stattdessen den Schlüssel `Disabled`. - **Der Proxy wird stillschweigend übergangen.** Das Ziel ist `localhost` oder `127.0.0.1`, oder das Skript verlässt sich in 5.1 auf `HTTPS_PROXY`. Vergleichen Sie `api.ipify.org` mit und ohne `-Proxy`. ## Entscheidungshilfe | Bedarf | Empfehlung | |---|---| | Ein Befehl über den Proxy | `-Proxy` plus `-ProxyCredential` | | Jeder Befehl einer Sitzung | `$PSDefaultParameterValues` in `$PROFILE` | | Kein Passwort im Skript | IP-Whitelist im Panel, nur `-Proxy` | | Firmen-Proxy mit Windows-Anmeldung | `-ProxyUseDefaultCredentials` | | Ein Aufruf ohne Proxy | `-NoProxy` (7) oder der Schlüssel `Disabled` (5.1) | | SOCKS5 | PowerShell 7.2+ oder `curl.exe` mit `socks5h://` | | Code mit `WebClient` oder `HttpWebRequest` | `[System.Net.WebRequest]::DefaultWebProxy` | | Dieselbe Exit-IP für einen Login-Ablauf | Sticky-Sitzung im Benutzernamen | | Dienste und Windows Update | `netsh winhttp set proxy` | ## Häufige Fragen ### Wie setze ich einen Proxy für Invoke-WebRequest? Ergänzen Sie `-Proxy "http://host:port"` und, wenn der Proxy ein Passwort verlangt, `-ProxyCredential` mit einem `PSCredential`-Objekt. Dieselben zwei Parameter gibt es bei `Invoke-RestMethod` und, laut der Dokumentation zu PowerShellGet 2.x, bei `Install-Module`. ### Warum gibt Invoke-WebRequest 407 Proxy Authentication Required zurück? Weil der Proxy keine brauchbaren Zugangsdaten erhalten hat. In 5.1 passiert das, wenn Benutzername und Passwort in die Adresse statt in `-ProxyCredential` geschrieben wurden, wenn das Passwort falsch ist oder wenn der Proxy Ihre IP auf einer Whitelist erwartet und sich die Adresse des Rechners geändert hat. ### Nutzt Invoke-WebRequest die Proxy-Einstellungen von Windows? Ja, wenn Sie kein `-Proxy` angeben. Windows PowerShell 5.1 nimmt den Proxy aus den Internetoptionen des aktuellen Benutzers; PowerShell 7 liest zuerst `HTTP_PROXY` und `HTTPS_PROXY` und fällt auf die Einstellungen des Benutzers zurück. Der mit `netsh winhttp` gesetzte WinHTTP-Proxy ist ein eigener Speicher und wird von keiner der beiden Versionen gelesen. ### Wie umgehe ich den Proxy in PowerShell für eine einzelne Anfrage? In PowerShell 7 ergänzen Sie diesen Aufruf um `-NoProxy`. In 5.1 lassen Sie `-Proxy` weg; fügt `$PSDefaultParameterValues` ihn trotzdem hinzu, setzen Sie rund um den Aufruf `$PSDefaultParameterValues["Disabled"] = $true`. Für ganze Hosts nutzen Sie `NO_PROXY` in 7 oder eine `BypassList` an einem `WebProxy`-Objekt in 5.1. ### Kann ich einen SOCKS5-Proxy mit Invoke-WebRequest verwenden? Nicht in Windows PowerShell 5.1, das das Schema `socks5://` ablehnt. PowerShell 7.2 und neuer laufen auf .NET 6+, das SOCKS5-Proxys in `HttpClient` unterstützt; prüfen Sie es auf Ihrer Version. Rufen Sie unter 5.1 stattdessen `curl.exe` mit `socks5h://` auf. ### Wie prüfe ich, ob PowerShell den Proxy wirklich nutzt? Rufen Sie `https://api.ipify.org` einmal ohne und einmal mit `-Proxy` ab: Zwei verschiedene Adressen, die zweite im Land des Proxys, bedeuten, dass der Proxy genutzt wird. Dieselbe Adresse zweimal heißt, der Aufruf ging direkt hinaus, meist weil das Ziel `localhost` war oder weil 5.1 die gesetzten Variablen ignoriert hat. ## Fazit Übergeben Sie den Proxy an `Invoke-WebRequest` und `Invoke-RestMethod` mit `-Proxy` und einem `PSCredential` in `-ProxyCredential`, nie in der Adresse; setzen Sie beides einmal in `$PSDefaultParameterValues`, wenn jeder Aufruf ihn nutzen soll. Windows PowerShell 5.1 ignoriert `HTTP_PROXY`, fällt auf die Internetoptionen zurück, umgeht Loopback-Adressen und kann kein SOCKS5; PowerShell 7 liest die Variablen, bringt `-NoProxy` und Wiederholungen mit und akzeptiert SOCKS5 ab 7.2. Behalten Sie `-UseBasicParsing` und `-TimeoutSec` in jedem 5.1-Skript und testen Sie gegen eine öffentliche Adresse. Endpunkte, die genau diese Parameter annehmen, finden Sie auf der [Proxy-Seite von Proxynet](/de/proxy).