2026年8月31日

Cloudflare 導入後に WordPress で起きやすいトラブル事例と直し方

ネットワーク・接続

WordPress サイトに Cloudflare を導入した直後に起きるトラブルは、多くが「SSL/TLS暗号化モードとWordPressのHTTPS判定の食い違い」「キャッシュの対象が広すぎる」「訪問者のIPが Cloudflare のIPに置き換わる」「セキュリティ機能の誤検知」の4系統に分けられます。この記事では、よくある事例を起こりやすい順に並べ、それぞれの症状の見分け方・確認方法・直し方を説明します。

設定画面の名称や配置、プランごとに使える機能は変わることが多いため、ここでは目的ベースで説明します（2026年10月現在）。設定を変える前に、現在の設定値を控えておくと戻しやすくなります。

まず Cloudflare が原因かを切り分ける

トラブルが起きたら、最初に「Cloudflare を通したときだけ起きるのか」を確認します。レスポンスヘッダーを見ると、Cloudflare を経由しているか、キャッシュから返っているかが分かります。

curl -sI https://example.com/ | grep -iE "^(server|cf-cache-status|cf-ray|location)"

server: cloudflare と cf-ray があれば Cloudflare 経由です。cf-cache-status: HIT ならキャッシュから返っています。

次に、Cloudflare を経由せずオリジンへ直接つないで同じ症状が出るかを試します。--resolve で名前解決だけをオリジンのIPに差し替えます。

curl -sI --resolve example.com:443:203.0.113.10 https://example.com/

203.0.113.10 はオリジンサーバーのIPに置き換えてください。直接アクセスで正常なら Cloudflare 側の設定、直接でも同じ症状ならオリジン側の問題です。ダッシュボードの開発モード（キャッシュを一時的に止める機能）や、一時的にプロキシを止める機能も切り分けに使えます。

事例1: リダイレクトが繰り返される（ERR_TOO_MANY_REDIRECTS）

導入直後に最も多い事例です。原因はほぼ、SSL/TLS暗号化モードが「Flexible」になっていることです。Flexible では Cloudflare からオリジンへの通信がHTTPになるため、オリジン側（WordPress や .htaccess）がHTTPSへ転送し、Cloudflare がまたHTTPで取りに行く、という往復が続きます。

直し方は、オリジンに有効な証明書を置いたうえで暗号化モードを「Full (strict)」にすることです。オリジンの証明書は Cloudflare の Origin CA 証明書でも、Let's Encrypt などの公開証明書でもかまいません。

それでも WordPress が HTTPS と認識せずループする場合は、wp-config.php の require_once ABSPATH . 'wp-settings.php'; より上に、プロキシ経由のHTTPSを認識させる処理を追加します。

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) && 'https' === $_SERVER['HTTP_X_FORWARDED_PROTO'] ) {
	$_SERVER['HTTPS'] = 'on';
}

このヘッダーは誰でも送れるため、オリジンへの直接アクセスを Cloudflare のIPだけに制限した構成で使うのが前提です。編集前に wp-config.php のバックアップを取ってください。

事例2: ログイン状態や個人の情報がキャッシュされる

「ログインしていないのに管理バーが表示された」「別の人のカートの中身が見えた」という事例です。Cloudflare は標準ではHTMLをキャッシュしませんが、キャッシュルールでHTMLまでキャッシュする設定（いわゆる全件キャッシュ）にしたときに起きます。

確認は、ログイン中に表示したページを別のブラウザ（シークレットウィンドウ）で開き、cf-cache-status を見ることです。HTMLで HIT が出ていれば、HTMLがキャッシュされています。

直し方は次のとおりです。

/wp-admin/、/wp-login.php、プレビュー、WooCommerce のカート・チェックアウト・マイアカウントなど、個人ごとに内容が変わるパスをキャッシュ対象から外す。
wordpress_logged_in_ や woocommerce_items_in_cart などのCookieがあるリクエストはキャッシュを使わない設定にする。Cookie を条件に使えるかはプランや機能によって異なります。
WordPress 向けには Cloudflare の APO（Automatic Platform Optimization）という機能があり、公式プラグイン「Cloudflare」と組み合わせてログインユーザーを除外しつつHTMLをキャッシュできます。利用条件は公式の案内で確認してください。

設定を変えたら、キャッシュを全削除（パージ）してから再確認します。

