HTTP/3（QUIC）の有効化手順（Nginx・CDN・確認方法）

HTTP/3 を有効にするには、Webサーバー（または前段の CDN）が QUIC に対応していること、UDP の443番が外から届くこと、そしてブラウザに「HTTP/3 も使える」と伝える Alt-Svc ヘッダーを返すこと、の3つがそろう必要があります。HTTP/3 は TCP ではなく UDP の上で動くため、HTTP/2 までと同じ感覚で設定すると「設定したのに使われない」状態になりがちです。この記事では、自分で Nginx を運用している場合の設定手順を中心に、CDN やレンタルサーバーで有効にする場合の考え方、使われているかの確認方法、つまずきやすい点を説明します。

HTTP/3 と QUIC の関係

HTTP/3 は、HTTP の通信を QUIC というトランスポートプロトコルの上で行う仕組みです。QUIC は UDP を使い、TLS 1.3 を組み込んでいるので、HTTP/2（TCP＋TLS）より接続確立のやり取りが少なく、パケットの取りこぼしがあっても他のリクエストが巻き込まれて止まりにくい特徴があります。

効果が出やすいのは、モバイル回線や混雑したWi-Fiなど、遅延やパケットロスが多い環境です。安定した回線では、HTTP/2 との体感差が小さいこともあります。HTTP/3 にしたことで検索順位が上がる、というものではないので、表示速度の改善策の1つとして位置づけてください。

もう1つ大事な前提は、HTTP/3 は HTTP/2 や HTTP/1.1 を置き換えるのではなく「追加で使えるようにする」ものだという点です。ブラウザは最初の接続を TCP（HTTP/2 など）で行い、サーバーから Alt-Svc ヘッダーを受け取ってから、次の接続で HTTP/3 を試します。UDP が通らないネットワークでは自動的に TCP に戻るため、TCP の443番の設定は残したままにします。

どこで HTTP/3 を有効にするかを決める

HTTP/3 を終端する場所は、構成によって変わります。

• Cloudflare などの CDN を経由している：利用者との通信は CDN が受けるので、CDN 側の設定で有効にします。オリジンサーバーの変更は不要なことが多いです
• レンタルサーバーやマネージド WordPress：事業者が対応していれば、管理画面の設定で有効にできる場合があります。対応状況は事業者のドキュメントで確認してください
• VPS やクラウドで Nginx を自分で運用している：この記事の次の章の手順で設定します
• ロードバランサーを前に置いている：ロードバランサーが HTTP/3 を終端できるかどうかを確認します。終端できない場合は、UDP をそのまま通す構成にするか、前段の CDN で終端する方法を検討します

Apache（httpd）は、本体だけでは HTTP/3 に対応していません（2026年10月現在）。Apache で動いているサイトで HTTP/3 を使いたい場合は、前段に CDN や対応したリバースプロキシを置くのが現実的です。LiteSpeed 系のサーバーや Caddy は HTTP/3 に対応しており、Caddy は標準で有効になっています。

Nginx で HTTP/3 を有効にする

1. 使っている Nginx が HTTP/3 に対応しているか確認する

Nginx は 1.25.0 から HTTP/3 のモジュール（ngx_http_v3_module）を含むようになりました。ただし、ビルド時に組み込まれていないと使えません。まず、手元の Nginx のバージョンとビルドオプションを確認します。

nginx -v
nginx -V 2>&1 | tr ' ' '\n' | grep -E 'http_v3|--with-openssl|built with'

--with-http_v3_module が表示されれば、HTTP/3 のモジュールが組み込まれています。表示されない場合は、nginx.org が配布している公式パッケージのリポジトリに切り替えるなど、対応したビルドを入れる必要があります。ディストリビューション標準のパッケージは、バージョンが古かったりモジュールが含まれていなかったりすることがあります。

QUIC には、それに対応した TLS ライブラリも関係します。対応状況は Nginx と OpenSSL などのバージョンの組み合わせで変わってきたため、使っている環境が公式ドキュメントの要件を満たしているかを確認してください。Nginx の公式ドキュメントでは、このモジュールに実験的な位置づけの注意書きが付いていた時期もあるので、本番に入れる前に検証環境で試すのが安全です。

2. server ブロックに QUIC の待ち受けを追加する

すでに HTTPS で動いている server ブロックに、UDP の443番で待ち受ける listen ... quic を追加します。設定ファイルは事前にバックアップしておいてください。

server {
    # 既存の TCP（HTTP/1.1・HTTP/2）
    listen 443 ssl;
    listen [::]:443 ssl;

    # 追加：UDP（HTTP/3）
    listen 443 quic reuseport;
    listen [::]:443 quic reuseport;

    http2 on;
    http3 on;

    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;

    # ブラウザに「HTTP/3 も使える」と伝える
    add_header Alt-Svc 'h3=":443"; ma=86400' always;

    # 以下、既存の location など
}

