PowerShellを活用してシステムのプロキシ設定を確認・変更する手順

Windowsのプロキシ設定は一つではありません。現在のユーザーのWindows設定、WinHTTP、HTTP_PROXYなどの環境変数、アプリ独自の設定を分けて確認します。netsh winhttpを変更しても、すべてのアプリの通信がそのプロキシを通るわけではありません。

この記事はWindows上のPowerShellで設定を確認し、承認された範囲だけ変更するためのガイドです。会社・学校の端末では管理者の指定を優先してください。プロキシの変更は通信先や認証情報の送信先に関係するため、接続障害を直す目的でも管理ポリシーを回避しません。例は公式資料に基づくもので、実機での接続テストはしていません。

目次

まず対象のアプリ・ユーザー・PowerShellの版を特定する

$PSVersionTable.PSVersion
whoami

Windows PowerShell 5.1とPowerShell 7は同じものではありません。PowerShell 7はWindows PowerShellと別に導入されるため、Windows搭載という理由だけで7の機能を前提にしないでください。また、別の管理者アカウントで起動した場合、HKCUはその管理者の設定を指します。サービスの実行アカウントと対話ユーザーも区別します。

コマンドを対話的に確認するためにSet-ExecutionPolicyを一律に変更する必要はありません。ps1ファイルの実行が組織ポリシーで制限される場合は、回避せず管理者へ確認します。

ユーザーの手動プロキシ設定を読み取る

$key = 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings'
Get-ItemProperty -Path $key |
    Select-Object ProxyEnable, ProxyServer, ProxyOverride, AutoConfigURL

ProxyEnableは手動プロキシ設定の有効・無効、ProxyServerは指定値、ProxyOverrideは例外、AutoConfigURLは構成スクリプトのURLを確認する手がかりです。ProxyEnable=0だけで「どのアプリもプロキシを使っていない」とは判断できません。PAC、自動検出、ポリシー、アプリ独自設定は別に確認が必要です。

Connections配下のDefaultConnectionSettingsをバイト列のまま表示しても、システム全体の実効プロキシを調べたことにはなりません。バイナリ値を推測で書き換えるのは避けます。

Start-Process 'ms-settings:network-proxy'

Windowsの「ネットワークとインターネット → プロキシ」を開いて、手動設定だけでなくセットアップスクリプトと自動検出も確認します。設定が管理されている場合は変更せず、表示内容を管理者へ伝えてください。

WinHTTPの設定を確認する

netsh winhttp show proxy
netsh winhttp help

これはWinHTTP側の基本設定の確認です。「直接アクセス」と表示されても、ブラウザー、環境変数を読むツール、独自プロキシを指定したアプリが直接通信する証明にはなりません。対応するWindowsではshow advproxyもありますが、利用できる構文はそのPCのヘルプで確認します。

環境変数はProcess・User・Machineを分けて確認する

HTTP_PROXY・HTTPS_PROXY・ALL_PROXY・NO_PROXYは、それを参照するアプリにだけ影響します。値に認証情報が含まれている可能性があるため、次は値そのものを出さず存在と文字数だけを一覧にします。

foreach ($name in 'HTTP_PROXY','HTTPS_PROXY','ALL_PROXY','NO_PROXY') {
    foreach ($scope in 'Process','User','Machine') {
        $value = [Environment]::GetEnvironmentVariable($name, $scope)
        [pscustomobject]@{
            Name = $name
            Scope = $scope
            Present = ($null -ne $value)
            Length = if ($null -eq $value) { 0 } else { $value.Length }
        }
    }
}

Processは現在のPowerShell、UserとMachineは保存された設定です。永続設定を変えても、既に起動しているプロセスの値が即座に更新されるとは限りません。値を個別に読む場合も、資格情報入りURLや社内ホスト名をそのままスクリーンショット・チャットへ貼らないでください。

変更は小さい範囲から:リクエストだけにプロキシを指定する

PowerShellからの1回の通信を確認したいだけなら、端末全体を変更せず、対象のWebコマンドに-Proxyを指定する方法があります。次は構文例で、example.comの名前は管理者が指定した正しいプロキシと承認済みの確認先へ置き換えます。

Invoke-WebRequest -Uri 'https://example.com/' -Proxy 'http://proxy.example.com:8080'

PowerShell 7.0以降のInvoke-WebRequestは環境変数によるプロキシ設定にも対応しますが、5.1へ同じ動作をそのまま当てはめません。HTTPSの宛先だからHTTPS_PROXYの値も必ずhttps://になるわけではなく、値のスキームはプロキシ自体への接続方式です。管理者・製品の指定に従います。

