導入時の注意点とトラブルシューティング

《 Cloudflare完全ガイド 目次へ 》

ガイドの最後のページです。ここまで50ページ近くをかけて、Cloudflareの仕組みと使い方を見てきました。最後に扱うのは、実際に導入したときに起きることです。

Cloudflareを使い始めると、それまでになかった種類のトラブルに出会います。理由は単純で、あなたのサイトの前に新しい層が1枚増えるからです。サイトが表示されないとき、原因はブラウザ側かもしれず、Cloudflare側かもしれず、オリジンサーバー側かもしれません。

このページの目的は、症状の一覧を暗記することではありません。どこで起きているのかを切り分ける手順を身につけることです。それさえできれば、初めて見るエラーにも対処できます。

このページで分かること

• トラブルがどの層で起きているかを切り分ける手順
• 導入直後に起きやすい失敗（ネームサーバー・メール・DNS）
• エラーコードの読み方（520〜527番台と1000番台）
• リダイレクトループ、タイムアウト、キャッシュが更新されない問題への対処
• 調査に使う道具（Ray ID・cf-cache-status・trace）
• 導入前に確認しておくとよいこと

まず「どこで起きているか」を切り分ける

これがすべての出発点です。

Cloudflareを通したサイトへのアクセスは、次の3つの層を通ります。

1. 訪問者のブラウザ：DNSキャッシュ、ブラウザキャッシュ、HSTSの記憶
2. Cloudflareのエッジ：DNS解決、WAF、Rate Limiting、キャッシュ、SSL終端
3. オリジンサーバー：実際のWebサーバーやアプリケーション

切り分けの3つの質問

質問1：他の人・他の回線でも起きるか
自分だけに起きているなら、ブラウザキャッシュ・DNSキャッシュ・自分のIPがブロックされている可能性が高くなります。スマートフォンのモバイル回線で試すのが手軽な確認方法です。

質問2：Cloudflareを通さないと起きるか
これが最も強力な切り分けです。オリジンのIPアドレスに直接アクセスして再現するかを見ます。

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

203.0.113.10 の部分をオリジンのIPアドレスに置き換えます。ここで同じエラーが出るならオリジン側の問題であり、Cloudflareの設定をいくら見直しても直りません。逆に、直接なら正常で、Cloudflare経由だと失敗するなら、Cloudflare側の設定が原因です。

一時的に該当レコードのプロキシをオフ（グレー雲）にして確認する方法もありますが、DNSの反映を待つ必要があるので、curl の方が速く確認できます。

質問3：エラー画面はCloudflareのものか
Cloudflareが出すエラー画面には、必ずRay ID（7abc123def456789 のような文字列）が表示されます。Ray IDがあればCloudflareが返した応答で、なければオリジンが返した応答です。この見分けだけでも切り分けが半分終わります。

導入直後に起きやすいこと

ネームサーバーが切り替わらない

ドメインを追加してネームサーバーを変更しても、いつまでも「Pending Nameserver Update」のままになることがあります。

• DNSSECを無効にしていない：これが最も多い原因です。DNSSECを有効にしたままネームサーバーを変更すると、ドメインが引けなくなります。 レジストラ側でDNSSECを無効にしてから変更し、Cloudflareで有効化し直してください
• ネームサーバー名の写し間違い：Cloudflareが割り当てるネームサーバーはアカウントごとに違います。表示されたものを正確にコピーしてください
• 古いネームサーバーが残っている：追加ではなく「置き換え」です。既存のものは削除します
• 単に時間がかかっている：反映には最大24時間かかります

メールが届かなくなった

導入直後で最も影響が大きいトラブルです。 原因はほぼ1つで、MXレコードや、メール関連のレコードをプロキシしてしまっていることです。

プロキシ（オレンジ雲）はHTTP/HTTPSの通信だけを扱います。メールはSMTPという別のプロトコルなので、プロキシを通すと届かなくなります。

• MXレコード：そもそもプロキシできません
• MXレコードが指すホスト名のAレコード（mail.example.com など）：必ずDNS-only（グレー雲）にします
• SPF・DKIM・DMARCのTXTレコード：TXTなのでプロキシの対象外ですが、移行時にコピーし忘れることがあります

Cloudflareの自動スキャンは既存のDNSレコードを取り込みますが、すべてを取得できるとは限りません。切り替え前に、現在のDNSレコードを一覧で控えておくことを強くおすすめします。

特定のサブドメインだけ表示されない

上と同じ理由です。自動スキャンで拾えなかったレコードは、手で追加する必要があります。切り替え前に控えたレコード一覧と突き合わせてください。

Error 1000 が出る

「DNS points to prohibited IP」というエラーです。プロキシが二重になっていることを示します。

• AレコードがCloudflareのIPアドレスを指している
• 別のリバースプロキシを経由して、もう一度Cloudflareに戻ってきている

DNSレコードには、オリジンサーバーの実IPアドレスを設定してください。

