WordPress × LiteSpeed Cache × Cloudflare CDN構成【2025年最新版】

WordPressサイトの高速化・安定化・セキュリティ強化を一挙に実現するための構成として、「LiteSpeed Cache+Cloudflare CDN」の組み合わせは、2025年現在でも非常に有力な選択肢です。
本記事では、実際に運用している複数サイト(mlabo.org や gpt4jp.com など)での構築・検証をもとに、最適な設定手順やトラブル回避策、さらには他CDNサービスとの比較までを実例を交えて解説します。
FreeBSDサーバーの運用からWebアプリ開発まで17年以上にわたり手を動かしてきたエンジニアとして、「なぜこの構成を選ぶのか」「どのような問題に直面し、どう回避したのか」といった判断のリアルを重視しています。
そもそも CDNってなんだー? って人はこっち先に読むといいかも?

はじめに

WordPressサイトのパフォーマンスを本気で改善したい。そう考えたとき、多くの人がLiteSpeed Cacheを導入し、CDNにはQUIC.cloudかCloudflareかで悩む場面に直面します。
筆者は元々QUICを愛用していたのですが最近の仕様変更でちょと面倒になり笑
いっそ同じ面倒ならCloudflareにしてみるかっていうかなり適当な動機で変更しました笑
真面目に悩む方がほとんどだと思うので本文ではしっかり比較してあります。
本記事の目的と想定読者
この構成記事は、次のような方を対象にしています:
- WordPressを本格的に高速化・安定化したい方
- LiteSpeed CacheとCloudflareの正しい組み合わせを知りたい方
- QUIC.cloudとCloudflareのCDN選択で迷っている方
- キャッシュ不具合や403系エラーなど、ありがちな落とし穴を避けたい方
実運用の視点から「どちらが現実的に安定するか」を判断したい方にとって、本記事はその判断材料を提供することを目的としています。
検証スタンスと構成方針
本記事は、検証環境での理想論ではなく、実際の運用で起きた問題・解決・成果を元に構成しています。
- 他サイトにも応用できる再現性
- セキュリティ・キャッシュ制御・運用性の三点バランス
- 単なる「設定方法」ではなく「なぜこの構成なのか」の判断軸
このような構成思想のもとで、Cloudflareを中核にしたWordPress最適化の実例を紹介していきます。
Cloudflare導入の全手順

Cloudflareの導入は、単なるCDN設定にとどまらず、セキュリティやキャッシュ制御の基盤にもなります。
正しく初期設定を行うことで、後のトラブルを回避しつつ、高速かつ安定したWordPress運用が実現できます。
アカウント作成と初期登録ステップ

