Windows ServerのWindows Update通信要件は、Microsoftから直接更新を取得する構成と、社内WSUSから配信する構成を分けて確認します。インターネット向けのTCP 80/443と、WSUS向けの既定TCP 8530/8531は通信先も設定箇所も違います。URL一覧だけを転記する前に、取得元・通信方向・プロキシ経路を整理してください。
Windows Updateの取得を許可する時は、更新する側から宛先への送信通信を確認します。
Windows Update・WSUSのポートと通信方向
| 通信する側 → 宛先 | 宛先ポートの基本 | 確認する設定 |
|---|---|---|
| Microsoft Updateから直接取得するWindows Server → Microsoftの更新サービス | HTTP TCP 80 / HTTPS TCP 443など、対象バージョンと更新機能の要件 | 外向き通信・プロキシ・実際に拒否された更新URL |
| インターネット接続する最上位WSUS → Microsoft Update | TCP 80 / 443 | 外向き通信と下記の公式WSUS宛先一覧 |
| 更新するWindows Server/PC → 社内WSUS | 既定TCP 8530 / 8531。変更した構成は実際のポート | クライアント側送信、WSUS側受信、IIS、更新先ポリシー |
| 下位WSUS → 上位WSUS | 既定TCP 8530 / 8531 | 上位サーバー名・ポート・TLS設定 |
| プロキシを使う機器 → 社内プロキシ | 管理者が指定したプロキシ待受ポート | まずプロキシへ到達できるか。外部80/443はプロキシ側でも確認 |
Microsoftからダウンロードするために、更新するWindows Serverのローカル受信80/443を開ける手順ではありません。受信を開けるのは、そのサーバーがWSUS等のサービスを提供し、社内クライアントから接続を受ける場合です。送信元、宛先、宛先ポート、適用するネットワーク区間を管理者と確認します。
先に更新元がMicrosoftかWSUSか確認する
- Windows Serverのバージョン/ビルド、対象のKB、失敗時刻、エラーコードを記録します。
- 適用されているグループポリシーや更新管理の構成を確認し、Microsoft Update、社内WSUS、Configuration Manager等のどの取得元を使うか調べます。
- WSUSなら実際のサーバーFQDN、HTTP/HTTPS、ポートを確認します。「WSUSを使っている」という情報だけでは接続先URLは決まりません。
- 直接通信かプロキシ経由か、プロキシの待受ポートと認証方式を確認します。
- 更新の検索が失敗するのか、検索後のダウンロードが失敗するのかを分け、同時刻のファイアウォール/プロキシログを調べます。
WSUSの基本構成では、クライアントは社内WSUSに接続し、最上位WSUSがMicrosoftへ接続します。ただし、下位WSUSが更新ファイルをMicrosoftから直接取得する構成では下位側にも外部通信が必要です。追加の更新機能や管理構成もあるため、WSUS名が設定されているだけで全種類の更新が社内経由になると決めつけず、実際のポリシーとログを確認します。
Microsoftへ接続するWSUSのURL一覧
次の一覧はMicrosoft公式のWSUS構成手順が掲載する、最上位WSUSからMicrosoftへ向かう送信許可の対象です。すべてのWindows Server/Windows 11の全機能に共通する完全な一覧としては扱いません。直接更新するOS、Delivery Optimization、Microsoft 365 Appsなどは対象製品・バージョンの通信要件も確認します。
| 公式WSUS資料のURLパターン | 通信 |
|---|---|
| http://windowsupdate.microsoft.com | HTTP / TCP 80 |
| http://*.windowsupdate.microsoft.com | HTTP / TCP 80 |
| https://*.windowsupdate.microsoft.com | HTTPS / TCP 443 |
| http://*.update.microsoft.com | HTTP / TCP 80 |
| https://*.update.microsoft.com | HTTPS / TCP 443 |
| http://*.windowsupdate.com | HTTP / TCP 80 |
| http://download.windowsupdate.com | HTTP / TCP 80 |
| https://download.microsoft.com | HTTPS / TCP 443 |
| http://*.download.windowsupdate.com | HTTP / TCP 80 |
| http://wustat.windows.com | HTTP / TCP 80 |
| http://ntservicepack.microsoft.com | HTTP / TCP 80 |
| http://go.microsoft.com | HTTP / TCP 80 |
| http://dl.delivery.mp.microsoft.com | HTTP / TCP 80 |
| https://dl.delivery.mp.microsoft.com | HTTPS / TCP 443 |
| http://*.delivery.mp.microsoft.com | HTTP / TCP 80 |
| https://*.delivery.mp.microsoft.com | HTTPS / TCP 443 |
HTTPとHTTPSは公式資料に示された組み合わせで確認します。download.microsoft.comは上表ではHTTPSです。URLフィルターとFQDNフィルターでは登録形式が異なり、ワイルドカードの意味も製品によるため、http://やパスを含める欄なのか、ホスト名を登録する欄なのかを確認してください。
同じ公式資料は、関連IPアドレスが変動するため固定IP範囲で置き換えないよう説明しています。DNSで一度得たIPを永久的な許可先にせず、利用するファイアウォール/プロキシのドメイン・URL制御と最新の対象製品資料で管理します。
wustat.windows.comは許可一覧にありますか？
上記のMicrosoft公式WSUS資料にはhttp://wustat.windows.comが掲載されています。ただし、掲載されていることだけで、現在の各Windows Serverが必ずこのホストへ接続する、ここだけを許可すれば更新できる、という意味にはなりません。構成に適用する許可一覧と、対象機器で観測された通信を分けて確認します。
Windows Defender Firewallは送信側の状態を確認する
管理者用PowerShellではGet-NetFirewallProfileで有効なポリシーのプロファイル設定を読み取れます。次の例は設定を変更しません。
Get-NetFirewallProfile -PolicyStore ActiveStore |
Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundActionDefaultOutboundActionだけでは個別の拒否ルールや境界装置の制限までは分かりません。組織の有効な送信ルール、ファイアウォールログ、プロキシ拒否ログを確認し、必要な宛先に限定した通信を管理者が設計します。全宛先への送信80/443を無条件で許可したり、ファイアウォール全体をオフにしたりする必要はありません。
WSUSクライアントの8530/8531とTLS設定
Microsoft公式資料では、クライアントからWSUS、下位WSUSから上位WSUSへの既定ポートはTCP 8530/8531です。TLS構成では通常、更新メタデータをHTTPSの8531、更新ファイルをHTTPの8530で扱います。設定を変更している環境は、実際のIISバインドとポリシー値を確認してください。
TLSを使う構成のポリシーURLは、例えばhttps://wsus.contoso.com:8531のようにFQDNと正しいHTTPSポートを含めます。「イントラネットのMicrosoft更新サービスの場所を指定する」の更新検出先と統計サーバーの両方を、対象構成に合わせて設定します。この名前は説明用で、実環境のサーバー名へ置き換えます。
WSUS全サイトで「SSL必須」を有効にしないでください。公式手順はTLSを要求する仮想ディレクトリと、Content等の要求しないディレクトリを区別しています。更新ファイルは署名・ハッシュで検証されます。HTTPを含む構成だからといって、独自に全URLをHTTPSへ置き換えると通信が成立しないことがあります。
TLS接続するクライアントは、WSUSに設定された証明書と発行元を信頼する必要があります。公式手順の証明書ストアはローカルコンピューター側で、利用者個人の証明書ストアだけでは足りません。証明書エラーではFQDN・有効期間・信頼関係・時刻を確認し、検証を無効にして回避しません。
WinHTTPとWSUSのプロキシ設定を分ける
Windows Updateクライアントのプロキシ説明では、更新検索にはWinHTTPが使われ、ダウンロードにはBITSまたはDelivery Optimizationが使われます。ユーザーがEdgeでWebページを開けることと、サービスの更新通信が成功することは別です。まず現在のWinHTTP設定を確認します。
netsh winhttp show proxynetsh winhttpの公式コマンド説明で確認したうえで、設定が必要なら管理者が正しいプロキシ名・ポート・バイパス方針を決めます。set proxyはWinHTTPの設定変更で、全アプリの通信設定をまとめて変更する命令ではありません。社内WSUSをバイパスするかもネットワーク設計に従い、架空のPROXY_SERVERやPORTをそのまま投入しないでください。
WSUS自体の同期用プロキシは、WSUS管理コンソールの「オプション」→「更新ソースおよびプロキシサーバー」→「プロキシサーバー」で設定します。サーバー名、ポート、必要な認証を確認します。認証がある環境ではサービスがその方式を利用できるかを管理者と確認し、パスワードが平文で送られるBasic認証を一律に推奨しません。
URLを許可してもダウンロードが失敗する時
MicrosoftのWindows Updateトラブルシューティングは、プロキシでHTTP RANGE要求が扱われない場合、ダウンロードが進まない問題や0x80d05001（DO_E_HTTP_BLOCKSIZE_MISMATCH）が起こり得ると説明しています。ドメイン許可だけでなく、部分取得、HTTP/HTTPS、認証、実際の応答を確認します。
検索が成功してダウンロードが失敗するなら、配信先が検索先と違う可能性を確認します。TLS/証明書エラーがある場合も、宛先の許可不足、証明書の信頼、プロキシの検査等をログから切り分け、セキュリティ検査を全体で停止する初手にしません。Windows 10の古い通信先例を最新のServerへそのまま流用するのも避けます。
実際の通信先でDNS・TCP・更新ログを確認する
ログで拒否されたホスト、または実際の社内WSUSを使って調べます。次のPowerShell例は設定を変更せず、入力したホストのDNSとTCP接続を確認します。ワイルドカードやhttps://付きのURLではなく、実際のホスト名を入力します。プロキシ経由なら最初に確認する相手はプロキシ名とその待受ポートです。
$updateHost = Read-Host "確認する実際のホスト名（URLや*は入力しない）"
$updatePort = [int](Read-Host "宛先TCPポート（構成に応じて80/443/8530/8531等）")
nslookup $updateHost
Test-NetConnection -ComputerName $updateHost -Port $updatePortTest-NetConnectionの公式説明が示すTCP確認は到達性の診断です。TcpTestSucceededがTrueでも、TLS証明書、HTTP認証、URLフィルター、更新ファイルの取得がすべて成功する証明ではありません。直接外部接続を禁止するプロキシ環境では、外部ホストへのTCPテストが失敗しても更新失敗の原因とは断定できません。
Windows UpdateのETLログはGet-WindowsUpdateLogで読み取り可能なWindowsUpdate.logへ変換できます。対応するOSで生成したログ、イベントビューアーのWindowsUpdateClientログ、境界ファイアウォール/プロキシログを同じ時刻で照合し、検索・ダウンロード・インストールのどこで失敗したかを整理します。ログ変換は設定修復を行うコマンドではありません。
| 記録する情報 | 調べる理由 |
|---|---|
| OSバージョン、ビルド、KB、失敗時刻・コード | 対象となる更新機能と失敗段階を特定 |
| 更新元URL、プロキシ名・ポート、適用ポリシー | 通信経路と宛先を確定 |
| 拒否されたホスト/URL、送信元、宛先ポート、応答 | どの区間で制限されているか確認 |
| WSUS同期状態、IIS/TLS、クライアントログ | 上流同期失敗とクライアント接続失敗を区別 |
変更後の確認とサーバー運用
許可設定やプロキシ設定を変更したら、代表サーバーで更新検索、対象更新のダウンロード、インストール、再起動後の結果を別々に確認します。予定した変更と元の値を記録し、問題が出た場合の戻し方を決めます。TCPが接続できることだけで更新運用の検証を終えないでください。
本番適用はサーバーの役割に合わせて検証・保守時間・バックアップと復旧手順を用意します。仮想マシンのスナップショットだけで全役割を安全に戻せると決めつけず、業務アプリケーションやデータベース等の復旧要件も確認します。通信障害の確認と、更新の承認・再起動計画は分けて管理します。
よくある質問
443番だけ許可すれば足りますか？
上表の公式WSUS構成は80/443の両方を示しています。WSUSクライアントでは8530/8531などの実際の内部ポートも確認します。対象のプロトコルを独自に変更して443だけへ統一しないでください。
Windows Update用に受信80/443を開放しますか？
Microsoftから取得するだけなら、取得する側から外向きの通信を確認します。WSUSを提供する側はクライアントから接続を受けるため、そのWSUSの実際の受信ポートを設計します。役割を分けてください。
ブラウザーでMicrosoftを開けたら問題ありませんか？
Windows Updateのサービスとブラウザーではプロキシ・実行アカウント・接続先が違うことがあります。更新処理のログとサービスが使う経路を確認してください。
まとめ
Windows ServerのWindows Update通信は、更新元を確認してから送信先と宛先ポートを整理します。最上位WSUSは公式URL一覧と80/443、社内WSUSへの接続は実際の8530/8531等、プロキシ利用時はWinHTTPとWSUS同期用設定を確認します。拒否ログと更新ログを照合し、必要な通信に絞って変更・検証してください。
コメント