ERR_QUIC_PROTOCOL_ERROR の意味と直し方（Chrome・Edge・Opera対応）

ERR_QUIC_PROTOCOL_ERROR とは？

ERR_QUIC_PROTOCOL_ERRORは、サイトがページを送り始めた後に、ChromeのQUIC接続が途切れたことを示すエラーです。 QUICは、HTTP/3の土台になっているUDPベースの通信方式です。Chromeは、汎用の「このサイトにアクセスできません」ページ（「…のウェブページは一時的に停止しているか、新しいウェブアドレスに移動した可能性があります。」）の下にこのコードを表示します。Chromiumでは、エラー番号-356「There is a QUIC protocol error」として定義されています。

通常、Chromeは自力で復旧します。QUICでのリクエストが失敗すると、サーバーがすでに応答を始めていた場合を除き、通常のTCP接続でリクエストをやり直します（http_network_transaction.cc）。そのため、QUICを完全にブロックするネットワークではこのエラーは起きません。原因になるのは、QUICの開始を許してから壊すネットワーク、VPN、サーバーです。

このエラーが出るのは、Chrome、Edge、Opera、Brave、VivaldiといったChromiumベースのブラウザーだけです。ERR_SSL_PROTOCOL_ERROR（TLSハンドシェイクの失敗）やERR_NETWORK_CHANGED（接続の切り替わり）とは別の障害です。まずページを再読み込みしてください。再試行でうまくいくことがよくあります。何度も出る場合は、以下の対処法を、最も確実なQUICの無効化から順に、原因ごとに試してください。

QUICとは？Chromeが使用する理由

QUICはGoogleが開発し、2013年に初めて発表され、2021年にIETFがRFC 9000として標準化しました。TCP + TLSを、UDP上で動く1つの暗号化プロトコルに置き換えるもので、HTTP/3の土台です（Androidの「プライベート DNS」も、DNS over HTTP/3でこれを使います。プライベートDNSとはを参照）。

TCP + TLS 1.3では最初のリクエストまでに2往復が必要ですが、QUICは1往復で、再接続時は0往復も可能です。2020年10月7日、GoogleはChrome安定版ユーザーの25%がすでにIETF QUIC（ドラフトh3-29）を使っていると発表しました。Googleの計測では、検索のレイテンシは2%以上、YouTubeの再バッファリングは9%以上減少し、スループットはデスクトップで3%以上、モバイルで7%以上向上しました（Chromium Blog）。

ChromeがQUICを使うのは、サイトが Alt-Svc ヘッダーまたはDNSのHTTPSレコードで対応を告知している場合だけです。2026年10月26日に、よくアクセスされる20サイトを調べたところ、10サイトが Alt-Svc ヘッダーでHTTP/3を告知していました（Google、YouTube、Facebook、Instagram、Amazon、LinkedIn、Bing、WhatsApp、Cloudflare、OpenAI）。

ERR_QUIC_PROTOCOL_ERROR の原因

原因はどれも同じパターンです。QUICは開始できたのに、その後で何かが壊しています。

• QUICの開始は許すが、その後に壊すネットワーク — 転送の途中でUDPトラフィックを破棄したりタイムアウトさせたりするファイアウォール、ルーター、ISPの機器。（UDP 443を完全にブロックするネットワークでは、ChromeがTCPを使うだけで、エラーは出ません。）
• UDPを途中で落とすVPN — VPNが再接続したり、サーバーや経路を切り替えたり、通信のないUDPフローをタイムアウトさせたりすると、開いているQUIC接続が切れます。（QUICには小さすぎる経路はハンドシェイクの段階で失敗し、その場合はChromeがTCPを使います。）
• 通信を検査するセキュリティソフト — 接続に割り込むウイルス対策ソフトやファイアウォールの「Web保護」が、QUICのストリームを壊すことがあります。
• 不安定な接続 — 弱いWi-Fiや、ダウンロード中のネットワーク切り替え。
• サイト側のHTTP/3設定 — HTTP/3を告知しているのに、QUICスタックが応答の途中で失敗するサーバーやCDN。その場合は、どのネットワークからでも、そのサイトだけで全員がエラーになります。サーバーダウンチェックで、ほかの人からも失敗しているか確認できます。
• 原因ではないもの：プロキシ — ChromeがQUICを使うのは直接接続だけなので、プロキシを設定していると、すべてのリクエストはTCPで送られます。

修正方法1：ChromeでQUICプロトコルを無効にする

