はじめに

自宅サーバーの広帯域（10G回線など）とパブリッククラウド（VPS）を組み合わせたリバースプロキシ構成は、固定IPの確保やセキュリティ遮断層の構築において非常に有効なアプローチです。

しかし、この構成で「HTTP/3 (QUIC)」の導入と「SSL Labs A+評価」の獲得を同時に目指す場合、多段Nginx特有のヘッダー競合やUDP/IPv6の経路制御など、単一サーバー構成では発生しない特有のボトルネックに直面します。

本稿では、リバースプロキシ構成下でHTTP/3およびA+評価を安定して両立させるためのアーキテクチャ要件と、構築時に留意すべき技術的ポイントを整理します。

全体アーキテクチャの概要

                 ┌─── [ IPv6 訪問者 ] ─── (10G直結) ─────────┐
                 │                                          ▼
[ サイト訪問者 ] ─┤                                   ┌──────────────┐
                 │                                   │   自宅10G鯖   │
                 └─── [ IPv4 訪問者 ] ─── (VPS) ────► │ (Nginx / WP) │
                                                     └──────────────┘

エッジ層（VPS）:
- 最前面でSSL/TLS終端およびQUICハンドシェイク（UDP 443）を処理。
- ヘッダーの正規化と不要なリクエストのフィルタリング。
バックエンド層（自宅サーバー）:
- コンテンツのレンダリングおよび静的・動的アセットの保持。

押さえておくべき主要な落とし穴と設計指針

多段プロキシにおけるレスポンスヘッダーの重複
バックエンドとエッジの両方で add_header を安易に設定すると、Alt-Svc や Strict-Transport-Security (HSTS) が多重出力される事故が発生します。
- 影響: ヘッダー不正によるHTTP/3ハンドシェイクの失敗、SSL Labs判定での減点。
- アプローチ: エッジ側のプロキシ設定で proxy_hide_header を用い、バックエンドから送出されるヘッダーを一度隠蔽・除去した上で、エッジ層で一元付与する設計が必須となります。
HTTP/2への意図しないフォールバック（UDP/IPv6経路）
設定自体に誤りがなくても、ブラウザが h2 へフォールバックしてしまう場合、トランスポート層（UDP 443）の疎通に原因があるケースが大半です。
- IPv6セキュリティグループのスコープ: デフォルトでIPv6通信（Happy Eyeballs）が優先される環境下で、UDP 443の許可範囲が単一ホスト（/128）に絞られていないか確認が必要です。
- ソケットバインドの競合 (reuseport): Nginxにおいて reuseport ディレクティブは同一IP:ポートの組み合わせで複数定義できません。マルチドメイン構成時は先頭のブロックのみに限定する制約があります。
- QUICハンドシェイクの安定化: パケットロス時の再試行（quic_retry）やセグメンテーションオフロード（quic_gso）を明示的にチューニングすることで、モバイル回線等のゆらぎによるフォールバックを抑制できます。
モバイル環境での 400 Bad Request（ヘッダーバッファ）
QUIC通信特有のトランスポートパラメータやモバイル端末のヘッダー肥大化に伴い、Nginxのデフォルトバッファを超過して400エラーとなるケースがあります。large_client_header_buffers の適切なサイジングが必要です。

設定ファイルの全文・詳細な検証ログについて

本稿で触れたNginxの詳細なディレクティブ記述例（VPS側・バックエンド側それぞれのブロック定義）、SSL Labsでの判定レポート、およびChrome DevToolsを用いた全リソースのプロトコル検証ログは、個人ブログにて全編を公開しています。

実機検証済みの完全な設定スニペットを参照したい方は、以下の記事をご覧ください。

👉 ブログ本編はこちら：
【10G自宅サーバー×ConoHa VPS】NginxでSSL Labs「A+」と「HTTP/3 (QUIC)」を完全両立する構築＆トラブルシューティング