日本国内サーバー × Cloudflare の最速設定ガイド【Xserver / ConoHa 対応】

WordPressサイトの高速化やセキュリティ対策として、XserverやConoHa WINGなどの国内レンタルサーバーとCloudflareを組み合わせる方法があります。

Cloudflareを利用すると、CDNによる静的ファイルの配信、DNS、DDoS対策、キャッシュなどを利用できます。

ただし、Cloudflareを導入すれば必ず表示速度が大幅に向上するわけではありません。
国内ユーザーが中心のサイトでは、もともとのレンタルサーバーが高速なため、ページによっては体感速度がほとんど変わらないこともあります。

また、キャッシュやSSL/TLSの設定を間違えると、WordPressの管理画面に入れない、更新した内容が反映されない、リダイレクトループが発生するといったトラブルにつながることがあります。

この記事では、Xserver・ConoHa WINGとCloudflareを併用するときの基本設定と注意点を、2026年時点の仕様に合わせて解説します。

1 Cloudflareを使う主なメリット

• CDNによるコンテンツ配信
• DNSサービスの利用
• DDoS攻撃への対策
• Webサイトへの不正アクセス対策
• 静的ファイルのキャッシュ
• オリジンサーバーへの負荷軽減
• HTTP/3など新しい通信方式の利用

特に画像、CSS、JavaScriptなどの静的ファイルへのアクセスが多いサイトでは、Cloudflareのキャッシュが役立つ場合があります。

2 最初に知っておきたいこと：ドメイン移管とDNS変更は別

Cloudflareを利用するとき、

「ドメインをCloudflareへ移管しなければならない」

と思われることがありますが、通常はその必要はありません。

Cloudflareを利用するために行うのは、基本的にはドメインのネームサーバーをCloudflare指定のものへ変更する作業です。

ドメインの管理会社はそのままで、DNSだけCloudflareを利用することができます。

3 Cloudflareへ変更する前にDNSレコードを確認する

Cloudflareへサイトを登録すると、既存のDNSレコードが検出されます。

ただし、すべてのDNS設定が必ず正しく移行されるとは限らないため、ネームサーバーを変更する前に必ずDNSレコードを確認してください。

特にメールを使用しているサイトでは重要です。

3.1 確認したい主なDNSレコード

• Aレコード
• AAAAレコード
• CNAMEレコード
• MXレコード
• TXTレコード
• SPF
• DKIM
• DMARC

会社サイトなどでメールを利用している場合、MXやTXTレコードを移し忘れるとメールの送受信に影響する可能性があります。

4 Webサイト用DNSレコードはProxied（オレンジ雲）にする

CloudflareのDNS設定には、

• Proxied（オレンジ雲）
• DNS only（グレー雲）

があります。

WebサイトとしてCloudflareのCDNや保護機能を利用したいA・AAAA・CNAMEレコードについては、基本的にProxiedにします。

これによって、訪問者からのWebアクセスがCloudflareを経由するようになります。

5 メール用ホストはDNS onlyにする

メールに使用するホスト名までWebサイトと同じようにプロキシしてはいけません。

たとえば、

mail.example.com

をメールサーバーとして使用している場合は、通常DNS onlyにします。

MXレコードについても、メールサーバーへ正しく接続できる状態になっていることを確認してください。

Cloudflareへの切り替え後にWebサイトは表示できるのにメールだけ届かなくなった場合は、まずDNS設定を確認しましょう。

6 SSL/TLSはFull (strict)を基本にする

Cloudflareを導入すると、

訪問者 → Cloudflare → レンタルサーバー

という経路でWebサイトへ接続します。

そのため、Cloudflare側のSSL/TLS設定も重要です。

オリジンサーバーに正常なSSL証明書が設定されている場合は、基本的にFull (strict)を利用します。

XserverやConoHa WINGですでに独自SSLを正常に利用しているサイトであれば、オリジンサーバー側の証明書が有効であることを確認したうえで設定します。

7 Flexibleは安易に使用しない

CloudflareにはFlexibleというSSL/TLSモードもあります。

Flexibleでは、

• 訪問者 → Cloudflare：HTTPS
• Cloudflare → サーバー：HTTP

となります。

WordPress側やレンタルサーバー側ですでにHTTPSへのリダイレクトを行っている場合、設定の組み合わせによってはリダイレクトループが発生することがあります。

そのため、オリジンサーバーでSSLを利用できる環境では、FlexibleではなくFullまたはFull (strict)を使用する方が安全です。

8 Cloudflareのキャッシュは最初から過剰に設定しない

