DDoS Protection for Websites That Actually Stops Attacks

Short, sub-10-minute HTTP floods can take down a website even when bandwidth looks normal. Put a reverse proxy with an anycast CDN and WAF in front of the origin, hide the origin IP, enable rate limiting and caching, use scrubbing or upstream filtering for network floods, then verify that test traffic is blocked before relying on the design.

You may first notice the problem as browser timeouts, intermittent 502 responses, or a web server whose CPU is pinned while the network interface looks ordinary. That pattern is why effective DDoS protection for websites has to address application behavior, origin exposure, and response speed, not just headline bandwidth capacity.

Table of Contents

• Your Site Is Down Under Load and Logs Show Flood Traffic
  • What this looks like on shared infrastructure
• How DDoS Attacks Against Websites Actually Work
• Mitigation Layers Compared From Network to Application
  • Reverse proxy behavior
• Building a Resilient Architecture With CDN WAF and Scrubbing
  • Step 1, establish the traffic path
  • Step 2, configure Nginx for bounded work
  • Step 3, separate application and network mitigation
  • Step 4, verify and prepare rollback
• Choosing Between Managed Protection and Self Hosted Controls
  • Always-on versus on-demand scrubbing
• Monitoring Detection and Incident Response Playbook
  • Confirm the failing layer
  • Run the incident sequence
• Cost Performance and Next Steps for Your Website

Your Site Is Down Under Load and Logs Show Flood Traffic

The symptom usually reads like this: 504 Gateway Timeout, 502 Bad Gateway, or a site that loads once and then stalls. On the server, Nginx workers accumulate, PHP-FPM reaches its process limit, PostgreSQL connections queue, and the origin becomes unavailable to legitimate visitors even though the incoming link isn't saturated.

The immediate fix is architectural. Place the site behind a reverse proxy CDN and WAF, allow only proxy addresses to reach the origin, turn on caching and endpoint-specific rate limiting, and send network floods to upstream filtering or a scrubbing service. Then test the path from the edge to the origin and confirm that direct-origin traffic fails.

Production rule: If an attacker can reach the origin directly, edge mitigation is optional from the attacker's perspective.

The most common cause is an exposed origin address. Old DNS records, forgotten staging names, mail server headers, certificate transparency records, and application responses can reveal it. The attacker then bypasses the CDN and sends requests straight to Nginx, Apache, or the application listener.

Next comes missing application controls. A login, search, checkout, or API endpoint can perform expensive work for every valid request. A distributed HTTP flood doesn't need one source to exceed a local threshold. It only needs enough aggregate work to exhaust workers, database connections, CPU, or memory.

A third cause is incorrect caching. If every request reaches PHP or a backend API, the CDN can't absorb repeated traffic. A fourth is slow escalation, especially when on-demand mitigation requires a human to detect the event, activate protection, and wait for routing changes.

What this looks like on shared infrastructure

On multi-tenant bare metal and VPS systems, one noisy tenant can expose the weakness of a shared edge design. The attacked virtual machine consumes CPU and connection tracking entries, but neighboring workloads may also experience storage latency, network queue pressure, or hypervisor contention. The correct response isn't to reboot the affected VM. Rebooting removes symptoms briefly while leaving the attack path open.

A useful first split is whether the origin is receiving the flood. If the edge reports an incident but the origin access log stays quiet, the architecture is doing its job. If the origin sees the same request pattern as the edge, bypass traffic or an incomplete allowlist is likely.

How DDoS Attacks Against Websites Actually Work

Start with the layer that is failing, not the product category printed on a vendor page. A volumetric attack fills the road to your facility. A protocol attack consumes the network's ability to maintain connections. An application attack reaches the checkout counter and keeps asking for slow service until real customers can't get served.

Volumetric attacks use large amounts of traffic to consume transit, interface, or upstream capacity. UDP floods and amplification attacks are typical examples. In an amplification attack, the attacker causes third-party services to send larger responses toward the victim. Your web server might be healthy, but users can't reach the network that carries it.

Protocol attacks target connection handling. A SYN flood sends connection attempts that cause the operating system to reserve resources while waiting for completion. The important signals include SYN backlog pressure, retransmissions, and exhausted connection tracking, not just megabits per second.

