Website under DDoS attack? What to do right now

If your site is suddenly slow or down and your server shows far more requests than usual, you may be under a DDoS attack. The most effective thing you can do right now is to get filtering in front of your server, because a server that is already overwhelmed cannot defend itself. This guide walks you through recognizing an attack, the first hour of response, and the setup that makes the next attack much less painful.

How to tell it's a DDoS attack

A distributed denial-of-service (DDoS) attack floods your site with traffic from many sources at once, so real visitors can't get through. Not every traffic spike is an attack, though. A newsletter, a TV mention or a sale can look similar at first glance. Look for these patterns:

• The spike has no business reason. No campaign, no press, no launch, yet requests jump sharply.
• Requests hit the same few URLs. Often the homepage, a search page, a login page or a URL with random query strings (/?x=83729) designed to skip caches.
• Odd traffic sources. Many requests from countries where you have no customers, from hosting provider IP ranges, or with identical or empty user agents.
• No conversions. Traffic goes up while sales, sign-ups and time on page don't move at all.
• Your server is maxed out. CPU, PHP workers or database connections are at their limit, and the error log fills with timeouts and 502/503/504 errors.

Check your access log

If you have shell access, a quick look at the access log tells you a lot. These commands show the top IPs and the most requested paths (adjust the log path for your server):

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20

A handful of IPs sending thousands of requests points to a small attack you can block directly. Thousands of IPs each sending a moderate amount points to a botnet, which is much harder to stop at the server level.

Types of attacks you might face

Knowing the rough type helps you pick the right response.

Most attacks on small and mid-sized business sites are Layer 7 HTTP floods. They don't need huge bandwidth, because each request makes your server do expensive work: render a page, run a search, query the database. A few hundred uncached requests per second can be enough to take down a typical shop or CMS.

What to do in the first hour

Stay calm and work through this in order. Write down what you do and when, because you'll need it later.

1. Confirm and communicate

Make sure it's not a broken deploy, a failing plugin or a legitimate spike. Then tell the people who need to know: your team, your agency, and your hosting provider. Hosts often see the attack in their network monitoring and may already be filtering or, in some cases, null-routing your IP to protect other customers.

2. Contact your host

Ask your host directly: what do they see, what protection do they have, and can they filter at the network level? Some hosts include basic DDoS protection, others don't. If your server is being null-routed, you need a filtering layer in front of it before it comes back online.

3. Block what you can identify

If the attack comes from a small number of IPs or ranges, block them in your firewall or web server config. If it targets one expensive URL, such as a search endpoint, temporarily rate limit or disable it. If it comes mostly from countries you don't serve, a temporary geo block or challenge can buy time. These are stopgaps, not a strategy.

4. Put a filtering layer in front of your server

The real fix is to stop bad traffic before it reaches your origin. A reverse proxy or CDN with DDoS protection absorbs and filters requests at the edge, and your server only sees what gets through. Onboarding usually means switching your domain's nameservers, which takes effect as DNS caches expire. If you do this mid-attack, follow a checklist so you don't lose email or other records. Our guide on changing nameservers without downtime covers exactly that.

5. Reduce the work each request causes

While the attack runs, make every request cheaper. Serve cached pages wherever possible, switch off heavy features you can live without for a day (live search, related product widgets, external API calls), and make sure your caching isn't bypassed by random query strings.

Mistakes to avoid during an attack

• Don't just upgrade the server. More CPU helps briefly, but attackers can usually scale faster than your hosting budget. It also doesn't stop bandwidth floods.
• Don't pay a ransom. Some attacks come with a demand. Paying doesn't guarantee anything and marks you as a willing target. Report extortion to the police.
• Don't block too broadly. Blocking whole countries or all bots can lock out customers and search engine crawlers. Prefer challenges over hard blocks where you're unsure, and remove temporary rules once the attack ends.
• Don't forget other attack surfaces. A DDoS is sometimes a distraction. Check logins, admin accounts and recent changes afterwards. CISA's overview of denial-of-service attacks mentions this too.

After the attack: harden your setup

Once things are quiet, use what you learned. The goal is that the next attack hits a filter, not your server.

Keep a proxy in front permanently

Edge filtering works best when it's already in place. Adding it mid-attack costs you time while DNS changes propagate. If you're not sure what a CDN actually does for you beyond speed, read what a CDN is and whether your site needs one.

Cache as much as you safely can

Every page served from a cache is a request your server never sees. Public pages like the homepage, categories, product pages and blog posts should be cached. Personal pages like cart, checkout and account must stay dynamic. A high cache hit ratio also means your server has more headroom for real visitors, and a fast origin helps too: see how to reduce TTFB.

Lock down the origin

Allow HTTP and HTTPS traffic to your server only from your proxy's IP ranges. Keep the origin IP out of public DNS records, email headers and old subdomains, since those are the usual ways attackers find it.

Set rate limits and alerts

Rate limits on logins, search and APIs stop both floods and brute force attempts. Alerts on traffic spikes and error rates mean you learn about the next attack from a notification, not from a customer.

Write a short runbook

One page is enough: who to call at your host, who has access to DNS and the proxy dashboard, which rules to switch on, and how to tell customers. In the middle of an attack, nobody wants to search for passwords.

How fast.site helps

fast.site sits in front of your existing hosting. You keep your host and point your domain's nameservers to fast.site. From then on, traffic reaches the edge network first and is filtered there before anything is passed on to your origin.

Layer 7 DDoS detection runs automatically on all domains, with no configuration needed. On top of that, you can block IPs and CIDR ranges, block or challenge whole countries with a CAPTCHA, create your own challenge rules, and set per-IP rate limits. Managed rulesets protect against SQL injection, XSS and bad bots. See the security docs for details.

Caching reduces the load further. Public pages served from the edge show fs-cache: HIT and never touch your server, while carts, checkouts and logged-in sessions show BYPASS and go to your origin as usual. Analytics shows requests, error rates and origin bandwidth, and anomaly alerts notify you about traffic spikes.

If you're under attack right now, go to the under attack page for the fastest path. Otherwise you can set up protection calmly with a free 7-day trial, no credit card needed, and check the result on your own site. Plans and included traffic are on the pricing page.

FAQ

How long does a DDoS attack last?

It varies a lot. Some attacks last minutes, others come in waves over days. Short bursts are common, often as a test before a larger attack or alongside a ransom demand. That's why protection that is always on is more useful than something you switch on during an attack.

Can a DDoS attack hurt my SEO?

A short outage usually has no lasting effect. If your site stays unreachable or returns errors for a longer period, search engines may crawl it less and temporarily drop pages. Getting the site back up quickly and returning proper status codes limits the damage.

Is a DDoS attack illegal?

Yes, in most countries launching a DDoS attack is a criminal offense. Keep logs, timestamps and any ransom messages, and report the attack to the police or your national cybercrime unit. This is especially important when money is demanded.

Can a WordPress security plugin stop a DDoS attack?

Not really. A plugin runs inside WordPress, so every request still reaches your server, starts PHP and often queries the database before the plugin can block it. That's exactly the load a DDoS relies on. Plugins are useful against login attacks and malware, but DDoS filtering has to happen in front of the server.

Why is my site slow even though traffic looks normal?

Then it's probably not a DDoS. Common causes are slow hosting, heavy plugins, uncached pages or large images. The support article on a slow site is a good place to start.