Cloudflareを導入すると、

「とにかくすべてキャッシュすれば速くなる」

と考えてしまいがちですが、WordPressでは注意が必要です。

WordPressには、

• 管理画面
• ログイン状態
• お問い合わせフォーム
• ショッピングカート
• 会員ページ
• ユーザーごとに内容が変わるページ

など、キャッシュしてはいけない、または慎重に扱うべきページがあります。

そのため、導入直後からWordPressサイト全体に「Cache Everything」を指定するのはおすすめできません。

9 通常の画像・CSS・JavaScriptはまず標準設定で確認する

Cloudflareでは、キャッシュ可能な画像やCSS、JavaScriptなどの静的コンテンツを通常のキャッシュ機能で配信できます。

そのため、

/wp-content/uploads/

に対して、いきなり特別な「Cache Everything」ルールを作成する必要はありません。

まずはCloudflareの標準設定で動作を確認し、実際のキャッシュ状況を調べたうえで必要な箇所だけ調整する方が安全です。

10 キャッシュを細かく設定するならCache Rulesを使う

現在のCloudflareでは、キャッシュ条件を細かく設定するときにCache Rulesを利用できます。

古い記事ではPage Rulesを使用した設定例が多く見つかりますが、新しく設定するのであればCache Rulesを中心に検討するとよいでしょう。

Cache Rulesでは、URLなどの条件によって、

• キャッシュ対象にする
• キャッシュ対象外にする
• Edge側のキャッシュ期間を変更する
• ブラウザ側のキャッシュ期間を調整する

といった設定ができます。

11 WordPressの管理画面をむやみにHTMLキャッシュしない

HTMLページまで積極的にCloudflareへキャッシュする設定を行う場合は、特に注意が必要です。

少なくとも、

/wp-admin/
/wp-login.php

などの管理・ログイン関連ページを一般公開ページと同じ方法でキャッシュしないようにします。

WooCommerceや会員サイトなど、Cookieやログイン状態によってページ内容が変化するサイトでは、さらに慎重な設定が必要です。

12 Browser Cache TTLを長くすれば必ず速くなるわけではない

ブラウザキャッシュの期間を長くすると、同じ画像やCSSを再度ダウンロードする回数を減らすことができます。

一方で、キャッシュ期間を長くしすぎると、

• CSSを変更したのに反映されない
• JavaScriptの修正が反映されない
• 古い画像が表示される

といった問題が起きやすくなります。

そのため、すべてのサイトで「1日以上」「1か月以上」などと一律に決める必要はありません。

オリジンサーバーが出しているCache-ControlやExpiresも確認しながら設定しましょう。

13 HTTP/3は利用を検討してよい

CloudflareではHTTP/3を利用できます。

HTTP/3はQUICを利用する通信方式で、ネットワーク状況によっては通信効率の改善が期待できます。

基本的には有効化を検討してよい機能ですが、Webサイトの表示速度はHTTP/3だけで決まるものではありません。

有効化前後で実際のサイト表示を確認することをおすすめします。

14 Early HintsはONにして効果を確認する

Early HintsはHTTPステータス103を利用し、ブラウザが必要なリソースを早めに読み込み始められるようにする仕組みです。

利用できる環境では有効化を検討してよい機能ですが、すべてのページで大幅な高速化が起きるわけではありません。

ONにしたうえで、PageSpeed Insightsやブラウザの開発者ツールなどを使って効果を確認するとよいでしょう。

15 古い記事にあるAuto Minifyは現在使用しない

以前のCloudflare高速化記事では、

• HTML Minify
• CSS Minify
• JavaScript Minify

などのAuto MinifyをONにする方法がよく紹介されていました。

しかし、現在Auto Minifyは非推奨となっています。

そのため、新しいCloudflare設定の記事を参考にするときは、Auto Minifyを前提とした説明ではないか確認してください。

16 Mirageも現在は利用できない

以前Cloudflareには、モバイル向けの画像最適化機能としてMirageがありました。

しかしMirageはすでに廃止され、現在は利用できません。

古いCloudflareの記事には、

Mirage → ON

といった設定が残っていることがありますが、現在の設定として使用しないようにしましょう。

画像の高速化では、WordPress標準のレスポンシブ画像、WebPなどの画像形式、lazy loadingなども活用できます。

17 画像最適化を何重にも行わない

WordPressでは、

• レンタルサーバーの画像最適化
• WordPressプラグインによる画像最適化
• Cloudflareの画像最適化

を同時に使用できる場合があります。

しかし、同じ画像に複数の最適化処理を重ねても効果がほとんど増えない場合があり、設定によっては予期しない表示になる可能性もあります。

