HTTP/3接続の切り分け｜QUIC・UDP遮断とHTTP/2へのフォールバックを検証する

---

本記事のポイント

1. HTTP/3の利用案内と接続成立は別であり、実際の通信方式と待ち時間を記録して接続差を判断します。
2. QUICが失敗してもTCPベースのHTTPを使える場合があり、HTTP/2への切替を保証せず代替経路の結果を確認します。
3. CDNとオリジンの区間を分け、同じ回線・URL・重要操作で比較して継続・停止・再開の条件を決めます。

---

1. HTTP/3の案内と実際の接続を分けて観測する

HTTP/3はHTTPの意味をQUIC上で実現するプロトコルです。QUICはUDPを使います。HTTP/2が主にTLSとTCPの組合せで使われることとは、経路の条件が異なります。ファイアウォールでTCPの通信が許可されていても、同じ宛先へのUDP通信が許可されているとは限りません。

RFC 9114の接続確立の説明では、HTTP/3の利用可能性を案内する方法としてAlt-Svcを挙げています。Alt-Svcは別のサービスを案内する仕組みであり、レスポンスにあるだけで、そのリクエストがHTTP/3で処理された証拠にはなりません。案内を受け取った後の別接続で利用される場合もあります。

たとえばAlt-Svc: h3=":443"; ma=86400は、HTTP/3の代替サービスとその情報の有効期間を示す例です。ここでの443は案内されたポートであり、すべての構成で固定とは限りません。別のポートを案内している場合は、そのポートへのUDP到達性を確認します。maも記事の値をそのまま設定するのではなく、実際のレスポンスを記録してください。

ブラウザーの開発者ツールでネットワーク一覧のProtocol列を表示し、対象リクエストがh3、h2、http/1.1など、どの方式で処理されたかを確認します。列名や表示値はブラウザーによって異なります。トップのHTMLだけでなく、ログイン、フォーム送信、API呼び出し、重要な画像やスクリプトまで確認すると、別ドメインへの通信を見落としにくくなります。

最初のアクセスと、案内を受け取った後のアクセスを分けます。代替サービス情報や既存接続の再利用により結果が変わるため、「初回」「再訪」「既存接続を再利用」の条件を書き添えます。比較のために新しいテスト用ブラウザープロファイルを使う場合も、その条件を記録し、普段の利用状態と混ぜません。

2. UDP経路・TCP経路・オリジンを比較する

切り分けは、対象URLと試験時間帯を固定して進めます。社内回線、別の許可された回線、同じクライアントからのTCP接続という比較を作ると、端末差とネットワーク差を分けやすくなります。社内の制御を無断で解除せず、通信確認はネットワーク管理者と合意した範囲で実施してください。

RFC 9114 §3.1は、UDPの遮断などでQUIC接続が失敗した場合、クライアントはTCPベースのHTTPを試みるべきだとしています。ただしHTTP/2だけを保証する規定ではありません。相手の対応やネゴシエーションの結果によってHTTP/1.1になる可能性もあるため、「HTTP/2へ必ず戻る」とは判断せず、実際の方式を確認します。

UDPの確認では、「443が開いている」という説明だけでは不十分です。TCPかUDPか、向き、宛先、ポート、IPv4かIPv6かを揃えます。UDPポートの簡単な送信試験やスキャンで応答がないことだけでは、HTTP/3の失敗や遮断の位置を証明できません。対応するクライアントでQUIC接続を試し、管理者が確認できる制御ログと組み合わせます。

QUICは接続や経路についてTCPと異なる仕組みを持ちますが、回線切替やVPN利用のどの問題も自動的に解決するわけではありません。RFC 9000の経路検証・接続移行と、実環境の経路変更を区別し、固定回線で再現するか、切替時だけ再現するかを記録します。

CDNのHTTP/3設定はクライアントからエッジへの区間に効く場合があります。CloudflareのHTTP/3公式ガイドもこの区間を説明しています。画面のh3表示を見て、オリジン側もHTTP/3になったと推測しません。キャッシュやエッジ設定の確認は、Cloudflare Cache Rulesの運用手順と分けて記録してください。

3. curlとブラウザーで再現条件を揃える

curlを使う前にcurl --versionでビルドの機能を確認します。OS付属版がHTTP/3に対応しているとは限りません。HTTP/3非対応のcurlでオプションが拒否された場合は、対象サイトの接続失敗ではなく、試験環境の条件不足として記録します。TCP側のHTTP/2対応も併せて確認します。

curl公式マニュアルでは、--http3-onlyはHTTP/3のみを試し、--http3はHTTP/3を試しながら代替接続も行うオプションです。後者が成功しても、HTTP/3で成功したとは限りません。終了コード、HTTPステータス、http_versionと時間をセットで読みます。

curlの公式資料は、プロキシ経由のHTTP/3には対応しないと説明しています。ブラウザーのプロキシ利用状態を、そのままcurlで再現できるとは限りません。プロキシ設定による試験制約と、サービス側の障害を区別し、試験のために社内のプロキシを無断で迂回しないでください。

次は、対象サービスが通常のHTTPSポートでHTTP/3を提供する場合の比較例です。www.example.comは説明用なので、自分が確認できる対象ホストへ置き換えます。別ホストや別ポートを案内している構成では、その提供条件に合う試験を追加してください。ブラウザーが保存したAlt-Svcをこの単純なコマンドが再現するわけではありません。