書き方で気をつける点は次のとおりです。

• reuseport は、同じアドレスとポートの組み合わせに対して1か所にだけ書きます。複数の server ブロックで同じ443番の quic を待ち受ける場合、2つ目以降には reuseport を付けません。重複すると duplicate listen options のエラーになります
• QUIC は TLS 1.3 が前提です。ssl_protocols で TLS 1.3 を無効にしていると、HTTP/3 では接続できません
• http2 on; は Nginx 1.25.1 以降の書き方です。古い設定の listen 443 ssl http2; も当面動きますが、新しい書き方にそろえておくと警告が出ません
• add_header は、location ブロックの中に別の add_header があると、そこでは server ブロックの指定が引き継がれません。Alt-Svc が返らない location がないか確認してください

設定したら、構文を確認してから再読み込みします。

sudo nginx -t && sudo systemctl reload nginx

# UDP の443番で待ち受けているか
sudo ss -ulnp 'sport = :443'

3. UDP の443番をファイアウォールで開ける

HTTP/3 が使われない原因として非常に多いのが、UDP の443番が閉じたままになっていることです。TCP の443番を開けていても、UDP は別に許可する必要があります。

# ufw
sudo ufw allow 443/udp

# firewalld
sudo firewall-cmd --permanent --add-port=443/udp
sudo firewall-cmd --reload

クラウドのセキュリティグループや、VPS 事業者の管理画面にあるパケットフィルターでも、UDP の443番の受信を許可します。OS 側だけ開けても、こちらが閉じていれば届きません。

HTTP/3 で通信できているか確認する

ブラウザの開発者ツールで確認する

Chrome や Edge の開発者ツールを開き、「ネットワーク」タブの列見出しを右クリックして「プロトコル」の列を表示します（表示名はブラウザのバージョンで変わることがあります）。h3 と表示されていれば HTTP/3 で通信しています。

最初のアクセスでは h2 のまま、再読み込みすると h3 に変わることがよくあります。これは前述のとおり、ブラウザが Alt-Svc を受け取ってから HTTP/3 を試すためで、正常な動作です。何度再読み込みしても h2 のままなら、次の項目で原因を切り分けます。

curl で確認する

HTTP/3 に対応した curl であれば、コマンドラインからも確認できます。curl -V の Features 欄に HTTP3 があるかで対応を判断できます。

curl -V | grep -i http3

# HTTP/3 だけで接続を試す（対応した curl のみ）
curl -sI --http3-only https://example.com/

# Alt-Svc ヘッダーが返っているか（通常の curl で確認できる）
curl -sI https://example.com/ | grep -i alt-svc

OS 標準の curl は HTTP/3 に対応していないことが多いので、--http3-only が使えない場合は、Alt-Svc の確認とブラウザでの確認を組み合わせてください。

Nginx のアクセスログに $server_protocol を出力するようにしておくと、HTTP/3.0 で届いたリクエストがどれくらいあるかも確認できます。

h3 にならないときの確認ポイント

可能性の高い順に確認します。

1. UDP の443番が届いていない：OS のファイアウォール、クラウドのセキュリティグループ、VPS のパケットフィルターのどれかで閉じていないか
2. Alt-Svc ヘッダーが返っていない：curl -sI で確認し、location ごとの add_header で消えていないか、CDN が書き換えていないか
3. Nginx が HTTP/3 対応のビルドではない：nginx -V に --with-http_v3_module があるか
4. 利用者側のネットワークが UDP を通さない：社内ネットワークや一部の公衆回線では UDP の443番が止められていることがあり、その場合は TCP に戻るのが正しい動作です。別の回線（スマートフォンのモバイル回線など）で試します
5. ブラウザ側の設定やキャッシュ：シークレットウィンドウや別のブラウザでも同じかを確認します

まとめ

• HTTP/3 は UDP 上の QUIC を使うため、UDP の443番の開放と Alt-Svc ヘッダーが必要です
• HTTP/3 は追加の手段で、TCP の443番（HTTP/2・HTTP/1.1）の設定は残します
• CDN を使っているなら CDN 側、自分で Nginx を運用しているなら listen 443 quic reuseport と http3 on で有効にします
• Nginx は HTTP/3 対応のビルドか、TLS 1.3 が有効かを先に確認します
• 確認は開発者ツールの h3 表示と、curl による Alt-Svc の確認で行い、初回は h2 になることを前提に再読み込みで判断します

• Nginx で HTTP/2 を有効にする方法
• TLS 1.3 への移行手順