CloudflareのSSL設定方法｜HTTPS化の失敗を防ぐ

2026年8月21日
Cloudflare

こんにちは。Osukeラーニング、運営者の「osuke」です。

CloudflareのDNS設定を終えたあと、SSL/TLS画面で「Flexible」「Full」「Full (strict)」のどれを選ぶべきか迷いませんか。HTTPSの鍵マークが出ていても、訪問者からCloudflareまでしか暗号化されていない場合があります。反対に、よく分からないままFull (strict)へ変更すると、525や526エラーでサイトが開けなくなることもあります。

この記事では、CloudflareのSSL設定を安全に進める順番を、証明書の仕組み、暗号化モード、HTTPS強制、525・526、リダイレクトループ、HSTSまで解説します。osuke本人の体験としては書かず、2026年8月21日時点のCloudflare公式資料と、Xで公開された利用者8件の成功・失敗・反対事例を照合しました。X投稿は各投稿者の体験に関する一次情報であり、Cloudflare全体の仕様は公式資料を優先しています。

まだネームサーバーやA・CNAMEを確認していない場合は、先にCloudflareのDNS設定方法を済ませてください。アカウント登録から確認したい方はCloudflareの始め方、サービス全体を知りたい方はCloudflareとは何かを解説した記事から読むと流れがつながります。

記事のポイント

訪問者→CloudflareとCloudflare→元サーバーの2区間を確認する
元サーバーの証明書を整えてFull (strict)を選ぶ
HTTPSが安定してからAlways Use HTTPSを有効にする
525と526、リダイレクトループを別々に切り分ける
HSTSは全ホストのHTTPS確認が終わるまで有効にしない

CloudflareのSSL設定とHTTPS化の手順

安全なHTTPS化は、SSLモードのスイッチを押す作業だけではありません。エッジ証明書と元サーバー証明書を区別し、2本の接続が暗号化される構成を作ってから、HTTPをHTTPSへ転送します。順番どおり進めれば、エラーが出ても変更箇所を特定できます。

Universal SSLの仕組みを理解する

Cloudflareを経由する通信は、「訪問者のブラウザ→Cloudflare」と「Cloudflare→元サーバー（オリジン）」の2区間に分かれます。Universal SSLは主に前半でCloudflareが提示するエッジ証明書です。ブラウザの鍵マークは前半のHTTPSを確認できますが、それだけでは後半も暗号化・検証されているとは限りません。後半の安全性は、元サーバーの証明書とSSL/TLS暗号化モードで決まります。

Cloudflare公式のUniversal SSL有効化資料によると、一般的なフルDNS設定ではドメインがActiveになってから通常15分〜24時間で証明書が自動発行されます。対象はルートドメインのexample.comと、www.example.comやblog.example.comのような第1階層サブドメインです。証明書自体はDNS onlyのレコードがあっても用意されますが、Cloudflareが証明書を提示するのは対象レコードがProxied、つまりオレンジ色の雲になっているときです。

Xでは、深いサブドメインで証明書が有効になった理由を疑問視する公開投稿がありました。これは利用者が混乱しやすい論点を示しています。通常のUniversal SSLだけに頼るフルDNS設定では、dev.blog.example.comのような第2階層以降は対象外です。一方、Workersのカスタムドメインなど別の証明書発行機能が関わる構成もあるため、深いサブドメインで鍵が出たことだけを見てUniversal SSLの仕様を一般化しないようにします。

最初にCloudflareの「SSL/TLS」→「Edge Certificates」を開き、Universal SSLの状態がActiveか確認してください。Pendingなら暗号化モードやリダイレクトを何度も変えず、ドメインがActiveか、CAAレコードが証明書発行を妨げていないか、最大24時間が経過したかを確認します。急いでFlexibleへ下げると、本来は証明書発行待ちだった問題へ別の設定問題を重ねることになります。

最初に区別する2つの証明書

エッジ証明書：訪問者とCloudflareの間で使用
オリジン証明書：Cloudflareと元サーバーの間で使用
Universal SSLの目安：Active後15分〜24時間
通常の対象：ルート＋第1階層サブドメイン
Cloudflareから提示する条件：DNSレコードがProxied

暗号化モードの違いを確認する

