How to Use Cloudflare "Under Attack" Mode During a DDoS Attack on Your Website

When your website is under a DDoS attack, Cloudflare's Under Attack mode provides an urgent defense setting that filters bot traffic by displaying a brief security verification to visitors. By selecting your site in the Cloudflare dashboard and enabling the Under Attack Mode feature from the Security section, you can slow down intense HTTP/HTTPS requests within minutes, protect real users' access to your site, and reduce your server's load. However, this mode is not a permanent solution on its own; it should be used alongside proper DNS proxy settings, WAF rules, rate limiting, cache configuration, and origin server security.

In this guide, we will step-by-step address how to activate Cloudflare's Under Attack mode, when it should be used, what settings should support it, and how to safely return to normal after the attack has ended. The goal is to provide a practical checklist that can be applied in panic situations and to restore your site's accessibility as quickly as possible.

What is Cloudflare Under Attack Mode?

Cloudflare Under Attack mode is an emergency security level offered by Cloudflare. When activated, Cloudflare subjects visitors to the site to a brief verification of their browsers. This verification typically lasts a few seconds and makes it difficult for automated bots, simple HTTP flood tools, or malicious non-browser clients to directly burden the site.

The primary purpose of this mode is to mitigate application-layer or Layer 7 attacks. For instance, if thousands of GET requests are hitting the homepage per second, if there are intense POST attempts on the WordPress login page, or costly queries sent to the search page or fake traffic directed to the cart page, Under Attack mode provides a quick initial response.

The key distinction here is that Under Attack mode filters web requests; however, if your server's IP address is directly targeted, if your services outside of the Cloudflare proxy are exposed, or if the attack is at Layer 3/4, additional precautions are necessary. Therefore, it’s critical that DNS records are proxied through Cloudflare, the origin IP address is hidden, and proper security measures are implemented on the hosting side. For safe infrastructure choices, you can refer to Secure Web Hosting Services and SSL Certificate Installation.

Signs of a DDoS Attack: What to Check Before Switching to Under Attack Mode?

Not every slowdown is due to a DDoS attack. Sometimes a faulty plugin, a database lock, a high CPU-consuming cron task, or incorrect cache settings can yield similar results. Therefore, it is beneficial to make a quick diagnosis before activating Under Attack mode. However, if the server is struggling to respond, users are receiving 502, 503, or 504 errors, and there is a significant spike in requests in the logs, emergency mode should not be delayed.

Typical Indicators of DDoS Attacks

• A sudden traffic increase of 5, 10, or 50 times the normal volume in a short period.
• Hundreds of requests per second to a single page or endpoint.
• Traffic flow from different countries but with similar user-agent values.
• Targeting costly URLs such as admin, login, search, or cart in WordPress, WooCommerce, OpenCart, or custom software.
• Server CPU, RAM, PHP-FPM worker, or MySQL connection limits being reached.
• A sudden spike in 4xx and 5xx errors on the Cloudflare Analytics screen.
• Real users being intermittently able to access the site while bot traffic continuously sends requests.

For example, if an e-commerce site that normally receives 2,000 requests per minute escalates to 80,000 requests per minute in 10 minutes and 70% of those requests are directed to the cart or search pages, this is a clear sign of a Layer 7 attack. In this scenario, Under Attack mode should be activated within the first 5 minutes, followed by the addition of targeted WAF and rate limiting rules for the URLs in question.

When Should You Use Cloudflare Under Attack Mode?

Cloudflare Under Attack mode is not a standard security setting that should be kept on all the time. This is because it also displays a brief waiting screen to real visitors. This can negatively impact user experience, especially on conversion-oriented pages, payment steps, or structures utilizing APIs. The most appropriate use is to temporarily activate it during an attack and then adjust the security level back to normal once traffic returns to normal.

Suitable Situations for Use

• If the site is receiving abnormal and intense HTTP/HTTPS requests.
• If server resources are quickly depleting and 502/503 errors are increasing.
• If the Cloudflare WAF has not yet been configured with custom rules and a quick shield is needed.
• If bot traffic is significantly higher than real user traffic.
• If the attack targets web pages, forms, login screens, or search endpoints.

Situations to Use with Caution

• If mobile applications, payment providers, webhooks, or API traffic are heavily utilized.
• If you are in a period where search engine bots are conducting critical crawls.
• If your corporate users are accessing from legacy browsers or restricted network environments.
• If your site has subdomains that are not behind Cloudflare proxy.

For sites with API traffic, applying Under Attack mode to the entire domain may lead to some integrations failing. Therefore, it is advisable to plan specific WAF rules, allowlists, or different security levels for API subdomains if possible. For a detailed guide on API security, you may refer to API Security and Rate Limiting Guide.

