SiteOps
トップメディアダッシュボード更新履歴
記事一覧

Cloudflare 525 SSL handshake failedのとき、最初の30分でやること

Cloudflare 525 SSL handshake failedが出たときに、最初の30分で「影響範囲の固定 → SSL/TLSモード確認 → オリジン証明書/到達性の切り分け」で止血するチェックリストです。

著者: 川原更新: 2026-05-17障害対応RSS
Xで共有FacebookLinkedIn
料金相談

Cloudflareで 525 SSL handshake failed が出たときは、まず「Cloudflare ↔ オリジン間のTLS（証明書/設定/到達性）」の問題として扱うのが最短です。

この記事は、525が出て「サイトが落ちた/一部だけ落ちた」状況になったとき、最初の30分で“止血”するチェックリストです。

関連:

  • /media/cloudflare-deploy-not-reflected-first-30-minutes
  • /media/search-console-server-error-5xx-first-30-minutes

0. まず結論（先にやる順番）

最初の30分は「直す」より「壊れている場所を確定する」を優先します。

  1. 525で確定（Cloudflare側のエラー番号・発生URL・発生率）
  2. 影響範囲を固定（全員/一部地域/一部URL/自分だけ）
  3. SSL/TLSモードとオリジン証明書の整合（Full/Full(Strict)・有効期限・SAN・チェーン）
  4. オリジン到達性の確認（443で応答するか、SNIで正しい証明書が出るか）
  5. 収束後に 再発防止（更新/監視/手順） を追加

1. 525で確定する（推理禁止）

まず「本当に525か」を確定します（似た症状でも原因が違います）。

  • ブラウザのエラー画面に 525 が出ているか
  • Cloudflareダッシュボードの Events / Analytics で、525が増えているか
  • もし可能なら curl -I <URL> を複数回実行し、再現率 を把握する

2. 影響範囲を固定する（最優先）

次を順に試して、影響範囲を固定します。

  • 別端末（スマホ/PC）で同じURLを見る
  • 別回線（モバイル回線）で見る
  • 別リージョン（VPNなどが使えるなら）で見る
  • 別URL（トップだけ/サブページだけ/特定パスだけ）で傾向を見る

「特定URLだけ525」なら、オリジンの 特定ルート/特定ホスト/特定証明書 の疑いが上がります。

3. CloudflareのSSL/TLSモードを確認する（最短で止血）

525は、CloudflareがオリジンとTLSハンドシェイクできないときに出ます。まずは設定の取り違えを疑います。

  • CloudflareのSSL/TLSモードが Full(Strict) のとき:
    • オリジン証明書が 有効期限切れ / ホスト名不一致 / チェーン不備 だと落ちます
  • CloudflareのSSL/TLSモードが Full のとき:
    • オリジン証明書が自己署名でも動く場合がありますが、結局はオリジン側TLSの不備が残ることがあります

判断の目安:

  • 直前で「証明書更新/失効/自動更新失敗/ドメイン追加/サブドメイン追加」をしていたら、まずここです

4. オリジンが443で“正しい証明書”を返せるか確認する

オリジン側でありがちな原因は以下です。

  • 443が開いていない（LB/Firewall/セキュリティグループ/プロキシ設定）
  • SNI の設定不備で、要求ホストと別の証明書が返っている
  • 証明書が更新されたが、片系だけ古い（複数台/複数AZ/複数オリジン）
  • 中間証明書（チェーン）が欠けている

確認のしかた（可能な範囲で）:

  • オリジン直叩きのヘルスチェックがあるなら、まずそれを見る
  • curl -Iv https://<hostname>/ でTLSハンドシェイクのエラー有無を見る（-k で誤魔化さず、まずは素で観測）

5. “今すぐ復旧”のための切り戻し候補

原因特定に時間がかかるときは、復旧優先の切り戻しを先に検討します（最初の30分の範囲）。

  • 直前の証明書変更を戻す（以前の証明書に復帰できるなら）
  • 直前のオリジン構成変更（LB/プロキシ/リバプロ）を戻す
  • Cloudflare設定の取り違え（対象ドメイン/Zone/ルーティング）を戻す

※ 恒久対応（証明書の自動更新や監視）は、止血後にやります。

6. 再発防止（30分の外）

復旧後に、次のどれかを最低1つ入れると再発率が下がります。

  • 証明書更新の 失敗検知（期限切れ前に通知）
  • 複数オリジン/複数台があるなら、更新の 反映漏れ検知（片系だけ古いを潰す）
  • 525が出たときの 復旧手順（誰が見ても同じ順番で確認できる）

状況が再現しない/原因が複合している場合は、相談だけ先に進めるのも有効です。

  • 料金・導入の概要を見る
  • 相談する

この記事を書いた人

川原

SiteOps編集チームの公開窓口として、検索、アクセス、収益データをもとにした運営判断の知見をまとめています。

著者情報

関連記事

Cloudflare 502 Bad Gatewayが出たとき、最初の30分でやること障害対応更新: 2026-05-18Cloudflare 504 Gateway Timeoutが出たとき、最初の30分でやること障害対応更新: 2026-05-18Cloudflare 520（Web server returned an unknown error）が出たとき、最初の30分でやること障害対応更新: 2026-05-18
前の記事Cloudflareへデプロイしたのに反映されないとき、最初の30分でやること次の記事Cloudflare 526 Invalid SSL certificateのとき、最初の30分でやること

次にやること

複数サイトの検索、アクセス、収益データをまとめて見直すなら、SiteOpsのダッシュボードでサイト別に確認できます。

料金を見る相談したい / お問い合わせ