# ⚡ HTTP/3 を配信する HTTP/3 は、何かを導入しなくても使えるという意味で既定で有効です。プロトコルの集合が 許せば、サーバーは UDP 443 に QUIC リスナーを開きます。注意が要るのは検証です。 黙って HTTP/2 に落ちたクライアントは、成功とまったく同じに見えます。 ## 🧾 はじめる前に - ホストに解決する名前と、その名前の証明書（[HTTPS](/ja/start/https/)）。 - プロバイダのファイアウォールとホスト側の両方で **UDP 443 を開放**すること。 QUIC に代替はありません。UDP が塞がれていれば、クライアントは HTTP/2 を使い、 そのことを告げません。 - HTTP/3 対応のクライアント。多くのディストリビューションの `curl` は非対応で、 要求すればはっきり分かります。 ```text curl: option --http3: the installed libcurl version doesn't support this ``` ## 🔌 有効にする ```caddyfile { email pingclair@pingclair.com servers { protocols h1 h2 h3 } } example.com { file_server /srv/site } ``` サイトを動かした状態でホスト上で実測: ```bash sudo ss -lunp | grep ':443 ' ``` ```text UNCONN 0 0 *:443 *:* users:(("pingclair",pid=5425,fd=22)) ``` リストから `h3` を外すとこのリスナーは消えます。リストがスイッチです （[TLS で調整できること](/ja/guides/tls-tuning/#-which-protocols-are-served)）。 リスナーを止めずに 1 つのサイトだけ HTTP/3 から外すこともできます。 ```caddyfile example.com { tls { http3 off } file_server /srv/site } ``` ## ✅ クライアントが使ったことを示す サーバーのアクセスログはプロトコルを名乗らないので、証拠はクライアント側から取り ます。ngtcp2 か quiche でビルドされた curl なら何でもよく、HTTP/3 を使えない curl しかないホストではコンテナが最短です。 ```bash docker run --rm --network host \ ymuski/curl-http3 curl -sI --http3 https://example.com/ ``` ```text curl 8.2.1-DEV (x86_64-pc-linux-gnu) libcurl/8.2.1-DEV BoringSSL zlib/1.2.13 nghttp2/1.52.0 quiche/0.18.0 ``` ```text HTTP/3 200 content-type: text/html; charset=utf-8 etag: "5e-6ab20622" accept-ranges: bytes x-served-by: pingclair server: Pingclair ``` `--network host` が、コンテナにホストの UDP 経路を使わせます。無いと QUIC を塞ぐ ネットワーク名前空間を通ることがあります。 最初の行がすべての答えです。ステータス行は `HTTP/2` ではなく `HTTP/3` です。同じ URL を `--http2` と `--http1.1` で要求すると残り二つが表示され、クライアントが 単に落ちているのではないと分かります。 コンテナが使えない場合、QUIC ハンドシェイクはシステムの OpenSSL 3.5 以降で確認 できます。 ```bash openssl s_client -quic -alpn h3 -connect example.com:443 -servername example.com