【実録】Cloudflare初心者が陥る「4つの設定ミス」サイト停止を防ぐためのチェックリスト

ウェブサイトの高速化やセキュリティ向上に欠かせない「Cloudflare」。しかし、強力なツールであるがゆえに、初期設定時のわずかな勘違いが「サイトが表示されない」「ログインできない」といったトラブルを招くケースが後を絶ちません。

本稿では、初心者が特にはまりやすい4つの設定ミスとその対策を解説します。

1. 「危険なサイト」の罠：SSL/TLS設定不良
1. 「リダイレクトループ」の罠：SSL/TLS設定の重複
番外編１：Cloudflrareを使ったらOGPが死んだ？！
1. Xは最小TLSバージョンが１.3になると通信不可になる
番外編２:CDNが機能してない？！
最後に：Cloudflareを使いこなすための3原則

1. 「危険なサイト」の罠：SSL/TLS設定不良

Cloudflrareを初めて使ってたときに自分でサイトにアクセスしようとしたら真っ赤な警告で、「危険なサイト」と表示されたことはありませんか？

この表記は、お使いのブラウザーが接続先のサイトでHTTPS（HTTP/Secure）と呼ばれる暗号化通信ができない＝平文通信になっている時に表示される警告です。

このまま、ユーザー情報を送信するとすべての送信内容が筒抜けになりCookieなどに記録される個人情報がすべてログなどに人間が読める状態で保存され悪用されるリスクを伴います。

考えれる原因

有効なSSL証明書がUniversalSSLで発行されていない
UniversalSSLのセキュリティレイヤーレベル設定ミス
Origin Certificateがインストールされていない

有効なSSL証明書がUniversalSSLで発行されていない

Cloudflareを導入する最大のメリット、それは「Universal SSL」の存在です。これはCloudflareがLet’s Encrypt等と連携し、ドメインに対してSSL証明書をオンデマンドで自動発行・更新してくれるサービスです。

極論、「この機能があるからこそCloudflareを使う」というユーザーも多いはず。しかし、この便利すぎる機能こそが、初心者を混乱させる原因にもなります。

Universal SSLは全自動ですが、魔法ではありません。以下の「前提条件」が崩れると、ブラウザには真っ赤な警告が表示されます。

「発行待ち」の数分間が耐えられない: ボタンを押した瞬間に世界中のエッジサーバーに証明書が配備されるわけではありません。ステータスが「Active（有効）」になる前にHTTPSでアクセスすると、ブラウザは「正しいコモンネームの証明書は無い」と判断し、容赦なく警告を出します。

しかし、この程度は数分で解決することが多いです。それでも解決しない場合はネームサーバーの変更の伝播待ちなので「24時間～72時間」待機で解決することが多いです。

CAAレコードでLet’ｓEncryptからの証明書発行を明示的に制限していると発行完了までさらにタイムラグが発生することになります。

UniversalSSLのセキュリティレイヤーレベル設定ミス

次によくあるのがUniversalSSLのセキュリティレイヤーレベル設定ミスです。UniversalSSLにはおいては、「Flexible」「Strict」「Strict/Full」の３段階があります。

Flexible・・・柔軟性の高いセキュリティレイヤー
Strict・・・高度なセキュリティレイヤー
Strict/Full・・・よりセキュアなセキュリティレイヤー

Flexibleでは、クライアント（エンドユーザーのブラウザーとCDN間の通信を暗号化するまでに留めるため。オリジン（コンテンツを提供する側）のサーバーの暗号化通信を求めてこない、最悪の場合オリジンにHTTPS暗号通信機能が無くても暗号化通信が提供できる。

これがまさにCloudflrareを使う唯一無二のメリットです。

Origin Certificateがインストールされていない

Strictは、CloudflrareプロキシとブラウザーさらにCloudflrareのCDNとオリジンサーバー間のエンドツーエンドの暗号化を行うレベルの設定です。CloudflrareのCDNとオリジンサーバー適切に暗号化通信を行えるようにするために信頼された発行機関から発行されるSSL証明書がオリジンサーバー内にインストールされている必要があります。

