WSLの更新が403で失敗する時の対処法｜WARPと0x80190193

WSLを新しい版へ更新しようとしたら、「許可されていません（403）」と表示されて先へ進めない。管理者としてPowerShellを開き直しても同じ結果だと、Ubuntuを入れ直すべきか迷うところです。

Wsl/UpdatePackage/0x80190193は、更新の処理でHTTP 403に相当するエラーが返ったことを示します。公式の別の取得経路に加え、Cloudflare WARPなどの通信経路も確認候補になります。この記事では、組織のWARPを切断すると更新できた事例と、Gatewayのログ・HTTPS検査の調べ方、公式MSIを使う方法を紹介します。

403エラーは何を意味する？

PowerShellでwsl --updateを実行すると、次のようなメッセージが表示されることがあります。

更新プログラムを確認しています。
許可されていません (403)。
エラー コード: Wsl/UpdatePackage/0x80190193

Microsoftのエラーコード一覧では、0x80190193はHTTP_E_STATUS_FORBIDDEN、つまりHTTP 403に対応しています。「許可されていません」という文言だけを見るとWindowsの管理者権限不足にも見えますが、このコードだけでローカルの権限が原因と判断することはできません。

配信先からの応答なのか、通信経路上のプロキシなどから返されたものなのかは、短いエラー表示だけでは特定できません。WSLの更新中に出た403と、Ubuntuのファイルへのアクセス拒否は、調べる入口が異なります。

出典：Microsoftのエラーコード一覧（HTTP_E_STATUS_FORBIDDEN）。

別の取得経路で更新する

通常の更新だけで失敗している場合は、PowerShellで次のコマンドを試してください。

wsl --update --web-download

--web-downloadは、Microsoft StoreではなくGitHubから更新を取得する公式のオプションです。Storeへのアクセスに問題がある場合の選択肢で、Microsoft Learnにも案内されています。

更新が完了したら、次のコマンドでWSL本体のバージョンを確認できます。

wsl --version

一方、--web-downloadを付けても同じ403が出る場合は、そこで確認を次の段階へ進めます。GitHubのWSLリポジトリにも、通常更新とこのオプションの両方で同じエラーになった利用者の報告があります。取得経路を変えれば必ず直る、というエラーではありません。

このオプションは組織の利用制限を解除する機能でもありません。会社・学校の端末でWSLや外部パッケージの導入が管理されている場合は、許可されている方法で進める必要があります。

出典：WSLの更新コマンド、Storeへアクセスできない場合の案内、両方の更新コマンドで403が出た利用者の報告。GitHubの報告は個別の事例で、すべての環境の原因を示すものではありません。

Cloudflare WARPとGatewayの設定を確認する

組織のCloudflare Zero Trust／Gatewayを利用している環境で、次の結果になった事例がありました。

• WARP接続中は、wsl --updateが403・Wsl/UpdatePackage/0x80190193で失敗した。
• wsl --update --web-downloadでも、同じ403とメッセージが表示された。
• WARPを切断すると、WSLを更新できた。

この比較から、WARP／Gatewayを通る通信経路の関与が強く疑われます。ただし、WARPの切断ではHTTPS検査以外の経路条件も変わります。この結果だけで「HTTPSインスペクションが原因」とまでは断定できません。組織の接続設定で同じ問題に遭遇したら、更新に失敗した時刻とコマンドを管理担当者へ伝えると、ログを照合しやすくなります。

失敗した通信のログを調べる

管理担当者はCloudflareの「Zero Trust」→「Insights」→「Logs」→「HTTP request logs」を開き、失敗した時刻と端末の通信を探してください。「Host」「Action」「Policy details」から、接続先とGatewayが適用した判断・ポリシーを確認できます。

該当する更新通信の「Action」が「Block」なら、まずそのポリシーの条件が意図したものかを調べます。HTTPS検査に伴う証明書の問題と決めつける前に、更新用の通信やファイル取得がポリシーで止められていないかを見ておくと、対処を絞りやすくなります。

「Allow」でも更新が失敗する場合は、ログのHTTPステータスや接続先も手がかりになります。HTTPログに見当たらなければ、DNS・Networkのログとログ保存設定も確認してください。記録がないことだけでは、Gatewayを通っていないと判断できません。

出典：CloudflareのGatewayログと各項目の説明。

HTTPS検査の影響を調べる

GatewayのTLS decryptionは、HTTPS通信を復号してHTTPポリシーを適用する機能です。Cloudflareは、証明書ピンニングなどと互換性がない場合、SSL・信頼性のエラーや接続失敗が起きることを案内しています。HTTPS検査は確認候補ですが、今回の403だけでWSLの証明書検証やピンニングが原因と判断する根拠にはなりません。

ログでブロックの理由を確認しても解決しない場合は、管理担当者の管理下で、実際に記録された更新先のホスト名に限定して「Do Not Inspect」を一時適用し、WARPを接続したまま同じ更新コマンドの結果を比べる方法があります。リダイレクト先も含め、対象は実際の通信から決めてください。

ただし「Do Not Inspect」は、該当通信のTLS復号だけでなく、HTTPのログ・ブロック、DLP、ウイルス検査にも影響します。これで更新できても、HTTPS検査とHTTPポリシーのどちらが原因かは、まだ絞り切れていません。ネットワークポリシーは引き続き適用できるため、試験前後の条件とログを合わせて判断する必要があります。

