Caddyとは？HTTPSとリバースプロキシの基礎

アプリを直接公開しないための入口

Next.jsなどのアプリは、手元では3000番のようなポートで動きます。Caddyは利用者からの通信を受け、内部のアプリへ渡すリバースプロキシとして利用できます。HTTPS証明書やアクセスログをアプリから分離して管理できます。

最小構成は短い

同じサーバーの3000番で動くアプリへ通信を渡す基本形です。

app.example.com {
    reverse_proxy 127.0.0.1:3000
}

実際の本番環境では、これに加えてDNS、ファイアウォール、アプリの自動起動、ログ、監視を構成します。

HTTPS証明書を自動管理できる

公開DNS名などの条件が整っていれば、CaddyはTLS証明書を取得・更新し、HTTPからHTTPSへの転送も自動化します。社内限定システムでは公開サイトと同じ取得方法を使えない場合があり、DNSと接続経路を含めた設計が必要です。

DNSとCDNはCloudflareに任せる

CaddyはHTTPSとリバースプロキシを担いますが、VPSのIPアドレスを直接インターネットに晒す前提です。VPSのIPをそのまま公開する代わりに、DNSとCDNをCloudflareに任せ、Cloudflareの背後にCaddyを置く構成をこの手引では推奨しています。オリジンのIPを隠せるほか、静的アセットのキャッシュや、DDoS・ボットトラフィックの大部分をCaddyへ届く前に吸収してくれます。個人開発の規模であれば無料プランの範囲で十分です。

DNSレコードは、CloudflareのCDNを経由する「プロキシ済み（オレンジクラウド）」で登録します。この手引のCloudflare Workers編と同じくTerraformで管理する場合の例です。

resource "cloudflare_dns_record" "app" {
  zone_id = var.cloudflare_zone_id
  name    = "app"
  type    = "A"
  content = "203.0.113.10"
  proxied = true
  ttl     = 1
}

CloudflareのSSL/TLSモードは「Full（strict）」にします。CloudflareからオリジンのCaddyまでの区間も、Caddyが自動取得した証明書でHTTPS化されるため、モードを「Flexible」のままにする場合に起きがちなリダイレクトループや証明書不一致を避けられます。

ログの送信元IPを読み違えない：Cloudflareを経由すると、Caddyから見た接続元IPはCloudflareのエッジサーバーのIPになります。実際の利用者IPはCF-Connecting-IPヘッダーで渡されるため、Caddyのグローバル設定でこのヘッダーを信頼するよう指定します。

{
  servers {
    trusted_proxies static 173.245.48.0/20 103.21.244.0/22
    client_ip_headers CF-Connecting-IP
  }
}

Cloudflareが公開しているIPレンジは定期的に見直されるため、上記は一部のみの例です。実装時は最新の一覧を確認し、xcaddyでのカスタムビルドが可能であれば、レンジを自動更新できるCloudflare向けのtrusted_proxiesモジュールを使う方法もあります。これを設定しないと、アクセスログやレート制限がすべてCloudflareのIPを基準に動いてしまい、実質的に機能しなくなります。

Caddyだけでは守れない

DBポートをインターネットへ公開しない
管理画面に認証とアクセス制御を設ける
Next.jsの開発サーバーを本番利用しない
OS、Node.js、依存パッケージ、Caddyを更新する
ログを監視し、バックアップから復元できることを確認する

公開設定と継続運用を任せたい方へ

Web/APIサーバー、HTTPS、DB、バックアップ、監視、セキュアアクセスをまとめて構成します。

運用について相談する

AIで作ったアプリを公開するCaddyとは？