Application-layer attacks send HTTP requests that look valid. A request to /login, /search, or an API endpoint may pass a basic firewall because it uses normal TCP and HTTP. The cost appears later, in TLS handshakes, web workers, template rendering, session lookups, cache misses, or database queries.

Bandwidth measures how much traffic arrived. It doesn't tell you how much work each request forced the origin to perform.

Attackers distribute requests across many sources, so blocking individual addresses rarely solves a sustained HTTP flood. They may also switch between GET and POST requests, vary paths, or target an endpoint that bypasses cache. The application sees legitimate syntax, but the request pattern is hostile.

A useful diagnostic map looks like this:

• Transit saturation: Use upstream filtering, anycast distribution, or scrubbing before traffic reaches the facility.
• Handshake exhaustion: Use provider-level transport controls, SYN protection, and upstream filtering.
• Worker or database exhaustion: Use WAF rules, behavioral filtering, caching, and endpoint-specific rate limits.
• Mixed symptoms: Keep the reverse proxy in front, then combine edge application controls with network mitigation.

A website owner evaluating dedicated server DDoS protection should ask where filtering occurs and whether the provider protects only the interface or also the HTTP path. The distinction matters because a lower-bandwidth request flood can still make a server unavailable.

Mitigation Layers Compared From Network to Application

The controls below aren't interchangeable. Each one sees a different part of the request path and fails differently when configured poorly. A reverse proxy is valuable because it can inspect traffic before it reaches the origin, while upstream controls are necessary when the traffic would otherwise consume the link before the proxy can process it.

A traditional host firewall still has a role. It can restrict administrative ports, reject unwanted protocols, and reduce the local attack surface. It can't absorb traffic that has already consumed the upstream connection, and it can't reliably distinguish a valid HTTP request from a malicious one without application context. A layered firewall with DDoS protection is more useful when its role is clearly separated from edge WAF and upstream scrubbing.

Reverse proxy behavior

DDoS mitigation commonly operates as a reverse proxy. The proxy accepts the visitor connection, evaluates it, serves cached content where possible, and forwards only approved requests to the origin. Cloudflare's civil society infrastructure report describes this model as inspection before traffic reaches the origin, allowing malicious requests to be filtered while legitimate visitors continue through the service. The reverse proxy architecture is explained in this report.

The failure mode to watch is bypass. If the origin accepts traffic from the public internet, the attacker can ignore the proxy. The second failure mode is over-blocking. A WAF rule that stops the attack but rejects payment requests from real customers is technically effective and operationally unacceptable.

Building a Resilient Architecture With CDN WAF and Scrubbing

Start with control of the origin server, a reverse proxy or CDN account, access to the web server, and an upstream mitigation contact. The examples below assume Ubuntu Server 24.04 LTS, Nginx, and systemd. The same architecture works with Debian 12, but package names and existing configuration paths may differ.

Step 1, establish the traffic path

The intended path is:

visitor -> anycast CDN -> WAF and rate limit -> origin firewall -> Nginx -> application

The origin should accept web traffic only from the CDN's published address ranges. Don't copy a static list into a script and forget it. Use the provider's maintained ranges, update them through change control, and test the result from an allowed edge request and a denied direct request.

On Ubuntu with UFW, first review the current rules before changing them:

sudo ufw status numbered
sudo ss -lntp | grep -E ':(80|443)s'

Expected output should show the web listener and the current firewall policy. Apply the provider's documented proxy ranges only after confirming the list and your administrative access path:

sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

The last two rules are only a starting point. Replace broad web access with the proxy provider's ranges when the service supports it. Keep an out-of-band console or remote hands path available before tightening access.

Step 2, configure Nginx for bounded work

Use Nginx limits as a second control, not as your primary volumetric defense. The following configuration limits request concurrency and connections at the origin. Tune the values from normal behavior, and don't paste them into a high-traffic production site without testing.

http {
    limit_req_zone $binary_remote_addr zone=login_limit:10m rate=5r/s;
    limit_conn_zone $binary_remote_addr zone=perip:10m;

    server {
        listen 443 ssl http2;
        server_name example.invalid;

        limit_conn perip 40;

        location = /login {
            limit_req zone=login_limit burst=20 nodelay;
            proxy_pass 
        }

        location / {
            proxy_pass 
        }
    }
}

