Visual Studio 2022でASP.NET Core MVCを作成してそのまま起動すると、Chrome/Edgeのコンソールに「aspnetcore-browser-refresh.jsのWebSocket接続に失敗」と表示され、ホットリロード（ブラウザ自動更新）が効いていないように見えることがあります。原因の切り分け方法と、よく使われている回避策をまとめます。
「aspnetcore-browser-refresh.js の接続失敗」とは何が起きているのか
このエラーは、開発中の利便性を高めるためのブラウザ自動更新（Browser Refresh）機能が、ブラウザと開発サーバー間のWebSocket通信を確立できなかったときに出ることが多い現象です。
重要なのは、エラーが出ていても次の状態になっているケースがある点です。
- アプリの画面表示や通常の動作はできる（＝アプリ本体の致命的エラーではない）
- ただし、ファイル変更時の自動リロード／ホットリロードの体験だけが壊れているように見える
| 項目 | 内容 |
|---|---|
| コンソールに出る代表的なメッセージ | 「WebSocket connection failed」「aspnetcore-browser-refresh.js の接続に失敗」など（URLは環境により異なる） |
| 画面表示 | 表示自体は正常なことが多い |
| 影響が出やすい機能 | ホットリロード、ブラウザ自動更新、Razor変更の反映など |
| 本番環境への影響 | 通常はなし（開発補助用スクリプトのため、公開物に入らない／入れない運用が一般的） |
発生しやすい環境の傾向
質問で挙がっている条件は、実際に「新規プロジェクトでも出る」「IE11だと再現しない」「Chrome/Edgeで出る」という点が特徴的です。特に新規MVCテンプレートで発生する場合、アプリのコードよりもVisual Studioや起動プロファイル、開発用通信の組み合わせを疑うのが近道です。
| カテゴリ | 条件例 | ポイント |
|---|---|---|
| IDE | Visual Studio 2022（例：17.1.0で顕在化報告） | VSの特定バージョン依存の不具合が疑われる |
| .NET | .NET 6 / .NET 8 | SDK側というより、VSの統合機能側の問題として見えることがある |
| テンプレート | ASP.NET Core Web App (Model-View-Controller) | 「何もいじっていないのに出る」＝再現性が高く切り分けしやすい |
| ブラウザ | Chrome / Edge（最新） | WebSocketや証明書、セキュリティ制限の影響を受けやすい |
| 再現しない例 | IE11 | IEは機能が古く、同じ仕組みで動かない／そもそも注入が行われない場合がある |
技術的な背景：Browser Refresh が動く仕組み
aspnetcore-browser-refresh.jsは、開発時にページを自動で更新するためのスクリプトです。ざっくり言うと、次の流れで動作します。
- Visual Studio（または開発ツール）が、開発実行時にページへ
aspnetcore-browser-refresh.jsを読み込ませる - スクリプトがブラウザ側で起動し、開発サーバーへWebSocket（多くはwss://）で接続しようとする
- ファイル変更などを検知すると、サーバー側から通知が飛び、ブラウザがリロードする
つまり、エラーの本質は「アプリが落ちた」ではなく、WebSocketの接続が確立できないことにあります。ここが切り分けポイントです。
まず最初にやるべき切り分けチェック
原因が「Visual Studioの不具合」なのか、「環境（証明書・プロキシ・起動方式）」なのかで対処が変わります。以下のチェックを順番に行うと、無駄打ちが減ります。
起動方法の違いで挙動が変わるか
| チェック | 操作 | 見える結果 | 示唆される原因 |
|---|---|---|---|
| Ctrl+F5 と F5 の比較 | 同じプロジェクトを Ctrl+F5（デバッグなし）と F5（デバッグ）で起動 | 片方だけエラーが出る/出ない | VSの統合機能（ホットリロードや注入）周りの問題の可能性 |
| 起動プロファイルの切替 | 「IIS Express」⇔「プロジェクト名（Kestrel）」を切替 | 片方だけ発生 | プロファイル固有のHTTPS/ポート/証明書/プロキシ影響 |
| 別ブラウザでの比較 | Chrome⇔Edge⇔（可能ならFirefox） | Chrome/Edgeのみ発生 | WebSocketや証明書、ブラウザのセキュリティ仕様の影響 |
本当にホットリロードが効いていないのか確認する
「コンソールにエラーがある＝ホットリロードが100%死んでいる」とは限りません。次のように再現性のある変更で確認します。
- Razor（.cshtml）の見出しテキストを変える → 保存 → ブラウザが自動更新されるか
- 自動更新されない場合でも、手動リロードしたら反映されるか
- F12のNetworkタブで「WS（WebSocket）」を見て、接続が失敗していないか
「手動リロードすれば反映される」なら、アプリ本体は動いていて、開発補助の通知だけが止まっている可能性が高いです。
主な原因：Visual Studio側の既知問題の可能性
この現象は、Visual Studio 2022の特定バージョンで「MVCテンプレートを新規作成し、そのまま起動しただけで毎回出る」という報告があり、Visual Studioのバージョン依存不具合として扱われることがあります。
質問で挙がっている例では、次のような状況が示されています。
- Visual Studio 2022 17.1.0で発生し、17.0.4に戻すと改善したケースがある
- .NET 8、新規MVCテンプレートでも、別のVSバージョン（例：17.9.6 / 17.12.5）で同様の表示が出たという報告がある
- VS2019で作ったプロジェクトをVS2022で開いたケースで起きやすい、という指摘もある
ここから読み取れるのは、アプリのコードというより「VSのブラウザリフレッシュ統合」の不安定さが疑われる点です。
ただしVS不具合以外の要因もある：代表的な落とし穴
同じ「WebSocket接続失敗」に見えても、実際には複数の原因があり得ます。以下に、現場で遭遇しやすい要因と確認ポイントを整理します。
| 原因候補 | 起きやすい状況 | 確認方法 | 対処の方向性 |
|---|---|---|---|
| Visual Studioのバージョン依存不具合 | 新規テンプレートでも毎回出る／複数環境で再現 | VSの更新/戻しで改善するか、別PCでも出るか | VS更新、安定版へ戻す、修正情報を追う |
| 開発用HTTPS証明書の問題 | wss://接続に失敗する、証明書警告が出る | 同じURLを開くと証明書エラーが出るか、HTTPSが赤い警告になっていないか | 開発証明書の再作成/信頼、ブラウザの証明書状態を整える |
| プロキシ／セキュリティ製品がWebSocketを遮断 | 社内ネットワーク、EDR、フィルタ製品、厳しいポリシー | 自宅回線や別ネットワークで再現するか、プロキシ設定有無 | WebSocket許可、localhost例外設定、ネットワーク管理者へ相談 |
| 起動プロファイルの設定不整合 | IIS Expressだけ発生、またはKestrelだけ発生 | 起動プロファイル切替で変わるか、ポートが衝突していないか | ポート変更、プロファイル再作成、不要な設定の整理 |
| 古いプロジェクト資産の持ち込み | VS2019→VS2022移行で発生しやすい | 新規作成プロジェクトと差分比較 | 新規で作り直して必要部分だけ移植 |
回避策：実際に取られている対処を「おすすめ順」で整理
ここからは、実際に現場でよく選ばれる回避策を、効果が出やすい順に並べます。すべてをやる必要はありません。まずは上から順に、少ない手間で効果が出るものから試すのが現実的です。
Visual Studioを更新する（まずはここから）
Visual Studio側の既知問題が原因の可能性があるため、最新版への更新で改善するケースがあります。特に、発生が「特定バージョンだけ」という報告がある場合は有効です。
- Visual Studio Installerで更新を確認
- 更新後、同じ新規テンプレートで再現確認（既存プロジェクトだけで判断しない）
更新しても直らない場合は、次の「安定版へ戻す」を検討します。
安定しているバージョンに戻す（ダウングレード）
「開発体験が壊れていてストレスが大きい」「チーム全体で再現する」場合は、一時的に問題の出ないバージョンへ戻すのが最短ルートになることがあります。
実例として、Visual Studio 2022のあるバージョンで発生し、以前のバージョン（例：17.0.4）へ戻すと改善したというケースが挙げられています。
| 方針 | メリット | 注意点 |
|---|---|---|
| 安定版へ戻す | 短時間で症状が消え、ホットリロードが復活しやすい | チームでバージョンを揃える運用が必要／自動更新で戻らないようにする配慮が必要 |
| 最新版を待つ | 将来的に修正される可能性 | 直るまで不便が続く／いつ直るか読みにくい |
「今すぐ安定して開発したい」なら、ダウングレードは現実的です。特にホットリロードが業務効率に直結する場合は効果が大きいです。
エラーを割り切って無視する（本番に影響しない前提で）
このエラーは、ページ表示やAPI処理などアプリ本体の動作に影響がないことも多く、通常のデバッグ（ブレークポイント、ウォッチ等）はできる場合があります。
- コンソールエラーは気になるが、機能開発は進められる
- 本番公開では、通常このスクリプトに依存しない（開発用補助機能のため）
「納期が迫っている」「更新/戻しが難しい社内PC」など、環境変更ができない場合の現実的な選択肢です。
開発用HTTPS証明書をリセットして信頼し直す
エラーメッセージに wss:// が出ている場合、WebSocketのTLS確立に失敗している可能性があります。特に、Windowsの環境更新やブラウザ更新のタイミングで、開発証明書の扱いが不整合になることがあります。
次のコマンドで、開発用証明書を整理して信頼し直す手順が一般的です。
dotnet dev-certs https --clean
dotnet dev-certs https --trust実行後は、ブラウザを完全に閉じて再起動し、もう一度Visual Studioから起動して確認します。これで改善するなら、VSの不具合ではなく「証明書・TLS周り」の問題だった可能性が高いです。
プロキシ・セキュリティ製品・VPNの影響を疑う
企業ネットワークやVPN、セキュリティ製品が導入されているPCでは、localhostであってもWebSocket通信がフィルタされることがあります。見落としやすいのですが、次のようなときは疑う価値があります。
- 社内LANでは発生するが、自宅回線だと発生しない
- VPN接続中だけ発生する
- セキュリティソフトを更新した直後から発生する
| 状況 | 試せること | 期待できる効果 |
|---|---|---|
| 社内プロキシが強い | プロキシ設定の例外に localhost / 127.0.0.1 を追加（可能な範囲で） | WebSocketの握手（Upgrade）が遮断されにくくなる |
| EDR/フィルタが厳しい | 開発サーバーの通信許可、ローカル開発の例外ルールを確認 | 開発補助の通信が通る |
| VPN利用 | VPNを切って再現確認 | 原因がネットワーク経路にあるか切り分けできる |
組織のポリシーによっては開発者側で変更できないため、切り分け結果を添えて情シスに相談するのが早いです。
プロジェクトを新規作成して必要なコードだけ移植する
「VS2019で作ったプロジェクトをVS2022で開いたら出る」「古い設定が混ざっていそう」な場合は、同じテンプレートでVS2022で新規プロジェクトを作り直し、コントローラーやビューなど必要な資産だけを移植して比較するのが有効です。
移植時のおすすめ手順は次の通りです。
- VS2022で同じテンプレート（MVC）を新規作成し、何も変更せず起動して状態を確認
- 問題が出ないなら、既存プロジェクトから段階的にファイルを移植（Controller → View → wwwroot → 追加設定の順）
- どの段階で再発するかを見て、原因になっている設定差分を特定
「再現条件が複雑で追いにくい」ケースでも、段階移植だと原因箇所が見えやすくなります。
エラーの見え方を「正しく理解」して不安を減らす
このエラーは、見た目が強い（毎回コンソールに赤字が出る）ため不安になりますが、落ち着いて整理すると次の2点が重要です。
| 観点 | 結論 | 理由 |
|---|---|---|
| アプリの品質への影響 | 多くの場合、直接は影響しない | Browser Refreshは開発補助で、アプリ本体の処理ロジックとは別 |
| 開発効率への影響 | 影響は大きいことがある | 自動更新が止まると、検証のたびに手動リロードや再起動が必要になる |
つまり、焦点は「このエラーをゼロにする」よりも、開発効率を取り戻すために何を選ぶかです。更新・戻し・無視・環境修正のどれが最適かは、チームの運用やPC制約で決まります。
よくある質問
新規プロジェクトでも出るのはなぜ？
新規テンプレートでも出る場合、アプリ固有のコードではなく、起動時にVisual Studioが追加する開発機能（ブラウザリフレッシュやホットリロード統合）の問題である可能性が高いです。特定VSバージョンで発生しやすい報告があるのも、その推測を後押しします。
IE11で再現しないのはなぜ？
IE11はモダンなWeb開発の対象から外れている機能が多く、同じスクリプト注入やWebSocketの挙動にならない場合があります。再現しないこと自体は「問題が解決した」ではなく、単に条件が違う可能性が高いです。
本番環境に影響しますか？
通常は影響しません。開発補助の仕組みなので、本番デプロイで同じスクリプトが動作する構成にはしないのが一般的です。とはいえ、万一公開環境で同様のスクリプトを配信している場合は意図しない挙動になり得るため、公開物に含まれないことをビルド・デプロイ手順で確認しておくと安心です。
まとめ：最短で安定させるための判断基準
最後に、行動を決めやすいように判断の軸を整理します。
| 優先したいこと | おすすめの選択 | 理由 |
|---|---|---|
| とにかく早く直したい | VSの更新、または安定版へ戻す | VS由来の不具合なら最も効果が出やすい |
| 環境要因かどうか確かめたい | 起動プロファイル切替、証明書のリセット、VPN/プロキシ切り分け | WebSocket/TLS/ネットワークの問題を潰せる |
| 当面開発を止めたくない | エラーは割り切って無視（必要なら後で修正） | 本体が動いていれば作業は進められる |
| 移行プロジェクトでだけ起きる | 新規作成→段階移植で原因差分を特定 | 設定の持ち込みが原因なら最短で切れる |
「新規MVCでも毎回出る」「Chrome/Edgeでだけ出る」「ホットリロードが効かない」という条件が揃うなら、まずはVisual Studioの更新または安定版への戻しを第一候補にしつつ、並行して証明書・ネットワークをチェックすると解決に近づきます。
コメント