高速化機能は一度に全部ONにせず、一つずつ有効化して表示を確認することをおすすめします。

18 XserverとCloudflareを併用する場合

XserverにはCloudflareとは別に、独自の高速化機能があります。

主なものとして、

• サーバーキャッシュ
• Xアクセラレータ
• ブラウザキャッシュ
• XPageSpeed

などがあります。

18.1 XアクセラレータをCloudflareのためにOFFにする必要はない

XアクセラレータはXserver側でWebサイトを高速化する機能です。

Cloudflareを利用するからという理由だけで、必ずOFFにする必要はありません。

まず現在の正常な設定を維持したままCloudflareを導入し、問題がある場合に一つずつ設定を調整する方が安全です。

18.2 Xserverのサーバーキャッシュも一律OFFにしない

Xserverにはサーバー側のキャッシュ機能があります。

Cloudflareはサーバーより手前で動作するため、

CloudflareのキャッシュとXserverのキャッシュはまったく同じ場所で動いているわけではありません。

そのため、Cloudflareを利用するからXserverのキャッシュを必ずOFFにする、という考え方ではありません。

ただし、更新内容が反映されない場合は、Cloudflare側だけでなくXserver側のキャッシュも確認してください。

18.3 XPageSpeedは最初から必ずOFFではない

XPageSpeedはCSS、JavaScript、画像などを最適化するXserverの機能です。

Cloudflareを利用する場合でも、必ず無効にしなければならない機能ではありません。

ただし、XPageSpeed、WordPress高速化プラグイン、Cloudflareなどで同種の最適化を何重にも行うと、どの機能が問題を起こしているのか分かりにくくなります。

表示崩れやCSS・JavaScriptの更新が反映されない問題が起きた場合は、XPageSpeedを含めて一つずつ設定を確認してください。

18.4 XserverのWAFも基本的にはそのまま利用できる

Cloudflareにもセキュリティ機能がありますが、それだけを理由にXserver側のWAFを必ず無効にする必要はありません。

通常はそのまま運用し、正規の通信までブロックされるなどの問題が発生した場合にルールや設定を確認します。

19 ConoHa WINGとCloudflareを併用する場合

ConoHa WINGにも独自の高速化機能があります。

• コンテンツキャッシュ
• ブラウザキャッシュ
• WEXAL

19.1 ConoHaのコンテンツキャッシュはデフォルトでON

ConoHa WINGではコンテンツキャッシュ機能が提供されており、WordPressの管理画面である wp-admin 配下はキャッシュ対象外となるように設計されています。

Cloudflareを導入する場合でも、いきなりすべてのConoHa高速化機能をOFFにする必要はありません。

19.2 WEXALとConoHaのコンテンツキャッシュは併用できない

ここは特に注意が必要です。

ConoHa WINGでは、WEXALとConoHa自身のコンテンツキャッシュを同時に利用することはできません。

コンテンツキャッシュがONの状態でWEXALをONにすると、コンテンツキャッシュは自動的にOFFになります。

これはCloudflareとの競合という意味ではなく、ConoHa WING内の機能同士の仕様です。

19.3 WEXALはCloudflareを使うから必ずOFFではない

「CloudflareとWEXALは必ず競合するためOFFにする」という説明を見かけることがありますが、一律にOFFにする必要があるとは限りません。

ただし、WEXALにも画像や各種リソースの最適化機能があるため、Cloudflare側でも同種の最適化を行う場合は処理が重複しないか確認しましょう。

Cloudflare導入前と導入後で表示確認と速度測定を行い、問題がある機能だけを調整する方法がおすすめです。

20 Cloudflare APOは必須ではない

CloudflareにはWordPress向けのAutomatic Platform Optimization（APO）があります。

APOを利用すると、WordPressのHTMLなどをCloudflareのエッジから配信できるため、オリジンサーバーから遠い利用者に対して効果が期待できる場合があります。

ただし、Cloudflareを利用するならAPOが必須というわけではありません。

通常のCloudflare CDNだけで運用することもできます。

また、APOとWordPressのキャッシュプラグインを併用すると、組み合わせによっては予期しない動作が発生する可能性があります。

APOを導入するときは、最初から複数のキャッシュ機能を同時に有効にせず、まずAPO単体の動作を確認する方が安全です。

利用できるCloudflareプランや条件については変更される可能性があるため、導入時にCloudflare公式の最新情報を確認してください。

21 WorkersでWordPress全体を単純キャッシュするのは避ける

