2026年5月20日

WordPressにCloudflareのCDNを設定する方法（SSLモード・キャッシュ・実IP）

SEO・パフォーマンス

Cloudflare は、ドメインのネームサーバーを Cloudflare に切り替えると、サイトへのアクセスを Cloudflare のエッジサーバー経由にできるサービスです。無料の Free プランでも、CDN（静的ファイルのキャッシュ）、HTTPS 化、DDoS 対策を使えます。

この記事では、既存の WordPress サイトを Cloudflare 経由にする手順と、WordPress で問題になりやすい設定（SSL モード、HTML のキャッシュ、訪問者 IP）を説明します。Cloudflare の仕様と画面は2026年11月時点の公式ドキュメントで確認しています。画面の項目名は英語表記で書きます。ダッシュボードのメニュー構成は変わることがあるので、見つからないときはダッシュボードの検索欄で設定名を検索してください。

導入前に知っておくこと

初期状態では HTML はキャッシュされません。 Cloudflare は拡張子で判断し、CSS・JS・画像・フォント・PDF などをキャッシュします。WordPress が出力するページ（HTML）は、設定しない限り毎回オリジン（自分のサーバー）に問い合わせます。
オリジンが Cache-Control: private・no-store・no-cache・max-age=0 を返したとき、Set-Cookie を返したとき、GET 以外のリクエストはキャッシュされません。
そのため、静的ファイルの配信とHTTPS化だけなら、WordPress 側の変更はほとんど要りません。HTML までキャッシュしたいときは、後述の除外条件を正しく設定する必要があります。

ステップ1：サイトを追加してネームサーバーを切り替える

Cloudflare のアカウントを作り、ダッシュボードでドメインを追加します。
プランを選びます。この記事の手順は Free プランで行えます。
既存の DNS レコードが読み込まれます。A レコード（例: example.com と www）が今のサーバーの IP を指しているか、メール用の MX レコードが抜けていないかを、今の DNS 設定と見比べてください。
Web サイト用の A／CNAME レコードは、プロキシ状態を「Proxied（オレンジの雲）」にします。メールサーバーなど、Web 以外に使うホスト名は「DNS only」にします。
画面に表示される2つのネームサーバー名を、ドメインを登録しているレジストラの管理画面で設定します。

切り替わったかは次のコマンドで確認します。

dig NS example.com +short

Cloudflare から指定されたネームサーバー名が返れば切り替わっています。反映にかかる時間はレジストラと上位の DNS のキャッシュによって変わります。

DNS の細かい設定は CloudflareのDNS設定も参考にしてください。

ステップ2：SSL/TLS の暗号化モードを選ぶ

SSL/TLS の設定には、訪問者と Cloudflare の間、Cloudflare とオリジンの間の2区間があります。暗号化モードは後者の通信方法を決めます。

モード	Cloudflare からオリジンへの通信	WordPress での使いどころ
Off	HTTP（暗号化なし）	使わない
Flexible	常に HTTP	オリジンに証明書がないときだけ。リダイレクトループが起きやすい
Full	訪問者と同じプロトコル。HTTPS のとき証明書を検証しない	自己署名証明書しかないとき
Full (strict)	訪問者と同じプロトコル。HTTPS のとき証明書を検証する	推奨。公的な証明書か Cloudflare Origin CA 証明書が必要
Strict (SSL-Only Origin Pull)	常に HTTPS で、証明書を検証する	オリジンを HTTPS だけにしたいとき

2026年11月時点では、既定は「Automatic SSL/TLS」で、オリジンが対応する最も安全なモードが自動で選ばれます（段階的に展開中のため、手動の選択肢だけが表示されるゾーンもあります）。手動で選ぶ場合は、オリジンに有効な証明書を入れて Full (strict) にしてください。オリジンの証明書は Let's Encrypt でも、Cloudflare が発行する Origin CA 証明書でも構いません（Cloudflare Origin CA証明書の設定）。

Flexible でリダイレクトループになる理由

Flexible では、訪問者が HTTPS で来ても Cloudflare はオリジンへ HTTP で接続します。WordPress のサイトアドレスが https:// になっていたり、.htaccess などで HTTP から HTTPS へリダイレクトしていたりすると、オリジンは HTTPS へのリダイレクトを返し、Cloudflare はまた HTTP で接続する、という往復が続いて ERR_TOO_MANY_REDIRECTS になります。オリジンに証明書を入れて Full (strict) にするのが根本的な対処です。

HTTP から HTTPS へのリダイレクト

HTTPS への転送は、Cloudflare の Always Use HTTPS（Edge Certificates の設定）で行えます。全プランで使えます。オリジン側で転送を設定している場合は、Full (strict) にしていればループにはなりません。

wp-config.php の設定は必要か