Strict/Fullは、CloudflrareプロキシとブラウザーさらにCloudflrareのCDNとオリジンサーバー間のエンドツーエンドの暗号化をCloudflrareが発行するOrigin Certificateを用いて行うレベルの設定です。Origin Certificateとはオリジン認証用の証明書で信頼されていないCAであるためSSL証明書を柔軟にコントロールできるCpanleなどの備わっているサーバーでないと実装は困難です。

Strict/Fullは使えれば完全ななりすまし（コンテンツ偽装）をCDNとの間で防ぐことができますがその分サーバーの自由度を求められるためよっぽどのことが無ければStrictで十分高いセキュリティレイヤーを実現することができます。

Origin Certificateが無い状態でStrict/Fullを選択するとエンドツーエンドの暗号化に失敗しクライアントとのCDNの暗号化通信も制限され危険サイトエラーになります。
「チェインオブトラストの崩壊」

1. 「リダイレクトループ」の罠：SSL/TLS設定の重複

証明書問題を解決して、サイトが開けるかな・・・と安堵していた矢先に襲いかかってくる第二のエラー「ERR_TOO_MANY_REDIRECTS」直訳でリダイレクトの過多という意味ですが、これはブラウザーが許容できるリダイレクトチェーンを超えてリダイレクトが発生したことでブラウザーがリクエストを放棄したときに発生させる一種の例外処理です。

ここで説明に従ってCookieを消すとGoogleなどの普段お使いのWebサービスの認証情報などまとめてすべてが無に帰しユーザーセッションが空になるためすべてのサービスで再ログインが必要になります。

考えれる原因

不必要なHSTS設定
Cloudflrare SSL設定との競合「バッティング」
純粋なリダイレクトミス

不必要なHSTS設定

Cloudflareのダッシュボードには、サイトへの接続を強制的にHTTPS化する「HSTS」という強力なスイッチがあります。しかし、この設定を安易にオンにすることは、時に自分の首を絞めることになります。

HTTP Strict Transport Security（HTTPストリクト・トランスポート・セキュリティ）いわゆる常時HTTPSは有効化するとGoogleのプリロードリストと呼ばれるものに登録できてブラウザーが事前読み込みに対応してくれるようになるため閲覧を含めたUXの向上につながるが・・・

まともにHTTPSサイトへのリダイレクトが機能しない状態でこれを有効にするとリダイレクトループが発生し、HTTP→HTTPS→HTTP→HTTPS→・・・ERR_TOO_MANY_REDIRECTSとなってしまうだけでなくHTTP Strict Transport Securityが有効なのでHTTPでのアクセスはできないと言う追加メッセージをもらうことになる。

正直な話・・・HSTSPreloadはそれほどページスピードに影響しないのでやるのであればQUIC（HTTP/3）対応やBrotli圧縮、WebP/AVIF、DNSプリフェチ・プリコネクトをお勧めします。

Cloudflrare SSL設定との競合「バッティング」

Cloudflrare SSL設定にはHSTSと類似して勘違いしやすい常時SSLリダイレクトという設定があるこれは、HTTPでのアクセスをHTTPSへリダイレクトしなさいと言う301リダイレクトレスポンスをCloudflrare CDNに配信させる設定です。

つまりサーバーの.htaccessに書き込む

# BEGIN Redirect to https
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{ENV:HTTPS} !on
RewriteCond %{HTTP:X-Forwarded-Proto} http
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>
# END Redirect to https

がCloudflrareから配信されている状態・・・

これがサーバーの設定とバッティング「競合すると・・・」

HTTPリクエスト→HTTPSへリダイレクト→HTTPSへリダイレクト・・・とHTTPSリクエストではなくリダイレクトが連鎖することになりERR_TOO_MANY_REDIRECTSとなってしまう。

💡 運用のベストプラクティス

どちらか一方に任せる: Cloudflareの「常にHTTPSを使用」をオンにするなら、サーバー側のリダイレクト設定はオフにするのが最もシンプルで安全です。