Validate before reload:

sudo nginx -t
sudo systemctl reload nginx
sudo journalctl -u nginx --since "5 minutes ago" --no-pager

A production system should apply stricter controls to expensive endpoints than to static pages. Cache immutable assets at the edge, and bypass the origin for content that doesn't need dynamic generation. Cloudflare's proactive guidance recommends managed DDoS rules at High sensitivity, WAF custom rules, rate limiting, origin restriction to Cloudflare addresses, and caching to reduce origin strain. Review the documented proactive defense settings.

Step 3, separate application and network mitigation

Use CDN and WAF controls for HTTP floods, bot filtering, and endpoint abuse. Use upstream filtering or BGP scrubbing for traffic that threatens the network link or router. BGP diversion can steer traffic to a clean path, but it introduces routing operations that need testing.

A 2025 study of five leading scrubbing providers found always-on scrubbing covered about 11k prefixes, compared with 5.6k on-demand prefixes. Upstream-change rerouting covered about 1k prefixes, while origin-change rerouting covered 104. The RIPE Labs analysis explains these deployment patterns. Always-on protection reduces failover delay, while on-demand activation can leave a short interval before clean-path steering.

Tampa colocation can be relevant for a Florida business that needs local hands, regional latency, and a documented continuity plan for hurricane or grid events. Geography doesn't replace mitigation, but facility redundancy, multiple upstreams, and on-site access can shorten recovery when a network or hardware issue accompanies an attack. ARPHost's traffic management solutions are one option to evaluate alongside the CDN and upstream design.

Step 4, verify and prepare rollback

Test the public path without generating abusive traffic:

curl -sS -o /dev/null -w 'status=%{http_code} connect=%{time_connect} start=%{time_starttransfer} total=%{time_total}n' 
curl -sS -I 

Then inspect the origin logs and confirm the source addresses are the proxy addresses, not arbitrary public clients:

sudo tail -n 50 /var/log/nginx/access.log
sudo ss -s

Common failures include a leaked origin in an email header, a forgotten staging hostname, incorrect real-IP configuration, and a cache rule that stores personalized responses. For rollback, keep a timestamped copy of every Nginx file, remove the new limit directives, restore the previous firewall rule set through console access, and reload only after nginx -t passes. Never disable the edge and expose the origin as an emergency shortcut unless upstream staff have approved the risk.

Choosing Between Managed Protection and Self Hosted Controls

The decision isn't whether you can install Nginx or write an iptables rule. It depends on where the traffic is stopped, who watches the alerts, and how quickly a mitigation action must occur.

Self-hosted controls are useful at the origin. Nginx can cap expensive requests, Linux can restrict ports, and an application can reject abusive sessions with full business context. None of those controls can restore an already saturated transit link. They also depend on someone being available to identify the attack, select a rule, deploy it, and remove it later.

Managed protection moves detection and edge capacity outside the origin. The tradeoff is less direct control over classification and a need to understand how the provider handles false positives, emergency rule changes, logs, and origin verification. A managed service that only advertises raw capacity but can't explain HTTP handling isn't enough for a website.

Always-on versus on-demand scrubbing

Always-on scrubbing keeps traffic on a protected path continuously. That can reduce failover time and avoid routing churn, but it puts more trust in the provider's classification and operational process. On-demand scrubbing changes the path after detection. It may be economical for some networks, but the site can remain exposed while detection and rerouting occur.

RPKI deserves attention in either model. A global BGP study of the top five scrubbing providers found 48% of prefixes temporarily originated by scrubbers during attacks lacked valid RPKI ROAs, including 12.5% invalid and 35.5% notfound. The University of Twente research details the route-validation risk. If your mitigation design depends on BGP diversion, maintain valid route authorizations and alert on unexpected origin changes.

Stay managed when the team lacks continuous coverage or the site can't tolerate a response delay. Self-host controls when you need deep application tuning and already operate the network. Use a hybrid model when the edge must absorb the flood while your own Nginx, application, and routing policies preserve service quality.

