Windowsの「プロキシ設定」は一種類ではありません。対話ユーザーが使うWindowsのインターネット設定、WinHTTPを使うサービスやシステムコンポーネント、環境変数、各アプリ固有設定、PACやWPAD、企業のネットワーク制御が共存します。PowerShellで確認するときは、どのアプリ・ユーザー・実行方式の通信を調べるのかを先に決め、複数の層を読み取り専用で照合します。本記事では安全な確認手順と結果の解釈を整理します。
最初に「誰の何の通信か」を確認する
ブラウザー、Windows Update、PowerShell、サービス、業務アプリでは参照するプロキシが異なることがあります。現在サインイン中ユーザー、管理者、SYSTEM、サービスアカウントでも設定は別です。発生アプリ、実行アカウント、接続先URL、社内外、VPN、発生時刻を記録し、「システムプロキシ」という一語でまとめません。
同じ端末でEdgeは開けるがサービスは失敗する場合、ユーザー側設定とWinHTTP側の差が手掛かりになります。PowerShell 5.1と7、.NETアプリでも既定プロキシの扱いが異なる場合があります。アプリの公式文書で参照先を確認し、設定値があることと実際に使われていることを分けて検証します。
Windows設定画面の状態を利用者と照合する
Windows 11では「設定」「ネットワークとインターネット」「プロキシ」で、自動検出、セットアップスクリプト、手動プロキシを確認できます。画面は現在の利用者コンテキストで確認し、スクリーンショットに内部アドレスや認証情報が含まれないか注意します。組織によって管理されている項目は利用者が回避しません。
設定画面とPowerShellの取得値が異なる場合、ユーザー違い、32/64ビット、ポリシー、反映待ち、アプリ独自設定を確認します。表示がオフでもPACやWPAD、VPNクライアント、セキュリティエージェントが経路を制御する場合があります。画面一枚だけで「プロキシなし」と判断しません。
ユーザーのInternet Settingsを読み取る
現在ユーザーの代表的な値はGet-ItemProperty -LiteralPath "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" | Select-Object ProxyEnable,ProxyServer,AutoConfigURLで読み取れます。ProxyEnableは手動プロキシ、ProxyServerはサーバー指定、AutoConfigURLは構成スクリプトURLの手掛かりです。値が存在しない場合もあります。
レジストリ値を直接変更する方法は、ポリシーとの競合、画面との不整合、資格情報、例外形式を誤るおそれがあるため、確認記事では扱いません。取得したProxyServerやAutoConfigURLは内部ネットワーク情報です。ログや公開チャットへそのまま貼らず、必要な担当者だけが閲覧できる場所へ保存します。
WinHTTPプロキシは別に確認する
サービスや一部Windowsコンポーネントが使うWinHTTP設定は、netsh winhttp show proxyで確認できます。PowerShellから実行しても、これはnetshのWinHTTPコンテキストを呼び出すコマンドです。Direct accessと表示されても、ユーザーのブラウザー設定やアプリ固有プロキシがないことを意味しません。
WinHTTPには静的プロキシ、バイパス、設定ソースなどが関係します。設定を変更するnetsh winhttp setやresetは通信へ広く影響するため、確認と同じ手順で実行しません。変更が必要なら、対象サービス、現行値、ポリシー、バックアップ、保守時間、戻し方を管理者が準備します。
環境変数とプロセス単位設定を見る
クロスプラットフォームツールや開発ツールはHTTP_PROXY、HTTPS_PROXY、NO_PROXYなどの環境変数を参照する場合があります。Get-ChildItem Env: | Where-Object Name -match "(?i)proxy"で現在のPowerShellプロセスから見える変数名と値を確認できます。ただし変数の対応はアプリごとに異なります。
環境変数にユーザー名やパスワードを含むプロキシURLが設定されると、プロセス一覧、ログ、履歴へ漏れる危険があります。値を共有するときは資格情報やトークンを伏せます。ユーザー環境、マシン環境、タスクやサービスが起動時に継承した環境は異なるため、実際の実行アカウントとプロセスで確認します。
PAC・自動検出・バイパスを理解する
AutoConfigURLがある場合、PACファイルのJavaScriptロジックがURLやホストに応じてDIRECTまたは複数プロキシを返します。設定URLへ到達できること、PACの配布、DNS、認証、キャッシュを確認します。PAC内容を無断で編集せず、管理者が版管理とテストを行います。WPADによる自動検出もDNSやDHCP、セキュリティ方針に依存します。
バイパス一覧では、ローカルアドレス、特定ドメイン、ワイルドカードなどが使われます。表記を誤ると内部サイトが外部プロキシへ送られたり、外部サイトが直接接続されたりします。現在値の確認では、どのURLがどの経路になるかを代表サイトでテストし、秘密情報を含むURLを使わないようにします。
実際のアプリ通信で設定を検証する
設定値を確認したら、問題のアプリと同じユーザー・同じネットワークで許可されたテストURLへ接続します。PowerShellならInvoke-WebRequest、TCPだけならTest-NetConnectionを使えますが、アプリが異なるプロキシスタックを使う可能性を考慮します。状態コード、認証、証明書、最終URL、応答時間を記録します。
プロキシがTLS検査を行う環境では、端末へ企業の信頼証明書が正規配布されている必要があります。証明書エラーを回避するため検証を無効化せず、証明書チェーン、端末時刻、対象ホスト、プロキシのポリシーを確認します。407 Proxy Authentication Requiredはプロキシ到達後の認証問題であり、単純なネットワーク不通とは異なります。
リモート収集とトラブル時の記録
リモート端末のHKCUは、コマンドを実行するアカウントのユーザーハイブを示し、問題の利用者と一致しない場合があります。利用者ごとの値を無断で読み取らず、組織のプライバシーとサポート手順に従います。WinHTTPは端末単位でも、アプリサービスの実行条件と合わせて確認します。
報告には、ユーザー側ProxyEnable、ProxyServer、AutoConfigURLの有無、WinHTTP表示、環境変数名、VPN、テストURL、結果、取得時刻を分けて記録します。資格情報、PAC全文、内部ホスト一覧は必要最小限にします。変更後は、対象アプリ、Windows Update、ブラウザーなど影響を受ける代表通信を確認します。
実務での確認チェックリスト
- 対象アプリと実行ユーザー・サービスアカウントを特定する
- Windowsのユーザー設定、WinHTTP、環境変数、アプリ固有設定を分ける
- HKCUのProxyEnable、ProxyServer、AutoConfigURLを読み取り確認する
- netsh winhttp show proxyの結果をユーザー設定と混同しない
- PAC、WPAD、バイパス、VPNの経路を代表URLで検証する
- プロキシURLやログから資格情報・内部情報を除いて共有する
コメント