もともと、このブログのセットアップは、ホームサーバーで運用しているため、WireGuardを使用した純粋なIPv6プロジェクトとして計画されていました（ちなみに、無料のIPv6アドレスはroute64.orgで取得できます）。アクセシビリティを向上させるために、外部のIPv4プロキシを導入しました（@Larvitzに感謝）。

しかし、その際にすぐにSSLの問題が発生しました。当初、AレコードとAAAAレコードの両方がプロキシを経由していたため、サーバー上でのLet's Encryptの検証が失敗してしまったのです。

解決策：「IPv6ハック」

解決策は、AAAAレコードをプロキシ経由にするのではなく、サーバーのWireGuard IPを直接指すように明示的に設定することでした。

  • ドメイン: blog.burningboard.org
  • Aレコード (プロキシ): 194.28.98.217
  • AAAAレコード (サーバー): 2a11:6c7:f05:a8::2 (WireGuard)

このようにAAAAレコードをWireGuard IPに直接向けることで、Let's Encryptは（AAAAレコードがデフォルトで優先されるため）引き続きIPv6経由でサーバーに直接アクセスし、SSL証明書を発行します。IPv4トラフィックは、プロキシによって暗号化された状態で私に転送されます。

最終的な設定

通信を円滑に行うために、Caddyサーバーの設定を調整する必要がありました。

1. 自サーバー側 (NixOS, blog.nix)

訪問者の本当のIPアドレスが正しく届き、プロキシのIPで上書きされないように、プロキシを信頼できるものとして設定する必要があります。

services.caddy.globalConfig = ''
  servers {
      trusted_proxies static 2a06:9801:1c:1000::10
  }
'';

2. 外部プロキシ側 (Caddy)

プロキシがHTTPS経由でサーバーに正しくアクセスするために、ホスト名（SNI）を送信する必要があります。

reverse_proxy [https://[2a11:6c7:f05:a8::2]:443](https://[2a11:6c7:f05:a8::2]:443) {
    header_up Host {host}
    transport http {
        tls_server_name blog.burningboard.org
    }
}

これで、ブログはIPv4とIPv6の両方からアクセス可能になり、安全に暗号化され、自宅のIPアドレスも秘匿されたままになりました！ 🚀

MD-Blog