2026年10月10日
2026年10月10日
WordPressにCDN(CloudFront・Cloudflare)を設定する方法|構成の選び方と手順
CDN(コンテンツ配信ネットワーク)は、画像や CSS・JavaScript などを世界各地のサーバー(エッジ)にキャッシュし、利用者に近い場所から返す仕組みです。WordPress のサーバー(オリジン)への負担が減り、遠い地域からの表示も速くなります。
WordPress に CDN を入れる構成は、大きく2つあります(2026年10月時点)。
| 構成 | 仕組み | 代表的なサービス | WordPress 側の変更 |
|---|---|---|---|
| サイト全体をプロキシ | ドメインのアクセスをすべて CDN が受け、オリジンへ中継する | Cloudflare | 基本的に不要(HTTPS・IPアドレスの判定に注意) |
| 静的ファイルだけ別ドメインで配信 | cdn.example.com など別のホスト名で、画像・CSS・JS だけを配信する |
CloudFront など | 静的ファイルのURLを CDN のホスト名に書き換える |
CloudFront でもサイト全体を配信できますが、ページごとにキャッシュする・しないを細かく決める必要があります。その構成はWordPressのCloudFront設定:キャッシュ動作とカスタムオリジンの組み立てで説明しています。
始める前に
- WordPress の「設定」→「一般」の「WordPress アドレス(URL)」と「サイトアドレス(URL)」は、CDN のホスト名に変えません。ここを変えると、管理画面やログインも CDN 経由になり、ログインできなくなることがあります
- オリジンのサーバーで HTTPS が使えている状態にしておきます
- DNS を変更する前に、変更前のレコードを記録しておきます
- 料金はサービスとプランで変わるため、各社の料金ページで確かめます
構成1:Cloudflareでサイト全体をプロキシする
手順
- Cloudflare にアカウントを作り、サイト(ドメイン)を追加する。既存の DNS レコードが読み込まれるので、漏れが無いか確かめる
- ドメインを登録している会社の管理画面で、ネームサーバーを Cloudflare が指定する2つに変える
- Cloudflare の DNS 画面で、Webサイトの A レコード(または CNAME)のプロキシ状態を「プロキシ済み」(オレンジの雲)にする。メールサーバーなど、Web 以外のレコードは「DNS のみ」のままにする
- 「SSL/TLS」の概要画面で、暗号化モードを Full (strict) にする
Full (strict) では、オリジンのサーバーに、期限内で、ホスト名が一致し、公的な認証局か Cloudflare Origin CA が発行した証明書が必要です。「Flexible」はオリジンへ HTTP で接続するため、WordPress 側が HTTPS へリダイレクトしているとリダイレクトがループします。
ネームサーバーの移行とレコードの作り方はCloudflareでDNSを管理する初期設定、WAF などの設定はWordPressにCloudflareを設定する完全ガイドを参照してください。
キャッシュされるもの
Cloudflare は初期設定では、ファイルの拡張子で判断して画像・CSS・JS などをキャッシュし、HTML はキャッシュしません。また、Cache-Control: private・no-store・no-cache が付いた応答や、Set-Cookie を含む応答はキャッシュしません。そのため、初期設定のままなら、管理画面やログイン中の画面がほかの人に見えることはありません。
HTML までキャッシュしたい場合は、Cloudflare の Cache Rules や、WordPress 向けの有料機能 APO(Automatic Platform Optimization)を使います。Cache Rules で HTML をキャッシュする場合は、/wp-admin/、/wp-login.php、ログイン中(wordpress_logged_in_ で始まる Cookie がある)のアクセス、WooCommerce のカートや決済のページをキャッシュから外す設定が必要です。
WordPress側で気をつけること
- 訪問者のIPアドレス:オリジンには Cloudflare のIPアドレスから接続されるため、そのままではアクセスログやセキュリティプラグインに Cloudflare のIPアドレスが記録されます。本当の訪問者のIPアドレスは
CF-Connecting-IPヘッダーに入っているので、Webサーバーの設定(Apache の mod_remoteip、nginx の real_ip モジュール)で置き換えます - キャッシュの削除:CSS や画像を差し替えたのに古いものが表示される場合は、Cloudflare の管理画面からキャッシュを削除します
構成2:CloudFrontで静的ファイルだけを配信する
https://cdn.example.com/wp-content/uploads/... のようなURLで、画像・CSS・JS だけを CloudFront から配信する構成です。HTML は今までどおりオリジンが返すので、ログインやフォームの動きに影響しません。
手順1:証明書を用意する
cdn.example.com を HTTPS で配信するため、AWS Certificate Manager(ACM)で証明書を発行します。CloudFront で使う ACM の証明書は、米国東部(バージニア北部)リージョン(us-east-1) で発行する必要があります。ほかのリージョンで発行した証明書は CloudFront で選べません。
手順2:ディストリビューションを作る
CloudFront のコンソールでディストリビューションを作り、主に次のように設定します。
| 項目 | 設定 |
|---|---|
| オリジンのドメイン | WordPress のホスト名(例:example.com) |
| オリジンへのプロトコル | HTTPS のみ |
| ビューワーのプロトコルポリシー | HTTP を HTTPS にリダイレクト |
| 許可する HTTP メソッド | GET, HEAD |
| キャッシュポリシー | CachingOptimized(マネージド) |
| 代替ドメイン名(CNAME) | cdn.example.com |
| カスタム SSL 証明書 | 手順1の証明書 |
CachingOptimized は、Cookie とクエリ文字列をキャッシュのキーに含めず、既定で24時間(最短1秒、最長365日)キャッシュするポリシーです。WordPress は CSS・JS のURLに ?ver=6.8 のようなクエリ文字列を付けて更新を伝えるため、ファイルを更新しても古いものが返ることがあります。これを避けたい場合は、クエリ文字列をキャッシュのキーに含める独自のキャッシュポリシーを作ります。
Webフォントを CDN から配信する場合、ブラウザーは別ドメインからのフォントに CORS のヘッダーを求めます。フォントが読み込まれないときは、CloudFront のレスポンスヘッダーポリシーで CORS のヘッダーを付けるか、フォントだけはオリジンから配信します。
手順3:DNSにCNAMEを追加する
DNS に、cdn.example.com を CloudFront のディストリビューションのドメイン名(d1234abcd.cloudfront.net の形)に向ける CNAME レコードを追加します。追加したら、次のコマンドで CloudFront を経由しているか確かめます。
curl -sI https://cdn.example.com/wp-includes/css/dist/block-library/style.min.css | grep -iE '^(HTTP|x-cache|via)'
2回続けて実行し、2回目の x-cache が Hit from cloudfront になればキャッシュから返っています。
手順4:WordPressのURLをCDNに書き換える
HTML の中の画像・CSS・JS のURLを cdn.example.com に書き換えます。主な方法は次のとおりです。
- CDN Enabler プラグイン:「設定」→「CDN Enabler」で CDN のホスト名を入れると、出力する HTML の中の静的ファイルのURLを書き換える。書き換える拡張子と、除外する文字列を指定できる
- キャッシュプラグインの CDN 機能:W3 Total Cache、LiteSpeed Cache などには、静的ファイルのURLを CDN のホスト名に置き換える設定がある。すでに使っているならその機能を使う
データベースの中の記事本文を wp search-replace で CDN のURLに置き換える方法は勧めません。CDN をやめるときに元に戻す作業が必要になるためです。
書き換えたら、ログアウトした状態でページのソースを開き、画像・CSS・JS のURLが cdn.example.com になっていること、管理画面では表示や編集に問題が無いことを確かめます。
サイト全体をCDN経由にするときのHTTPSの判定
Cloudflare やロードバランサーなどの後ろで、CDN とオリジンの間が HTTP になっている構成では、WordPress が自分は HTTP で動いていると判断し、HTTPS へのリダイレクトがループしたり、CSS が http:// で読み込まれたりします。Cloudflare やロードバランサーが付ける X-Forwarded-Proto ヘッダー(利用者が HTTPS で接続したかどうか)を見て、wp-config.php で HTTPS と判定させます(「編集が必要なのはここまでです」より上に書きます)。
<?php
if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
$_SERVER['HTTPS'] = 'on';
}
このヘッダーは誰でも付けて送れるため、オリジンに CDN 以外から直接アクセスできる場合は、オリジンへの接続を CDN からに限る設定も検討します。CloudFront とオリジンの間を HTTPS にし、Cloudflare を Full (strict) にしていれば、この設定は通常不要です。
うまくいかないとき
- CSS が崩れる・画像が出ない:ソースで該当するURLを開き、CDN 側で 403 や 404 になっていないか確かめる。CloudFront のオリジンのドメインが正しいか、オリジンの証明書がホスト名と一致しているか(一致しないと 502 になる)を見る
- 更新が反映されない:CDN のキャッシュを削除する(CloudFront は「無効化」)
- ログインできない・管理画面が崩れる:WordPress アドレス・サイトアドレスを CDN のホスト名にしていないか、HTML をキャッシュする設定で管理画面を外しているかを確かめる
CDN 導入後の個別のトラブルはCloudflare 導入後に WordPress で起きやすいトラブル事例と直し方、ルートドメインに CNAME を向けられない問題はCDN導入時のDNS設定:CNAMEフラット化・ALIASの使い方を参照してください。
まとめ
- 構成は「サイト全体をプロキシ(Cloudflare)」と「静的ファイルだけ別ドメイン(CloudFront など)」の2つ
- WordPress アドレス・サイトアドレスは CDN のホスト名に変えない
- Cloudflare は暗号化モードを Full (strict) にし、HTML をキャッシュするなら管理画面とログイン中を外す
- CloudFront の証明書は us-east-1 で発行し、静的ファイルのURLはプラグインで書き換える
- CDN の後ろで HTTPS の判定がずれる場合は、
X-Forwarded-Protoを見て$_SERVER['HTTPS']を設定する