システムエンジニアXの「プログラミング以外」の話 50代会社員SEのお仕事・副業・システム運用の経験談
トラブル Windows 11 プロキシ ネットワーク運用 情シス WinINET WinHTTP トラブルシューティング

【検証】Windows 11プロキシ例外の書き方とアスタリスク・後方一致の罠

公開:

※本記事には広告を含みます。

はじめに

社内のWebシステムや特定のクラウドサービスをプロキシ経由させずに直接アクセスさせようとして、Windowsの「プロキシの例外リスト」にドメインを登録したものの、なぜかバイパスされずに通信エラーになった経験はないでしょうか。

私も過去に、社内SaaSの移行プロジェクトでプロキシ例外を設定した際、「*.example.com」と書いたためにルートドメインの「example.com」だけがプロキシへ飛んでしまい、原因究明に丸一日頭を抱えた苦い経験があります。

Windows 11におけるプロキシ例外リストの挙動は、公式ドキュメントの記述が非常に簡潔であるため、ワイルドカード（*）の扱いや後方一致の仕様を誤解しやすいポイントです。

この記事では、Windows 11環境で「abc.net」「*.abc.net」「.abc.net」を登録した際の実機検証結果をもとに、正しい記述ルールとトラブルシューティング手順を徹底解説します。

読み終えるころには、どのパターンで書けば意図通りにバイパスできるのかを迷わず判断できるようになります。

この記事の要点

  • Windows 11のWinINET（Edge/Chrome等）では、abc.net と書くだけでサブドメイン（sub.abc.net）も自動的に後方一致でバイパスされる
  • 逆に *.abc.net と明示すると、サブドメインはバイパスされるが、ホスト名なしのルートドメイン（abc.net）がバイパス対象から外れる罠がある
  • プロキシ例外リストには「2064バイト（文字）の上限制限」があり、大量登録時はPACファイル（WPAD）への移行が必要になる
項目 動作確認・検証環境
検証年月 2026年3月
対象OS Windows 11 Pro 23H2 / 24H2
対象ブラウザ Microsoft Edge (Chromium版) / Google Chrome
設定箇所 Windows設定（GUI）/ GPO / レジストリ（ProxyOverride）

結論：「abc.net」と「*.abc.net」の違いと後方一致の仕様

結論からお伝えすると、Windows 11のプロキシ例外リストでは 「abc.net」とドメイン名のみを記述するのが最も安全で推奨される書き方 です。

Windowsの標準プロキシエンジン（WinINET）は、ドメイン名を記述した場合に「暗黙的な後方一致」として評価します。そのため、アスタリスク（*）を付けなくてもサブドメインまですべて自動的にバイパスされます。

1. 「abc.net」と書いたときの挙動（実はサブドメインも含む）

abc.net と例外リストに登録した場合、以下のURLはすべてプロキシをバイパス（直接接続）します。

  • https://abc.net（ルートドメイン）
  • https://sub.abc.net（第3レベルドメイン）
  • https://app.dev.abc.net（深層サブドメイン）

Windowsは前方一致ではなく、右側からのドメイン一致（サフィックス一致）として判定するため、abc.net 単体で傘下の全ホストをカバーできます。

2. 「*.abc.net」と書いたときの挙動（ルートドメインが外れる罠）

一方で、*.abc.net とアスタリスクを先頭に付けた場合、挙動に予期せぬ落とし穴が生じます。

  • https://sub.abc.net → バイパスされる（直接接続）
  • https://abc.net → プロキシを経由してしまう（バイパスされない）

アスタリスクは「1文字以上の任意の文字列」として解釈されるため、ドットの前に何もないルートドメイン（abc.net）にはマッチしなくなります。

3. 構文別マッチング対照表

記述パターンによるアクセスの違いを以下の表にまとめました。