How to Activate Cloudflare Under Attack Mode? Step-by-Step Implementation

The following steps provide a practical checklist prepared for quick action during an attack. The Cloudflare interface may show slight changes over time, but the logic remains the same: select your domain, raise the security level, and validate incoming traffic through Cloudflare.

1. Log into Your Cloudflare Account

First, log into your Cloudflare account and select the domain under attack. If you manage multiple domains, ensure you are making changes on the correct zone. Activating Under Attack mode on the wrong domain wastes time and allows the actual attack to continue.

2. Check that DNS Records are Proxied

For Under Attack mode to be effective, web traffic must pass through Cloudflare. Ensure that A, AAAA, and CNAME records are in proxied mode (orange cloud) in the DNS section. DNS-only records (grey cloud) do not pass through Cloudflare's security layer. It's essential to check especially for www, root domain, and used subdomains.

If your origin IP address is visible on the internet, attackers can bypass Cloudflare and attack the server directly. Therefore, allowing only HTTP/HTTPS traffic from Cloudflare IP ranges on your server's firewall is a powerful additional measure. You can get support from your hosting provider on this or refer to How to Configure Cloudflare DNS Settings guide.

3. Enable Under Attack Mode from the Security Section

After opening the relevant domain in the Cloudflare panel, locate the Under Attack Mode option in the Security or Overview screen. When you enable this option, Cloudflare will start showing a brief verification page to visitors coming to the site. In some panels, this setting may also appear under Security Level as "I am Under Attack."

After activation, changes typically take effect quickly. In the first minutes, it is essential to monitor Cloudflare Analytics, Security Events, and server resource consumption together. If CPU and connection numbers start to decrease, it means the mode is working. However, if the error rate continues, additional rules should be implemented.

4. Test the Real User Experience

After activating the mode, test the site from various networks. Try accessing the homepage, product page, login page, and payment flow from mobile internet, office network, and preferably from a different location. If users can reach the site after the verification screen, this is the expected behavior. If users are entering an endless verification loop, settings that block cookies, browser compatibility issues, or conflicts with Cloudflare security rules should be examined.

5. Identify the URLs Targeted by the Attack

Under Attack mode provides a general shield; however, real effectiveness is gained through targeted rules. Use Cloudflare Security Events, Web Analytics, hosting access logs, and application logs to find the most requested paths. For example, URLs like /wp-login.php, /xmlrpc.php, /search, /cart, /api/login, or /checkout may be under attack.

Once the target URL is identified, actions can be taken using WAF Custom Rules based on criteria such as country, user-agent, request method, URI path, or bot score. For example, for a specific login endpoint, managed challenges can be applied to IPs sending requests above a reasonable number per minute. For WordPress sites, WordPress Security Measures provides a natural internal linking opportunity.

Differences Between Under Attack Mode and Other Cloudflare Security Options

Cloudflare security tools serve different purposes. Under Attack mode is a quick and general emergency filter; WAF and Rate Limiting offer more targeted, sustainable, and user experience-balanced solutions.

In practice, a good defense approach proceeds as follows: First, the emergency pressure is reduced with Under Attack mode, then the attack pattern is analyzed, WAF and rate limiting rules are added, and finally, permanent structure is reinforced with cache and origin firewall settings.

Recommended Additional Cloudflare Settings During an Attack

While Under Attack mode can be activated with a single button, the success of DDoS defense relies on supportive settings. The following recommendations are the most frequently effective applications in real operations.

Create Targeted Protection with WAF Rules

Cloudflare WAF allows you to take action based on specific conditions. For example, you can apply challenges to POST requests coming only to the /wp-login.php page from specific countries. This way, the attack's target can be isolated without overburdening the entire site.

• Open admin and login pages only to specific countries or IP ranges.
• Block unused endpoints like XML-RPC.
• Apply managed challenges for suspicious user-agent values.
• Limit clients making too many requests on a specific URI path with rate limiting.

Set the Cache Level Correctly

If the origin server needs to respond to every request during a DDoS attack, resources can quickly deplete. Static files, images, CSS, JavaScript, and cacheable pages should be served via Cloudflare edge. In dynamic setups like WordPress, page cache plugins, Cloudflare cache rules, and appropriate cache-control headers can be used together.

For example, on a news or blog-heavy site, pages shown to anonymous visitors can be cached for 5 to 30 minutes. This simple setting reduces TTFB values even during non-attack periods and lightens hosting resources. For performance-related considerations, you may evaluate the Website Acceleration Guide.

Set Rate Limiting Thresholds Realistically

