LightsailのWordPressにCloudflareを導入する — DNS、証明書、プロキシ

2026-02-15

Bitnamiのイメージを使うと、AWS LightsailですぐにWordPressを立ち上げられる。運用を続けるうちに、読者数が普段どおりでも、ときどきサイトが遅くなったり、ログイン先に同じようなアクセスが繰り返されたりする。アクセスログを見れば、自動化された通信が原因の一つかどうかを調べられる。

WordPressにはログイン、コメント、XML-RPC、REST APIなど、外部から利用される入り口がある。PHPやデータベースに届く処理が重なると、小さなインスタンスでは応答が遅くなり、プロキシが返答を待ち続けることもある。

Lightsailの手前にCloudflareを置くと、キャッシュできるデータをエッジから返し、一部の通信をそこで処理できる。WordPress側で処理が必要なリクエストは、元のサーバーに送る。

設定するのは、DNS、Lightsail側の証明書、Cloudflareの暗号化モードの三つ。プロキシを有効にする前に、元のサーバーの動作を確かめられる順に進める。

通信経路を整理する

リクエストの経路は次のように変わる。

  • 導入前 — 閲覧者 → Lightsailサーバー
  • 導入後 — 閲覧者 → Cloudflareのエッジ → Lightsailサーバー

プロキシを通るHTTPS通信には、二つのTLS接続がある。

  1. 閲覧者 ↔ Cloudflare
  2. Cloudflare ↔ Lightsailのオリジン

閲覧者にはCloudflareが証明書を提示する。Full (strict)では、Lightsail側の証明書もCloudflareが検証する。

1. ドメインを追加し、DNSを確認する

Cloudflareにドメインを追加し、読み込まれたDNSレコードを確認する。ネームサーバーの切り替え前に、ウェブだけでなく、メールやほかのサービスのレコードも確認しておく。

ルートドメインのAレコードはLightsailのインスタンスに向ける。インスタンスを停止して起動し直したあとも行き先が変わらないよう、Lightsailで静的IPを割り当てる。

以下の例は最後に設定する状態。bncertで最初の証明書を取得する間は、対象のレコードをDNS onlyにしてLightsailへ直接解決できるようにする。

Type: A
Name: @
IPv4 address: Lightsail static public IP
Proxy status: Proxied

wwwでも配信する場合は、ルートドメインを指すCNAMEを追加する。

Type: CNAME
Name: www
Target: @
Proxy status: Proxied

オリジンでHTTPSが使えることを確認したら、Cloudflareに通したいウェブ用レコードのプロキシを有効にする。DNS onlyのレコードには、CloudflareのHTTPキャッシュやファイアウォールは適用されない。

2. ネームサーバーを切り替える

ドメインの登録事業者の管理画面で、Cloudflareがそのゾーンに割り当てたネームサーバーを設定する。変更が反映されると、そのドメインの権威DNSをCloudflareが担当する。

Cloudflareの管理画面でゾーンがActiveになったことを確認する。DNSのキャッシュで、しばらく古い応答を受け取る利用者もいる。ウェブ通信がCloudflareを通るのは、Proxiedにしたレコードだ。

3. Lightsailに証明書を入れる

Bitnami版では、bncertでLet’s Encryptの証明書を設定できる。AWSの案内に沿い、証明書に含めるホスト名がすべてLightsailへ直接解決できることを確かめる。SSHで接続したら次のコマンドを実行する。 公式資料

sudo /opt/bitnami/bncert-tool

ドメイン名とリダイレクトについて画面の指示に答える。ツールはウェブサーバーの設定を更新し、証明書の更新も設定する。プロキシを有効にする前に、使うホスト名をHTTPSで開き、証明書とリダイレクトを確認する。

4. Cloudflareの暗号化モードを設定する

管理画面で「SSL/TLS」から「概要」を開く。

この構成ではFull (strict)を選ぶ。

三つのモードは、オリジン側の通信で違いが出る。

  • FlexibleではCloudflareからオリジンまでがHTTPになる。オリジンがHTTPをHTTPSに転送すると、ループになることがある。
  • Fullでは、閲覧者からのHTTPSリクエストをオリジンにもHTTPSで送る。Cloudflareはオリジンの証明書を検証しない。
  • Full (strict)では、証明書の有効期限、発行元、ホスト名も検証する。

対象のホスト名に対する有効なLet’s Encrypt証明書は、Full (strict)の証明書の条件を満たす。 公式資料

5. WordPressのリダイレクトを確認する

Full (strict)では、HTTPSのリクエストがLightsail側のウェブサーバーにもHTTPSで届く。転送がループする場合は、WordPressのサイトURLとホームURL、Cloudflareの暗号化モード、オリジンのリダイレクトを先に確かめる。

ApacheとPHPの間に別のリバースプロキシがあると、WordPressに伝わる通信方式が変わることがある。その構成に合った設定を使う。

転送元のプロトコルを示すヘッダーを信頼できるのは、信頼済みのプロキシが設定し、直接のリクエストでは偽装できない場合だ。外部から直接つながるオリジンの wp-config.php に、汎用のヘッダー判定を足すのは避ける。

ウェブサーバーの設定を変えたら、使っているBitnamiイメージに合った方法で再起動し、公開ページとログインを試す。

sudo /opt/bitnami/ctlscript.sh restart

どの層でリダイレクトしているかを記録しておくと、ループの原因を追いやすい。

6. キャッシュとセキュリティの設定を見直す

HTTPSで問題なく開けるようになってから、サイトに必要なCloudflareの設定を選ぶ。

この構成で検討したのは次の項目だ。

  • Always Use HTTPS — 閲覧者からのHTTPリクエストをエッジでHTTPSに転送する。
  • Automatic HTTPS Rewrites — 対象の混在コンテンツURLに対応する。サイトに直接書かれたHTTPのURLは、できる範囲で修正する。
  • Bot Fight Mode — 一部の自動通信にチャレンジを出す。使い続ける前に、連携サービスや正規の利用者への影響を確認する。
  • キャッシュはStandardから始め、非公開ページや認証の応答をキャッシュしないようにする。

キャッシュにヒットすれば、静的ファイルのリクエストをオリジンに送らずに済む。セキュリティルールが働くのは、条件に合う通信だ。効果はそれぞれ確認する。

導入後の変化を確認する

プロキシを有効にしたら、公開URLがHTTPSのまま開けるかを試し、以前と比べてログや応答時間がどう変わったかを見る。

  • 自動ログイン試行がオリジンに届く件数が減ったかを調べる。
  • 通信量の似た時間帯のCPU使用率を比べる。
  • 読者がいる地域からの応答時間を確認する。
  • ボット対策やファイアウォールを変えた場合は、コメントスパムの量を見る。
  • オリジンのログで断続的なタイムアウトが減ったかを確認する。

小さなインスタンスでは、エッジで処理できる仕事が増えると負荷が下がることがある。直接アクセスできるオリジンには、Cloudflareを経由しない通信も届く。

最後に確認する順番

この構成では、Cloudflareがサイトの手前に入り、オリジンまでのHTTPSも検証できる。次の順序で確かめる。

  1. オリジンの証明書を導入し、動作を確認する。
  2. DNSの委任を確認し、対象のウェブ用レコードのプロキシを有効にする。
  3. Full (strict)を使い、オリジンの証明書を検証する。

最後に公開ページ、管理者ログイン、設定した別ホスト名からのリダイレクトを試す。

記事を検索