速度改善・安全対策

WordPressでCloudflare Error 1013が出るときの直し方｜SNI・Host不一致の確認順

Cloudflareを利用しているWordPressで「Error 1013: HTTP hostname and TLS SNI hostname mismatch」と表示されたら、TLS接続で示されたホスト名と、その後のHTTPリクエストが示すホスト名が一致していません。

このエラーは、WordPressのテーマや投稿データより前の通信経路で起きます。証明書を再発行したり、CloudflareのSSL/TLSモードを下げたりする前に、ブラウザー、VPN、SSL検査プロキシ、セキュリティ製品、独自クライアントが同じ宛先名を使っているかを確認します。

最初にError 1013の画面、完全なURL、発生時刻とタイムゾーン、Ray ID、端末・ブラウザー・回線・プロキシの情報を保存してください。その後、別端末と別回線を一条件ずつ比較すると、不一致を作った場所を絞れます。

先に結論：Error 1013は8段階で確認する

  1. 1013の画面、URL、時刻、Ray IDを保存する
  2. 特定URL・特定ブラウザー・特定回線だけか確認する
  3. 入力URLとリダイレクト後のホスト名を確認する
  4. VPN、プロキシ、HTTPS検査、セキュリティ製品の有無を調べる
  5. 管理された別回線・別端末で一度ずつ比較する
  6. 標準のcurlとOpenSSLで宛先名をそろえて基準を取る
  7. 原因のクライアントまたはプロキシだけを修正する
  8. HARを安全に保存し、主要経路とTLSを再確認する

CloudflareからオリジンサーバーへのTLSハンドシェイクで525が出る場合は、Cloudflare 525の確認手順を使います。オリジン証明書をStrictモードで検証できない526は、Cloudflare 526の証明書確認手順へ進んでください。

Error 1013とは？

異なる形の二つの宛先情報が同じ入口で一致しない場面

Cloudflare公式のError 1013は、HTTP hostnameとTLS SNI hostnameの不一致です。公式が挙げる代表的な原因は、ローカルブラウザーが誤ったSNIを送ること、またはSSL通信をプロキシするネットワークがSNIとHTTP Hostを一致しない状態にすることです。

SNIは、TLS接続を始める際にクライアントが「どのホスト名へ接続したいか」を伝える情報です。一つのIPで複数サイトを提供するとき、CloudflareはSNIを参考に適切な証明書や接続設定を選びます。

HTTP/1.1ではHostヘッダーが、HTTP/2・HTTP/3では主に:authorityが「このHTTP要求の宛先」を示します。たとえばTLSではexample.comへ接続したのに、HTTPではother.example.netを要求すれば、Cloudflareは同じ接続内の宛先が食い違っていると判断できます。

SNIとHostの違いを簡単に理解する

情報送られる段階役割
TLS SNI暗号化接続を始めるClientHello接続したいサーバー名を伝える
HTTP HostTLS接続後のHTTP/1.1要求要求対象のホストとポートを伝える
:authorityHTTP/2・HTTP/3要求Hostに相当する宛先情報を伝える
証明書のSANTLSハンドシェイク証明書が対象とするホスト名を示す

RFC 6066では、SNIのhost_nameはクライアントが理解する完全修飾DNSホスト名です。RFC 9110では、Hostは対象URIのホストとポートを示し、HTTP/2・HTTP/3では:authorityが代わる場合があると定義されています。

ここで大切なのは、SNIとHostのどちらかが単独で「正しいか」だけではなく、同じ要求で両者が同じ宛先を示すことです。大文字・小文字や既定ポートの表現だけを見て慌てず、実際に異なるホスト名へ書き換わっていないかを確認します。

1013・525・526・1000・リダイレクトループの違い

表示問題の区間・内容最初の確認
1013クライアント側SNIとHTTP Hostの不一致ブラウザー、プロキシ、VPN、要求先
525CloudflareからオリジンへのTLS接続失敗443、SNI、TLS、暗号スイート
526Cloudflareがオリジン証明書を検証できない期限、SAN、チェーン、Strict
1000禁止IP、DNS設定、プロキシ循環などDNS、実オリジン、ループ
リダイレクトループHTTP応答の転送先が循環Location、WordPress URL、CDN転送

DNSがCloudflareの禁止IPやCloudflare自身へ向いている場合は、Cloudflare Error 1000のDNS・プロキシ確認手順を使います。ブラウザーが転送を繰り返す場合は、WordPressのリダイレクトループ確認手順でLocationの連鎖を追ってください。

最初に影響範囲を切り分ける

特定ブラウザーだけか

同じ端末、同じ回線、同じURLで、問題のブラウザーと更新済みの標準ブラウザーを一度ずつ比較します。一方だけ1013なら、拡張機能、ブラウザー内プロキシ、セキュリティ機能、古い接続処理の差が有力です。シークレットモードで直るかだけで結論を出さず、拡張機能と接続設定を確認します。