Cloudflareの導入は、まず公式ページからアカウント作成することから始まります。ログインページ(https://dash.cloudflare.com/login)を開くと、メールアドレスとパスワードによるログインのほか、GoogleアカウントやApple IDでの登録も可能です。
筆者はGoogleアカウントを用いて登録しましたが、この方法であればメール認証などを省略でき、スムーズにセットアップに入れます。
ログイン後に表示される「アカウントホーム」では、すでにCloudflareに接続済みのドメインが一覧で表示されます。新規登録直後であれば、このリストは空白の状態です。
ドメインの接続は、画面右上の「+追加」ボタン、または画面中央の「ドメインを追加する」ボタンから開始できます。
WordPressにCDNを適用するまでの実践フロー
CloudflareをCDNとして適用するには、次のステップに沿って作業を進めます。

表示されたフォームに自分のドメイン(例:example.com)を入力し、CloudflareによるDNSスキャンを実行します。AIクローラー制御などのオプションも表示されますが、後からでも設定可能です。
この後に出てくるのが プラン選択です。 Freeで十分です。 デフォルト選択は有料側になってます笑


登録が完了すると、Cloudflareのダッシュボード上に対象ドメインが表示されるようになります。ドメイン名リンクをクリックして詳細設定に進みます。

左側メニューの「DNS」を選ぶと、Cloudflareが指定するNS情報(例:jeremy / paloma)が表示されます。これを取得元ドメイン側で指定します。 とりあえずここのDNS設定は元々設定されているものが表示していると考えてください。実際のNSの書き換えはドメイン登録してある業者側の設定画面で行います。

ムームードメインなど管理元サービスのネームサーバー設定画面で、Cloudflare指定のNSを入力・保存します。反映には早くて数分、場合により数時間〜数日かかります。

画面右側に API トークン取得を取得のリンクあるのでそれをクリック

そのまま トークンを作成するを押して
トークンのテンプレートの選択画面になるので そこで WordPressを 選択しておいて・・
トークン名は 任意で決めて良いので適切な名前にします。もちろんデフォルトのWordPressでもOK.
特に変更の必要はないのでそのまま 最下部のボタン押して確定しちゃってください。

ここで作成された実際のトークン画面は1度しか表示されないので
紛失したら作り直しです。メモにコピペするなり Bitwardenのセキュアメモに格納しておくなり各自でバックアップしてください。

WordPressの管理画面を開いて 左側のメニューの Lite Speed Cacheを選択して CDN → Cloudflare
を選択。
そこにAPIトークン入力画面あるので 画像のようにコピペしてください。 スイッチは両方ONです。
正常に認識すると最下部に 全てをパージする スイッチが出現します。
不具合と対策:403エラー編

Cloudflareを導入した直後に「403 Forbidden」が表示されて驚いた──というケースは少なくありません。筆者もその一人でした。
これはCloudflare側の設定ミスではなく、Webサーバー側がCloudflare経由のアクセスをブロックしていることが原因です。
原因:ロリポップの「海外アタックガード」
ロリポップ!レンタルサーバーには、セキュリティ機能として「海外アタックガード」が機能としてあります。
ほとんどの皆さんはこれをONで運用しているはずです。
この機能は海外IPアドレスからのアクセスを遮断するためのものですが、Cloudflareは海外拠点を含む世界中のIPからリバースプロキシでアクセスを中継するため、Cloudflare経由のアクセスもブロックされてしまうのです。
つまり、Cloudflare導入後に403が出るのは「正常な挙動」です。むしろこの段階で403が出るということは、Cloudflare経由で接続が行われている証拠とも言えます。
解決策:CloudflareのIPに対する許可設定
ロリポップのユーザー専用ページから「海外アタックガード」をOFFにするだけで、403エラーは解消します。
設定はリアルタイムに反映されるため、Cloudflareを通したアクセスも即座に通過するようになります。
CloudflareのIPレンジを個別にホワイトリスト化する方法も理論上は可能ですが、Cloudflareは頻繁にIPリストを更新するため、シンプルに「海外アタックガードをOFFにする」のがもっとも現実的な対処法です。
WAF設定とセキュリティ干渉の回避

Cloudflareとサーバー側のWAF(Web Application Firewall)は、どちらもセキュリティ強化のために有効な手段ですが、二重に設定することで不具合や制限が発生するのでは?という不安を持たれる方も多いでしょう。
実際に、筆者もこの「WAFの重複」について事前に調査と検証を行いました。
ロリポップWAFとCloudflareの併用可否
結論から言えば、ロリポップのWAFはONのままで問題ありません。Cloudflare側でもWAFが有効になっている状態で、以下のような干渉は確認されませんでした:
- 投稿画面やログイン画面のアクセス制限
- APIコールやWP-Cronなどのバックグラウンド通信
- Contact Form 7等のフォーム送信処理
むしろCloudflare側で「日本国内ユーザー向けのアクセス傾向」をAIで分析し、それに合わせたルールが動的に適用されるため、セキュリティレイヤーがもう一段階強化される印象です。
実際の運用とログ確認
Cloudflareのダッシュボードには、WAFログやアクセス拒否の統計も表示されます。
万が一、特定のリクエストが弾かれているようであれば、「セキュリティ」→「イベント」から個別のIPやURLを確認可能です。
筆者の環境では、特に何も設定せずとも403系の拒否が頻発するようなことはありませんでした。むしろ、ログ確認によって不審なアクセスやBOT攻撃の発見に役立った場面が多々あります。
Cloudflare Page Rulesの最適設定

Cloudflareには「Page Rules(ページルール)」という強力な機能があります。これは特定のURLやパスに対して、キャッシュレベルやセキュリティ動作を個別に制御できる仕組みです。
WordPress運用においては、このPage Rulesを使って「wp-login.php」や「wp-admin」以下のディレクトリに対してキャッシュを無効化することが重要です。
wp-login.phpとwp-adminディレクトリのキャッシュ除外
ログイン関連の画面はキャッシュされると誤動作やセキュリティ事故につながるため、必ず除外設定を行います。以下は代表的な2つのルールです:
example.com/wp-login.php
→ キャッシュレベル:Bypassexample.com/wp-admin/*
→ キャッシュレベル:Bypass
これらを設定しておくことで、管理画面の読み込み・ログイン処理が安定し、意図しないキャッシュトラブルを防ぐことができます。
必須ルールの設定方法と注意点
Cloudflareのダッシュボード →「ルール」→「ページルール」から新しいルールを追加します。
設定時の注意点:
- ワイルドカード(
*)を使うことでディレクトリ全体に適用できる - ルールは上から順に評価される(最大3件まで無料で設定可)
- wp-json やカスタムログインURLを使っている場合は追加で除外設定が必要
特にLiteSpeed Cacheと併用している場合は、Cloudflare側のキャッシュと干渉した不具合が出る可能性もあります。 様子見ながら設定をするのが良いです。
管理人ちなみに・・・筆者は記事で指摘しているくせに笑
自分ではこの除外ルールは設定してません
なんか問題発生したら脊髄反射でキャッシュ類を全て削除するタイプなので必要ないだけです笑
QUIC.cloud vs Cloudflare:どちらを選ぶべきか?

LiteSpeed Cacheを使っていると、CDN選定で必ず名前が挙がるのが「QUIC.cloud」と「Cloudflare」です。どちらも無料プランがあり、高速化とセキュリティを同時に担える存在ですが、特徴や使い勝手には明確な違いがあります。
筆者もこの2択で本気で悩み、複数のドメイン・サーバー構成で検証を行った結果、Cloudflareを採用するに至りました。
QUIC.cloudの特徴とLiteSpeed連携
QUIC.cloudの最大の利点は、LiteSpeed Cacheとの親和性です。以下のようなメリットがあります:
- LSCWPプラグインとの直接連携(キャッシュ・画像最適化・Critical CSSなど)
- HTTP/3やQUIC対応による通信高速化
LiteSpeed Cacheの開発元が提供するCDNということもあり、WordPress側との統合は非常にスムーズです。
ただし、無料プランでは帯域制限があり、日本リージョンを安定して使いたい場合は有料トークンの購入が前提となる点がネックです。また、障害時の情報発信やサポート体制がやや弱いと感じました。
Cloudflareの強みと無料プランの充実度
Cloudflareの強みは、グローバルCDNとしての実績とサービスの幅広さにあります。
- 無料プランでもDNSを含めたフルプロキシが利用可能
- SSL/TLS、WAF、キャッシュ制御など多機能で直感的なUI
- TurnstileやBot管理、IP制御などオールインワン対応
※画像圧縮(Polishなど)は有料プラン限定 - 専用アプリや公式プラグインも豊富で、エコシステムが広い
また、障害情報の公開やステータスモニターもあり、透明性と信頼性の面でも安心できます。
筆者の判断基準と最終選定理由
結論として、構成全体の再現性と拡張性を重視してCloudflareを選択しました。
- 無料プランでも十分な機能が使えること
- ドメイン・サーバー構成ごとの差異が少なく、横展開しやすい
- 不具合時の切り分けがしやすく、ログも充実している
- セキュリティ、CDN、キャッシュ機構が一体で運用できる
QUIC.cloudも技術的には優れたCDNですが、運用のしやすさと安定感という意味では、Cloudflareに軍配が上がるというのが実感です。
補足・Tips

ここではCloudflareとLiteSpeed Cacheを併用する上で見落としやすいポイントや、トラブルを未然に防ぐための小技をいくつか紹介します。実際の運用で筆者が行っている調整や対策も含めています。
.htaccessとLiteSpeed Cacheの関係
LiteSpeed Cacheを有効にすると、自動的に .htaccess ファイルに多数のルールが追加されます。これには以下のような処理が含まれます:
- キャッシュ対象の制御(HTML / CSS / JSなど)
- BrotliやGZIPの圧縮指定
- モバイル/デスクトップキャッシュの振り分け
- エッジ制御(no-vary設定など)
Cloudflareを併用する場合でも、この .htaccess は削除してはいけません。むしろCloudflareがHTMLキャッシュを強めに保持する場合、このファイルが正しく設定されていないと不整合が発生するため要注意です。
SiteGuardとログインURL変更
セキュリティ強化の観点から、筆者はSiteGuard WP Pluginを導入し、ログインURLを変更しています。
Cloudflareとの併用でも特に問題なく稼働しており、ログインのキャッシュ除外と合わせて使用すれば、高いセキュリティと安定性が両立できます。
変更したログインURLにはCloudflareのページルールで「Cache Level: Bypass」を適用するのを忘れずに。
開発モードやPageSpeedスコア最適化テクニック
Cloudflareには「開発モード」という便利な機能があります。これはHTML/CSS/JSのキャッシュを一時的に停止して、変更をリアルタイムに反映させるモードです(自動で3時間後に切れる)。
テーマやプラグインの調整時にはこの開発モードをONにしておくと、反映待ちのキャッシュストレスから解放されます。
また、PageSpeed Insightsのスコア向上には次の2点が効果的でした:
- 画像はすべてWebPに変換+遅延読み込み
- CSS/JSの結合とインライン化はLiteSpeed Cache側で制御
Cloudflareでは「自動最適化」機能もありますが、LiteSpeed Cacheとバッティングするため、どちらで制御するか方針を明確にしておくのがおすすめです。
導入後の実測と評価

構成を組んだだけでは意味がありません。実際にどれだけ速くなったのか、安定したのか、それを計測してこそ価値があります。
ここでは、Cloudflare+LiteSpeed Cache構成を導入した後の「PageSpeedスコア」や、他ドメインへの横展開による実用性について触れておきます。
PageSpeed Insightsの結果と分析

本構成を適用したWordPressサイトでは、モバイル・デスクトップともにPageSpeed Insightsで極めて高いスコアを記録しました。
- モバイル:75-100点(キャッシュ・圧縮・表示最適化済)
- デスクトップ:ほぼ100点(初期表示、画像最適化、CSS統合済)
特にCloudflare側でのキャッシュやLiteSpeed側でのHTML静的キャッシュ、EWWWによる一括変換でWebP化と画像遅延表示が効いており、スコア上だけでなく実際の体感速度も向上しています。
管理人ちなみに・・筆者はSWELLテーマを愛用してますが SWELL本体で設定できる高速化や遅延読み込みは全てOFFです。
スコアを追い求めすぎる必要はありませんが、「設定が正しく機能しているか」の検証ツールとして非常に有効です。
他ドメイン(gpt4jp.com等)への適用実績
この構成は筆者が運営している他のドメイン、たとえば gpt4jp.com にもそのまま展開可能でした。
- DNS設定、Cloudflare接続、Page Rulesの流用
- LiteSpeed Cacheの設定エクスポート・インポート
- .htaccessの調整も最小限
構成全体が再現性を持っていることで、ドメイン単位の最適化が短時間で完了できるのは大きなメリットです。
特に複数サイトを管理している場合、このようなテンプレート化された構成は、メンテナンス性や移設時の効率にも直結します。
まとめ:Cloudflare構成の決定版として

WordPressを高速かつ安全に運用するためのCDN構成として、「LiteSpeed Cache+Cloudflare」の組み合わせは2025年現在でも第一線で通用する強力な解です。
本記事では、実際の運用経験に基づき、Cloudflare導入から設定、トラブル対策、他サービスとの比較まで段階的に整理してきました。
今後の拡張性と他構成への応用可能性
この構成は、単体サイト向けにとどまらず、以下のような拡張にも十分対応できます:
- 複数ドメインへの横展開(DNS / Cache / Page Rules共通化)
- マルチサイト構成(サブドメイン / サブディレクトリ)への適用
- セキュリティ強化との両立(WAF / Turnstile / URL変更)
また、Cloudflare側の新機能が追加された場合にも、構成を大きく壊さず取り込める柔軟性があるのも大きなポイントです。
選定理由の再確認と運用時の注意点
最後に、筆者がCloudflareを選んだ理由を整理しておきます:
- 無料プランでも必要十分なCDN+セキュリティ機能
- DNSからキャッシュ・WAFまで一体で構成できる汎用性
- エラー時の切り分けがしやすく、運用トラブルが減少
- 専用UIとログ解析機能により「見える化」された安心感
一方で、次の点には注意が必要です:
- CloudflareとLiteSpeed両方でキャッシュ制御ができるため、役割の重複には常に意識を置くこと
- Page Rulesは無料枠が3つまでなので、除外優先順位を決めること
- WAFやBot制御が誤検知するケースがあるため、ログ確認を習慣化すること
Cloudflare+ロリポップ環境におけるSSL証明書運用の注意点
ロリポップの無料独自SSLは Let’s Encrypt(有効期限90日) を利用しており、本来は自動更新される仕組みです。
しかし、CloudflareをCDNとして挟んでいる場合、http-01認証が正しく通らず更新が失敗することがあります。
この環境で安定して運用するには、更新時に一度Cloudflareの「オレンジ雲(プロキシ有効)」を「グレー雲(DNSのみ)」に切り替え、SSL更新完了後に再度オレンジ雲に戻す作業が必要です。これをおおよそ3か月に1回繰り返すことで、自動更新エラーを回避できます。
もしCloudflareを外せばLet’s Encryptは自動更新されますが、その代わりにCDNやWAF、DDoS防御などのメリットを失います。
また、Cloudflareオリジン証明書を使えば最長15年間更新不要にできますが、ロリポップの無料SSL環境では証明書持ち込みができないため利用できません(PRO契約や持ち込み対応のサーバーが必要です)。
つまり「CDNの恩恵を取りつつ運用するなら、3か月ごとに更新時だけプロキシを切る」「更新の手間を減らすならCloudflareを外す」という選択になります。アクセス規模やセキュリティ優先度に応じて運用方針を決めるのが現実的です。
SSL証明書更新タイミングをChatGPTのスケジュール機能で活用してみる。
適当にプロジェクト作ってその中のカスタム指示に以下の指示を作成しておくと
勝手にリマインド設定を行ってくれます。
使い方は 次のSSL証明書の更新期限はMM月DD日だよ 的に 指示すればリマインダーのタスクを生成してくれます。 期限の10日前から ChatGPTが通知を使って毎日21:00に更新しろよって通知してくれます。
修正が済んだら 新たな証明書の有効期限をChatGPTに伝えれば旧タスクを削除して新しい更新日に合わせて再度リマインドします。
以下をコピペして カスタム指示に貼り付けて使用して下さい。
次回のSSL証明書リマインダーを設定する。
仕様:
- 入力として「次回のSSL証明書の有効期限日 (YYYY-MM-DD)」を受け取る。
- 既存のSSLリマインダー(例: 「リマインド: SSL更新期限前チェック」「定期リマインド: SSL更新チェック」などSSL関連のもの)はすべて削除する。
- 新しいリマインダーを作成する:
- リマインド開始日: 有効期限日の10日前 (YYYY-MM-DD - 10日)
- リマインド終了日: 有効期限日 (YYYY-MM-DD)
- リマインド頻度: 毎日 21:00
- リマインド文言:
「SSL証明書の期限が近づいています。更新を確認してください。必要ならクラウドフレアを一時的にDNSのみ運用にしてください。」
- 実行後は「削除済みリマインダー」と「新規作成リマインダー」の一覧を報告すること。
LiteSpeed Cache+ Cloudflare CDNで よくある質問