SSL/TLS暗号化モードは、2区間のうち特にCloudflareから元サーバーへどう接続するかを決めます。Offは両区間を暗号化せず、Flexibleは訪問者からCloudflareまでだけHTTPS、Fullは元サーバーまでHTTPSにするものの証明書を検証しません。Full (strict)は元サーバーまで暗号化し、証明書の期限、発行元、ホスト名まで検証します。

Cloudflare公式の暗号化モード一覧は、可能ならFullまたはFull (strict)を使うよう推奨しています。ログイン、問い合わせフォーム、会員情報などを扱うサイトでFlexibleを使うと、ブラウザにはHTTPSと表示されても後半がHTTPのままです。元サーバーがSSL/TLSに対応できるなら、最終目標はFull (strict)です。

ただし、Full (strict)は「最も強そうだから先に選ぶ」のではなく、元サーバーの準備後に選びます。証明書がない状態なら525、証明書はあっても期限切れ・ホスト名不一致・中間証明書不足などで検証できなければ526が起きる可能性があります。共有レンタルサーバー、VPS、Vercelなど接続先ごとに証明書の用意方法が違うため、ホスティング会社の独自ドメイン手順も確認してください。

現在のモードを変更する前に、画面のスクリーンショット、変更時刻、元サーバーの証明書状態を記録します。Automatic SSL/TLSが表示されている場合も、元サーバー証明書を継続管理する責任は残ります。公式資料では自動アップグレードは1%のトラフィックから段階的に検査し、失敗時に戻す仕組みが説明されていますが、期限切れ証明書を自動で安全性の低いモードへ下げる機能ではありません。

モード	訪問者→Cloudflare	Cloudflare→元サーバー	証明書検証	用途・注意
Off	HTTP	HTTP	なし	安全な公開サイトには使わない
Flexible	HTTPS可	HTTP	なし	元サーバーがTLS非対応の一時用途
Full	HTTPS	HTTPS	しない	自己署名など検証できない証明書向け
Full (strict)	HTTPS	HTTPS	期限・CA・ホスト名を検証	元サーバー準備後の推奨構成

鍵マークだけで安全と判断しない

Flexibleでも訪問者側にはHTTPSが表示されます。個人情報やログインを扱うサイトは、元サーバーまで暗号化されるFull系を選び、可能なら証明書を検証するFull (strict)へ進めてください。

Full strictを安全に設定する

Full (strict)へ切り替える前に、元サーバーがHTTPSの443番ポートで応答することを確認します。証明書は有効期間内で、公開認証局またはCloudflare Origin CAが発行し、アクセスするホスト名がCommon NameまたはSubject Alternative Nameに含まれている必要があります。中間証明書を含むチェーンも正しく配信されなければなりません。

Full (strict)の公式要件では、これらを満たさない場合に526が起きる可能性が明記されています。レンタルサーバーやマネージドホスティングでLet’s Encrypt等が有効なら、その証明書を使える場合があります。VPSでCloudflare以外から元サーバーへ直接アクセスさせない構成なら、Origin CAをインストールする方法もあります。ただしOrigin CA証明書は一般のブラウザから直接信頼されないため、Cloudflareを一時停止して直接表示する運用には向きません。

Xでは、AレコードをProxiedにし、Full (strict)とCloudflareのIPだけを許可するファイアウォールを組み合わせたVM構成の公開例がありました。これは後半まで暗号化し、元サーバーの露出を絞る一例です。ただし、同じファイアウォールをそのままコピーすると、CloudflareのIP帯更新や管理用接続を考慮できず停止する恐れがあります。投稿者の成功例は考え方の参考とし、実装はホスティング環境の手順へ合わせます。

切り替えはアクセスの少ない時間に行い、まず1つのホストで元サーバー証明書を確認してからCloudflareのOverviewでFull (strict)を選びます。直後にトップページだけでなく、www、管理画面、フォーム、APIなど主要5経路を確認してください。526が出た場合、すぐFlexibleへ下げて隠すのではなく、証明書の期限、ホスト名、チェーン、443を直すのが本来の解決です。

Full (strict)切り替え前の5条件

元サーバーの443番ポートが応答する
証明書が期限内で失効していない
公開CAまたはCloudflare Origin CAが発行
CNまたはSANが対象ホスト名と一致
中間証明書を含むチェーンが完全