認証が必要なら承認済みの相手に限り、対応する-ProxyCredentialや-ProxyUseDefaultCredentialsを検討します。パスワードをURLやスクリプトに埋め込みません。証明書エラーを無視するオプションで接続確認を成功扱いにしないでください。

現在のPowerShellプロセスだけ環境変数を変える例

対応アプリをこのPowerShellから新しく起動して試す場合の例です。既存の値を保持し、作業後に元へ戻します。HTTP_PROXYだけを扱う最小例であり、HTTPS_PROXY・ALL_PROXY・NO_PROXYとの優先順位は対象アプリの仕様で確認してください。

$name = 'HTTP_PROXY'
$before = [Environment]::GetEnvironmentVariable($name, 'Process')
try {
    [Environment]::SetEnvironmentVariable($name, 'http://proxy.example.com:8080', 'Process')
    # この範囲で承認済みの対象ツールを新しく起動して確認する
}
finally {
    [Environment]::SetEnvironmentVariable($name, $before, 'Process')
}

この例だけでは通信しません。現在のプロセスの値を一時変更して戻す構造です。既に起動済みのブラウザーやサービスまで設定が変わるわけではありません。起動した子プロセスが動作中なら、そのプロセス内の値まで元へ戻るわけではありません。

ユーザーの環境変数を永続変更する場合

継続して使うことが承認された場合だけ、変更前のUser値を安全に記録してから実行します。例はHTTP_PROXY一つの設定です。新規起動した対象アプリで確認し、不要なら変更前の値へ戻します。元が未設定ならその変数を削除します。Machine全体へ広げる必要があるとは限りません。

[Environment]::SetEnvironmentVariable('HTTP_PROXY', 'http://proxy.example.com:8080', 'User')

保存されたUser値と現在のProcess値は別です。確認のためだけにシステム再起動を繰り返すのではなく、対象プロセスの再起動・ログイン状態と値の継承を確認してください。資格情報を環境変数に保存する運用は避けます。

WinHTTPを変更する場合は元の設定と復旧手順を残す

WinHTTPを参照する対象機能への変更が必要と分かった場合だけ、管理者が変更前の状態を記録します。遠隔作業では接続不能時の復旧手段も準備してください。

netsh winhttp show proxy
netsh winhttp dump

dumpの出力は現在の設定を再構成するための資料になります。機密性に注意して安全に保存し、復旧時には内容と適用先を確認します。以下は管理者が承認した固定プロキシへ変更する構文例です。

netsh winhttp set proxy proxy-server="proxy.example.com:8080"
netsh winhttp show proxy

成功表示は設定を書けたという意味で、対象サービスの接続成功ではありません。サービスの実行アカウント、認証、実際の通信先で確認します。例外リストを指定する場合も管理者が決めた対象だけにします。

netsh winhttp import proxy source=ieは現在のユーザー側設定をWinHTTPへ取り込む操作で、常時同期する機能ではありません。PACや自動検出を含むすべての挙動が完全に複製されると想定せず、版の対応と結果を確認します。

netsh winhttp reset proxyは「前の設定へ戻す」コマンドではなくDIRECTへリセットする操作です。元が組織指定のプロキシなら、記録した元の値へ戻してください。通信できないからという理由でリセットして制御を外さないでください。

ユーザーのWindowsプロキシをレジストリへ直接書かない理由

HKCUのProxyEnableとProxyServerを書き換えるだけでは、PAC・自動検出・ポリシー・起動済みアプリへの反映まで扱えません。MicrosoftはWinINetの既定値変更にレジストリ関数を直接使わないよう案内しています。手動ならWindows設定、組織配布なら管理方式、開発なら文書化されたAPIを選びます。

変更後に確認すること・自動化の条件

変更前後を同じユーザー・同じアプリ・同じURLで比較し、設定値だけでなく対象アプリの実際の動作とログを確認します。ブラウザーが動くことはサービスが動く証明ではありません。407はプロキシ認証、名前解決・タイムアウト・証明書の問題は別に切り分けます。

自動化では対象範囲の限定、変更前の記録、エラー検出、成功確認、復旧を組み合わせます。netshは外部コマンドなのでPowerShellのtry/catchだけに頼らず、実行直後の$LASTEXITCODEも確認してください。失敗したのに「設定完了」と出すスクリプトは避けます。

参考資料

Microsoft:netsh winhttp / WinINetの既定プロキシ設定 / Internet Optionsの取得・設定

Invoke-WebRequest / 環境変数のスコープ / HttpClient.DefaultProxy

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次