DDoS protection for websites: what actually helps

Good DDoS protection for a website is not one product but a few layers that each stop a different kind of attack: network filtering for raw floods, a reverse proxy in front of the site, rules against application-layer attacks, and an origin server that only talks to that proxy. Timing matters most, because protection that is already in place works on the first request, while protection added mid-attack costs you hours. If your site is under attack right now, go to the under attack page or our guide on what to do when your website is under DDoS attack.

Why protection belongs in front of your server

A server that is busy answering junk requests cannot also decide which requests are junk. By the time a firewall rule or security plugin on your server inspects a request, the bandwidth is used and PHP has often started. Effective protection filters as far away from the origin as possible.

For prevention, the useful question is which layer stops which type of attack:

No single layer covers everything: a proxy without origin hardening can be bypassed, and a hardened origin without a proxy faces every HTTP flood alone.

The four layers in detail

1. Network level: volumetric and protocol floods

Volumetric attacks fill the connection to your server with more traffic than it can carry. Nothing you configure on the server helps, because the link is saturated before your firewall sees a packet. This layer is handled upstream by your host's network or a dedicated scrubbing service. Your job is to know what your host does here, and to hide your origin IP behind a proxy so attackers have to flood the proxy's network instead of your server's connection.

2. A reverse proxy in front of the whole site

A full-site reverse proxy receives every request for your domain, answers what it can from its cache and forwards the rest to your origin. Two effects matter:

• Cached pages are cheap. A flood against your homepage is harmless if the homepage is served from the edge and never reaches your server.
• Filtering happens before the origin. Rules, rate limits and challenges run at the edge, so blocked requests cost your server nothing.

Make sure the proxy covers your HTML. An asset CDN that only serves images and scripts from a separate hostname speeds things up, but page requests still go straight to your server, and so do attacks. The guide on what a CDN is explains the difference.

3. WAF, rate limiting and bot rules for Layer 7

Application-layer floods are the most common attacks on small and mid-sized sites and the hardest to spot, because each request looks legitimate. They target the URLs that make your server work hardest, so plan your rules around those:

A web application firewall (WAF) with managed rulesets also blocks exploit attempts such as SQL injection and cross-site scripting, and bot rules keep scrapers out. Country rules help if you serve only a few markets, but prefer a challenge over a hard block so customers on a VPN still get through.

4. Origin hardening

A proxy only protects you if attackers cannot go around it. Once your site is behind one, lock down the origin:

• Accept web traffic only from the proxy. Configure the server or host firewall so ports 80 and 443 only accept connections from your proxy provider's published IP ranges.
• Assume old DNS records are known. If your domain used to point straight at your server, services that archive historical DNS data make that IP easy to find. Ask your host whether you can get a new IP after the move.
• Check subdomains. Records like staging, dev, ftp, cpanel or mail often point directly at the same server and reveal the origin.
• Separate email from the web server. If your MX record points at the web server, or the server sends contact form emails itself, its IP appears in DNS and in the Received headers of every email. Also check your SPF record for ip4: entries that give the server away.

A quick check shows which records resolve to your origin IP:

dig +short example.com A
dig +short mail.example.com A
dig +short example.com MX
dig +short example.com TXT

Any answer that contains your server's IP is a way around your proxy.

What your host covers, and what it doesn't

Many hosts filter large volumetric attacks at the edge of their network. That protects their infrastructure and all customers on it, which is not the same as protecting your site. Typical gaps:

• Layer 7 floods pass through. A few hundred HTTP requests per second are tiny for a data center network but enough to overload a typical CMS or shop.
• Null routing takes you offline. If an attack threatens the network, some hosts stop routing traffic to the targeted IP. Other customers are safe, your site is down.
• Resource limits bite. On shared or managed plans, an attack can push your account into its CPU or process limits, and your site gets throttled.
• No per-site rules. You usually can't set your own rate limits or challenges at the host's network level.

Ask your host these questions and keep the answers:

1. Which attack types do you filter, and is HTTP flood (Layer 7) filtering part of my plan?
2. What happens to my site during a large attack: throttling, null routing, suspension?
3. Can I restrict my server to accept web traffic only from a proxy's IP ranges?
4. How do I reach support during an attack?

How to choose a protection service

If your host covers the network level but not your application, a proxy-based service fills the gap. Compare by criteria, not marketing labels:

• Whole-site coverage. It proxies your HTML, not only static assets.
• Always on. Permanent filtering needs no switch-over during an attack. With on-demand services, the switching time is exactly the problem.
• Layer 7 tools you control. Automatic detection plus your own IP blocks, country rules, challenges and rate limits.
• Safe caching and visibility. It respects your Cache-Control headers, never caches carts or logged-in pages, and shows requests and errors with alerts.
• Good bots keep working. Search engine crawlers and payment callbacks still get through when rules tighten.
• Complete DNS. Whether you switch nameservers or a single record, MX, TXT and SRV records must keep working. Our checklist for changing nameservers without downtime covers this.
• Billing during attacks. Ask how attack traffic counts towards included traffic.
• Support. How you reach a person during an attack.

The UK National Cyber Security Centre's denial of service guidance is a good vendor-neutral read on planning.

A preparation checklist

Work through this list once, then review it every few months:

• Contacts. Host support with your customer number, your agency or developer, your protection provider, and who decides about switching off features or informing customers.
• Access. At least two people can log in to the registrar, DNS and proxy dashboard, each with their own account and two-factor authentication.
• DNS. Keep a current export of your zone and know which records must stay reachable.
• Monitoring. An external uptime check, alerts for traffic spikes and rising 5xx errors, and a view of your origin's CPU.
• Runbook. One page with the stricter rules to switch on, the expensive features you can turn off for a day (live search, recommendation widgets, external API calls) and a short note for customers.
• Origin test. Confirm your origin refuses direct traffic, using your server's IP:

curl -sI --max-time 10 --resolve www.example.com:443:203.0.113.10 https://www.example.com/

If this returns a response instead of timing out or being refused, your origin still accepts traffic that bypasses the proxy.

How fast.site helps

fast.site is a full-site reverse proxy in front of your existing hosting. You keep your host and switch your domain's nameservers to fast.site. From then on every request reaches the edge network first and is filtered there before anything is passed to your origin. fast.site manages your DNS zone, including MX, TXT and SRV records, as described in the DNS docs.

Layer 7 DDoS detection runs automatically on all domains, with no configuration needed. You can also block IPs and CIDR ranges, block countries or send them to a CAPTCHA challenge, create your own challenge rules and set per-IP rate limits. Managed rulesets filter SQL injection, XSS and bad bots. The security docs list all options.

Caching takes load off your server too: public pages show fs-cache: HIT and are served from the edge, while carts, checkouts and logged-in sessions show BYPASS. Analytics shows requests, error rates and origin bandwidth, and anomaly alerts flag traffic spikes. Network-level protection for your origin's own connection stays with your host, so lock your origin to the proxy.

Set it up calmly and measure the result on your own site. You can try it with a free 7-day trial, no credit card needed. Plans are on the pricing page.

FAQ

Do small websites need DDoS protection?

Size doesn't protect you. Small sites go down under a modest HTTP flood, and on shared hosting an attack on a neighboring site can affect yours too. If downtime costs you orders, leads or reputation, protection in front of the site is worth setting up.

Is DDoS protection included in my web hosting?

Often partly. Many hosts filter large network floods to protect their infrastructure, but application-layer floods against your site usually pass through, and some hosts null-route an attacked IP. Ask exactly which attack types are covered.

Does a CDN protect against DDoS attacks?

Only if it proxies your whole site and filters traffic before it reaches your server. An asset CDN on a separate hostname does not protect your pages, because HTML requests still go directly to your origin.

Does DDoS protection slow down my website?

A proxy adds a stop between visitor and server, but cached pages from a nearby edge often arrive faster. It depends on your site and visitors, so run a before-and-after comparison as described in our guide on measuring website speed.