トラブルシューティング

Cloudflare は、すべてのページビューからデータを収集するわけではありません。効率よく情報を集めるため、サンプリングを使います。そのためトラフィックが少ないドメインでは、十分なサンプルが溜まるまで初期レポートの生成に時間がかかることがあります。レポートを早めるには、クライアントサイトリソースモニタリングを有効にした あと、アプリケーションへ能動的にトラフィックを流すことを推奨します。データが増えるため、レポート生成が速くなります。

この問題を切り分けるには、次も試してください。

• クライアントサイトリソースモニタリングがオンになっていること を確認します。
• クライアントサイトリソースモニタリングを有効にし、アプリケーションへトラフィック（少なくとも 100 リクエスト）を流したあと、約 1 時間待ちます。Cloudflare がデータを収集・処理し、クライアントサイトリソースモニタリングのダッシュボードに表示できる状態になるまで時間がかかります。
• ブラウザーの開発者ツール（Network タブ）で、content-security-policy-report-only HTTP ヘッダー があるかを確認します。
• アナリティクスのダッシュボードで、トラフィックが Cloudflare でプロキシされているかを確認します。
• レスポンスに CSP（Content Security Policy）ヘッダーの重複や競合がないかを確認します。オリジンサーバーがレスポンスに CSP ヘッダーを付けていることがあります。

スクリプトは、アプリケーション外の別スクリプトを参照することがよくあります。

ただし、リソースモニタリングのダッシュボードに想定外のスクリプトがある場合は、悪意のある活動の兆候がないかを確認してください。

Cloudflare は、Content Security Policy (CSP) の report-only ディレクティブを使い、アプリケーション上で動いている全スクリプトの一覧を集めます。

一部のブラウザーは、報告対象のスクリプトを開発者ツールのコンソールに警告として表示します。例:

[Report Only] Refused to execute inline script because it violates
the following Content Security Policy directive: "script-src 'none'".

Either the 'unsafe-inline' keyword, a hash ('sha256-RFWPLDbv2BY+rCkDzsE+0fr8ylGr2R2faWMhq4lfEQc='), or a nonce ('nonce-...')
is required to enable inline execution.

これらの警告は無視して問題ありません。読み込まれたスクリプトを Cloudflare が検出するために必要なレポートに関するものです。詳細は Client-side security の仕組み を参照してください。

CSP の report-only ディレクティブ 経由で報告されるルール違反は、リダイレクトやリダイレクトの HTTP ステータスコードを考慮しません。これはセキュリティ上の理由による 仕様 ↗ です。

許可ルールでカバーしたいサードパーティサービスには、リダイレクトを行うものがあります。例として Google Ads は、CSP ポリシーとの相性がよくありません ↗。

たとえば許可ルールに adservice.google.com ドメインを追加しても、別ドメイン（許可ルールにないドメイン）へのリダイレクトが原因で、このドメインのルール違反レポートが届くことがあります。この場合、違反レポートにはリダイレクト先ではなく元のドメインが残るため、混乱することがあります。

対処するには、リダイレクト先のドメインを許可ルールに追加します。リダイレクトの都合で、複数ドメインの追加が必要になることがあります。

違反レポートが、ユーザー同意管理や行動トラッキングのサービスに属するドメインを指している場合、訪問者のブラウザーに入っている広告ブロック拡張機能が原因であることが多いです。

こうした拡張機能は、該当ドメインへのリクエストをブロックすることがよくあります。多くの場合、宛先へ届ける代わりにローカルリソースへリダイレクトします。違反レポートは、ブロックまたはリダイレクトされた先ではなく、ページが要求した元のドメインを記載するため、すでに許可リストに入れたドメインの違反レポートが見えることがあります。

この挙動は、該当拡張機能を入れている訪問者だけが引き起こすため、サイト全体のトラフィック量に比べて違反レポートは疎になります。

SSL for SaaS のルートゾーンでカスタムホスト名を運用しており、'self' キーワードを使うコンテンツセキュリティルールで スコープ付きアラート を設定している場合、自分のアプリケーション面だけでなく、ルートゾーン配下の全カスタムホスト名で検出されたリソースに対してアラートが届きます。

これは想定どおりの動作です。