最も確実な修正方法です。QUICをオフにすると、Chromeはすべてのサイトで、TCP上のHTTP/2（またはHTTP/1.1）を使います。ページは問題なく表示されますが、QUICによる高速化は失われます。Googleの計測では、検索が約2%速くなり、YouTubeの再バッファリングが9%減る程度の差です。

IT管理者の方へ： ChromeとEdgeのポリシー QuicAllowed をfalseにすると、chrome://flagsに触れずに、管理対象のデバイスでQUICをオフにできます。

Google ChromeでQUICを無効にする

以下の手順に従って、Windows、Mac、LinuxのChromeでQUICを無効にしてください。

1. Open Chrome and type in the address bar:
   chrome://flags/#enable-quic

2. Find "Experimental QUIC protocol"

3. Change the dropdown from "Default" to "Disabled"

4. Click "Relaunch" at the bottom to restart Chrome

5. Verify: visit the website that showed the error

Microsoft EdgeでQUICを無効にする

EdgeはChromiumベースなので、手順はほぼ同じです。

1. Open Edge and type in the address bar:
   edge://flags/#enable-quic

2. Find "Experimental QUIC protocol"

3. Change to "Disabled"

4. Click "Restart" to apply

OperaとBraveでQUICを無効にする

OperaとBraveも同じChromiumのフラグシステムを使用しています。

Opera:  opera://flags/#enable-quic → Disabled → Restart
Brave:  brave://flags/#enable-quic → Disabled → Restart

修正方法2：Chromeの接続をリセットする

データを消してもこの問題が直ることはまれですが、開いている接続をリセットすると直ることがあります。Chromeがサイトへの新しいQUIC（またはTCP）接続を張り直すためです。

接続をフラッシュしてからキャッシュをクリアする

まずFlush socket poolsを試してください（下の補足を参照）。それでもエラーが出る場合は、キャッシュをクリアします。

1. Press Ctrl+Shift+Delete (Windows/Linux) or Cmd+Shift+Delete (Mac)

2. Choose More → All time for the time range

3. Tick "Cached images and files"

