Japan Server Error Fix Lab

ホーム / Cloudflare / Cloudflare

Cloudflare SSL 525 handshake failed

Cloudflare とオリジンサーバー間の TLS 接続に失敗したときに発生する代表的な SSL エラーです。

high5258 分で読む
最初の確認コマンド
curl -Iv https://example.com --resolve example.com:443:ORIGIN_IP
最初に見る証拠

Cloudflare 525 は、発生時刻、リクエストURL、ユーザー、直近変更、最初のログ行から確認します。

検索クエリ
Cloudflare 525Cloudflare error 525Cloudflare SSL 525 handshake failed

この状況で発生します

Cloudflare プロキシを有効にした後、サイトには 525 が表示される一方でオリジンサーバー自体は稼働している場合によく発生します。DNS の誤りというより、Cloudflare がオリジンと TLS 接続する段階で証明書、SNI、TLS バージョン、VirtualHost 設定が合っていないことが多いです。

症状チェック

  • ブラウザに Error 525 が表示されます。
  • Cloudflare のイベントログに SSL handshake failed が残ります。
  • オリジン IP に直接アクセスすると証明書警告または別の TLS エラーが出ます。
  • DNS only に切り替えるとページが開く、またはエラーコードが変わることがあります。
  • 同じサーバーの別ドメインは正常でも、特定ホスト名だけ失敗することがあります。

可能性が高い原因

  • オリジン証明書が期限切れ、またはホスト名と一致していません。
  • Cloudflare SSL モードが Full strict で、中間証明書チェーンが不足しています。
  • Nginx または Apache が SNI に合う証明書を返していません。
  • オリジンサーバーが TLS 1.2 以上、または Cloudflare が許可する cipher をサポートしていません。
  • VirtualHost の server_name、ServerName、ssl_certificate パスが実ドメインと合っていません。
  • ALB やリバースプロキシの背後で再度 TLS 終端され、証明書がずれています。

1分で先に確認

  1. Cloudflare SSL モードを Full strict から Full に一時的に下げ、症状の変化を確認します。
  2. オリジン IP に SNI を含めて curl と openssl を実行します。
  3. Nginx または Apache の VirtualHost がどの証明書を返すか確認します。
  4. オリジンサーバーの TLS バージョンと cipher 設定を確認します。

最初に見る証拠

Cloudflare 525 は、発生時刻、リクエストURL、ユーザー、直近変更、最初のログ行から確認します。

出力例

正常出力

curl -Iv https://example.com --resolve example.com:443:ORIGIN_IP
# no matching 525 entries during the checked window

失敗出力

curl -Iv https://example.com --resolve example.com:443:ORIGIN_IP
# 525 appears with timestamp, request path, user, and upstream layer

出力別の判断

  • 同じ時刻のエラーがログにありません。
    ブラウザ、CDN、プロキシ、DNSキャッシュなどサーバー外のレイヤーから分けます。
  • 同じ時刻と同じパスのエラーがログにあります。
    そのログを出したサービス、上流、権限、データ状態を優先して確認します。
  • 正常ユーザーと失敗ユーザーの出力が違います。
    権限、セッション、ネットワーク位置、キャッシュ差分を比較します。

避ける操作

  • 画面表示やコードだけで複数設定を同時に変えないでください。
  • 原因レイヤーの確認前に、全キャッシュ削除、広い権限付与、セキュリティ無効化を先にしないでください。

検証状態

運用者向けドラフト: 基本出力例と分岐対応を含みます。実際の incident 出力と公式リンクは更新キューで継続補強します。

先に実行するコマンド

curl -Iv https://example.com --resolve example.com:443:ORIGIN_IP
openssl s_client -connect ORIGIN_IP:443 -servername example.com -showcerts
nginx -T | grep -n "server_name\|ssl_certificate"
apachectl -S
nmap --script ssl-enum-ciphers -p 443 example.com

解決順序

  1. オリジンサーバー証明書の期限とホスト名一致を確認します。
  2. Cloudflare SSL モードが Flexible、Full、Full strict のどれか確認します。
  3. SNI 付き openssl テストで実際に返る証明書を見ます。
  4. Nginx/Apache VirtualHost 設定をドメイン基準で再確認します。
  5. 修正後に Cloudflare キャッシュを消し、同じコマンドで再検証します。

原因別の対応

  • オリジン証明書を更新し、full chain ファイルを使います。
  • Nginx の server_name と ssl_certificate、Apache の ServerName と SSLCertificateFile を実ドメイン基準で合わせます。
  • Cloudflare Origin Certificate を使う場合、プロキシを外した直接接続では信頼されない可能性を分けて判断します。
  • TLS 1.2 以上を許可し、古い cipher 設定を削除します。
  • ALB の背後にある場合は ALB listener 証明書とバックエンド証明書ポリシーを合わせて確認します。

検証メタ

  • operator-draft
  • official-reference-linked
  • 2026-07-23

更新キュー

  • 更新周期
    weekly-source-review
  • 次の補強
    Add one official-source check and one real output example for Cloudflare 525.

環境別の確認ポイント

  • Xserver、ConoHa、CPI など日本のホスティングでは、管理画面で SSL 反映完了状態を先に確認します。
  • AWS ALB の背後なら listener 証明書、target group health、バックエンドポートを一緒に見ます。
  • Cloudflare proxy をオフにして DNS only にした結果を別に記録します。
  • Let’s Encrypt 更新直後なら Web サーバー reload が済んでいるか確認します。
  • 複数ドメインが同じサーバーにある場合、SNI 基準で証明書が変わるか必ず見ます。

再発させないために

  • 証明書期限の 30 日前通知を設定します。
  • デプロイ後の curl と openssl 確認をチェックリストに入れます。
  • Cloudflare SSL モードとオリジン証明書ポリシーを文書化します。
  • Nginx/Apache VirtualHost 変更時はテストドメインで先に確認します。
  • DNS、プロキシ、証明書変更は同じ日にまとめず分けて実施します。