System.Net.WebProxy の BypassList 引数には正規表現を指定します。*.office.example のようなパターンは、先頭のアスタリスクが繰り返す対象の式を持たないため無効です。

office.example とそのサブドメインへの HTTP および HTTPS リクエストには、PowerShell の構成で次を使えます。

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

エスケープしたドットは文字どおりのドットに一致します。繰り返されるホスト名ラベルのグループは、基底ドメインとその配下の名前の両方を許可します。アンカーにより office.example.other.test のような名前はこの規則の外に保たれます。単一引用符の PowerShell 文字列は、式が使うバックスラッシュをそのまま保持します。

現在の .NET 実装は、これらの式を宛先のスキーム、ホスト名、非既定ポートと照合します。リクエストのパスやクエリ文字列は含みません。そのため省略可能なポートのグループは非既定ポートも許可します。ポリシーが特定のサービスを要求する場合は、このグループを削除するか狭めてください。

この例では BypassProxyOnLocal を false にして、正規表現ポリシーをその追加のバイパス設定とは別に確認できるようにしています。生成したプロキシ オブジェクトは、それを使うべき HTTP クライアントに接続します。バイパス ドメイン外の許可された公開 URL のテストには、HTTP proxy list の HTTP エントリがそのアドレスを提供できます。プロキシ アカウントは構成しません。

IsBypassed を代表的な Uri 値で使って、ルーティングの判定を調べます。基底ドメイン、1 つのサブドメイン、無関係な外部ホスト、そして紛らわしい長い接尾辞です。true の結果は直接アクセスが選ばれたことを意味しますが、直接の宛先に到達できることを証明するものではありません。

関連記事