Rate limiting is particularly effective on costly endpoints. However, if thresholds are set arbitrarily, real users may be blocked. For example, a normal user may perform 5-15 searches per minute on a product search page; 100 searches per minute would be abnormal. On the login page, 10 failed attempts within 5 minutes is suspicious in most scenarios.

A sample approach: apply a managed challenge to IPs sending more than 10 requests per minute to /wp-login.php, and apply a temporary block to IPs sending more than 50 requests in 5 minutes. For API endpoints, more refined limits based on user sessions, IPs, tokens, and methods should be preferred.

Hide and Limit the Origin IP Address with Firewall

One of the most critical mistakes made when using Cloudflare is leaving the origin IP address exposed. Old DNS records, subdomains operating directly with IPs, or web services mixed with mail records can allow attackers to reach the server from outside of Cloudflare.

On the server side, opening ports 80 and 443 only to Cloudflare IP ranges provides strong protection. Additionally, SSH, panel, database, and management ports should not be left open to the internet; IP restrictions, strong passwords, 2FA, and preferably VPN should be used. For hosting security, you can refer to cPanel Security Settings and VPS Firewall Configuration content.

Special Considerations for WordPress, WooCommerce, and Corporate Sites

Not every website has the same traffic structure. A blog site, WooCommerce store, and SaaS panel may yield different results with Cloudflare Under Attack mode. Therefore, critical paths should be identified based on the type of site.

WordPress Sites

The most commonly targeted files in WordPress are the /wp-login.php and /xmlrpc.php paths. If you are not using XML-RPC, blocking it is generally safe. Country or IP restrictions can be applied to the admin panel. Additionally, security plugins should not conflict with Cloudflare rules; having too many challenge mechanisms at once can put users in a verification loop.

WooCommerce Stores

Cart, payment, and account pages in WooCommerce require special attention. Since these pages are dynamic, aggressive caching should not be applied. When Under Attack mode is active, ensure that the payment provider's callback or webhook URLs are functioning. If necessary, the IP ranges of the payment provider should be allowlisted or a special rule should be written for the relevant endpoint.

Corporate and API-Using Sites

Corporate portals, CRM integrations, and mobile app APIs may not handle JavaScript challenge screens. In such structures, it may be more appropriate to manage the API subdomain separately instead of applying Under Attack mode to the entire domain. For example, while Under Attack mode is activated for www.example.com, token-based security, rate limiting, and allowlisting can be applied for api.example.com.

Metrics to Monitor After Activating Under Attack Mode

To determine whether a security measure is effective, numerical monitoring is necessary. It is not enough for the site to just load; error rates, server load, and real user behavior should be evaluated together.

• Cloudflare Security Events: Shows how many requests each rule challenged or blocked.
• HTTP status codes: Changes in 403, 429, 502, 503, and 504 errors should be monitored.
• Server CPU and RAM usage: A decrease is expected after Under Attack.
• PHP-FPM and MySQL connections: Indicate relief in the application layer.
• Bandwidth and request counts: The traffic volume and the filtered request rate should be compared.
• Real user conversions: Form submissions, orders, logins, and payment steps should be tested.

For example, if the total number of requests remains the same after Under Attack mode is activated, but requests reaching the origin decrease by 60%, it means that the Cloudflare layer is absorbing a significant load. However, if MySQL CPU usage remains high, the attack may be triggering a specific dynamic query; in this case, application logs should be examined.

How to Safely Disable Under Attack Mode After the Attack

Once the attack traffic returns to normal, keeping Under Attack mode permanently enabled is not recommended for most sites. This is because showing additional verification to every visitor can affect conversion rates, crawling efficiency, and user satisfaction. The disabling process should be carried out as carefully as the activation process.

Steps to Return to Safe Normalcy

• Wait at least 30-60 minutes for traffic levels to normalize.
• Verify that the numbers of challenges and blocks have decreased on the Cloudflare Security Events screen.
• Before disabling Under Attack mode, ensure that targeted WAF and rate limiting rules are active.
• Adjust the security level to a more balanced level like High or Medium.
• Test the site from different devices and monitor the 5xx error rate.
• Continue to monitor logs for 24 hours to check if the attack resumes.

As a good practice, an incident report should be created after the attack. This report should include the attack start time, target URLs, peak request counts, actions taken, effective rules, and permanent improvements. This document significantly shortens the response time for the next event.

Common Mistakes to Avoid

Quick decisions need to be made during a DDoS attack; however, incorrect settings can also block real users. The following mistakes are particularly common under intense stress.

