昨今のIPアドレス枯渇問題の解決策として、各プロバイダーはIPv6への移管を徐々に進めてきています。

Nuroも同様であり、最近、Nuro光の回線が不調になり、調査したところルータが原因と判明。
電源入っているのに疎通しない。
そこでNuroサポートに問い合わせてONUルータ交換を依頼しました。
しかし届いたルータは利用中の機器とは別の機種（HG8045QからSGP200Wへ）となっており、ONU交換したことで、自宅のインターネット環境がこれまでの接続方式「IPv4/IPv6デュアルスタック」から「MAP-E（IPv4 over IPv6）」方式へ強制的に切り替わりました。

この結果、自宅で運用していたWebサーバのグローバル公開が不可能に！

この「MAP-E」方式は、従来のように自宅ごとに専用のグローバルIPv4アドレスが割り当てられず、プロバイダ側で多数ユーザーの通信をひとまとめにして“共有グローバルIP”でインターネットに接続する仕組みです（MAP-EではグローバルIPv4アドレスが割り当てられず、NAT越えも不可能になるため）

ルータ交換後、設定のために管理画面にログイン。写真の通りDMZ設定およびポートマッピング設定で「MAP-E機能動作中のため本機能は設定できません」との表示。これで「外部から自宅のWebサーバにつながらない」ことを理解。

回線を変えるか、IPv6で公開するか

そこでまず考えたのが、以下の通り、回線を変えるか、IPv6で公開するか、自宅サーバをやめるか。

A. 別の固定IP付き回線を新規契約

  • GMOとくとくBB（v6プラス非対応プラン）やフレッツ光＋固定IPサービス、**auひかり（ホームタイプ一部）**等で「固定IPv4」を再導入
  • メリット: これまで通り自宅サーバ可
  • デメリット: コスト増、回線切替・工事等の手間

B. オプションで固定IPv4アドレス契約（Nuroの場合は現状不可）

  • Nuro光は基本的にMAP-E以降は個人向け固定IPv4非対応（2024年時点）
  • 法人向けなら選択肢ありだがコスト・審査が重い

C. IPv6で外部公開（IPv6対応サーバとして運用）

  • ルータ・サーバをIPv6対応し、外部からIPv6アドレスでアクセス
  • メリット: 将来的な主流化に備えた先行対応
  • デメリット:
    • 訪問者（ユーザー）がIPv6ネットワークからアクセスしないと到達不可
    • 独自ドメインでのDNS AAAA対応が必須
    • クライアント側普及度は8〜9割だが、まだIPv6は「誰でも必ずOK」ではない

D. VPS/クラウド専有サーバ活用

  • VPS（月500〜1,000円程度）やAWS EC2で専有サーバを用意

できれば、コストはかけたくないので、上記案は却下。

そこで、サーバレス案も検討してみる。

実現可能な「サーバレス」運用モデル

サーバレス化の方がコストは安価で済むので、以下を検討した。

A. WordPress静的化+サーバレス配信

フロー例

  1. WordPressはローカルで管理し、S3に吐き出し（投稿時はhosts切替でローカル更新）
  2. 記事やページの静的HTMLを生成（例：Simply Static/Plugnなど）
  3. S3+CloudFrontに静的ファイルとしてデプロイ＝完全サーバレス配信
  4. 編集時のみWPサーバ起動、公開時は“ゼロ運用コスト”

メリット

  • サーバレスのコスト・スケール・安定性
  • セキュリティ（攻撃面少ない）

デメリット

  • ダイナミックなプラグインやコメント機能は原則使えない（外部サービス連携で補える）

B. Headless CMS＋サーバレス構成

  • WordPress「ヘッドレス」化（=APIサーバ化）→
    • 記事データをREST APIまたはGraphQL経由で公開
    • フロントはNext.js, Nuxt.js等のJamstack（静的生成/SSR）
  • AWS Amplify, Vercel, Netlify等で静的/SSR配信
  • データはS3, DynamoDB, Aurora Serverless等に格納

C. AWS Lambda＋PHPレイヤーでWP運用（チャレンジ枠）