社内・学校・公共Wi-Fiだけか

同じ端末でも携帯回線では正常で、社内回線だけ1013になる場合は、明示プロキシ、透過プロキシ、HTTPS検査、Secure Web Gateway、VPNなどの中継を確認します。組織の保護機能を利用者判断で停止せず、ネットワーク管理者へエラー時刻、URL、端末、出口IPを渡してください。

独自アプリ・監視だけか

監視ツール、APIクライアント、古い組み込みブラウザー、スクレイパーだけが失敗する場合は、接続先ホスト、SNI、Hostまたは:authorityをクライアント実装で確認します。IPアドレスへ直接接続し、Hostだけ目的ドメインへ上書きする実装は不一致を起こしやすいため、URLのホスト名から正しくTLS接続する構成へ戻します。

最初に保存する情報

  • Error 1013の画面全体とRay ID
  • 発生時刻とタイムゾーン
  • 入力した完全なURL
  • エラー直前までに表示された別ホスト名
  • 端末、OS、ブラウザー、アプリの名称とバージョン
  • VPN、プロキシ、HTTPS検査、セキュリティ製品の有無
  • 会社、家庭、携帯など回線の種類
  • 別端末・別ブラウザー・別回線での結果
  • 標準のcurlとOpenSSLでの確認結果
  • 問題を再現したHAR

HARにはCookie、Authorization、フォーム本文、個人情報などが含まれる場合があります。取得範囲を必要最小限にし、共有前に機密情報を除去し、安全な保管先と削除時期を決めます。公開の質問サイトやSNSへ添付しないでください。

どこで不一致が生まれたか確認する

SNIとHostを表す異なる形の部品を検査台で照合する場面

1. 入力URLとアドレスバーを照合する

ブックマーク、QRコード、メール内リンク、管理画面へのリンクを開いた直後に、アドレスバーのホスト名が意図したドメインか確認します。似た綴り、古いサブドメイン、全角文字、末尾の不要なドット、IPアドレス直打ちがないかを見ます。

WordPressの「サイトアドレス」と「WordPressアドレス」が別ホストを指すと、アクセス直後に別ドメインへリダイレクトされることがあります。ただし、通常のブラウザーは転送先へ新しいTLS接続を作るため、別ホストへの正しいリダイレクトだけで1013になるとは限りません。中継装置や独自クライアントが古いTLS接続を誤って再利用していないかも確認します。

2. プロキシとHTTPS検査を確認する

SSL検査プロキシはクライアントとのTLSを終端し、外側へ別のTLS接続を作ります。このとき、外側のSNIは元の宛先なのに、HTTP Hostだけ別の宛先へ書き換える、またはその逆になると1013が発生します。PACファイル、プロキシ除外、SNIルーティング、Host書き換え、接続プールの再利用条件を管理者が確認します。

3. VPNとセキュリティ製品を確認する

一部のVPN、ウイルス対策、ペアレンタルコントロール、広告遮断アプリはHTTPS通信を検査・中継します。製品名、バージョン、HTTPSスキャン機能、適用ポリシーを記録します。原因確認のために一時比較する場合も、管理された端末と許可された回線で行い、保護機能を恒久的に無効化しません。

4. 独自クライアントの接続処理を確認する

URL解析、DNS解決、TLS接続、HTTP送信を別々に実装している場合は、すべてが同じ正規化済みホスト名を参照しているか確認します。転送先へ追従した後も古いHostを残す、接続プールを別ホストへ誤再利用する、IP直結のままHostだけ変える処理がないかをログで追います。

curlとOpenSSLで基準を確認する

コマンド操作に慣れている担当者は、まずURLにホスト名をそのまま指定した標準要求を確認します。次の例では、www.example.comを実際の対象ホストへ置き換えてください。

curl -Iv https://www.example.com/
openssl s_client -connect www.example.com:443 -servername www.example.com

curlで標準要求が成功し、問題のブラウザーやアプリだけ1013になるなら、そのクライアントまたは途中経路の差が有力です。OpenSSLの-servernameは、Cloudflareエッジへ特定のSNIを送ってTLS応答を確認するために使えます。証明書の対象名と有効性も確認します。

IPアドレスへ直接接続し、Hostヘッダーだけ別ドメインへ上書きする方法を通常運用にしないでください。意図的な不一致テストは、所有・管理しているドメインに対して、担当者が影響を理解した検証環境でのみ行います。

HARを安全に取得する

Cloudflare公式のError 1013は、Supportへ再現時のHARを提供するよう案内しています。Cloudflare公式のトラブルシューティング情報に沿って、プライベートウィンドウで開発者ツールのNetworkを記録し、1013を一度再現してHARを書き出します。

  1. 不要なタブを閉じ、プライベートウィンドウを開く
  2. 開発者ツールのNetworkを開き、Preserve logを有効にする
  3. 対象URLを開いて1013を一度再現する
  4. 時刻、画面、Ray IDを同時に記録する
  5. HARを書き出し、Cookieや認証情報を確認する
  6. 必要に応じてサニタイズし、安全な窓口で共有する