高速化記事の中には、Cloudflare Workersを使ってWordPressのHTMLを強制的にキャッシュするコードが紹介されていることがあります。

しかし、WordPressではログイン状態やCookie、フォーム、会員ページ、ECサイトなどによって表示内容が変わることがあります。

これらを考慮せずに、

すべてのHTMLを1時間キャッシュする

といった処理を行うのは危険です。

HTMLまでエッジキャッシュしたい場合は、WordPressの仕組みを理解したうえでCache RulesやAPOなどを利用し、管理画面・ログインユーザー・動的ページなどを適切に除外してください。

22 Cloudflare導入後に更新が反映されない場合

WordPressでCSSや画像を変更したのに古い内容が表示される場合、複数のキャッシュが関係している可能性があります。

次の順番で確認すると原因を見つけやすくなります。

1. ブラウザキャッシュを確認する
2. WordPressキャッシュプラグインを確認する
3. Xserver・ConoHa側のキャッシュを確認する
4. Cloudflareのキャッシュを確認する

Cloudflareでは必要なURLだけキャッシュを削除することもできます。

更新のたびにすべてのキャッシュを削除するのではなく、原因となっているキャッシュを特定することが重要です。

23 Cloudflare導入後にリダイレクトループが発生した場合

Cloudflare導入直後に、

ERR_TOO_MANY_REDIRECTS

などが表示された場合は、まずSSL/TLS設定を確認します。

特に、サーバー側でHTTPSへリダイレクトしているにもかかわらず、Cloudflare側がFlexibleになっている場合は注意が必要です。

オリジンサーバーに正常なSSL証明書が設定されているのであれば、FullまたはFull (strict)を確認してください。

24 PageSpeed Insightsの点数だけで判断しない

Cloudflareを導入したからといって、PageSpeed Insightsの点数が必ず大幅に上がるわけではありません。

PageSpeed Insightsの評価には、

• 画像サイズ
• JavaScript
• CSS
• Webフォント
• テーマ
• プラグイン
• サーバー応答時間
• レイアウトシフト

など多くの要素が関係します。

Cloudflareはその中のCDN、キャッシュ、通信、セキュリティなどを担当する仕組みです。

導入前と導入後を同じ条件で測定し、本当に改善しているか確認しましょう。

25 2026年版：おすすめの基本構成

WordPressでXserverまたはConoHa WINGとCloudflareを利用する場合、まずは次のようなシンプルな構成から始めるのがおすすめです。

• ドメイン管理会社はそのままでOK
• ネームサーバーをCloudflareへ変更
• Webサイト用A・AAAA・CNAMEは必要に応じてProxied
• メール関連DNSは慎重に確認
• SSL/TLSは可能ならFull (strict)
• Cloudflare標準キャッシュから開始
• HTML全体へのCache Everythingは最初から使わない
• 必要になったらCache Rulesを利用する
• HTTP/3は有効化を検討
• Early Hintsは有効化後に効果を確認
• Auto Minifyは使用しない
• Mirageはすでに廃止
• 高速化機能を一度に何重にもONにしない
• APOは必要なサイトだけ検討する
• Workersによる無条件のWordPress全体キャッシュは避ける

26 まとめ：Cloudflareは「全部ON」が最速設定ではない

Cloudflareには多数の高速化・キャッシュ・セキュリティ機能があります。

しかし、WordPressサイトでは機能をたくさんONにすれば速くなるというものではありません。

XserverやConoHa WINGには、もともとサーバーキャッシュ、ブラウザキャッシュ、画像・CSS・JavaScriptの最適化などの機能があります。

そこへCloudflareやWordPressの高速化プラグインを追加すると、同じような処理を複数箇所で行うことになります。

重要なのは、

• まずシンプルな構成でCloudflareを導入する
• SSL/TLSを正しく設定する
• 管理画面などの動的ページを不用意にキャッシュしない
• 一つずつ高速化機能を追加する
• 変更するたびにPC・スマートフォンで動作確認する
• 導入前後の速度を実際に測定する

という進め方です。

国内レンタルサーバーはもともと高速なため、Cloudflareを導入しただけで劇的に速くなるとは限りません。

一方で、CDN、DNS、キャッシュ、セキュリティなどを適切に利用すれば、サーバー負荷の軽減や安定したWebサイト運営につなげることができます。

古いCloudflareの記事には、すでに廃止されたAuto MinifyやMirage、現在とは異なるPage Rules中心の設定方法などが残っています。
Cloudflareは仕様変更が比較的多いサービスなので、実際に設定するときは公式情報も確認しながら進めることが大切です。