D. 「WordPressライク」な完全サーバレスCMSを利用

  • 例：Ghost（Node.js静的/Jamstack対応）
  • Notion＋Super.so等のノーコード静的CMS
  • Netlify CMS, Contentful, Strapi, MicroCMS（API連携）

暫定対策としては、上記のS3+CloudFront案として進めることとした。

プラグインは使えず、表示を確認していたが、環境依存や記事が大量にある。
結局、自作スクリプトで公開ディレクトリをS3に手動同期することにした。
また日本語ページや画像で文字化けが発生したため、以下のように対処しました。
　- S3アップ時に「Content-Type: text/html; charset=utf-8」をスクリプトで明示。
　- ファイル名もURLエンコードで統一し、表示崩れを防止。

埋め込みリンクの文字化けやリンク切れがあり、埋め込みリンクだけ機能しないのが
修正しきれず残念ではあるが、これで一旦暫定とした。

マイIPというサービスを見つけた

インターリンク社のマイIPというサービスがあるのを発見。
https://www.interlink.or.jp/biz/aff/vpn/myip_3min.html

これ見ると、VPNサーバ経由でアクセスって話だった。
なるほど納得。

そこで、GCPのFreeTier（米国リージョン）を使えば、無料でサーバ立てられるので、
自前でVPNサーバ立てれば解決できそうだ。

というわけで、以下の通り進めることとした。

恒久対策：「GCP＋WireGuard＋Nginx＋HAProxy」で自宅サーバを復活

1. GCPに「公開用サーバ（リバースプロキシ）」を新設（無料枠／米国リージョン）

  • パブリックIP・必要なポート（UDP 51820, TCP 80/443）を開放。
  • GCPの「無料枠（Free Tier）」を利用することで、サーバ費用はほぼゼロ。

2. GCPと自宅サーバ間にWireGuard VPNトンネルを構築

  • GCPサーバと自宅サーバが仮想的に同一ネットワークに。
  • 自宅側のWireGuardクライアントにはこれまで利用していたHAProxyのサーバを中継として挟むことで、
    　Nginx（GCP）→WireGuard→HAProxy（自宅）→OpenLiteSpeedのリバースプロキシ構成を実現。

WireGuardサーバ側の設定

[Interface]
PrivateKey = サーバーのプライベートキー
Address = 10.8.0.1/24          # VPN内のIPアドレス
ListenPort = 51820

[Peer]
PublicKey = クライアントのパブリックキー
AllowedIPs = 10.8.0.2/32

WireGuardクライアント側の設定

[Interface]
PrivateKey = クライアントのプライベートキー
Address = 10.8.0.2/24

[Peer]
PublicKey = サーバーのパブリックキー
Endpoint = GCPの外部IP:51820
AllowedIPs = 10.8.0.1/24
PersistentKeepalive = 25

3. GCP側Nginxでリバースプロキシ設定

  • GCPグローバルIPへのアクセスをWireGuard越しで自宅のHAProxyへ中継。
  • HAProxyが各種リクエストをOpenLiteSpeedサーバに振り分け。

Nginx設定

events {
    worker_connections 768;
}

stream {
    server {
        listen 443;
        proxy_pass 10.8.0.2:443;
    }
    server {
        listen 80;
        proxy_pass 10.8.0.2:80;
    }
}

4. SSL証明書（Let’s Encrypt）はOpenLiteSpeed側で運用

  • 外部からのリクエストはGCP-Nginxで一度受けたあとWireGuardトンネルを経由して自宅へ。
  • SSL終端はOpenLiteSpeedで完結させているため、GCP側はリバースプロキシのみ。

5. DNS（Route53）でAレコードをGCPグローバルIPに変更

  • AWS Route53で全ドメイン管理を一元化。

■ まとめ：MAP-E時代の“自宅サーバ運用”生存戦略

IPv6＋MAP-E時代、従来方式の自宅サーバへのダイレクト公開は消滅に近い。マイIPサービスがヒントになった。
Nuro回線でもコストをかけずにGCP/AWS/VPS＋VPNトンネル＋Nginx＋HAProxy＋OpenLiteSpeed＋Route53という組み合わせで「疑似グローバルIP・SSL化・マルチドメイン」全て維持し続ける道はある。

同じ悩みを持つ方のヒントや勇気になれば幸いです。