HARはURL、HTTP要求・応答、リダイレクトの確認に役立ちますが、ブラウザーのHARだけでTLS ClientHelloのSNIが常に直接読めるとは限りません。SNIの確認には、プロキシ・ゲートウェイの許可されたログ、OpenSSLの基準テスト、必要に応じて管理者が取得するネットワーク記録を組み合わせます。

原因別の安全な直し方

宛先情報が一致し一つの経路で正しい入口へ進む場面

ブラウザー・拡張機能が原因

ブラウザーを正式な最新版へ更新し、プロキシ設定と拡張機能を確認します。特定の拡張機能が通信先を書き換えていると確認できた場合は、提供元の修正版へ更新するか削除します。出所不明の証明書や拡張機能を追加して回避しないでください。

SSL検査プロキシ・VPNが原因

ネットワーク管理者が、外向きTLS接続のSNIとHTTP Hostが同じ元URLから生成されるよう設定を修正します。ホスト書き換え、接続プール、HTTP/2の再利用、PAC、例外ルールを一つずつ確認します。検査除外が必要な場合も、組織の方針に従い対象ホストと用途を限定し、記録を残します。

独自アプリ・監視が原因

TLSライブラリへURLと同じホスト名を渡し、HTTPのHostまたは:authorityも同じ値から生成します。リダイレクト後は新しい宛先でTLS接続を作り直し、異なるオリジンへ古い接続を流用しません。DNSの検証で特定IPへ接続する場合も、URLホストとSNIを保持できる正式な機能を使います。

WordPressのURL・リダイレクトが関係する

WordPressの「WordPressアドレス」「サイトアドレス」、Webサーバー、Cloudflare Redirect Rules、プラグインが、意図しない旧ドメインや別サブドメインへ転送していないか確認します。修正時は正規ホストを一つ決め、HTTPSとホスト名をそろえます。ただし、1013がクライアント・プロキシの不一致である証拠があるのに、無関係なWordPress URLを先に変えないでください。

変更しなくてよい可能性が高いもの

  • WordPressのテーマや投稿内容
  • PHPバージョンやデータベース
  • Cloudflareとオリジン間のSSL/TLSモード
  • オリジンサーバー証明書
  • ファイル・ディレクトリ権限
  • WordPressユーザーのパスワード

1013はクライアント側SNIとHTTP Hostの不一致を示します。525や526が同時に確認されていない限り、オリジン証明書の再発行やSSL/TLSモードの変更は第一手ではありません。無関係な変更を増やすと、元に戻す判断も難しくなります。

やってはいけない対処

  • CloudflareのエッジIPへ直接アクセスしHostだけ上書きする
  • 組織のHTTPS検査やセキュリティ製品を無断で停止する
  • 原因確認前にSSL/TLSモードをFlexibleへ下げる
  • オリジン証明書を根拠なく再発行・削除する
  • 複数のプロキシ・VPN・リダイレクト設定を同時に変える
  • 機密情報を含むHARを公開場所へ添付する
  • 別回線で開けたことだけで恒久対処にする
  • SNIとHostを別々の固定値としてアプリへ埋め込む
  • 無関係なWordPressプラグインやテーマを削除する

修正後の確認項目

  • 問題のブラウザー・アプリ・回線で1013が消えた
  • 入力URLと最終URLのホスト名が意図どおり
  • SNIとHostまたは:authorityが同じ宛先を示す
  • トップ、投稿、固定ページ、カテゴリー、検索、404が正常
  • 管理画面のログイン、保存、プレビューが正常
  • REST API、フォーム、Webhook、監視、RSSが正常
  • HTTPからHTTPS、www有無、旧ドメインの転送が一方向
  • 525、526、1000、リダイレクトループへ変化していない
  • プロキシのHTTPS検査と他サイトの保護が正常
  • HARやログの保管・削除ルールを守った
  • 変更者、変更理由、復旧時刻、戻し方を記録した

まとめ

Cloudflare Error 1013は、TLS接続時のSNIとHTTP要求のHostまたは:authorityが一致しないエラーです。WordPress本体やオリジン証明書より先に、クライアントとCloudflareの間で宛先名を書き換えるブラウザー、プロキシ、VPN、HTTPS検査、独自アプリを確認します。

URL、時刻、Ray ID、別端末・別回線の比較、標準のcurl・OpenSSL、機密情報を除いたHARをそろえ、SNIとHostを同じ正規ホストへ戻してください。通信経路の一箇所を特定して直せば、CloudflareやWordPress全体を弱めずに復旧できます。

-速度改善・安全対策