Always Use HTTPSを有効にする

Full (strict)で主要URLが正常に開くことを確認したら、次にHTTPアクセスをHTTPSへ統一します。Cloudflareの「SSL/TLS」→「Edge Certificates」でAlways Use HTTPSを有効にすると、対象ゾーンの全ホストへ来たHTTPリクエストをHTTPSへ転送できます。先にエッジ証明書がActiveで、暗号化モードがOff以外になっていることが前提です。

Always Use HTTPSの公式資料は、元サーバー側で同じ転送を重ねるとリダイレクトループの原因になるため、Cloudflare側で行うことを推奨しています。WordPressプラグイン、レンタルサーバーの常時SSL、.htaccess、Cloudflare Redirect Rulesの複数箇所に同じ規則がないか確認し、HTTPS強制の担当を1か所へ寄せます。

有効化後は、アドレスバーへhttp://example.comを直接入力し、https://example.comへ1回の転送で到達するか確認します。ルートからwwwへ正規化する場合でも、「HTTP→HTTPS」と「www有無」の2回程度に収まり、同じURL間を往復しないことが大切です。ログインページやフォームだけHTTP対応の古い構成が残るなら、ゾーン全体で有効化せず、先にそのページを改修します。

Always Use HTTPSはページ内の画像・CSS・JavaScriptに残ったhttp://を修正する機能ではありません。トップページがHTTPSへ転送されても、内部資源がHTTPなら混在コンテンツ警告が残ります。WordPressではサイトURLとホームURL、テーマ、プラグイン、データベース内の古いURLを確認し、転送と資源の書き換えを別作業として考えてください。

HTTPS強制の安全な順番

Universal SSLがActive
Full (strict)で主要ページが正常
重複するリダイレクト規則を整理
Always Use HTTPSを有効化
HTTPからHTTPSへ1回で進むか確認

証明書とHTTPS表示を確認する

設定後の確認はトップページ1枚で終わらせません。最低でもルートドメイン、www、代表的なサブドメイン、WordPress管理画面、robots.txtの5種類を開きます。各URLで証明書エラーがなく、最終URLが意図したHTTPSになり、CSSや画像が崩れず、フォーム送信やログインが動くことを確認します。

Xでは、WordPressとCloudflareの構成でrobots.txtがSSL設定由来のリダイレクトループになり、Full (strict)への変更で直ったという公開事例がありました。利用者がトップページだけ見ていたら、検索エンジン向けファイルの問題を見逃した可能性があります。これは投稿者の環境での結果ですが、確認対象にrobots.txtやサイトマップを含める有用性を示しています。

証明書の詳細では、対象ホスト名、有効期限、発行元を確認します。Cloudflareのエッジ証明書が正常でも、元サーバー証明書はブラウザから直接見えにくいため、ホスティング管理画面やサーバー管理者の検査結果も使います。変更時刻と525・526が出た時刻を記録しておくと、サーバーログから該当するTLS接続を探しやすくなります。

最後に、スマートフォン回線とWi-Fi、シークレットウィンドウなど2種類以上の環境で確認します。HSTSや古い301転送がブラウザに保存されていると、自分の通常ブラウザだけ過去の動きを続けることがあります。HTTPステータス、最終URL、証明書、ページ機能の4点を表に記録すれば、「表示できた」という曖昧な判定を避けられます。

HTTPS化の確認対象

ルートドメインとwww
主要サブドメイン
管理画面・ログイン・フォーム
robots.txtとサイトマップ
CSS・JavaScript・画像の混在コンテンツ

CloudflareのSSL設定で失敗しない方法

エラーが起きたら、SSLモードを何度も往復させるのではなく、表示された番号と直前の変更を記録します。525、526、Too Many Redirects、混在コンテンツは原因が違います。ここでは症状ごとの確認順を整理します。

526・525エラーを切り分ける

525は、Cloudflareと元サーバーのSSLハンドシェイクが成立しなかった状態です。FullまたはFull (strict)で発生し、主な候補は元サーバーに証明書がない、443番が閉じている、SNIに対応していない、Cloudflareと共通の暗号スイートがない、接続が途中でリセットされた場合です。公式の525手順は、発生時刻のサーバーログと証明書の設置を確認するよう案内しています。