登録した例外文字列 abc.net へのアクセス sub.abc.net へのアクセス testabc.net へのアクセス 推奨度
abc.net 直接接続（バイパス） 直接接続（バイパス） プロキシ経由 ★★★（推奨）
*.abc.net プロキシ経由（除外失敗） 直接接続（バイパス） プロキシ経由 ★☆☆（非推奨）
.abc.net プロキシ経由（除外失敗） 直接接続（バイパス） プロキシ経由 ★☆☆（非推奨）
*abc.net 直接接続（バイパス） 直接接続（バイパス） 直接接続（意図せずマッチ） ☆☆☆（危険）

上記のように、*abc.net とドットなしでアスタリスクを付けると、まったく無関係な testabc.net や fakeabc.net まで意図せず直接接続になってしまいます。セキュリティ上も推奨されません。

【実機検証】Windows 11でのプロキシバイパス判定テスト

Windows 11の実機環境において、Microsoft EdgeおよびGoogle Chromeを使って実際の通信経路を検証しました。

Edge / Chrome（WinINET）での通信検証

Windows 11の「設定」>「ネットワークとインターネット」>「プロキシ」を開き、「次のエントリで始まるアドレスを除くすべてのプロキシサーバーを使用する」に以下の値を入力して検証を行いました。

abc.net;<local>

Edgeのアドレスバーから https://sub.abc.net へアクセスし、プロキシサーバー（Squid / Fiddler）側のアクセスログを確認したところ、ログにリクエストは一切記録されず、クライアントPCから直接DNS名前解決とTCP接続が行われていることを確認できました。

この検証結果から、一般的なWeb閲覧（Edge/Chrome）の例外設定では「*.」を付ける必要は一切ない ことが実証されました。

PowerShell / WinHTTP での挙動差異

コマンドラインツール（PowerShellの Invoke-WebRequest やバックグラウンドのOSサービス）は、WinINETではなく WinHTTP という別の通信スタックを使用する場合があります。

WinHTTPのプロキシ設定は、通常以下のコマンドでWinINETからインポートして同期します。

# 現在のWinHTTPプロキシ設定を確認
netsh winhttp show proxy

# ブラウザ（WinINET）の設定をWinHTTPにコピー
netsh winhttp import proxy source=ie

WinHTTPにおいても、abc.net のサフィックス一致ルールはWinINETと同様に機能します。ただし、プログラム内部で独自のプロキシハンドリングを行っている特殊なCLIツールでは、*.abc.net 形式でなければワイルドカードとして認識しないライブラリ（PythonのRequestsや一部のJavaアプリ等）も存在します。ブラウザ以外のツールで通信する場合は個別検証が必要です。

現場でハマる「プロキシ例外リスト」3つの落とし穴

現場のインフラ運用において、プロキシ例外設定でトラブルになりやすい代表的な落とし穴を3つ紹介します。

落とし穴1：最大文字数（2064バイト制限）の壁とレジストリ

プロキシ例外をGUIやGPOで登録し続けると、ある日突然「新しく追加したドメインだけプロキシを経由してしまう」という現象が発生します。

Windowsのプロキシ例外設定は、以下のレジストリ値にセミコロン区切りの文字列として格納されます。

キー: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings
名前: ProxyOverride
種類: REG_SZ

この ProxyOverride の値には、合計で2064バイト（全角・半角含め約2000文字）という上限 が存在します。上限を超えて文字列を書き込んだ場合、Windowsは超過部分を無視するか、設定全体を不正として読み込みを破棄します。

落とし穴2：IPアドレスやCIDR（192.168.1.0/24）は直接書けない

例外リストに社内LANのサブネットをまとめて登録しようとして、192.168.1.0/24 や 10.0.0.0/8 のようなCIDR表記を書いてしまうミスが多発しています。

Windowsのプロキシ例外リストは CIDR表記に対応していません。IPアドレスを指定する場合は、以下のようにアスタリスクを用いたオクテット単位のワイルドカードで記述する必要があります。

192.168.1.*;10.*.*.*

落とし穴3：末尾の「<local>」の書き忘れ

