Das Argument BypassList von System.Net.WebProxy enthält reguläre Ausdrücke. Ein Muster wie *.office.example ist ungültig, weil der führende Stern keinen vorangehenden Ausdruck hat, den er wiederholen könnte.

Für HTTP- und HTTPS-Anfragen an office.example und seine Subdomains kann eine PowerShell-Konfiguration Folgendes verwenden:

$bypass = @('^https?://([a-z0-9-]+\.)*office\.example(:[0-9]+)?$')
$proxy = [System.Net.WebProxy]::new(
    'http://proxy.example:8080',
    $false,
    [string[]]$bypass
)

Die maskierten Punkte entsprechen wörtlichen Punkten. Die wiederholte Gruppe für Hostnamen-Labels lässt sowohl die Basisdomain als auch Namen darunter zu. Die Anker halten einen Namen wie office.example.other.test aus dieser Regel heraus. Einfach quotierte PowerShell-Zeichenketten erhalten die Backslashes, die der Ausdruck verwendet.

Die aktuelle .NET-Implementierung vergleicht diese Ausdrücke mit Schema, Hostname und nicht standardmäßigem Port des Ziels. Sie umfasst weder den Anforderungspfad noch die Abfragezeichenfolge. Die optionale Portgruppe erlaubt daher auch nicht standardmäßige Ports; entfernen oder verengen Sie sie, wenn die Richtlinie einen bestimmten Dienst verlangt.

BypassProxyOnLocal ist in diesem Beispiel false, damit die Regex-Richtlinie getrennt von dieser zusätzlichen Ausnahmeeinstellung geprüft werden kann. Hängen Sie das resultierende Proxyobjekt an den HTTP-Client, der es verwenden soll. Für einen erlaubten Test einer öffentlichen URL außerhalb der Ausnahmedomain kann ein HTTP-Eintrag aus der HTTP proxy list seine Adresse liefern, ohne konfiguriertes Proxykonto.

Nutzen Sie IsBypassed mit repräsentativen Uri-Werten, um die Routingentscheidung zu prüfen: die Basisdomain, eine Subdomain, einen unabhängigen externen Host und ein irreführend längeres Suffix. Ein true-Ergebnis bedeutet, dass direkter Zugriff gewählt wurde; es belegt nicht, dass das direkte Ziel erreichbar ist.

Ähnliche Artikel