Full または Full (strict) では、訪問者が HTTPS で来ればオリジンにも HTTPS で接続するので、WordPress は HTTPS のリクエストとして認識します。$_SERVER['HTTPS'] を書き換えるコードは不要です。

X-Forwarded-Proto を見て $_SERVER['HTTPS'] を on にするコードは、オリジンが HTTP しか受けない構成（Flexible や、手前のロードバランサーで TLS を終端する構成）で使うものです。このヘッダーはクライアントが自由に付けられるため、オリジンへの接続を Cloudflare（またはロードバランサー）からに限定していない場合は信用しないでください。

ステップ3：訪問者の IP アドレスを復元する

Cloudflare 経由にすると、オリジンから見た接続元（REMOTE_ADDR）は Cloudflare の IP になります。WordPress はコメントの投稿者 IP などに REMOTE_ADDR を使い、ログイン試行回数を制限するプラグインも多くが同じ値を見ます。そのため、Web サーバー側で本来の訪問者 IP に戻しておきます。

Cloudflare は訪問者の IP を CF-Connecting-IP ヘッダーで送ります。ただし、このヘッダーは誰でも偽装できるので、Cloudflare の IP から来た接続のときだけ採用するように設定します。Cloudflare の IP 範囲は https://www.cloudflare.com/ips/ で公開されています（変わることがあるので定期的に確認してください）。

Apache（mod_remoteip、Ubuntu／Debian の例）:

sudo a2enmod remoteip
sudo nano /etc/apache2/conf-available/remoteip.conf

RemoteIPHeader CF-Connecting-IP
# https://www.cloudflare.com/ips/ の範囲をすべて1行ずつ書く
RemoteIPTrustedProxy 173.245.48.0/20
RemoteIPTrustedProxy 103.21.244.0/22
# （以下、公開されている IPv4・IPv6 の範囲を続ける）

sudo a2enconf remoteip
sudo apache2ctl configtest
sudo systemctl restart apache2

アクセスログにも訪問者 IP を出すには、LogFormat の %h を %a に変えます。

Nginx（ngx_http_realip_module）:

# http ブロックまたは server ブロックに書く
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
# （公開されている範囲をすべて続ける）
real_ip_header CF-Connecting-IP;

sudo nginx -t
sudo systemctl reload nginx

PHP のコードで $_SERVER['HTTP_CF_CONNECTING_IP'] を直接読む方法は、接続元が Cloudflare かを確かめないと偽装を受け入れてしまうので、サーバー側の設定で直す方法をおすすめします。

ステップ4：HTML をキャッシュするかを決める

静的ファイルだけをキャッシュする初期状態なら、管理画面やログイン中の表示が他人に配信される心配はありません。トップページなど HTML まで Cloudflare にキャッシュさせたい場合は、次のどちらかを使います。

方法A：Automatic Platform Optimization（APO）

APO は WordPress 用の機能で、HTML を Cloudflare のエッジから配信します。利用には Cloudflare 公式の WordPress プラグイン（プラグイン名「Cloudflare」）を入れて有効化する必要があります。料金や含まれるプランは Cloudflare の料金ページで確認してください。

方法B：Cache Rules で HTML をキャッシュ対象にする

Cache Rules（Free プランでは10個まで）で、HTML をキャッシュ対象（Eligible for cache）にするルールを作ります。このとき、管理画面、ログイン画面、ログイン中・コメント投稿後・パスワード保護ページの閲覧中の利用者を除外します。式は Expression Builder で組み立てるか、次のように書きます。

(http.host eq "example.com"
 and not starts_with(http.request.uri.path, "/wp-admin")
 and not starts_with(http.request.uri.path, "/wp-login.php")
 and not starts_with(http.request.uri.path, "/wp-json")
 and not http.cookie contains "wordpress_logged_in_"
 and not http.cookie contains "comment_author_"
 and not http.cookie contains "wp-postpass_")

キャッシュの可否: Eligible for cache
Edge TTL: 「Ignore cache-control header and use this TTL」を選ぶ場合は、更新の頻度に合わせて短め（例: 数時間）にし、更新時は次のステップのように削除します

WordPress の wp-admin 以下はオリジンが no-cache 系のヘッダーを返しますが、上の式のように明示的に外しておくと設定ミスに気づきやすくなります。WooCommerce などカートや会員ページがあるサイトでは、それらのパスとプラグインが使う Cookie（WooCommerce なら woocommerce_items_in_cart など）も除外してください。

設定後は、ログアウトした状態とログインした状態でページを開き、レスポンスヘッダーの cf-cache-status を確認します。

curl -sI https://example.com/ | grep -i cf-cache-status

2回目以降のアクセスで HIT になればキャッシュされています。DYNAMIC はキャッシュの対象外、BYPASS は除外条件やヘッダーによってキャッシュを通さなかったことを表します。

ステップ5：記事の更新時にキャッシュを削除する