３．純粋なリダイレクトミス

Cloudflareの設定画面を離れ、WordPressの管理画面内で完結するはずの操作が、実はサイトをダウンさせる最大の引き金になることがあります。その代表例が、「Really Simple SSL」などのSSL化補助プラグインによる設定重複です。

これらのプラグインは本来、サーバーが直接インターネットからのアクセスを受ける「標準的な環境」を想定して設計されています。しかし、Cloudflare（プロキシ）が間に立つことで、プラグインの検知ロジックが狂い、自ら無限ループの渦に飛び込んでしまうのです。

通常、サイトが暗号化されているかどうかは、サーバーが受け取る通信プロトコルで判断されます。

Cloudflare（Flexibleモード）利用時:
1. ユーザー ↔ Cloudflare間は HTTPS
2. Cloudflare ↔ サーバー間は HTTP このとき、WordPress側のプラグインは「サーバーに届いた通信がHTTPである」ことだけを見て、「まだSSL化されていない！HTTPSへ強制転送（301リダイレクト）だ！」と判断してしまいます。

Really Simple SSL」を有効化すると、プラグインはサイトを守るために以下の処理を自動で行います。

.htaccess への強制書き込み: Webサーバーの最下層で「HTTPならHTTPSへ飛ばせ」という命令を固定します。
PHPレベルでの転送: WordPressが立ち上がる瞬間に、再度HTTPSへのチェックを行います。
Cloudflareとのバッティング: Cloudflare側でも「常にHTTPSを使用」をオンにしていると、エッジサーバー（Cloudflare）とオリジンサーバー（WordPress）が互いに「相手にHTTPSで送り直せ」と命令を投げ合うことになり、ブラウザには ERR_TOO_MANY_REDIRECTS が表示されます。

番外編１：Cloudflrareを使ったらOGPが死んだ？！

Cloudflareを導入して「さあ記事をシェアしよう！」とSNSにURLを貼った瞬間、アイキャッチ画像が表示されず、タイトルも真っ白……。この「OGP（Open Graph Protocol）消失事件」は、Cloudflareの強力な保護機能が裏目に出た典型的なトラブルです。

なぜ「守護神」であるはずのCloudflareが、SNSからのアクセスを拒絶してしまうのか。

答えは単純最小TLSバージョンの上げ過ぎ

Xは最小TLSバージョンが１.3になると通信不可になる

SNS（X、Facebook、Discordなど）に記事をシェアした際、アイキャッチ画像（OGP）が出ない原因として「ボット対策」や「キャッシュ」を疑う人は多いですが、実はもっと深い階層、「TLSバージョン（暗号化の世代）」に原因があるケースが増えています。

Cloudflareの「SSL/TLS」設定内には、「最小TLSバージョン」を指定する項目があります。

理想: 「古い脆弱な規格（TLS 1.0 / 1.1）は排除して、最新の TLS 1.3 だけを許可しよう！」
現実: X（旧Twitter）などのクローラーは、TLS 1.3 に完全対応していない、あるいは接続に失敗するケースが報告されています。

Xのクローラー（Twitterbot）は、効率的に世界中のサイトを巡回するために特定のライブラリを使用していますが、これが最新の TLS 1.3 特有の挙動（1-RTT ハンドシェイクなど）と相性が悪い、あるいはサーバー証明書の提示順序でエラーを起こすことがあります。

現象: クローラーがサイトに接続しようとする → Cloudflareが「TLS 1.3 以外はダメ」と拒絶、または握手に失敗 → クローラーは「サイトが存在しない、またはアクセス不能」と判断 → OGPが真っ白に。

「最新が最強」なのは間違いありませんが、Webメディアにおいて「SNSでシェアされること」は生命線です。

推奨設定: 最小TLSバージョンは 「TLS 1.2」 に留めておくのが、2026年現在のベストプラクティスです。
- TLS 1.2 であれば、主要なSNSクローラーとの互換性を保ちつつ、十分な安全性を確保できます。
- TLS 1.3 も「有効」にはしておき、対応している最新ブラウザには 1.3 で、古いクローラーには 1.2 で、と「出し分け」をCloudflareに任せるのが正解です。

