QUIC.cloud を有効化するまでの実録（自宅 WordPress＋OpenLiteSpeed／WireGuard公開）

2025-10-30

LiteSpeed Cache の CDN（QUIC.cloud）を自宅 WordPress（OpenLiteSpeed, 以下 OLS）で有効化できず詰んでいたのですが、

①一時的に nginx を L7 終端で挟んで X-Forwarded-For を付与 →
②QUIC.cloud 登録
③nginx を外して WireGuard＋iptables の L4 構成に戻す

という三段ロケットで突破しました。以後は HTTP/3 は CDN 側で終端、オリジンは OLS のまま軽量運用です。

なお、リモートサーバ（Oracle Cloud Infrastructure 無料インスタンス）× WireGuard で自宅サーバを公開する土台は、すでに別記事でまとめています。公開経路の作り方自体はそちらをご覧ください：
WireGuardとVPS（OCI）を活用した集合住宅ネットワーク内Webサーバの公開

本記事では QUIC.cloud を有効化するための詰まりどころと回避策に絞って書きます。

構成と用語

リモート（OCI）：WireGuard（以下 WG-Remote）
ローカル（自宅）：WireGuard（以下 WG-Local） → OpenLiteSpeed（OLS） → WordPress
経路：インターネット →（CDN: QUIC.cloud）→ WG-Remote →（トンネル）→ WG-Local → OLS

用語	層/分類	できること
L4（レイヤ4）	ネットワーク（トランスポート層）	ポート単位の転送・負荷分散、DNAT/SNATなど
DNAT	L4/NAT	外向けポートを安全に裏側サーバへ中継
nginx `stream`	L4	80/443(TCP)や443/UDP(QUIC)の中継
L7（レイヤ7）	アプリケーション層	`X-Forwarded-For`の付与、ホスト名/URLベースの制御、WAF
OLS（OpenLiteSpeed）	Webサーバ	高速配信、LSCache連携、QUIC(状況により)
X-Forwarded-For（XFF）	HTTPヘッダ（L7）	実IPをアプリ/ログに渡す
CDN（QUIC.cloud）	配信ネットワーク	キャッシュ、TLS/HTTP3、DDoS緩和、PoP最適化

WordPressのLiteSpeed CacheのCDN（QUIC.cloud)の有効化

LiteSpeed Cache の CDN（QUIC.cloud）を有効化するまでの条件
- …/?rest_route=/lscwp/ip-check が remote_ip（経路IP）＋ x_forwarded_for（クライアント実IP）を返すこと

なぜ詰まったか

L4 のままでは X-Forwarded-For を付けられない
nginx stream や単なる DNAT は TCP/UDP の“中身”に触れません。
OpenLiteSpeed は PROXY protocol 非対応
L4 で元IPを運ぶ裏ワザ（PROXY proto）も OLS では使えません。
結果：WordPress/OLS が実クライアントIPを認識できず、LiteSpeed Cache の ip-check／CDN有効化が弾かれる。

対策

一時的に nginx を L7（HTTP）で前段に挿入
リモート側に nginx コンテナを立て、TLS終端＋X-Forwarded-For を付与。バックエンドは WireGuard 越しに OLS。
1. /?rest_route=/lscwp/ip-check が remote_ip＋x_forwarded_for を返すようになる。
この状態で LiteSpeed Cache の CDN（QUIC.cloud）を有効化
所有権確認や登録が通る。レスポンスに x-qc-pop, alt-svc: h3=":443" が出るのを確認。
nginx を撤去し、L4（WireGuard＋iptables DNAT）に戻す公開 :80/:443（必要なら :443/udp）を DNAT → OLS。OLS は「Use Client IP in Header = Trusted IP Only」にして、トンネル対向の送信元IPを T 付きで Allowed List 登録（= 信頼できるプロキシからの XFF だけを採用）。以後は HTTP/3 はCDN側で終端、オリジンは軽いまま。

ポイント：“登録時だけ L7 を挟んで XFF を保証” → 登録後は L4 に戻す。運用はCDN主体、オリジンは最小構成。

実施メモ（例)

一時的nginx(L7)の例

server {
  listen 443 ssl http2;
  server_name example.com;
  ssl_certificate     /etc/ssl/fullchain.pem;
  ssl_certificate_key /etc/ssl/privkey.pem;
  location / {
    proxy_pass https://&amp;lt;OLS_IP&amp;gt;;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # ←これ！
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header X-Real-IP $remote_addr;
  }
}

これで ip-check が「実IP（XFF）」を認識でき、QUIC.cloud の有効化が完了します。

L4（WireGuard＋DNAT）に戻したら

DNAT：公開 :80/:443（必要なら :443/udp）→ OLS の :80/:443
SNAT/MASQUERADE：「wg0から出る OLS宛だけ」に限定（戻り経路固定）
FORWARD：WAN→wg0 の OLS宛のみ許可／戻りは ESTABLISHED,RELATED で許可
OLS：Use Client IP in Header = Trusted IP Only、Allowed List にトンネル対向IPを T 付きで登録（=信頼プロキシだけXFF採用）

直アクセスでも HTTP/3 を受けたい場合だけ UDP/443 の DNATを残す。CDN終端で十分なら不要（攻撃面も減る）。

検証のしかた

CDN経由のヘッダ
curl -I https://example.com | tr -d '\r’ | grep -i 'server\|x-qc-pop\|alt-svc’
CDNバイパス（SNI固定）
curl -vk –resolve example.com:443: https://example.com/ | head -n1
WordPress側の見え方（確認用スクリプトで）
REMOTE_ADDR が実IPに、X-Forwarded-For に同じ先頭IPが入っていれば成功。