「イントラネット（社内LAN）のアドレスにはプロキシを使用しない」というチェックボックスをGUIでオンにすると、レジストリの末尾に <local> という特殊トークンが付与されます。

GPO（グループポリシー）やスクリプトで直接例外リストを配布する際に、この <local> を含め忘れると、http://fileserver/ や http://portal/ のような「ドットを含まないホスト名（単純名）」へのアクセスがすべて社外プロキシに転送され、社内システムが開かなくなります。

必ずリストの末尾に ; <local> を付与してください。

文字数制限に達したときの現実的な回避策（PACファイルの活用）

プロキシ例外に登録したいSaaSや社内ドメインが増加し、2064文字の壁にぶつかった場合は、静的な例外リストの運用を終了し、PACファイル（Proxy Auto-Configuration） へ移行するのが現場におけるベストプラクティスです。

PACファイル（JavaScript形式）を使用すれば、文字数制限を受けることなく、CIDRによるIP判定や複雑な条件分岐を柔軟に記述できます。

function FindProxyForURL(url, host) {
    // ローカルホストおよび社内プライベートIPは直接接続
    if (isPlainHostName(host) ||
        isInNet(dnsResolve(host), "10.0.0.0", "255.0.0.0") ||
        isInNet(dnsResolve(host), "192.168.0.0", "255.255.0.0")) {
        return "DIRECT";
    }

    // 特定ドメインとそのサブドメインを直接接続
    if (dnsDomainIs(host, "abc.net") ||
        dnsDomainIs(host, ".abc.net")) {
        return "DIRECT";
    }

    // それ以外は社内プロキシサーバーを経由
    return "PROXY proxy.corp.local:8080";
}

上記のPACファイルを社内Webサーバーに配置し、Windows設定の「セットアップスクリプトを使う」またはGPOでURLを配布することで、メンテナンス性が大幅に向上します。

よくある質問（FAQ）

Q: ポート番号を指定してプロキシ例外を設定できますか？

A: ポート番号を指定した例外設定は可能です。例えば abc.net:8443 のようにドメインやIPアドレスの後ろにコロンとポート番号を記述することで、特定ポートへのアクセスのみをバイパス対象に指定できます。ポート番号を省略した場合はすべてのポートが対象となります。

Q: GPOで配布したプロキシ例外がクライアントに反映されているか確認するコマンドは？

A: PowerShellで以下のコマンドを実行し、レジストリの ProxyOverride 値を確認するのが最も確実です。

Get-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" | Select-Object ProxyEnable, ProxyServer, ProxyOverride

設定が反映されていない場合は、gpupdate /force を実行した上で、再度コマンドを実行してレジストリ値が更新されているかを確認してください。

まとめ

Windows 11におけるプロキシ例外リストの設計ポイントは以下の通りです。

  • サブドメインを含めてバイパスしたい場合は、アスタリスクを付けずに 「abc.net」 とシンプルに記述する
  • 「*.abc.net」 と書くとルートドメインがプロキシ経由になってしまうため原則避ける
  • ドットなしの単一ホスト名通信を維持するために、必ず末尾に 「<local>」 を含める
  • 登録ルールが増えて2064文字の上限に近づいたら、無理に例外リストを広げず PACファイルの導入 を検討する

仕様を正確に把握しておくことで、ネットワーク移行時やトラブル発生時にも慌てず迅速な切り分けが可能になります。

関連記事

免責規定

この記事で提供される情報は、一般的なガイダンスを目的としており、すべての環境やシステムでの動作を保証するものではありません。

OSのバージョンやリリースによっては、記載されている事が実行できない、または異なる結果をもたらす可能性があります。 また、会社所有のパソコン、スマホ、タブレットなどでは、ポリシーや権限によって実行できない場合があります。

この記事の情報を使用することによって生じる問題や結果について、筆者およびサイト管理者は責任を負いません。 すべての操作は自己責任で行ってください。

最後までお読みいただきありがとうございました。
またお会いしましょう！
← 記事一覧に戻る