診断のための例外を恒久的な解決策にするかは、影響を確認してから決めます。広い範囲の検査を一括で外すより、失敗した通信に範囲を絞る方が、組織のルールを保ちながら原因を調べやすくなります。

出典：CloudflareのTLS decryptionと互換性の制限、Do Not Inspectの動作と影響。

公式MSIをブラウザーで取得する

コマンドによる取得が止まる場合でも、ブラウザーから公式の配布ファイルを取得できるかは別に確認できます。MicrosoftはWSLのオフライン導入方法として、公式GitHub ReleasesのMSIパッケージを案内しています。すでにWSLを使っている場合は、現在のバージョンを確認したうえで、本体の更新候補としてパッケージを選びます。

PCの種類と現在のバージョンを確認する

Windowsの「設定」→「システム」→「バージョン情報」を開き、「システムの種類」にあるプロセッサーの種類を確認してください。x64とARM64では、選ぶMSIファイルが異なります。WSL本体のバージョンはwsl --versionで確認できます。コマンドが使えない場合は、その表示も控えておくと後の診断に役立ちます。

正式リリースのパッケージを選ぶ

MicrosoftのWSL Releasesを開き、利用したい正式リリースの「Assets」からPCに合うMSIを選んでください。WSL 3.0.1のファイル名は次のとおりです。

3.0.1の配布ページにはコンテナー向けの開発用パッケージなども並ぶため、拡張子まで見て選ぶと迷いません。新しい正式版へ更新する際は、そのリリースのMSIを使い、現在より古い版への変更やプレリリース版の導入を403対策として混ぜないようにしてください。

取得したMSIを実行する

ダウンロードできたら、WSL上の作業を保存し、実行中のサービスやコンテナーを停止してからMSIを開き、インストーラーの案内に従ってください。管理者権限や再起動を求められた場合は、その案内に沿って進めます。完了後、PowerShellを開いてwsl --versionで結果を確かめてください。

MSIのダウンロードにも失敗する場合は、コマンドのオプションだけでは解決できていません。また、ファイルは取得できてもインストーラーで別のエラーが出た場合は、更新取得時の403とは別に、そのメッセージを記録して調べる必要があります。取得できたことと更新が完了したことは、別々に確認すると切り分けやすくなります。

出典：Microsoft LearnのMSIによる導入方法、WSL 3.0.1の公式配布ページ、WindowsでARMプロセッサーを確認する方法。

VPN・プロキシとダウンロードの結果を確認する

通常更新と--web-downloadの両方が403になる場合、通信経路は確認候補のひとつです。ただし、両方が失敗しただけでVPNやプロキシが原因と確定したわけではありません。

Windowsの「設定」→「ネットワークとインターネット」→「プロキシ」で、手動設定やセットアップスクリプトの使用状況を確認できます。VPN接続を使っている場合は、その接続にも別のプロキシ設定があることがあります。会社・学校の設定を使っているなら、まず管理担当者にWSLの更新と公式パッケージの取得が許可されているか相談すると、無関係な設定変更を減らせます。

個人所有の端末で、利用ルール上も問題がない場合は、別の信頼できるネットワークで同じ公式ファイルを取得できるか比べる方法もあります。比較時はネットワークなど変更する条件をひとつに絞り、同じ操作の結果を残すと判断しやすくなります。

出典：WindowsのプロキシとVPN接続の設定。上の比較は確認順の提案で、特定の原因が判明したことを示すものではありません。

改善しない場合はエラーと環境情報を残す

同じ403が続く場合は、何度も同じコマンドを繰り返すより、次の情報をまとめると相談や調査を進めやすくなります。

• wsl --updateとwsl --update --web-downloadそれぞれのエラー全文
• wsl --versionの結果
• Windowsのバージョン・OSビルド、x64かARM64か
• VPN・プロキシの利用有無、組織管理端末かどうか
• WARP／Gatewayの利用有無、接続条件を変えた時の結果、失敗した時刻
• 公式MSIを取得できたか、実行時に何が表示されたか

MicrosoftのWSLトラブルシューティング資料や、WSLのGitHub Issuesで同じコードを探し、環境や発生する操作が近い報告を確認できます。追加のログが必要な場合は、公式のWSLログ収集手順を使ってください。画面やログを共有する前に、ユーザー名・PC名・パスなど公開したくない情報が含まれていないかも見ておくと安心です。

出典：Microsoft LearnのWSLトラブルシューティング。

Ubuntuを削除する前に更新経路を調べる

このエラーが表示された段階では、Ubuntuを削除する必要があるとは判断できません。WSL本体の更新取得で止まっているなら、まず取得経路とパッケージの実行結果を確認する方が、既存の開発環境を保ちながら調べられます。

wsl --unregisterは更新をやり直すためのコマンドではなく、指定したディストリビューションの登録を解除します。関連するデータ・設定・ソフトウェアは失われるため、403への最初の対処として実行しないでください。

WSL 3.0系への更新でこのエラーに遭遇しても、エラーコードだけで3.0系固有の不具合とは判断できません。通常更新、--web-download、公式MSIの取得・実行という順に結果を残し、どの段階で止まるかを確認することが、次の対処を選ぶ手がかりになります。

出典：ディストリビューション登録解除の注意点。

WSL 3.0系の変更点とコンテナー機能については、WSL 3.0で何が変わった？WSL containers正式提供と更新方法で紹介しています。