• SSL for SaaS は、ルートゾーンのコンテンツセキュリティルールを、配下のすべてのカスタムホスト名に適用します。
• CSP ディレクティブの 'self' キーワードは、処理中のリクエストのホスト名に一致します。カスタムホスト名が自身のスクリプトを読み込むと、それらのスクリプトは 'self' に一致し、スコープ付きアラートが発火します。

SaaS の規模では、管理していないホスト名にわたってアラート量が多くなり、自社のコンプライアンス監査の範囲（例: カード会員データを収集する特定ページ）を切り出しにくくなります。

コンテンツセキュリティルールをルートゾーンだけに限定し、カスタムホスト名を除外する方法は、現時点ではありません。自社のアプリケーション面だけを監視したい場合は、次のいずれかを検討してください。

• 自分が管理する特定のページパスだけに一致するコンテンツセキュリティルール式を使います（例: カード会員データを収集するリクエストパス）。
• 'self' を、自分が管理するホスト名の明示的な一覧に置き換えます。ただし SaaS 規模では、CSP ヘッダーの実質的なサイズ上限があるため、現実的でないことが多いです。
• どちらの回避策も合わない場合は、アカウントチームに連絡し、コンテンツセキュリティルールを SaaS のルートゾーンだけに限定する要望として記録してもらってください。

コンテンツセキュリティルールを設定したのに、想定した CSP ヘッダーがレスポンスに付かない場合、Transform Rules がコンテンツセキュリティルールの評価前にリクエストパスを書き換えている可能性があります。

Cloudflare は、フェーズごとに 決まった順序 でルールを評価します。URL Rewrite Rules はリクエストライフサイクルの早い段階で動き、コンテンツセキュリティルールはそれより後のレスポンスフェーズで評価されます。

そのため、コンテンツセキュリティルールがリクエスト URI パス（例: http.request.uri.path フィールド）で受信リクエストに一致させている場合、評価対象は訪問者が要求した元の URI パスではなく、書き換え後のパスになります。

次のいずれかの方法で解決できます。

• コンテンツセキュリティルールの条件を、書き換え後のパスに合わせる: ルールの式を、訪問者の元の URI パスではなく、書き換え後の URI パスに一致するよう変更します。

• raw フィールドで元の URI パスに一致させる: コンテンツセキュリティルールの式では、http.request.uri.path の代わりに raw.http.request.uri.path を使います。Raw フィールド は元のリクエスト値を保持し、Transform Rules の影響を受けません。

この問題を切り分けるときは、Cloudflare Trace で、フェーズを進むにつれてリクエストパスがどう変わるかを確認するとよいです。

レスポンスに Content-Security-Policy または Content-Security-Policy-Report-Only ヘッダーが重複している場合、Client-side security と レスポンスヘッダーの Transform Rule の両方が、同じ種類のヘッダーを追加していることが原因である可能性が高いです。

コンテンツセキュリティルールは、レスポンスに CSP ヘッダーを自動で追加します。

• ログルール は Content-Security-Policy-Report-Only ヘッダーを追加します。
• 許可ルール は Content-Security-Policy ヘッダーを追加します。

同じヘッダータイプに対して Add 操作のレスポンスヘッダー Transform Rule がある場合、両方のヘッダーがレスポンスに残ります。

ブラウザーは複数の CSP ヘッダーに遭遇すると、すべてを適用し、いちばん厳しいポリシーが優先されます。正当なリソースまで予期せずブロックされることがあります。

Client-side security のポリシーと Response Header Transform Rules を併用する必要がある場合は、Set static または Set dynamic 操作を使います。これらの操作は、Cloudflare の Client-side security が付けたヘッダーを含め、既存のヘッダー値を置き換えます。この操作を使うと、Transform Rule が Client-side security より優先されます。

次の手順で切り分けます。

1. ブラウザーの開発者ツール（Network タブ）でレスポンスヘッダーを確認し、CSP ヘッダーの重複がないかを調べます。
2. 設定済みの Response Header Transform Rules を見直し、Content-Security-Policy または Content-Security-Policy-Report-Only ヘッダーに Add 操作を使っているものがないかを確認します。
3. Transform Rule で Client-side security の CSP ヘッダーを上書きしたい場合は、操作を Add から Set static または Set dynamic に変更します。
4. または、コンテンツセキュリティルールの範囲を無効化または調整し、Transform Rule との重複を避けます。