FAQ
Why does a security event display a Cloudflare IP address even though other fields match the client details?
This happens when a request goes through a Cloudflare Worker.
In this case, Cloudflare considers the client details, including its IP address, for triggering security settings. However, the IP displayed in Security Events will be a Cloudflare IP address.
Yes, you may have to escape certain characters in expressions. The exact escaping will depend on the string syntax you use:
- If you use the raw string syntax (for example,
r#"this is a string"#), you will only need to escape characters that have a special meaning in regular expressions. - If you use the quoted string syntax (for example,
"this is a string"), you need to perform additional escaping, such as escaping special characters"and\using\"and\\, both in literal strings and in regular expressions.
For more information on string syntaxes and escaping, refer to String values and regular expressions.
If you are using a regular expression, it is recommended that you test it with a tool such as Regular Expressions 101 ↗ or Rustexp ↗.
If you have SSL/TLS certificates managed by Cloudflare, every time a certificate is issued or renewed, a domain control validation (DCV) must happen. When a certificate is in pending_validation state and there are valid DCV tokens in place, some Cloudflare security features such as custom rules and WAF Managed Rules will be automatically disabled on specific DCV paths (for example, /.well-known/pki-validation/ and /.well-known/acme-challenge/).
Cloudflare may block an IP address due to various reasons:
-
Web Application Firewall (WAF) mitigation actions: The Cloudflare WAF protects websites from various online threats, including malicious traffic, DDoS attacks, and common vulnerabilities. If your IP address is associated with suspicious or malicious activity, it might trigger the WAF and block requests.
-
High security settings: The website owner might have set their Cloudflare security settings to a high level, making the filtering of incoming traffic stricter. In this situation, even legitimate users may get blocked or have to solve challenges.
-
Excessive requests: Cloudflare may block an IP address if it detects an unusually high number of requests in a short period, in which case it will rate limiting subsequent requests. This is a protective measure against potential abuse or attacks.
-
Traffic from malicious bots: Cloudflare employs bot detection mechanisms to distinguish between legitimate users and automated bots. If traffic from your IP address behaves like traffic from a malicious bot, it could get blocked.
-
Blocklisted IPs: Cloudflare might block IP addresses listed on public blocklists due to their association with known malicious activities.
If your IP address is blocked, try the following:
-
Check Cloudflare Security Events: Use the Security Events log to check for specific reasons your IP might be getting blocked. Look for details on the type of threat or activity that triggered the block.
-
Contact the website owner: If you are a legitimate user and your IP is wrongly blocked, contact the website owner or administrator. They may be able to allowlist your IP or investigate the issue further.
-
Verify your own website traffic: Check for abnormal activity. If you manage a website behind Cloudflare, ensure that your site's traffic is legitimate and not triggering security measures inadvertently.
-
Check your IP reputation: Verify whether your IP address is listed on public blocklists, such as Project Honey Pot ↗. If so, take steps to address any issues that may have led to the listing.
-
Adjust your security settings: If you are a website owner using Cloudflare, consider adjusting security settings to find the right balance between protection and accessibility.
When you create a WAF custom rule with a Block, Interactive Challenge, JS Challenge, or Managed Challenge (Recommended) action, you might unintentionally block traffic from known bots. Specifically, this might affect search engine optimization (SEO) and website monitoring when trying to enforce a mitigation action based on URI, path, host, ASN, or country.
Refer to How do I exclude certain requests from being blocked or challenged?.
Cloudflare Radar ↗ lists a sample of known bots that the WAF currently detects. When traffic comes from these bots and others not listed, the cf.client.bot field is set to true.
To submit a friendly bot to be verified, go to the Verified bots ↗ page in Cloudflare Radar and select Add a bot.
For more information on verified bots, refer to Bots.
Cloudflare issues challenges to website visitors to protect against malicious activity such as bot attacks and DDoS attacks. Key reasons include:
- High Threat Score: IP addresses with a high-risk score trigger challenges.
- IP reputation: If your IP has a history of suspicious activity, it may be flagged.
- Bot detection: Automated traffic resembling bots is filtered by Cloudflare.
- Web Application Firewall (WAF) custom rules: Site owners may set rules targeting specific regions or user agents.
- Browser Integrity Check: Cloudflare verifies that browsers meet certain standards.
- Challenge Passage: Technologies like Privacy Pass reduce the frequency of repeated challenges.
To avoid repeated challenges, ensure your browser is up to date, disable any privacy tools that might block standard browser headers, or use a different network connection if your current one has a poor IP reputation.
In certain situations you want to enforce a blocking or challenging action but make an exception for specific types of requests.
Cloudflare supports two methods of allowing requests using WAF custom rules:
- Exclude a type of request from being blocked or challenged in a custom rule by updating the rule expression, for example adding an exclusion based on IP address, ASN, or country.
- Create a separate custom rule with a Skip action. This skip rule must appear before the rule with the block/challenge action in the rules list.
The examples below illustrate a few possible approaches.
Example 1
Exclude multiple IP addresses from a blocking/challenging rule that assesses Threat Score.
-
Basic rule, no exclusion:
- Expression:
(http.host eq "example.com" and cf.threat_score > 5) - Action: Block (or a challenge action)
- Expression:
-
Rule that excludes IP addresses from being blocked/challenged:
- Expression:
(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}) - Action: Block (or a challenge action)
- Expression:
-
Two rules to skip remaining custom rules for specific IPs and block the rest.
-
Rule 1:
- Expression:
ip.src in {192.0.2.1 198.51.100.42 203.0.113.0/24} - Action: Skip > All remaining custom rules
- Expression:
-
Rule 2:
- Expression:
(http.host eq "example.com" and cf.threat_score > 5) - Action: Block (or a challenge action)
- Expression:
-
Example 2
Block Amazon Web Services (AWS) and Google Cloud Platform (GCP) because of large volumes of undesired traffic, but allow Googlebot and other known bots that Cloudflare validates.
-
Basic rule, no exclusion:
- Expression:
(ip.geoip.asnum in {16509 15169}) - Action: Block (or a challenge action)
- Expression:
-
Rule that excludes IP addresses from being blocked/challenged:
- Expression:
(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}) - Action: Block (or a challenge action)
- Expression:
-
Two rules to skip remaining custom rules for specific IPs and block the rest.
-
Rule 1:
- Expression:
ip.src in {192.0.2.1 198.51.100.42 203.0.113.0/24} - Action: Skip > All remaining custom rules
- Expression:
-
Rule 2:
- Expression:
(http.host eq "example.com" and cf.threat_score > 5) - Action: Block (or a challenge action)
- Expression:
-
Previously, unless you customize your front-end application, any AJAX request that is challenged will fail because AJAX calls are not rendered in the DOM.
Now, you can opt-in to Turnstile’s Pre-Clearance cookies. This allows you to issue a challenge early in your web application flow and pre-clear users to interact with sensitive APIs. Clearance cookies issued by a Turnstile widget are automatically applied to the Cloudflare zone that the Turnstile widget is embedded on, with no configuration necessary. The duration of the clearance cookie’s validity is controlled by the zone-specific configurable Challenge Passage security setting.
No. The challengeFailed and jschallengeFailed firewall rule actions account for observed requests that, under special circumstances, did not pass a challenge. However, some failed challenges cannot be traced back to a firewall rule. Additionally, Cloudflare Firewall Rules may not have a record of every request with a failed challenge.
Therefore, consider these actions with caution. A reliable indicator is the Challenge Solve Rate (CSR) displayed in Security > WAF > Firewall rules, which is calculated as follows: number of challenges solved / number of challenges issued.
Why would I not find any failed challenges? Why is ChallengeIssued not equal to ChallengeSolved plus ChallengeFailed?
Users do not complete all challenges. Cloudflare issues challenges that are never answered — only 2-3% of all served challenges are usually answered.
There are multiple reasons for this:
- Users give up on a challenge.
- Users try to solve a challenge but cannot provide an answer.
- Users keep refreshing the challenge, but never submit an answer.
- Cloudflare receives a malformed challenge answer.
Make sure you are looking at the correct request.
Only requests that triggered a challenge will match the request parameters of the rule. Subsequent requests with a [js]challengeSolved or [js]challengeFailed action may not match the parameters of the rule — for example, the bot score may have changed because the user solved a challenge.
The "solved" and "failed" actions are informative actions about a previous request that matched a rule. These actions state that "previously a rule had matched a request with the action set to Interactive Challenge or JS Challenge and now that challenge was answered."