curl --version
        curl --http3-only --max-time 20 -sS -o /dev/null \
          -w 'http=%{http_version} status=%{response_code} connect=%{time_connect} total=%{time_total}\n' \
          https://www.example.com/
        curl --http2 --max-time 20 -sS -o /dev/null \
          -w 'http=%{http_version} status=%{response_code} connect=%{time_connect} total=%{time_total}\n' \
          https://www.example.com/
        curl --http3 --max-time 20 -sS -o /dev/null \
          -w 'http=%{http_version} status=%{response_code} connect=%{time_connect} total=%{time_total}\n' \
          https://www.example.com/

--http2も相手との交渉結果を出力で確認します。HTTP/2で処理されたと決めつけないことが大切です。time_connectだけでQUICのどの段階が遅いかを特定せず、総時間、エラー内容、ブラウザーのタイミング、必要に応じた接続ログを併せて見ます。例の20秒は試験の打切り値であり、サービスの許容時間を決める基準ではありません。

同じ試験を無制限に繰り返さず、管理者と決めた少数回で傾向を確かめます。実行時刻、回線、VPN・プロキシ、OS・ブラウザー・curlの版、解決先IP、方式、終了コードを残します。IPv4とIPv6で差がある場合は両者を分けます。出力に認証情報やCookieが含まれる詳細ログは、そのまま共有しないでください。

ブラウザーでは実際の業務画面でも確認します。curlでトップページを取得できたことは、ログイン後のAPI、別ホストへの通信、フォーム送信の完了を保証しません。キャッシュによる見かけの成功も区別し、ETag・Last-Modified・304の検証方法でレスポンス再利用の条件を整理すると比較の精度が上がります。

4. 継続・停止・再開を利用者への影響で決める

導入の判断は、HTTP/3の接続率と、サイトを使えたかという結果を別の指標にします。HTTP/2で速やかに使える利用者をHTTP/3非成立だけで障害扱いすると、必要な対応が見えにくくなります。反対に、切替の待ち時間が重要操作の許容範囲を超えているのに「最終的に200だから問題なし」とするのも避けます。

1. 対象URL、重要操作、通常の許容時間、変更前の結果を記録する。
2. 実際のHTTP/3利用案内と、案内された宛先・ポートを確認する。
3. 対応クライアントでHTTP/3のみ、TCP側、代替接続ありの結果を比較する。
4. 回線・IP系統・VPNなどの条件差と、エッジ・オリジンの記録を照合する。
5. 画面操作の失敗や待ち時間を確認し、継続、限定的な設定変更、HTTP/3提供停止のいずれかを決める。
6. 変更範囲と戻す条件を残し、同じ条件で再試験する。
7. 代表回線と重要操作が基準を満たしたことを確認して再開する。

提供停止を選ぶ場合も、CDN事業者の現行手順に従います。HTTP/3の広告を止める操作と、既存接続やクライアントが保存した代替サービス情報の扱いは分けて確認します。RFC 7838は代替サービス情報の有効期間や消去の仕組みを定めています。設定を切り替えた時刻だけで全利用者の状態が変わったと判断せず、実レスポンスと接続結果を確かめます。

再開条件は「問題がなさそう」ではなく、再現した回線で重要画面が完了する、待ち時間が事前に定めた範囲に収まる、意図しない設定差がない、といった確認可能な形にします。通信経路の原因を修正したなら、修正前と同じ条件で比較し、原因未特定ならその状態と暫定対策を分けて記録します。

DNSや証明書の問題を同時に変えると原因が分かりにくくなります。名前解決やDNSSECを疑う場合もHTTP/3設定と別の変更として確認し、変更範囲を絞って比較できる状態を保ちます。

よくある質問

Alt-Svcにh3があれば、今の通信もHTTP/3ですか？

いいえ。Alt-Svcは代替サービスの利用案内です。実際のリクエストの方式はブラウザーのProtocol列やクライアントの出力で確認します。初回アクセスと案内を受け取った後の接続も分けて記録してください。

UDP 443を許可すれば必ず直りますか？

必ずではありません。案内されたポート、宛先、IP系統、クライアント対応、証明書やエッジの状態も確認します。UDPの制御はネットワーク管理者と協議し、全宛先への無条件な許可で試験を代用しないでください。

HTTP/3が失敗するとHTTP/2へ必ず戻りますか？

保証されません。RFCはTCPベースのHTTPを試みることを推奨しますが、実際の方式や待ち時間はクライアントと相手の対応によります。HTTP/1.1で成功する場合もあるため、処理された方式を記録します。

curl --http3の成功だけでHTTP/3を確認できますか？

確認できません。代替接続で成功する場合があるのでhttp_versionを読みます。HTTP/3のみの成立を試すには、対応ビルドで--http3-onlyを使い、通常利用の代替動作とは別の試験として扱います。

ブラウザーがh3ならオリジンもHTTP/3ですか？

そうとは限りません。ブラウザーからエッジまでと、エッジからオリジンまでを分けます。オリジン側の方式や失敗はCDN設定・ログとオリジンの記録で確認してください。

HTTP/3の接続率が低ければ停止すべきですか？

接続率だけでは決めません。重要操作の成功、待ち時間、影響する回線、代替接続の結果を確認します。利用者への影響が許容基準を超える場合に、変更範囲と再開条件を定めて対処します。