526は、Full (strict)でCloudflareが元サーバー証明書を検証できない状態です。公式の526手順に沿い、期限切れ、失効、自己署名、ホスト名不一致、証明書チェーン不足、443番の応答を確認します。つまり525はTLS接続そのもの、526は接続先が提示した証明書の検証を中心に調べると、確認範囲を整理できます。

Xでは、第三者サイトの検索でCloudflareの検証後に525を観測した投稿と、VPSからAWSへ移行する過程で526へ対応した公開投稿がありました。前者は利用者が目にする症状例、後者は移行時の発生例ですが、いずれも投稿だけでは技術的原因を確定できません。エラー番号を見た事実と、原因を特定した事実を分けることが重要です。

復旧を急いで526からFullへ一時的に下げる方法は、証明書検証を省略するため表示が戻る可能性があります。しかし根本原因を残すため、恒久策にはしません。最初に変更時刻、Ray ID、対象ホスト、発生頻度を保存し、ホスティング会社へ証明書・SNI・443・TLSログを確認してもらいます。1回だけか断続的かでも、証明書不備と負荷・接続リセットの見立てが変わります。

エラー番号で確認先を分ける

525：443、証明書設置、SNI、暗号スイート、TLSログ
526：期限、失効、CA、CN/SAN、証明書チェーン
両方：発生時刻、対象ホスト、Ray ID、変更履歴を保存
一時的なモード低下を恒久策にしない

リダイレクトループを直す

ブラウザの「Too Many Redirects」は、URL AからB、BからAへ転送が戻り、同じ経路を繰り返す状態です。代表例はCloudflareがFlexibleで元サーバーへHTTP接続し、元サーバーがHTTPをHTTPSへ戻す組み合わせです。Cloudflareは再びHTTPで元サーバーへ接続するため、転送が終わりません。元サーバーがHTTPSに対応するならFull以上へ変更し、HTTPS強制の担当を整理します。

Cloudflare公式のリダイレクトループ資料では、Full系なのに元サーバーがHTTPSをHTTPへ戻す逆方向の衝突や、Cloudflare Redirect Rules・Page Rules同士の競合も原因として挙げています。WordPressのURL設定、常時SSLプラグイン、レンタルサーバーの転送、.htaccessを含め、「誰がどのURLへ転送しているか」を1本の経路図にします。

Xでは、CloudflareのドメインをVercelへ接続した際、FlexibleからFull (strict)へ変えてループを解消した公開例があります。一方、Shopifyストアのループを調べた結果、CloudflareとSSLは正常で別設定を無効化して直った反対事例もありました。この2件から、Full (strict)が有効なケースはあるものの、すべてのループをSSLモードのせいにできないと分かります。

切り分けでは、Cookieを消す前にHTTP応答の転送先を記録し、HTTP→HTTPS、wwwなし→ありなど各規則を1つずつ確認します。WordPressなら「WordPressアドレス」と「サイトアドレス」もHTTPSへ揃え、プラグインを一時停止する場合は1つずつ行います。設定を同時に3個変えると、直っても原因が分からず、次回更新時に再発します。

ループを止める確認順

現在の暗号化モードを記録
HTTPとHTTPSの転送先を確認
CloudflareのRedirect Rulesを確認
ホスティング・WordPress・アプリ側の転送を確認
1項目ずつ変更して再テスト

サブドメインと混在コンテンツを確認する

ルートドメインに鍵が出ても、すべてのサブドメインが同じ証明書で守られるとは限りません。一般的なフルDNS設定のUniversal SSLは、ルートと第1階層サブドメインを対象にします。app.example.comは対象ですが、dev.app.example.comのような深い名前は通常の対象外です。さらに、DNSレコードがDNS onlyならCloudflareではなく接続先サーバーが証明書を提示します。

Universal SSLの公式制限では、深いサブドメインへTotal TLSやAdvanced Certificateを検討する方法が案内されています。料金や機能を追加する前に、深い階層が本当に必要かも見直してください。dev-app.example.comのように第1階層へ設計し直せるなら、証明書管理を単純化できる場合があります。

