Windows 11 で「Visual Studio 2022 Community」のセットアップを始めたのに、インストーラーのダウンロード表示がずっと 0 B/s のまま進まない——。本記事はその状況に直面した人のために、再現しやすい原因の見分け方から最短の回避策、恒久対策、そして企業ネットワークや家庭内ルーターでの“詰まりどころ”まで、現場で役立つ順に整理して解説します。環境を壊さず安全に進める手順・コマンドも豊富に掲載します。
症状の定義と前提条件
ここで対象とする症状は次のとおりです。
- 「Visual Studio Installer(コミュニティ版)」のダウンロード速度が常に 0 B/s と表示され、進行バーが動かない。
- 既に試した対処:VPN 利用、ファイアウォール無効化、
hostsへの IP 追記 → いずれも効果なし。 - OS は Windows 11、インストール先は通常の物理 PC(仮想環境でも可)。
結論から言えば、この症状はネットワーク経路上の遮断・検閲・変換によって発生することが非常に多く、アプリ側の不具合である可能性は相対的に低いです。特に ISP(回線事業者)や企業のプロキシ/UTM による TLS ハンドシェイク失敗、CDN 経路分岐の不整合、DNS フィルタリングなどが代表例です。
最短で復旧させる(結論ファースト)
- VPN を有効化した状態でインストーラーを再実行(ISP の経路をバイパス)。
- 改善しない場合は、スマホのテザリング/別の Wi‑Fi/別 ISP など物理的に異なる回線に切り替えて再試行。
- それでもダメなら、オフラインレイアウト(完全オフライン媒体)の作成→対象 PC でセットアップ。
この 3 ステップでほぼ収束します。失敗した回線でのみ再現するなら、原因は高確率でネットワーク側(ISP/プロキシ/ルーター設定)です。
なぜ 0 B/s で止まるのか:根本原因の理解
Visual Studio Installer は複数の Microsoft CDN(例:download.visualstudio.microsoft.com、azureedge.net 等)から多数のパッケージを並列取得します。TLS 1.2 以上が前提で、SNI(Server Name Indication)や OCSP ステープリングなどの近代的な TLS 機能を利用します。経路のどこかで以下が起きると、UI 上は 0 B/s で停止しやすくなります。
- TLS 1.2 無効・古い暗号スイートのみ許可 → ハンドシェイク失敗。
- DNS フィルタリング/改竄 → CDN エッジ到達前に接続失敗。
- HTTPS 検査型プロキシ(中間証明書挿し替え)→ 検査証明書が信頼されず失敗、または SNI ベースの遮断ルールに該当。
- ISP の経路制御・一部アドレス帯の輻輳/遮断 → 特定リージョンの CDN エッジに到達できない。
- ルーターの保護機能(マルウェアブロック、ペアレンタルコントロール)→ visualstudio や azureedge を誤検知。
公式推奨に基づく追加手順(実務向けサマリ)
| 手順 | 概要 | 参考コマンド/操作 |
|---|---|---|
| オフラインレイアウトを作成 | 他 PC で全コンポーネントを一括取得し、対象 PC にコピーして実行。 | vs_community.exe --layout C:\VS2022Offline --lang ja-JP |
| インストーラーのリセット | 破損キャッシュをクリア。UI から修復/リセット。 | Windows「アプリ」→「インストールされているアプリ」→ Visual Studio Installer →「詳細オプション」→「修復」or「リセット」 |
| TLS 1.2 の有効化確認 | 未適用の Windows 更新やレジストリ設定で TLS 1.2 が無効だと通信できない。 | PowerShell:Get-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server |
| プロキシ/セキュリティ製品の一時無効化 | HTTPS 検査や URL フィルタで遮断されることがある。 | 一時的にオフにして挙動を比較(企業環境では運用ルールに従う)。 |
ネットワークを変える vs. オフラインレイアウト(比較)
| 選択肢 | 長所 | 短所 | 向いているケース |
|---|---|---|---|
| VPN/別回線に切り替え | 追加準備ほぼ不要。常に最新パッケージを取得。 | 企業環境で VPN が禁止のことがある。別回線が手元にない場合も。 | 急ぎで 1 台だけ入れたい/モバイル回線が使える。 |
| オフラインレイアウト | 一度作れば複数 PC に再利用可能。ネット遮断でも導入可。 | 約 40 GB 前後の容量を要し、更新は手動。 | 複数台展開/閉域や検疫ネットワークでの導入。 |
現場で役立つ「まずやる診断」チェックリスト
- 同一 PC+別回線(スマホのテザリング等)で即改善 → 回線側(ISP/ルーター)問題が濃厚。
- 同一回線+別 PC でも再現 → 回線やルーターが原因。
- 企業ネットワークのみで再現 → プロキシ/UTM/フィルタのルール確認。
- 日時が大きくズレている → TLS 検証失敗(時刻を同期)。
- イベントログ(Schannel)に 36874/36888/36887 → TLS ハンドシェイク失敗。
コマンドで一気に確認・復旧(安全な順)
1) ネットワーク周りの軽微な詰まりを解消
ipconfig /flushdns
ipconfig /registerdns
netsh winsock reset
netsh int ip reset
netsh winhttp show proxy
netsh winhttp reset proxy
補足:企業環境で自動プロキシ(PAC)を使う場合は、netsh winhttp import proxy source=ie で WinHTTP にも取り込み、同じ経路で通信できるかを比較します。
2) 時刻同期(TLS 証明書検証の基本)
w32tm /resync
3) 関連サービスの状態確認
PowerShell
Get-Service BITS, wuauserv, CryptSvc | Format-Table Name,Status,StartType
# 必要に応じて
Start-Service BITS
Start-Service wuauserv
Start-Service CryptSvc
4) TLS 1.2 をレジストリで明示的に有効化(再起動要)
管理者 PowerShell で次を実行します(既存値はエクスポートでバックアップ推奨)。
New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" -Force | Out-Null
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" -Name "Enabled" -Value 1 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client" -Name "DisabledByDefault" -Value 0 -PropertyType DWord -Force | Out-Null
# .NET 4.x の強力暗号化を有効化
New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value 1 -PropertyType DWord -Force | Out-Null
New-ItemProperty -Path "HKLM:\SOFTWARE\WOW6432Node\Microsoft.NETFramework\v4.0.30319" -Name "SchUseStrongCrypto" -Value 1 -PropertyType DWord -Force | Out-Null
5) ルート証明書の更新(閉域/更新遅延対策)
certutil -generateSSTFromWU roots.sst
# 生成された roots.sst をダブルクリックしてインポート(管理者)
Windows Update が長期間停止していた PC では、信頼チェーン不足で TLS が失敗し、0 B/s のままになることがあります。
オフラインレイアウトの完全ガイド(確実性重視)
作成のポイント
- 通信の安定した PC(別回線で OK)にセットアップファイルを置き、管理者 PowerShell で実行。
- 容量はワークロードによりますが40 GB 前後見積もるのが安全。保存先は NTFS のローカルディスク推奨。
# 例:日本語 UI、推奨コンポーネントも含める
.\vs_community.exe --layout C:\VS2022Offline --lang ja-JP --includeRecommended
# さらに必要なワークロードを明示(例:.NET デスクトップ、C++ デスクトップ)
.\vs_community.exe --layout C:\VS2022Offline --lang ja-JP --add Microsoft.VisualStudio.Workload.ManagedDesktop --add Microsoft.VisualStudio.Workload.NativeDesktop
完了後、C:\VS2022Offline フォルダー一式を対象 PC にコピーし、vs_setup.exe を実行します。ネット未接続でもインストールできます(企業のセキュリティポリシーに従うこと)。
更新(レイアウトのメンテナンス)
.\vs_community.exe --layout C:\VS2022Offline --lang ja-JP --includeRecommended
同じコマンドを再実行すると不足分のみダウンロードされます。共有フォルダーや外付け SSD での運用が便利です。
企業ネットワークで詰まりやすいポイントと回避策
| ポイント | 症状 | 対処 |
|---|---|---|
| HTTPS 検査(中間証明書挿し替え) | TLS 警告/Schannel エラー、0 B/s 固定 | Microsoft ドメインを検査バイパスに登録。検査用中間 CA をクライアント信頼ストアへ配布。 |
| URL カテゴリ/アプリ制御 | CDN への接続が sporadic に失敗 | *.visualstudio.com、*.download.visualstudio.microsoft.com、*.azureedge.net などを許可。 |
| PAC の判定ミス | 一部の CDN のみ直結/プロキシ経由が混在し不安定 | PAC の SNI/ドメイン判定を見直し。WinHTTP へも同条件を取り込み。 |
| 古い TLS ポリシー | TLS1.0/1.1 のみ許可 | TLS1.2 以上を有効化。強力暗号を許可。 |
家庭用ルーターで詰まりやすいポイントと回避策
- セキュリティ/保護機能で「不審な大容量ダウンロード」を検知してブロック → 一時的に無効化して挙動を比較。
- DNS を独自サービス(広告ブロック等)に切り替えている → 一時的に ISP 標準やパブリック DNS へ変更。
- IPv6 経路が不安定 → ルーターの IPv6 を一時無効化/別回線で比較。
ログの集め方・読み方(原因を可視化)
インストーラーが 0 B/s で固まる際、ログには多くの手がかりが出ます。代表的な場所と文字列は次のとおりです。
%TEMP%フォルダー内のdd_client_*.log、dd_setup_*.log、dd_bootstrapper_*.log%ProgramData%\Microsoft\VisualStudio\Packages\_Instances配下のセットアップログ
ネットワーク系エラーの代表例と意味:
| コード/ログ片 | 意味 | 対処の方向性 |
|---|---|---|
0x80072EE7 / ERROR_WINHTTP_NAME_NOT_RESOLVED | DNS 解決失敗 | DNS 設定・フィルタの見直し、ipconfig /flushdns |
0x80072EFE / 接続が中断 | 経路中断・検査機器による切断 | VPN/別回線、HTTPS 検査バイパス |
12175 / ERROR_WINHTTP_SECURE_FAILURE | TLS 失敗(証明書/暗号) | TLS1.2 有効化、時刻同期、ルート証明書更新 |
0x80072F8F / セキュリティエラー | 証明書検証エラー | 中間 CA/ルート更新、時刻確認 |
0x80200010 / 0x80200013 | 転送の再試行多発 | 回線不安定/帯域制御、別回線で比較 |
サンプル(抜粋・匿名化):
[WebClient] HttpSendRequest failed: ERROR_WINHTTP_SECURE_FAILURE (12175)
[Acquisition] Download failed: https://<cdn-edge>/payloads/...
[Telemetry] Connectivity: Endpoint=download.visualstudio.microsoft.com; Result=HandshakeFailed
「インストーラー側」の再構築(キャッシュ・権限・一時領域)
- アプリ設定から Visual Studio Installer の「修復/リセット」を実行。
%ProgramData%\Microsoft\VisualStudio\Packagesと%TEMP%の空き容量を確保(システムドライブに 20 GB 以上推奨)。- 一時フォルダーがネットワークドライブや権限制限下にある場合は、環境変数
TEMPとTMPをローカル(例:C:\Temp)に一時変更。 - ウイルス対策のリアルタイムスキャンが極端に重い場合は一時的に除外(Packages フォルダー直下や vs_setup 実行ファイル)。
家庭・個人利用での「これだけは避けたい」NG 対処
hostsへの固定 IP 書き込み:CDN は動的に最適化・更新されるため長期的に破綻します。- 常時ファイアウォール無効化:原因切り分け以外での恒久運用は避ける。
- 怪しいミラーサイトからの入手:署名検証ができずリスク高。
企業・教育機関向けの運用設計(恒久対策)
- 許可リスト方式:*.download.visualstudio.microsoft.com、*.azureedge.net、*.visualstudio.com、*.windowsupdate.com 等をカテゴリ単位で許可。
- HTTPS 検査の例外:開発者向け CDN/パッケージ配布系を検査バイパス。SNI ベースの例外が有効。
- オフラインレイアウトの共有:バージョンごとに共有ディレクトリへ配置。月次で更新。
- Self‑Service ドキュメント整備:本記事のショート版(VPN/別回線/オフライン手順)を社内ポータルに掲載。
代表的な質問(FAQ)
Q. 0 B/s と表示されても裏で進んでいる可能性は?
ゼロ表記が UI の一時的不具合のケースもゼロではありません。リソースモニターや タスクマネージャー のネットワークタブでプロセス(vs_installer.exe 等)に実流量が出ていればそのまま待つ選択肢もあります。ただ、多くのケースでは実際にハンドシェイクが成立しておらず、待っても進みません。
Q. ウイルス対策は関係ある?
リアルタイムスキャンがパッケージ展開を遅延させることはありますが、「0 B/s 固定」の主因はほぼ通信経路です。検証用に一時停止して差が出るかを比べます。
Q. Winget での導入は?
Winget 経由でも最終的に Visual Studio の配布 CDN へ接続します。ネットワークが原因なら同様に詰まる可能性があります。問題の切り分けにはなりますが、根本解決には上記の回避策が必要です。
失敗しない「原因切り分け」の順番(テンプレート)
- 別回線/VPNに切り替えて再試行(ここで直れば回線由来確定)。
- PC を変えて同じ回線で再試行(PC 差か、回線差かを分離)。
- 時刻同期・TLS・サービス確認(前述のコマンド群)。
- インストーラー修復/キャッシュ整理。
- オフラインレイアウト(確実)。
実務に効く「メモ用ショート手順」
# 1) まず VPN または別回線で試す
# 2) だめなら時刻・TLS・サービス確認
w32tm /resync
PowerShell: Get-Service BITS, wuauserv, CryptSvc
# 3) インストーラー修復 / リセット
# 4) オフラインレイアウト作成(別 PC)
vs_community.exe --layout D:\VS2022Offline --lang ja-JP --includeRecommended
# 5) 対象 PC で vs_setup.exe を実行
まとめ(意思決定の指針)
- 原因の大半は回線(ISP や社内プロキシ)側のダウンロード経路遮断・変換に起因。
- 手っ取り早い回避策は VPN か別回線。差が出るならネットワーク側の問題が確定。
- 恒久対策やオフライン環境では「オフラインレイアウト」が最も安定。
- Windows の基本整備(時刻、TLS 1.2、ルート証明書、サービス)を揃えるだけで改善する例も多い。
- 企業ネットワークでは、Microsoft の配布 CDN を検査バイパス・許可リストに入れる設計が王道。
参考:トラブル対応の「見える化」補助表
| 観測点 | 正常系の兆候 | 異常系の兆候 | 次の一手 |
|---|---|---|---|
| 別回線での挙動 | 速度が出てダウンロード進行 | 0 B/s のまま | 経路に依存しない → OS/アプリ側へ、依存する → 回線・機器側へ |
| 時刻同期 | 誤差数秒以内 | 分単位でズレ | w32tm /resync、NTP 設定見直し |
| Schannel ログ | 警告なし | 36874/36888/36887 | TLS 1.2 と証明書、HTTPS 検査の例外化 |
| プロキシ設定 | 統一された経路(IE/WinHTTP) | PAC ミスで分岐 | netsh winhttp import proxy source=ie |
最後に:インストール後の安定運用のために
- 月次でオフラインレイアウトを更新し、複数台の同一バージョン展開を容易にする。
- 「修復/変更」からワークロードを必要最小限に保ち、更新量を抑える。
- 学内・社内の開発端末で共通のポリシー(TLS、証明書、許可リスト)を策定して再現性を確保。

コメント