FAQ
これは、リクエストがCloudflare Workerを通過する場合に発生します。
この場合、Cloudflareはセキュリティ設定をトリガーするために、IPアドレスを含むクライアントの詳細を考慮します。ただし、セキュリティイベントに表示されるIPはCloudflareのIPアドレスになります。
はい、式の中で特定の文字をエスケープする必要がある場合があります。正確なエスケープは、使用する文字列の構文によって異なります：
- 生文字列構文（例えば、
r#"this is a string"#）を使用する場合、正規表現で特別な意味を持つ文字だけをエスケープする必要があります。 - 引用文字列構文（例えば、
"this is a string"）を使用する場合、特別な文字"と\を\"と\\を使ってエスケープするなど、追加のエスケープが必要です。これはリテラル文字列と正規表現の両方に当てはまります。
文字列構文とエスケープに関する詳細は、文字列値と正規表現を参照してください。
正規表現を使用している場合は、Regular Expressions 101 ↗やRustexp ↗などのツールでテストすることをお勧めします。
特定のリクエストの種類に対して例外を設けつつ、ブロックまたはチャレンジアクションを強制したい場合があります。
Cloudflareは、WAFカスタムルールを使用してリクエストを許可する2つの方法をサポートしています：
- ルール式を更新して、IPアドレス、ASN、または国に基づく除外を追加することで、特定のリクエストの種類をブロックまたはチャレンジから除外します。
- スキップアクションを持つ別のカスタムルールを作成します。このスキップルールは、ルールリスト内のブロック/チャレンジアクションを持つルールの前に表示される必要があります。
以下の例は、いくつかの可能なアプローチを示しています。
例1
脅威スコアを評価するブロック/チャレンジルールから複数のIPアドレスを除外します。
-
基本ルール、除外なし：
- 式:
(http.host eq "example.com" and cf.threat_score > 5) - アクション: ブロック（またはチャレンジアクション）
- 式:
-
IPアドレスをブロック/チャレンジから除外するルール：
- 式:
(http.host eq "example.com" and cf.threat_score > 5) and not (ip.src in {192.0.2.1 198.51.100.42 203.0.113.0/24}) - アクション: ブロック（またはチャレンジアクション）
- 式:
-
特定のIPのために残りのカスタムルールをスキップし、残りをブロックするための2つのルール。
- ルール1:
- 式:
ip.src in {192.0.2.1 198.51.100.42 203.0.113.0/24} - アクション: スキップ > 残りのすべてのカスタムルール
- ルール2:
- 式:
(http.host eq "example.com" and cf.threat_score > 5) - アクション: ブロック（またはチャレンジアクション）
例2
大量の不要なトラフィックのためにAmazon Web Services (AWS)とGoogle Cloud Platform (GCP)をブロックしますが、GooglebotやCloudflareが検証する他の既知のボットは許可します。
-
基本ルール、除外なし：
- 式:
(ip.geoip.asnum in {16509 15169}) - アクション: ブロック（またはチャレンジアクション）
- 式:
-
IPアドレスをブロック/チャレンジから除外するルール：
- 式:
(http.host eq "example.com" and cf.threat_score > 5) and not (ip.src in {192.0.2.1 198.51.100.42 203.0.113.0/24}) - アクション: ブロック（またはチャレンジアクション）
- 式:
-
特定のIPのために残りのカスタムルールをスキップし、残りをブロックするための2つのルール。
- ルール1:
- 式:
ip.src in {192.0.2.1 198.51.100.42 203.0.113.0/24} - アクション: スキップ > 残りのすべてのカスタムルール
- ルール2:
- 式:
(http.host eq "example.com" and cf.threat_score > 5) - アクション: ブロック（またはチャレンジアクション）
Cloudflareによって管理されているSSL/TLS証明書がある場合、証明書が発行または更新されるたびに、ドメイン制御検証 (DCV)が行われる必要があります。証明書がpending_validation状態にあり、有効なDCVトークンが存在する場合、カスタムルールやWAF管理ルールなどのCloudflareのセキュリティ機能は、特定のDCVパス（例えば、/.well-known/pki-validation/や/.well-known/acme-challenge/）で自動的に無効になります。
ブロック、インタラクティブチャレンジ、JSチャレンジ、または*管理チャレンジ（推奨）*アクションを持つWAFカスタムルールを作成すると、既知のボットからのトラフィックを意図せずブロックする可能性があります。特に、URI、パス、ホスト、ASN、または国に基づいて緩和アクションを強制しようとすると、検索エンジン最適化（SEO）やウェブサイトの監視に影響を与える可能性があります。
特定のリクエストをブロックまたはチャレンジから除外するにはどうすればよいですか？を参照してください。
Cloudflare Radar ↗には、WAFが現在検出している既知のボットのサンプルがリストされています。これらのボットやリストにない他のボットからのトラフィックがある場合、cf.client.botフィールドはtrueに設定されます。
友好的なボットを検証するには、Cloudflare Radarの検証済みボット ↗ページに移動し、ボットを追加を選択してください。
検証済みボットに関する詳細は、ボットを参照してください。
以前は、フロントエンドアプリケーションをカスタマイズしない限り、チャレンジされたAJAXリクエストは失敗します。なぜなら、AJAX呼び出しはDOMにレンダリングされないからです。
現在、Turnstileのプレクリアランスクッキーにオプトインできます。これにより、ウェブアプリケーションのフローの早い段階でチャレンジを発行し、ユーザーが敏感なAPIと対話できるように事前にクリアランスを行うことができます。Turnstileウィジェットによって発行されたクリアランスクッキーは、Turnstileウィジェットが埋め込まれているCloudflareゾーンに自動的に適用され、設定は不要です。クリアランスクッキーの有効期間は、ゾーン固有の設定可能なチャレンジパッセージセキュリティ設定によって制御されます。
いいえ。challengeFailedおよびjschallengeFailedファイアウォールルールアクションは、特別な状況下でチャレンジを通過しなかった観測されたリクエストを考慮します。ただし、一部の失敗したチャレンジはファイアウォールルールに追跡できません。さらに、Cloudflareファイアウォールルールは、失敗したチャレンジを持つすべてのリクエストの記録を持っているわけではありません。
したがって、これらのアクションは注意して考慮してください。信頼できる指標は、セキュリティ > WAF > ファイアウォールルールに表示されるチャレンジ解決率 (CSR)で、次のように計算されます：解決されたチャレンジの数 / 発行されたチャレンジの数。
ユーザーはすべてのチャレンジを完了しません。Cloudflareは、決して回答されないチャレンジを発行します — 通常、提供されたチャレンジのうち2-3%しか回答されません。
これには複数の理由があります：
- ユーザーがチャレンジをあきらめる。
- ユーザーがチャレンジを解決しようとするが、回答を提供できない。
- ユーザーがチャレンジをリフレッシュし続けるが、回答を提出しない。
- Cloudflareが不正なチャレンジ回答を受け取る。
正しいリクエストを見ていることを確認してください。
チャレンジをトリガーしたリクエストのみが、ルールのリクエストパラメータに一致します。[js]challengeSolvedまたは[js]challengeFailedアクションを持つ後続のリクエストは、ルールのパラメータに一致しない場合があります — 例えば、ユーザーがチャレンジを解決したためにボットスコアが変更された可能性があります。
「解決済み」と「失敗」のアクションは、ルールに一致した以前のリクエストに関する情報提供的なアクションです。これらのアクションは、「以前にルールがインタラクティブチャレンジまたはJSチャレンジとして設定されたリクエストに一致し、現在そのチャレンジが回答された」と述べています。