WinHttpAutoProxySvc（WinHTTP Web Proxy Auto-Discovery Service）は、WinHTTPのプロキシ自動検出などに関わるサービスです。「プロキシを使わない」「Stoppedと表示される」という理由だけで無効化しないでください。この記事では、サービスの役割・停止状態の読み方・WPADを使わない場合の設定・通信エラーの確認順を説明します。
WinHttpAutoProxySvcとは
WinHTTP AutoProxyは、DHCPやDNSを使ってPAC（Proxy Auto-Configuration）ファイルのURLを見つけ、そのスクリプトから宛先に合うプロキシ等の経路を判定します。PACが直接接続を指示する場合もあるため、自動検出＝常に同じプロキシを使う、という意味ではありません。
| 項目 | 意味 |
|---|---|
| サービス名 | WinHttpAutoProxySvc。表示名はWinHTTP Web Proxy Auto-Discovery Service。 |
| WinHTTP | アプリやOSコンポーネントがHTTP要求を行うAPI/通信機能。 |
| WPAD | ネットワークからPACの場所を自動検出する仕組み。 |
| PACのURL指定 | 管理者等が指定したスクリプトURLを使う構成。自動検出と区別する。 |
| 静的プロキシ | サーバー名・ポート・除外先等を明示する構成。 |
| サービスがStopped | 現在の動作状態。Disabledという起動設定とは別。 |
停止・無効化してよい？
WPADによる自動検出を無効にする設定と、WinHttpAutoProxySvcサービスを無効にする操作は別です。
MicrosoftのWindows Server 2016 with Desktop Experience向けサービス指針では、このサービスはManualで「Do not disable」とされています。同資料は適用範囲を明示しているため、その表だけでServer 2022/2025やすべてのWindows 11の既定値を決めつけることはできません。実機の版・設定・依存関係を確認します。
ただし、「プロキシ未使用ならサービスを無効化しても安全」という共通の判断には根拠がありません。停止、手動起動、無効はそれぞれ異なる状態です。手動のサービスが必要なときだけ起動する構成もあるため、Stoppedという表示だけで故障や不要と判断しないでください。
| 目的・状態 | 確認すること | 対応方針 |
|---|---|---|
| WPADを使わない方針にしたい | PAC/固定プロキシ等の代替設定、対象OS。 | WPADの設定を管理し、サービス無効化と混同しない。 |
| サービスがStopped | 起動の種類、依存関係、実際の通信エラー。 | 表示だけで自動起動へ一律変更しない。 |
| 起動・停止時にエラーが出る | コード全文、管理ポリシー、Service Control Managerの記録。 | 無関係なサービスやACLを一括変更しない。 |
| プロキシを使っていないように見える | システム・ユーザー・アプリ・VPNそれぞれの設定。 | ネットワーク図だけでサービスを無効化しない。 |
| ネットワークが不安定 | 変更前後の状態、対象URL、実行アカウント、ログ。 | サービスだけを原因と断定せず経路を調べる。 |
1. サービスの状態と依存関係を読み取る
「services.msc」で対象のプロパティを開き、状態・スタートアップの種類・依存関係を記録します。PowerShellではGet-Serviceで現在の状態と明示的な依存関係を確認できます。次の命令は開始・停止・設定変更を行いません。
Get-Service -Name WinHttpAutoProxySvc |
Select-Object Name,Status,StartType
Get-Service -Name WinHttpAutoProxySvc -RequiredServices
Get-Service -Name WinHttpAutoProxySvc -DependentServicesコマンドプロンプトまたはPowerShellでは、sc.exe queryでも状態を読み取れます。PowerShellではscという省略名を使わず、実行ファイル名を明示します。
sc.exe query WinHttpAutoProxySvc明示的な依存サービスの一覧に何も出ない場合でも、アプリが機能上依存していない証明にはなりません。OSの版によって依存関係も変わり得るため、ドメイン内のすべての端末へ同じ無効化設定を配る前に、対象機能と実機の構成を確認します。
2. WinHTTPとユーザーのプロキシ設定を分ける
netsh winhttpはWinHTTPの構成を表示・管理するコマンドです。まず基本設定を読むだけの次の命令で確認します。
netsh winhttp show proxy出力がDirect accessでも、それだけですべてのアプリにプロキシ設定がないとは断定できません。自動検出・PAC・高度な設定や、アプリごとの構成、ユーザーの設定も確認が必要です。対応する版で高度な設定を使っている場合は、公式資料とnetsh winhttpのヘルプでshow advproxy等を確認してください。
Windowsの「ネットワークとインターネット → プロキシ」の設定と、WinHTTPの表示を両方記録します。Chromiumの資料もブラウザー独自のネットワークスタックとシステム設定の利用を説明しています。現在のEdgeやChromeがWinINetの通信スタックそのものを使う、という単純な分類はしないでください。
ブラウザーでページが開くことと、Local System等で動作する更新クライアント・サービスが通信できることは別です。netsh winhttp import proxy source=ieを実行すればChrome/Edge固有の設定をすべて取り込める、という意味でもありません。設定変更前に対象と影響範囲を確認します。
3. WPADを使わない場合の公式設定
MicrosoftのWPAD無効化資料では、Windows Server 2019およびWindows 10 version 1809以降に、次のレジストリ位置のDisableWpad（DWORD）を1にする方法を案内しています。これはWinHTTP APIによるWPAD検出を止めるための設定です。
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp\DisableWpadこの設定を適用する場合は、必要なプロキシを手動で構成する必要があります。さらに、第三者アプリやブラウザーがWindowsの設定を参照するため、同資料は設定画面側の自動検出も無効にするよう案内しています。サービス自体をDisabledへ変える操作で代用しません。
- 対象OSの条件と組織のWPAD利用方針を確認する。
- PACの指定・固定プロキシ・直接接続と必要な除外先を管理者が決める。
- 変更前の値とWindowsの設定を保存し、検証対象を限定する。
- WinHTTPとWindowsの自動検出設定をそれぞれ確認する。
- 更新・セキュリティ製品・管理ツールの実際の通信を確認する。
DisableWpadを設定しても、アプリが直接DNSでWPADという名前を照会することは可能です。nslookup WPADで名前が引けるかどうかだけでは、WinHTTPの自動検出が有効か無効かを証明できません。また、Proxy認証方式やProxy並べ替えの無効化は別設定なので混同しないでください。
Windows Updateで確認すべきこと
Windows Updateクライアントの資料は、更新のスキャンにはWinHTTP、ダウンロードにはBITSまたはDelivery Optimizationを使うと説明しています。スキャン先と報告等のURLではシステム/ユーザープロキシの選択も異なるため、全部を一つの設定で判断しません。
| 確認対象 | 記録する内容 |
|---|---|
| 失敗段階 | 更新の検出、ダウンロード、インストール、再起動後のどこか。 |
| 更新元 | Microsoft Update/Windows Updateか、組織内WSUSか。 |
| エラー | コード全文、KB、日時、対象URLや関連イベント。 |
| 通信の実行主体 | ログオンユーザーとシステムサービスの違い。 |
| ネットワーク条件 | プロキシ・PAC・認証・TLS・名前解決・必要な除外先。 |
pingはICMP、名前解決テストはDNSの確認です。成功してもHTTP/HTTPS・プロキシ認証・更新先への到達は証明できません。管理者のPowerShellで任意のWebページを開けることも、Windows Update自身と同じアカウント・スタック・宛先での成功を保証しません。対象機能のログと実際の結果を使って切り分けます。
WSUSサーバー自身と、クライアントの設定を分ける
WSUSサーバーの公式設定では、WSUS管理コンソールの「Options → Update Source and Proxy Server」で上流とプロキシを構成します。これは更新クライアントがWSUSへ接続するプロキシ方針とは別です。サーバーの上流同期失敗と、クライアントのスキャン失敗を分けて確認してください。
WSUSが必ずWPADで上流プロキシを見つける、サービスがRunningなら同期も成功する、という説明にはしません。WSUSの設定・承認・同期結果・必要な通信先、クライアント側の組織内更新URLとプロキシ選択をそれぞれ確認します。
サービス設定を変更する場合の確認順
- OSの版・サーバーの役割・GPO等の管理設定を確認する。
- 現状のサービス起動種類、状態、依存関係、通信設定を記録する。
- 変更目的がサービス修復なのかWPAD方針なのかを明確にする。
- 承認した対象だけで検証し、変更前の設定へ戻せるよう準備する。
- 実際の更新、管理ツール、セキュリティ製品、業務アプリの通信を確認する。
- 再起動やポリシー適用後にも再確認し、原因・変更・結果を記録する。
サービスを開始できない、停止を受け付けない、アクセス拒否になる場合は、コード全文とイベントを確認します。サービスの所有権やレジストリのアクセス許可を一括変更して強制停止する操作へ直ちに進むことは、通信障害の切り分けにはなりません。
ドメインコントローラーでは？
ドメインコントローラーも更新・管理製品・追加した機能の通信を確認する必要があります。ただし、WinHttpAutoProxySvcを停止すると必ずAD認証やDNS/DHCPが壊れる、と一律に断定することもできません。役割、機能上の依存、明示的な依存、実測エラーを基に判断します。
Microsoft Entra関連の同期・管理ツール等を使っている場合も、その製品が必要とする通信先とプロキシ構成を別に確認します。「一度ブラウザーが開いたので、ドメイン全体で無効化してよい」という運用基準にはしないでください。
判断の要点
WinHttpAutoProxySvcは、名前にAuto-Discoveryがあっても、プロキシ未使用という理由だけで不要とは判断できません。WPADを使わない方針はその設定で管理し、サービスの既定値・依存関係・実際の通信と分けて確認すると、更新失敗やネットワーク障害を具体的に調べられます。
コメント