番外編２:CDNが機能してない？！

「せっかくCloudflareを入れたのに、PageSpeed Insightsのスコアが変わらない」「サーバーの負荷が減っていない」……。実のところ、Cloudflareを「導入したつもり」で、実際にはただの「高機能なDNS管理ツール」としてしか使えていないケースが非常に多いのです。

Cloudflrareとは？

今更かもしれませんがCloudflrare自体がど言う存在か理解できていますでしょうか？

Cloudflrareとは、

Akamai級のロードバランシングが比較的安価で行える
セキュアな
持続化のなインフラ提供を行う会社です。

Cloudflrareが提供する製品・サービスには、

CDN「コンテンツ配信ネットワーク」
DNS「コンテンツネームサーバー」
WAF「ウェブアプリケーション向けファイアウォール」

ウェブサイドで以上の3つがあります。

Cloudflareの管理画面にある「DNSレコード」の設定。ここに、CDNとして機能するかどうかの運命を分ける「雲のアイコン」が存在します。

1. 「オレンジ」か「灰色」か、それが問題だ

DNS設定画面で、各レコードの右側に表示される雲のアイコンを確認してください。

オレンジの雲（Proxied）: 通信がCloudflareのエッジサーバーを経由します。CDN機能、WAF、SSL最適化、Brotli圧縮などがすべて有効になります。
灰色の雲（DNS only）: Cloudflareは単なる「電話帳（DNS）」として振る舞うだけで、通信は直接あなたのサーバーへ飛びます。CDNとしての恩恵はゼロです。

2. なぜ「灰色」になってしまうのか？

初心者が陥りやすい、意図しない「プロキシ無効化」の原因は主に2つです。

「Aレコード」以外もオレンジにしようとした: 基本的に、Webサイトの通信（AレコードやCNAME）以外（例：MXレコードやFTP用のサブドメイン）は、プロキシを通すと通信エラーになるため、Cloudflareが自動で灰色にします。これを混同して、肝心のドメインまで灰色にしてしまうミスが絶えません。
SSHやFTPの接続エラーを嫌った: プロキシをオンにすると、サーバーの本当のIPアドレスが隠されます。そのため、FTPソフトなどで「ドメイン名」で接続できなくなり、不便を感じて「一旦オフ（灰色）」にしたまま忘れてしまうケースです。

3. 「キャッシュ」の定義ミス：静的ファイルしか冷やさない

雲がオレンジ色でも、デフォルトの設定では「HTML」はキャッシュされません。

標準の挙動: 画像（jpg/png）、CSS、JSなどの「静的ファイル」だけをキャッシュします。
罠: WordPressなどの動的サイトでは、最も重い「HTML（PHPの実行結果）」が毎回サーバーまで取りに行かれるため、体感速度が改善しないのです。
解決策: 「キャッシュルール（Cache Rules）」を作成し、特定の条件下でHTMLもキャッシュさせる（いわゆる「エッジキャッシュ」）設定を組む必要があります。

最後に：Cloudflareを使いこなすための3原則

「待つ」ことも設定の一部: DNSや証明書の反映には時間がかかります。焦って設定をいじり倒さないこと。
「雲」は障害時を除いてオレンジに：SSL設定のミスなど障害でDNSネームサーバーとして動作させたいとき以外は常にオレンジにしておかないとCDNとして機能しません。
HSTSよりも高速化: セキュリティスコアのためにHSTSを急ぐより、HTTP/3、Brotli、画像最適化、DNSプリフェッチを先に導入しましょう。
Cookie削除は慎重に: デバッグ時にブラウザのCookieを全削除すると、Googleなどの他サービスからもログアウトされ、二段階認証の嵐に巻き込まれます。「そのドメインのCookieだけ」消す術を覚えましょう。

あなたのCloudflrareライフがより快適になることをお祈りしております。