HTML をキャッシュした場合、記事を更新しても Edge TTL が切れるまで古いページが表示されます。APO を使う場合は Cloudflare プラグインが削除を行います。Cache Rules を使う場合は、ダッシュボードの「Purge Cache」で URL を指定して削除するか、次のように更新時に API で削除します。

まず Cloudflare の「API Tokens」で、対象ゾーンの Cache Purge 権限だけを持つトークンを作ります。グローバル API キーは使わないでください。ゾーン ID はドメインの概要ページに表示されます。

wp-config.php に書きます（このファイルは公開ディレクトリの外に置くか、パーミッションを厳しくしてください）。

<?php
define( 'CF_ZONE_ID', 'ゾーンID' );
define( 'CF_API_TOKEN', 'Cache Purge 権限だけのAPIトークン' );

テーマの functions.php か独自プラグインに書きます。

<?php
/**
 * 公開中の投稿を保存したとき、その投稿とトップページの Cloudflare キャッシュを削除する。
 */
add_action( 'save_post', 'mysite_cf_purge_post', 10, 2 );

function mysite_cf_purge_post( int $post_id, WP_Post $post ): void {
	if ( wp_is_post_revision( $post_id ) || wp_is_post_autosave( $post_id ) ) {
		return;
	}
	if ( 'publish' !== $post->post_status ) {
		return;
	}
	if ( ! defined( 'CF_ZONE_ID' ) || ! defined( 'CF_API_TOKEN' ) ) {
		return;
	}

	$urls = array_values( array_unique( array_filter( array(
		get_permalink( $post_id ),
		home_url( '/' ),
	) ) ) );

	$response = wp_remote_post(
		'https://api.cloudflare.com/client/v4/zones/' . rawurlencode( CF_ZONE_ID ) . '/purge_cache',
		array(
			'headers' => array(
				'Authorization' => 'Bearer ' . CF_API_TOKEN,
				'Content-Type'  => 'application/json',
			),
			'body'    => wp_json_encode( array( 'files' => $urls ) ),
			'timeout' => 10,
		)
	);

	if ( is_wp_error( $response ) || 200 !== wp_remote_retrieve_response_code( $response ) ) {
		error_log( 'Cloudflare purge failed for post ' . $post_id );
	}
}

URL 指定の削除は Free プランでも使え、1回のリクエストで指定できる件数には上限があります（2026年11月時点の Free プランでは100件）。カテゴリーやタグの一覧ページもキャッシュしている場合は、それらの URL も $urls に加えてください。

ステップ6：そのほかの設定

設定	内容と注意
Rocket Loader	JavaScript の読み込みを遅らせる機能。実行順序が変わるため、プラグインやテーマの動作が変わることがある。有効にするなら全ページを確認する
Bot Fight Mode	自動化されたアクセスへの対策。外部サービスからの正当なアクセス（監視や連携など）が止まることがあるので、有効化後に確認する
HTTP/3 (with QUIC)	対応ブラウザとの通信に HTTP/3 を使う
Polish	画像の自動最適化。Pro プラン以上で利用でき、Free プランにはない
圧縮	訪問者への圧縮はプランごとの既定（2026年11月時点では Free は Zstandard、Pro と Business は Brotli）で行われ、Compression Rules で変えられる

以前あった Auto Minify（HTML・CSS・JS の縮小）は廃止されています。古い解説記事にある設定は今のダッシュボードにはありません。縮小が必要ならキャッシュプラグインなど WordPress 側で行います。

うまくいかないとき

症状	主な原因と確認すること
`ERR_TOO_MANY_REDIRECTS`	SSL モードが Flexible で、オリジンが HTTPS へ転送している。Full (strict) にする
管理画面やログイン状態が他人に見える	HTML をキャッシュするルールの除外条件が足りない。ルールを止めてから Purge Everything で全削除し、条件を見直す
記事を更新しても古いまま	HTML をキャッシュしている。URL を指定して削除するか、Edge TTL を短くする
コメントやログ上の IP がすべて同じ	ステップ3の実IPの復元が設定されていない
一部のスクリプトが動かない	Rocket Loader を無効にして確認する

まとめ

ネームサーバーを切り替えると、Free プランでも静的ファイルのキャッシュと HTTPS 化が使えます。初期状態では HTML はキャッシュされません。
SSL/TLS は、オリジンに証明書を入れて Full (strict)（または Automatic SSL/TLS）にします。Flexible はリダイレクトループの原因になります。
訪問者の IP は、Cloudflare の IP 範囲だけを信頼する形で Web サーバー側で復元します。
HTML をキャッシュするなら APO か Cache Rules を使い、管理画面とログイン中の利用者を除外し、更新時にキャッシュを削除します。

Cloudflare のセキュリティ設定については CloudflareのWAF設定も参考にしてください。