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.

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.

Die Spalte 5.1 ist das, was wir beobachtet haben; die Spalte 7.x folgt der Invoke-WebRequest-Referenz für 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 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:

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:

$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

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 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:

$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:

$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:

$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.

# 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.

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:

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:

$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 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; 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:

# 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:

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 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 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 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#

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.