エラーコードの読み方

5xx系（オリジンとの通信の問題）

520番台は、Cloudflareがオリジンサーバーと正常にやり取りできなかったことを示します。つまり、多くの場合オリジン側に原因があります。

521で最も多い原因は、オリジン側のファイアウォールです。 Cloudflareを導入したのに直接アクセスを遮断する設定を入れると、Cloudflare自身も遮断されます。CloudflareのIPアドレス範囲は公開されているので、そこからの通信を許可してください。

526は、自宅サーバーやNASでよく遭遇します。 自己署名証明書を使っている場合、SSLモードがFull (strict) だと検証に失敗します。Full に下げるか、Cloudflareが無料で発行するオリジン証明書を入れるのが正しい対処です。第1章のSSL/TLSとは？を参照してください。

1000番台（Cloudflare側の判断）

1020が出て自分のサイトに入れなくなるのは、WAFのカスタムルールや国別ブロックを設定した直後によくある事故です。慌てず、後述のSecurity Eventsで原因のルールを特定してください。

リダイレクトループ（ERR_TOO_MANY_REDIRECTS）

ブラウザに「リダイレクトが繰り返されました」と出る症状です。導入直後の代表的なトラブルで、原因はほぼSSLモードの設定です。

仕組みはこうです。SSLモードを Flexible にすると、CloudflareはオリジンへHTTPで接続します。ところがオリジン側に「HTTPで来たらHTTPSへリダイレクトする」設定があると、次のことが延々と繰り返されます。

1. ブラウザがHTTPSでCloudflareに接続する
2. CloudflareがHTTPでオリジンに接続する
3. オリジンが「HTTPSにしてください」とリダイレクトを返す
4. 1に戻る

対処は、SSLモードを Full か Full (strict) に変更することです。第8章のWordPressの接続でも触れたとおり、Flexibleは互換性のために残されている古い選択肢で、常用すべきではありません。

このほか、リダイレクトルールやPage Rulesどうしが衝突している場合もあります。設定したルールを一度すべて見直してください。

タイムアウトする（524）

Cloudflare経由のリクエストは、既定で125秒応答がないとError 524になります。

• 延長できるのはEnterpriseのみです。プランをProやBusinessに上げても変わりません
• 対処の方向は2つです。処理を非同期にする（実行はバックグラウンドに回し、すぐ応答を返して結果は後から取りに行く）か、その処理だけプロキシを通さない（DNS-onlyのサブドメインに逃がす）

重い処理をHTTPリクエストの中で完結させる設計そのものを見直す機会と考えるのが健全です。第5章のQueuesとWorkflowsは、まさにこの問題への回答です。

キャッシュが更新されない

「サイトを更新したのに古いままだ」という相談は非常に多いのですが、その多くはCloudflareのキャッシュが原因ではありません。

まず cf-cache-status を見る

応答ヘッダーを確認します。

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

主な値の意味です。

DYNAMIC や BYPASS が返っているなら、Cloudflareはキャッシュしていません。 それでも古い内容が見えるなら、原因はブラウザキャッシュか、オリジン側のキャッシュ（WordPressのキャッシュプラグインなど）です。

HTMLは既定でキャッシュされない

意外に知られていませんが、CloudflareはHTMLを既定ではキャッシュしません。キャッシュ対象は画像・CSS・JavaScript・PDFなど、拡張子で判断される静的ファイルです。

したがって「記事を更新したのに反映されない」場合、Cloudflareのキャッシュを疑う前に、WordPress側のキャッシュを疑うべきです。ただし、APOやCache Rulesで明示的にHTMLをキャッシュする設定をしている場合は別です。

消し方と、作業中の設定

• 単一ファイルのパージ：更新したファイルのURLを指定して消します。まずこれを試してください
• すべてパージ：全キャッシュを消します。オリジンへの負荷が一気に上がるため、常用は避けます
• Development Mode：3時間キャッシュを迂回します。サイトを改修している間に使う機能です。3時間で自動的に切れます

3時間以上キャッシュを止めたい場合は、Cache Rulesでバイパスを設定します。

逆に、キャッシュされては困るものがキャッシュされる

こちらの方が深刻です。ログイン後のページや会員向けのコンテンツがキャッシュされ、別の人に見えてしまう事故が起こり得ます。

Cache Rulesで「HTMLもすべてキャッシュする」といった設定を入れるときは、必ずログイン中のユーザーを除外する条件（Cookieの有無など）を組み合わせてください。設定した後は、必ずログアウト状態のブラウザで確認します。

自分がブロックされたとき

WAFやRate Limitingを設定した後に自分が締め出されるのは、誰もが一度は通る道です。

Ray ID から原因を特定する

Cloudflareのブロック画面には必ずRay IDが表示されています。これを控えて、ダッシュボードの Security → Events（Security Events）で検索してください。どのルールが、なぜ反応したかが1件ずつ記録されています。

原因が分かったら、次のいずれかで対処します。