Monitoring Detection and Incident Response Playbook

Protection that nobody verifies becomes a configuration assumption. Monitor the edge event stream, request rates by endpoint, response codes, origin CPU, memory pressure, connection counts, SYN backlog, and application latency. A website can look quiet at the interface while /login or /api/search consumes every worker.

Confirm the failing layer

On Ubuntu 24.04 or Debian 12, begin with service and socket state:

systemctl --failed
systemctl status nginx --no-pager
ss -s
nstat -az | grep -Ei 'Tcp|Listen|Retrans'

A healthy system might show an active Nginx service, stable TCP counters, and a listening socket. During a protocol event, watch for rising retransmissions, listen overflow, or connection counts that don't match normal traffic.

Check CPU and load without assuming load average equals attack volume:

uptime
vmstat 1 5
pidstat -p $(pgrep -o nginx) -ru 1 5

Inspect the busiest request paths:

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

If the output is dominated by one dynamic endpoint, apply an endpoint rule rather than blocking the entire site. If the origin log is quiet while the edge reports mitigation, leave the origin isolated and investigate only the edge policy.

Run the incident sequence

1. Confirm the event. Compare edge mitigation events with status codes, origin CPU, and request paths. Rule out a deployment, database failure, or legitimate launch.
2. Increase edge enforcement. Put the managed DDoS ruleset at its documented high sensitivity, add a temporary WAF rule for the affected path, and apply a narrowly scoped rate limit.
3. Verify origin isolation. Test that the origin firewall accepts proxy traffic and rejects direct public access. Review recent DNS and application changes for leaks.
4. Escalate network floods. Contact upstream filtering or scrubbing when the interface, transit, or router is under pressure. Don't wait for the web server to fail before escalating.
5. Preserve evidence. Save edge event identifiers, access logs, firewall counters, timestamps, affected paths, and rule changes. Record what was enabled and when.
6. Restore carefully. Remove temporary challenges only after traffic normalizes, then confirm error rates and user workflows. Keep a post-incident note with the first signal and the slowest response step.

Cloudflare documents average mitigation of Layer 3/4 and HTTP DDoS attacks in up to three seconds, with advanced TCP and DNS protection described as immediate. Its DDoS protection documentation explains the behavior. Treat that as a provider-specific capability, not a universal service-level expectation. Your own alerting, edge policy, and origin isolation still determine whether the site remains reachable.

Cloudflare reported 23.2 million network-layer DDoS attacks and 29.64 trillion HTTP DDoS requests in the first half of 2026, equivalent to roughly 5,343 network-layer attacks per hour or about 128,000 per day. The first-half 2026 report provides the underlying figures. The operational lesson is simple: detection must be automatic, and the runbook must be executable without waiting for a person to notice a graph.

Cost Performance and Next Steps for Your Website

The cheapest architecture is not the one with the fewest controls. Caching reduces origin work, anycast spreads traffic across edge locations, and scrubbing prevents network floods from consuming the local link. Each layer adds configuration, logging, and possible latency, so tune for real users rather than enabling every challenge globally.

Short attacks make automation valuable. Cloudflare reported that 89% of network-layer attacks and 71% of HTTP attacks ended in under ten minutes, while 94% of network-layer attacks stayed below 500 Mbps. The 2025 fourth-quarter threat report documents those patterns. The same report recorded 47.1 million attacks in 2025, up 121% year over year, with an average of 5,376 attacks every hour. Those figures support investing in fast classification, endpoint controls, and origin hardening instead of planning only for a rare massive flood.

Use managed protection when burst absorption and response coverage matter more than owning every tuning decision. Keep local Nginx, firewall, and application controls even with a managed edge. Review false positives through real user flows, especially login, checkout, APIs, and mobile clients.

For adjacent infrastructure work, see ARPHost's VPS hosting, bare metal servers, and managed services resources. The right next step is an origin exposure review, followed by a controlled block test and a documented escalation path.

ARPHost, LLC provides VPS, bare metal, colocation, Proxmox private clouds, secure web hosting, and managed IT operations with network and security controls suited to layered website protection. Review ARPHost, LLC to discuss origin hardening, traffic filtering, monitoring, and the infrastructure path that fits your workload.