クラウド

AWS LightsailでCaddyを使ってWordPressをHTTPS化する手順

AWS Lightsail上のWordPressに独自ドメインを割り当て、Caddyをリバースプロキシとして配置してHTTPS化する流れを、設定の理由と確認方法とともに解説します。

この記事でわかること

  • HTTPS化には、独自ドメインのDNS設定、Lightsail側の通信許可、Caddyのリバースプロキシ設定が必要です。
  • Caddyはドメイン名を使って証明書取得とHTTPS配信を自動化できる構成を検討できます。
  • WordPressのURL設定やHTTPからHTTPSへのリダイレクトを確認し、混在コンテンツや更新処理を確認します。

構成とHTTPS化の全体像を理解する

想定する通信経路は、ブラウザー → 独自ドメイン → Lightsailインスタンス → Caddy → 既存のWordPress用Webサーバーです。Caddyを前段に置くことで、外部からのHTTPS通信を受け、インスタンス内部のWordPressへリバースプロキシします。

必要な要素は、DNSによる名前解決、TCP 80・443番ポートへの到達性、Caddyのドメイン設定、WordPressがHTTPSを認識するための設定です。WordPressの実体をCaddyが直接処理するのか、ApacheやNginxなど既存のWebサーバーへ転送するのかを先に決めます。

  • DNS: 利用するホスト名をLightsailのIPアドレスへ向ける
  • Lightsail: 80番・443番を公開し、SSHは管理用途に限定する
  • Caddy: HTTPSを終端し、内部のWordPressへ転送する
  • WordPress: サイトURLとHTTPS判定を整合させる

事前に確認するドメインとLightsailの設定

独自ドメインのAレコードなどを、Lightsailインスタンスの固定IPへ設定します。Lightsailの動的なパブリックIPは停止・再起動などで変わる可能性があるため、公開サイトでは固定IPの利用を検討します。固定IPの作成場所はLightsailコンソールの「ネットワーク」です。

Lightsailのネットワーク設定では、HTTP（TCP 80）とHTTPS（TCP 443）を許可します。OS側にもufwなどのファイアウォールがある場合は、同じポートが遮断されていないか確認してください。SSH（通常はTCP 22）は接続元を制限できる場合、管理端末や踏み台など必要な範囲に絞ります。

DNSの反映後、対象ホスト名が想定したIPアドレスを返すことを確認してからCaddyを設定します。DNS、Lightsailのファイアウォール、OS側ファイアウォールのいずれかが未設定だと、証明書取得に失敗する可能性があります。

CaddyをインストールしてWordPressの前段に配置する

OSとWordPressイメージが資料上で確定していないため、以下はDebian・Ubuntu系で公式パッケージを使う場合の例です。実際には採用OSに対応したCaddy公式手順へ置き換えてください。

BASH
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo chmod o+r /usr/share/keyrings/caddy-stable-archive-keyring.gpg
sudo chmod o+r /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install -y caddy

# 期待される状態: caddyサービスがインストールされ、環境によっては自動起動します。
systemctl status caddy

既存のWebサーバーが80番または443番を使用している場合は、Caddyとポートが競合します。Caddyを公開ポートの前段に置き、既存サーバーをlocalhostの別ポートへ移すなど、役割分担を決めてください。

TEXT
example.com {
    reverse_proxy 127.0.0.1:8080
}

# example.com は実際のドメインへ置き換えます。
# 127.0.0.1:8080 は既存Webサーバーの待受アドレス・ポートの例です。

設定ファイルの場所は導入方法によって異なります。公式パッケージのsystemd構成では、通常は「/etc/caddy/Caddyfile」を確認します。反映前に構文を検証し、反映後はサービス状態とログを確認します。

BASH
sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy
systemctl status caddy
journalctl -u caddy --no-pager -n 100

# 期待される状態: validateが成功し、reload後もcaddyサービスが稼働します。

証明書取得とHTTPSリダイレクトを確認する

Caddyfileに公開ドメインを指定し、DNSがインスタンスを指し、80番・443番へ外部から到達できれば、CaddyのAutomatic HTTPSによる証明書取得を利用できます。Caddyは通常、HTTPアクセスをHTTPSへリダイレクトします。

確認は、まずDNS、次にポート、ドメイン名、Caddyのログ、最後に既存サービスとの競合という順で進めると切り分けやすくなります。ブラウザーで証明書エラーが出る場合は、アクセス先が設定したドメインと一致しているかも確認します。

BASH
curl -I http://example.com
curl -I https://example.com

# 期待される挙動の例:
# HTTP側はHTTPSへのリダイレクトを返し、HTTPS側はWordPressの応答を返します。
# 実際のステータスコードやヘッダーは構成によって異なります。

WordPressのURLと管理画面をHTTPS対応にする

WordPressのサイトURLとホームURLが、実際に公開する「https://example.com」と一致しているか確認します。変更前には、設定ファイルとデータベースをバックアップし、URL変更による画像・リンク・プラグインへの影響を確認してください。

リバースプロキシでTLSを終端し、WordPressへはHTTPで転送する構成では、WordPress側が元のHTTPSアクセスを認識できず、リダイレクトループになることがあります。Caddyが渡すX-Forwarded-Protoなどのヘッダーと、WordPress側のHTTPS判定を確認します。必要なwp-config.phpの変更は、採用イメージと既存設定を確認してから行ってください。

  • 管理画面とログイン画面がHTTPSで開く
  • 画像、CSS、JavaScript、フォームのURLがHTTPSになる
  • HTTPのURLが残る混在コンテンツがない
  • 更新、プレビュー、メディア登録が正常に動作する

動作確認と運用時のチェック項目

トップページだけでなく、管理画面、固定ページ、投稿、画像、フォームなど主要な導線を確認します。ブラウザーの証明書情報、HTTPからHTTPSへのリダイレクト、ページ内リソースの読み込みも確認してください。

症状主な確認箇所
ドメインに接続できないDNSレコード、固定IP、Lightsailの80・443番ルール、OS側ファイアウォール
証明書を取得できないDNSの名前解決、80・443番への外部到達性、Caddyログ、ポート競合
502 Bad GatewayになるCaddyのreverse_proxy先、既存Webサーバーの稼働状態、内部ポート
HTTPSでリダイレクトがループするWordPressのURL、プロキシヘッダー、HTTPS判定
一部の画像やCSSが警告になるWordPress内のHTTP URL、プラグイン設定、混在コンテンツ
障害時の切り分け例

証明書の更新はCaddyの自動管理に任せる構成を検討できますが、更新失敗を検知できるよう、Caddyログや外形監視を運用に組み込みます。インスタンス障害や設定変更に備え、バックアップと切り戻し手順も用意します。

参考