証明書が正常なのに鍵マークやページ表示へ警告が残る場合は、混在コンテンツを確認します。HTTPSページがHTTPの画像、CSS、JavaScript、iframeを読み込むと、ブラウザは一部を遮断します。Automatic HTTPS Rewritesの公式説明によると、HTTPSでも取得できるHTTP参照を自動変更できますが、JavaScriptやCSS内の参照、HTTPS非対応の外部資源などは直らない場合があります。

WordPressではデータベース内の古い画像URL、テーマのCSS、広告・地図・動画の埋め込みを確認します。自動書き換えを有効にして警告が消えても、元データをHTTPのまま放置しないほうが保守しやすくなります。ブラウザの開発者ツールでMixed Contentと表示された正確なURLを一覧にし、相対URLまたはHTTPSへ修正してください。

サブドメイン・混在コンテンツの確認

Universal SSLは通常ルート＋第1階層
深いサブドメインは別証明書または名前設計を検討
DNS onlyでは接続先の証明書を確認
自動書き換えで残るHTTP資源は手動修正

HSTSを有効にする前に確認する

HSTSは、対応ブラウザへ「このドメインは今後必ずHTTPSで開く」と記憶させるHTTPヘッダーです。HTTPへのダウングレード攻撃を防げますが、SSL設定を試している途中で有効にする機能ではありません。ブラウザが方針を保存した後に証明書を無効化すると、利用者は警告を無視してHTTPへ逃げることもできず、サイトへ入れなくなる可能性があります。

Cloudflare公式のHSTS資料は、有効化後にCloudflareを一時停止する、ProxiedからDNS onlyへ変える、ネームサーバーを外す、HTTPSをHTTPへ戻す、証明書を失効させる行為へ注意を促しています。HTTPSを先に外すと、設定したMax Ageが切れるまでアクセス不能が続く恐れがあります。

最初はルート、www、使用中の全サブドメイン、管理画面、API、メール用Web画面などがHTTPSで安定しているか確認します。includeSubDomainsを有効にすると、親ドメインの方針が全サブドメインへ及びます。HTTPS非対応の古いホストが1つでも残るなら有効にしません。Preloadはブラウザ配布リストへ組み込む仕組みで、取り消しに時間がかかるため、通常のMax Age検証よりさらに後です。

導入する場合は、短いMax Ageから始め、更新・障害対応・Cloudflare移行時にもHTTPSを維持できる運用を確認してから延ばします。Cloudflare画面では1〜12か月を選べ、Preload申請には少なくとも12か月が必要です。強い設定を一度にONにするのではなく、HTTPSの稼働実績を積み、サブドメインの棚卸しと証明書更新通知を整えてから進めます。

HSTSをまだ有効にしない条件

証明書やリダイレクトを調整中
DNS onlyやCloudflare一時停止の予定がある
HTTPS非対応のサブドメインが残る
証明書更新と障害時の運用が未確立
includeSubDomains・Preloadの影響を確認していない

CloudflareのSSL設定を完了する

CloudflareのSSL設定は、エッジ証明書Active、元サーバー証明書、Full (strict)、HTTPS強制、混在コンテンツ修正、最後にHSTSという順番で完成させます。今回確認したX投稿群では、Full (strict)でVM、Vercel、WordPressの問題を解決・運用した例がある一方、リダイレクト原因がCloudflare外だった反例もありました。特定の設定を万能薬として扱わないことが、停止を避ける近道です。

作業記録には、変更前後のSSLモード、変更時刻、対象ホスト、エッジ証明書状態、元サーバー証明書の期限、HTTPからの転送回数、エラー番号を残します。問題が起きたときは直前の1変更へ戻り、525ならTLS接続、526なら証明書検証、ループなら転送規則、警告なら混在コンテンツという順に確認してください。

今日できる最初の一歩は、SSL/TLS Overviewを開き、現在のモードを記録することです。次にEdge CertificatesがActiveかを見て、ホスティング管理画面で元サーバー証明書の有効期限と対象ドメインを確認します。この3点をそろえるまで設定を変えなければ、現在地を失わずにFull (strict)へ進められます。

HTTPS化が安定したら、次はCloudflareのキャッシュをWordPressへ合わせ、表示速度を改善します。SSLとDNSが未完成のままキャッシュ設定を始めると、古い転送やエラーページが残って切り分けが難しくなります。まず以下の10項目を完了し、24時間問題がないことを確認してから高速化へ進んでください。

Cloudflare SSL設定の最終チェック