4. Click "Delete data" ("Delete from this device" if you're signed out)

5. Restart Chrome and try the website again

修正方法3：ブラウザ拡張機能を無効にする

原因であることはまれです。拡張機能はQUIC自体を変更できず、デスクトップ版Chromeの「VPN」拡張機能は実際にはプロキシで、ChromeがQUICをまったく使わなくなります。

サイトをシークレット ウィンドウ（Ctrl+Shift+N）で開いてください。許可していない限り、拡張機能はオフになります。そこで表示できるなら、chrome://extensions/ で拡張機能を1つずつオフにして、原因を探します。

修正方法4：ファイアウォールとウイルス対策の設定を確認する

UDPポート443を完全にブロックするファイアウォールは、このエラーの原因になりません。ChromeがTCPを使うだけです。問題になるのは、QUICの開始を許してから、途中でパケットを破棄したり検査したりするファイアウォールやセキュリティソフトです。

アウトバウンドのUDP 443を完全に許可するか、完全にブロックしてください。よくある環境での確認方法は次のとおりです。

Windowsファイアウォール

Windows Defender ファイアウォールは既定でアウトバウンド通信を許可し、ブロック規則は常に許可規則より優先されます。そのため、誰かが追加したブロック規則を探して無効にします。PowerShellを管理者として実行してください。

# List enabled outbound block rules that cover UDP (or any protocol)
Get-NetFirewallRule -Direction Outbound -Action Block -Enabled True |
  Where-Object { ($_ | Get-NetFirewallPortFilter).Protocol -in 'UDP', 'Any' } |
  Select-Object Name, DisplayName

# Turn off the rule that blocks UDP 443 (use its Name from the list)
Disable-NetFirewallRule -Name '<Name>'

macOSファイアウォール

macOSの組み込みファイアウォールが制御するのは受信接続だけなので、QUICをブロックすることはありません。Little SnitchやLuLuなどのアウトバウンドファイアウォールを使っている場合は、ChromeのポートへのUDP 443宛てトラフィックに対する規則を確認してください。

ルーターレベルのファイアウォール

最も手っ取り早いテストは、スマートフォンのモバイルホットスポットに接続してサイトを読み込むことです。エラーが消えれば、原因はルーター、ISPの機器、またはオフィスのファイアウォールです。

次に、ルーターの管理ページ（通常は 192.168.1.1 または 192.168.0.1）で、UDPを制限するファイアウォール、「SPI」、セキュリティの設定を探し、ファームウェアを更新してください。

修正方法5：VPNを確認する

VPNはUDPを含むすべての通信をトンネリングするため、通常はQUICもそのまま通ります。問題になるのはトンネル自体が不安定な場合です。再接続、サーバーや経路の切り替え、通信のないUDPフローのタイムアウトによって、開いているQUIC接続が切れます。

VPNを切断して再読み込みしてください。エラーが消える場合は、次を試します。

• VPNのサーバーやプロトコルを変える — より安定したサーバーや別のプロトコルで、切断が止まることがよくあります
• 会社のVPN — HTTPSを検査するため、意図的にQUICをブロックしている企業ネットワークは多くあります。IT部門の設定に従い、エラーが続く場合はQUICをオフにしてください
• VPN接続中はQUICをオフにしておく — 修正方法1はどのVPNでも有効です。ChromeがTCPを使うようになるためです

修正方法6：隠れたプロキシやトラフィックフィルターを探す

プロキシの設定がこのエラーの原因になることはありません。ChromeがQUICを使うのは直接接続だけなので、プロキシがあるとすべてのリクエストはTCPで送られます。ただし、プロキシ設定なしでネットワークレベルで通信をフィルタリングするセキュリティソフトやVPNソフトは、プロキシのように見えることがあります。

どのネットワークでも、このパソコンだけでエラーが出る場合は、そうしたソフト（「Webシールド」「ネットワーク保護」、バックグラウンドで動くVPNアプリなど）を1つずつオフにして再読み込みしてください。

修正方法7：Chromeを最新バージョンに更新する

ChromeのQUICのコードは定期的に更新され、更新でChrome側の接続処理のバグが修正されます。しばらくオフラインだったパソコンでは、ほかの設定を変える前に、Chrome（またはEdge、Opera、Brave）を更新してください。

1. Open Chrome → click ⋮ (three dots) → Help → About Google Chrome

2. Chrome will automatically check for updates

3. If an update is available, click "Relaunch" to apply

4. After updating, verify your Chrome version:
   chrome://version
   
   Look for the version number 

サーバー側のQUIC問題（Webサイト管理者向け）

Webサイトの管理者で、訪問者からERR_QUIC_PROTOCOL_ERRORの報告を受けている場合、サーバー側に原因がある可能性があります。以下は最も一般的なサーバー側の原因です。

• CloudflareのHTTP/3設定 — Cloudflareを使っていて訪問者からエラーの報告がある場合は、Speed > Settings > Protocol Optimization > HTTP/3 を確認し、しばらくオフにしてテストしてください
• 自前サーバーのHTTP/3 — nginxは1.25.0からHTTP/3に対応しています（listen 443 quic reuseport; と Alt-Svc ヘッダー）。LiteSpeedとCaddyも対応しています。ポート443のUDPリスナーに到達できること、QUICスタックが最新であることを確認してください。QUICは常にTLS 1.3を使います。サーバーが対応しているかはSSLチェッカーで確認できます
• UDPを転送しないロードバランサー — AWS ALBなどのアプリケーションロードバランサーはTCPしか通しません。UDP 443を転送せずに Alt-Svc で h3 を告知すると、ChromeはそのサイトのQUICを5分間「使用不可」と記録し、その後に再試行して、待ち時間を最大2日まで倍々に延ばしながら、そのたびにTCPと競走させます。ヘッダーを外すか、UDPに対応した（レイヤー4の）ロードバランサーを使ってください

# Test HTTP/3 only, with no fallback (needs a curl built with HTTP/3)
curl --http3-only -sI https://your-domain.com

# Check something listens on UDP 443 (as root; firewalls are separate)
ss -ulnp 'sport = :443'

# Verify Alt-Svc header (tells browsers QUIC is available)
curl -sI https://your-domain.com | grep -i alt-svc
# Expected: alt-svc: h3=":443"; ma=86400

QUICを有効のままにすべきか、無効にすべきか？

QUICをオフにするのは安全な修正方法ですが、正常なネットワークでは実際の速度を手放すことになります。判断の目安は次のとおりです。

QUICをオンのままにするのは、自宅、モバイルデータ、エラーが出ないネットワークです。Google自身のデータでは、QUICで検索が速くなり、動画の再バッファリングが減り、スループットが上がります。スマートフォンがWi-Fiからモバイルデータに切り替わっても接続が保たれます。

QUICをオフにするのは、エラーが繰り返し出るネットワークやVPNです。Chromeは、どのネットワークでも通るTCP上のHTTP/2（またはHTTP/1.1）を使います。良好なブロードバンド回線なら、違いに気づく人はほとんどいません。

QUICではなくHTTP/2で同じ種類の障害が起きると、ChromeはERR_HTTP2_PROTOCOL_ERRORを表示します。原因と対処法は別です。