• ルールの条件を修正する
• IP Access Rulesで自分のIPアドレスを許可する
• 該当ルールを一時的にログのみのモードに変える

闇雲に設定を戻すのではなく、必ずEventsで理由を確認してから直すのが鉄則です。理由が分からないまま緩めると、防御に穴が空きます。

調査に使う道具

まずは cf-ray・cf-cache-status・/cdn-cgi/trace の3つを覚えてください。これだけで、Cloudflareを通っているか、キャッシュされているか、どの拠点に届いているかが分かります。

導入前に確認しておくとよいこと

事故の多くは、切り替え前の準備で防げます。

• 現在のDNSレコードを一覧で控える：スクリーンショットでもテキストでもかまいません。自動スキャンは完全ではありません
• メール関連のレコードを把握する：MXと、それが指すホスト名。移行後もDNS-onlyであることを確認します
• レジストラ側のDNSSECを無効にする：変更前に必ず行います
• オリジンのファイアウォール設定を確認する：CloudflareのIPからの接続を許可します
• SSLモードは Full (strict) を目標にする：オリジンに正しい証明書を入れてから切り替えるのが理想です
• 切り替えは余裕のある時間に行う：反映に最大24時間かかることを前提にします
• 元に戻す手順を用意しておく：ネームサーバーを戻せば元の状態に復帰できます。この安心感が判断を落ち着かせます

初心者が注意するポイント

• エラー画面にRay IDがあるかを最初に見る：あればCloudflare、なければオリジン。これだけで調査範囲が半分になります
• 520番台はオリジン側を疑う：Cloudflareの設定画面をいくら探しても直りません
• 設定変更は1つずつ行う：まとめて変えると、何が効いたか分からなくなります
• キャッシュを疑う前にcf-cache-statusを見る：思い込みでパージを繰り返すのは時間の無駄です
• メールは最優先で確認する：Webサイトの不調は気づけますが、メールが届いていないことには気づけません。切り替え後は必ず送受信テストをしてください
• ブロックされたら理由を調べてから緩める：Security Eventsを見ずに設定を消すのは、原因不明のまま防御を外すのと同じです
• 公式ドキュメントを一次情報にする：Cloudflareは変化が速く、古い解説記事の手順が現状と合わないことがよくあります

関連サービス

• Cloudflareのプロキシとは？：オレンジ雲とグレー雲の使い分け
• SSL/TLSとは？：SSLモードと525・526の背景
• DNSとは？：レコードの種類と反映の仕組み
• CDNとは？：キャッシュの基本
• WAFとは？：1020の発生源
• WordPressをCloudflareに接続する手順：導入手順そのもの

まとめ

• トラブル対応の基本は、ブラウザ・Cloudflare・オリジンのどこで起きているかを切り分けること
• Ray IDの有無でCloudflareの応答かどうかが分かる。curl --resolve でオリジンに直接当てれば、原因の側が特定できる
• 導入直後に多いのは、DNSSECの消し忘れ、MX関連レコードのプロキシによるメール不達、レコードの取り込み漏れ
• 520〜527はオリジンとの通信の問題。521はオリジンのファイアウォール、526は証明書とSSLモードの不一致が代表例
• リダイレクトループの原因はほぼSSLモードのFlexible。Full以上に変更する
• 524は既定125秒。延長はEnterpriseのみで、設計側の見直しが本筋
• キャッシュを疑う前に cf-cache-status を確認する。HTMLは既定ではキャッシュされない
• ブロックされたらSecurity EventsをRay IDで検索し、理由を確認してから直す
• 切り替え前にDNSレコードを控え、DNSSECを無効にし、メールの経路を確認しておく

ガイドを読み終えた方へ

これで「Cloudflare完全ガイド」の全50ページは終わりです。

第1章でDNSとドメインの仕組みから始めて、CDN・プロキシ・SSLという土台を作り、Webセキュリティ、Zero Trust、ネットワークサービス、開発者向けプラットフォーム、ストレージ、AIと進み、第8章では実際に手を動かして7つのものを作りました。そして最後に、運用と費用と、うまくいかないときの対処を扱いました。

Cloudflareは、これからも新しいサービスを増やし、名前を変え、仕様を更新していきます。このガイドの内容も、いずれ古くなります。 けれども、DNSが名前をIPアドレスに変える仕組みも、プロキシが間に立つという構造も、キャッシュが持つ意味も、そう簡単には変わりません。土台を理解していれば、新しいサービスが出てきたときに「これはあの位置に入るものだ」と分かります。 このガイドが目指したのは、そういう理解の枠組みでした。

分からないことが出てきたら、目次から該当するページに戻ってきてください。辞典として使ってもらえれば幸いです。

次に読む

• Cloudflare完全ガイド（目次）
• Cloudflareプランの選び方（無料版でどこまでできるか）
• Cloudflareと他社サービスの比較

→ ガイドの目次に戻る

※本記事の情報は 2026年8月時点のものです。