トラブルシューティング

Spectrum アプリケーションの問題を調べるには、このページで説明するログと診断を使います。アプリケーションの作成または更新時に返る API 検証エラーは、エラーコード を参照してください。

Spectrum はプロキシするすべての接続のライフサイクルを記録します。エッジからオリジンへの失敗のステータスコード（例: 521 接続拒否、522 タイムアウト、523 到達不能）も含みます。イベントログ を参照してください。

Spectrum アプリケーションが 仮想ネットワークオリジン を使う場合、オリジンへのトラフィックは仮想ネットワークに関連付けられたコネクタを経由します。オリジン接続の診断は、コネクタ種別ごとの情報源を使ってコネクタ側から行います。

• Tunnel logs は、cloudflared と Cloudflare ネットワークの間、および cloudflared とオリジンの間のアクティビティを記録します。Log streams を参照してください。
• Tunnel diagnostic logs は、1 つの cloudflared インスタンスから診断レポートを収集します。Diagnostic logs を参照してください。
• Private network connectivity は、トンネル経由でプライベートオリジンにトラフィックが届かない場合のよくある原因を扱います。Private network connectivity を参照してください。

WAN 接続オリジンのトンネル健全性、BGP、ルーティング診断は、Troubleshoot Cloudflare WAN を参照してください。

• ダッシュボードで Spectrum アプリケーションを作成すると、次のエラーが表示されます。"An A, AAAA or CNAME record already exists with that host."
• 新しい Spectrum アプリケーションに使いたいホスト名に対して、手動作成したプロキシ済み DNS レコード（A、AAAA、または CNAME）がすでにあります。

Cloudflare は、同じホスト名上で、手動作成したプロキシ済み DNS レコード（A、AAAA、または CNAME）と Spectrum アプリケーションの共存をサポートしていません。Spectrum はアプリケーション用の DNS レコードを自身でプロビジョニングして管理するため、既存の手動作成レコードと衝突します。これはプラットフォームの制限であり、ダッシュボードだけの制限ではありません。

この制限は、手動作成したプロキシ済みレコードにだけ適用されます。複数の Spectrum アプリケーション（HTTP/HTTPS と TCP/UDP の混在を含む）は同じホスト名を共有できます。Spectrum がそれぞれの DNS レコードを管理するためです。

そのホスト名で Spectrum アプリケーションだけが必要なら（例: HTTP/HTTPS の Spectrum アプリケーションと TCP/UDP の Spectrum アプリケーションを並べる）、回避策は不要です。同じホスト名に追加の Spectrum アプリケーションを作成してください。

ホスト名上の手動作成したプロキシ済み DNS レコードを残す必要がある場合（例: 通常の HTTP/HTTPS トラフィックを Spectrum ではなく CDN と WAF 経由にする）、ホスト名分割アーキテクチャ を使います。手動作成したプロキシ済みレコードと Spectrum アプリケーションで、別のホスト名を使います。

アプリケーションまたはクライアントを、トラフィック種別に応じたホスト名を使うよう設定します。

この制限の詳細は、Spectrum の制限事項 を参照してください。

• Spectrum アプリケーションのエッジポートは HTTP（例: ポート 8012）で、オリジンはポート 443 で HTTPS を期待しています。
• オリジンが平文 HTTP を受け取り、暗号化された HTTPS ではないため、接続を拒否するかエラーを返します。
• 設定の見え方は、期待する http:8012 → Cloudflare Spectrum → https:443 (origin) ではなく、http:8012 → Cloudflare Spectrum → http:443 (origin) になります。

Spectrum はレイヤー 4（TCP/UDP）で動作します。Edge TLS Termination が off（Passthrough）の場合、Spectrum は生の TCP ペイロードを変更せずオリジンへ転送します。プロトコルのアップグレードは行いません。オリジンのポート 443 へ接続しても、自動的に HTTPS になるわけではありません。

Cloudflare からオリジンへ暗号化したトラフィックを送るには、Spectrum アプリケーションで Edge TLS Termination をオンにし、Full または Full (Strict) に設定します。

• Full: Cloudflare は TLS でオリジンに接続しますが、オリジン証明書は検証しません。
• Full (Strict): Cloudflare は TLS でオリジンに接続し、信頼できる CA または Cloudflare Origin CA に対してオリジン証明書を検証します。

Edge TLS Termination は、ダッシュボードの Spectrum アプリケーション設定、または API で tls フィールドを full または strict に設定して構成できます。

詳細は Edge TLS Termination を参照してください。

• Edge TLS Termination が Full または Full (Strict) の TCP アプリケーション: オリジンへの接続が失敗します。オリジン側の TLS ハンドシェイク失敗はオリジン接続失敗として報告されるため、Spectrum イベントログには 521（接続拒否）または 522（接続タイムアウト）が出ることがあります。ステータスコードの一覧は イベントログ を参照してください。
• HTTP/HTTPS アプリケーション: クライアントはエラー 525（SSL handshake failed）を受け取ります。

これらのエラーは、Spectrum アプリケーションの作成後や TLS 設定の変更後に出ることが多いです。

Cloudflare とオリジンサーバーの間の TLS ハンドシェイクが失敗しています。よくある原因は次のとおりです。

• Edge TLS Termination が Full または Full (Strict) だが、オリジンに有効な TLS 証明書がない、または設定したポートで TLS 接続を受け付けていない。
• Spectrum アプリケーションのオリジンが、別の Cloudflare プロキシ済みホスト名を指している（例: origin.example.com.cdn.cloudflare.net）。TCP アプリケーション種別ではサポートされない二重プロキシチェーンになり、TLS ハンドシェイク失敗の原因になります。
• Cloudflare エッジとオリジンサーバーの間で TLS バージョンまたは暗号の不一致 がある。

1. オリジンサーバーに有効な TLS 証明書があり、オリジンポートで TLS 接続を受け付けるよう設定されていることを確認します。
2. Full (Strict) を使う場合は、オリジン証明書が一般に信頼される CA、または Cloudflare Origin CA 証明書 によって発行されていることを確認します。
3. Spectrum アプリケーションのオリジンが、別の Cloudflare プロキシ済みホスト名を指していないことを確認します。直接のオリジン IP アドレス、または（Cloudflare のプロキシを経由せず）オリジンサーバーへ直接解決する DNS 名を使います。
4. オリジンが特定の TLS バージョンだけに対応している場合、Edge TLS Termination がオンのとき Spectrum が対応するのは TLS 1.1、1.2、1.3 です。

Spectrum は、Cloudflare の CDN レイヤーが使う HTTP ステータスコードとは別の、独自の接続ステータスコードを使います。一部のコードは番号が同じでも（例: 444、499）、意味が異なります。

ステータスコードの一覧は、イベントログ を参照してください。

次の表は、よく見られる Spectrum ステータスコードのパターンと、想定される原因です。