• Believing that Under Attack mode will provide protection without proxied DNS records.
• Leaving the origin IP address exposed and not restricting firewall access outside of Cloudflare IPs.
• Applying challenges to the entire domain without testing API, webhook, and payment callback addresses.
• Writing overly broad WAF block rules that block real customers.
• Aggressively caching cart, payment, or user panel pages that should not be cached.
• Keeping the mode open for weeks after the attack has ended.
• Making decisions based solely on the Cloudflare screen without reviewing server logs.

Especially on e-commerce sites, blocking payment callbacks can cause significant revenue loss. Therefore, it is safer to test security rule writing with logging or managed challenges instead of blocking first. Once the rule's impact is observed, harsher actions can be taken.

How to Plan a More Resilient Defense on Hostragons Infrastructure?

Cloudflare provides a strong front layer; however, successful DDoS defense does not end solely on the CDN side. Hosting infrastructure, software optimization, SSL configuration, DNS management, and backup strategies should be considered together. For a site hosted on Hostragons, the basic approach should be: Cloudflare filters traffic, the hosting layer only responds to clean traffic, and the application is optimized to avoid unnecessary database load.

Before launching a new project, it is important to manage the domain with the correct DNS records, ensure a smooth SSL certificate installation, and choose web server resources suitable for your traffic profile. In this regard, Domain Lookup and Domain Registration, Web Hosting Packages, Corporate Hosting Solutions, and Free SSL certificate links can assist the user.

For high-traffic or high-risk projects, more controlled VPS or managed server options can be considered instead of standard shared hosting. This allows for more flexible configurations of firewalls, web servers, PHP-FPM, Redis, object cache, and database settings. However, regardless of the chosen infrastructure, Cloudflare Under Attack mode should only be positioned as an emergency tool; the permanent security architecture should be supported by WAF, log analysis, and regular updates.

Quick Checklist: The First 15 Minutes During a DDoS Attack

Time is critical during an attack. The following list summarizes what the technical team or site owner can do in the first 15 minutes.

• Log into the Cloudflare panel and select the correct domain.
• Check that the DNS records are in proxied mode (orange cloud).
• Activate Under Attack mode.
• Test the homepage, login, cart, payment, and API endpoints.
• Identify target URLs from the Cloudflare Security Events screen.
• Add specific WAF or rate limiting rules for the most attacked paths.
• Check server CPU, RAM, PHP-FPM, and MySQL status.
• Test for direct access to the origin IP.
• Examine whether allowlisting is needed for payment providers, webhooks, and critical integrations.
• Take note of all actions with timestamps.

If this list is rehearsed regularly, panic decreases during a real attack and the quality of intervention improves. For larger sites, it is recommended to document this process as an incident response plan.

Frequently Asked Questions

Does Cloudflare Under Attack mode fully protect the site?

No. Cloudflare Under Attack mode is particularly effective for reducing HTTP/HTTPS level bot and flood traffic; however, it does not provide complete protection on its own. It should be used alongside proxied DNS records, hidden origin IPs, WAF rules, rate limiting, cache, and server firewall settings.

Does Under Attack mode harm SEO?

Short-term usage usually does not cause significant SEO damage. However, if the mode is left on for an extended period, it can affect search engine crawling efficiency and user experience. Therefore, it is healthier to disable the mode after an attack and continue with targeted security rules.

How long should Cloudflare Under Attack mode remain active?

It can remain active until the attack intensity decreases; practically, it is recommended to monitor for at least 30-60 minutes after traffic returns to normal and then gradually disable it. WAF and rate limiting rules should be in place before disabling the mode.

Does Under Attack mode affect APIs or payment systems?

Yes, it can have an impact. Some API clients, webhook services, and payment callback systems may not be able to complete browser-based security verifications. Therefore, critical endpoints should be tested, and if necessary, allowlisting or special Cloudflare rules should be defined.

Is additional precaution necessary on the hosting side while using Cloudflare?

Yes. Cloudflare provides strong protection at the front layer; however, the origin server's IP address should be hidden, the firewall should only allow necessary traffic, software should be kept updated, and cache configuration should be done correctly. A secure hosting infrastructure is an important part of DDoS resilience.

Conclusion

Cloudflare Under Attack mode is an effective emergency tool that provides quick relief for a site under DDoS attack. When activated with the correct DNS proxy settings, it reduces bot traffic, lowers server load, and increases the chances of real users accessing the site. For optimal results, this mode should be supported by WAF rules, rate limiting, cache optimization, and origin firewall security.

If you want your website to function more resiliently against attacks, regularly review your infrastructure, DNS management, and SSL configuration. By exploring Hostragons’ hosting, domain, and SSL solutions, you can establish a more secure and sustainable foundation for your site.