事例3: コメントやログイン制限で全員が同じIPに見える

Cloudflare 経由では、オリジンから見た接続元が Cloudflare のIPになります。その結果、ログイン試行制限プラグインが Cloudflare のIPを丸ごとブロックして誰もログインできなくなる、コメントのIPがすべて同じになる、といった事例が起きます。

Cloudflare は本来の訪問者IPを CF-Connecting-IP ヘッダーで渡すので、Webサーバーで復元します。Nginx の例です。

# Cloudflare のIP範囲（https://www.cloudflare.com/ips/ で最新を確認）
set_real_ip_from 173.245.48.0/20;
# ...公開されている範囲をすべて列挙...
real_ip_header CF-Connecting-IP;

Apache では mod_remoteip の RemoteIPHeader CF-Connecting-IP と RemoteIPTrustedProxy で同じことができます。IP範囲は変わることがあるため、公式の一覧から定期的に更新する仕組みを用意してください。Wordfence などのセキュリティプラグインには、IPの取得元ヘッダーを選ぶ設定がある場合もあります。

事例4: 投稿の保存や管理画面の操作がブロックされる

ブロックエディターで「更新に失敗しました」「返答が正しい JSON レスポンスではありません」と表示される、管理画面で403や確認画面（チャレンジ）が出る、という事例です。WAFのマネージドルールやボット対策機能が、管理画面からのREST APIリクエストを攻撃と誤判定していることがあります。

ダッシュボードのセキュリティイベントのログで、該当時刻にブロックされたリクエストのパスと、反応したルールを確認します。直し方は、反応したルールだけを特定のパス（/wp-json/ や /wp-admin/）で除外することです。WAF全体を止めるのは避けてください。管理画面へのアクセスを自分のIPに限定するなど、除外の範囲を狭める工夫も有効です。

事例5: JavaScript が動かない・表示が崩れる

Rocket Loader（JavaScript の読み込みを遅らせる機能）を有効にすると、スライダーやフォーム、計測タグなどが動かなくなることがあります。まず Rocket Loader を無効にして再現するか確かめます。特定のスクリプトだけ対象外にしたい場合は、<script> タグに data-cfasync="false" を付ける方法があります。

かつて提供されていた自動圧縮（Auto Minify）は廃止されています。古い記事の手順にある設定項目が見当たらない場合は、機能自体が無くなっている可能性があります。

事例6: メールが届かない・送れない

ネームサーバーを Cloudflare に移した際に、MXレコードやメール用のAレコードが取り込まれていない、あるいはメールサーバーのホスト名をプロキシ有効（オレンジ雲）にしてしまった、という事例です。Cloudflare のプロキシはHTTP/HTTPSなどを対象とし、SMTPやIMAPは通しません。

dig +short MX example.com
dig +short A mail.example.com

mail.example.com が Cloudflare のIPを返していたら、そのレコードを「DNSのみ」に変更します。SPF・DKIM・DMARC の TXT レコードが移行時に漏れていないかも確認してください。

事例7: 520〜524 のエラーが出る

Cloudflare 独自の5xxエラーは、オリジンとの通信で問題が起きたことを示します。

521: オリジンが接続を拒否。Webサーバーの停止や、ファイアウォールが Cloudflare のIPを遮断していないか確認します。
522: 接続がタイムアウト。サーバーの負荷や、セキュリティグループ・iptables の設定を確認します。
524: 接続はできたが応答が遅すぎる。標準プランでは約100秒で打ち切られます。大量のインポートや重いバックアップ処理は、WP-CLI でサーバー上から実行するなど、Cloudflare を通さない方法に切り替えます。

いずれもオリジンのエラーログ（Nginx の error.log、PHP-FPM のログ）を同じ時刻で確認すると原因が絞れます。

まとめ

まず curl -sI と --resolve で、Cloudflare 側の問題かオリジン側の問題かを切り分ける。
リダイレクトループは暗号化モード Flexible が主因。オリジンに証明書を置き Full (strict) にする。
HTMLをキャッシュするなら、ログイン・カートなど個人ごとのページとCookieを除外する。
訪問者IPは CF-Connecting-IP でWebサーバー側で復元し、IP範囲は公式一覧から更新する。
WAFの誤検知はセキュリティイベントで該当ルールを特定し、パスを絞って除外する。メール用レコードはプロキシしない。