Website Down During Suspected DDoS Attack: What to Check and Fix

TL;DR — If your hosting company says your site is under a DDoS attack (a flood of unwanted traffic), first confirm whether the site is failing at the DNS/CDN layer, the web server, or the app itself. The most common working fix is to put the site behind a CDN/WAF (content delivery network/web application firewall), enable "Under Attack" or managed challenge mode in your provider dashboard, and restrict your origin server so only the CDN can reach it. Reading time: ~6 min

The scenario

It is a normal Tuesday afternoon. Your client messages you that the homepage is timing out, your uptime monitor starts sending alerts, and the hosting company replies with a short note: "We are seeing a DDoS attack against your server IP." You open the site and sometimes it hangs, sometimes it shows a 502 or 503, and sometimes it loads with no CSS because assets are failing too. You need to answer two questions fast: is this really attack traffic, and what can you change right now to get the site back up without making things worse?

Symptoms

• Visitors see one of these in the browser:
  • "This site can’t be reached"
  • "Connection timed out"
  • "502 Bad Gateway"
  • "503 Service Unavailable"
  • "504 Gateway Timeout"
  • A hosting-provider error page saying the origin is unavailable
• Uptime checks fail from multiple regions at once
• Your provider dashboard shows unusually high bandwidth, requests, or connections
• Web server logs show a sudden spike of repeated requests from many IPs, often to /, /wp-login.php, /xmlrpc.php, /search, or random query strings
• CPU, memory, or network graphs jump sharply even though you did not deploy anything
• You can sometimes reach the site through the CDN hostname, but not the origin IP directly — or the reverse
• DNS changes were made recently, and the site went down around the same time

Likely causes

Step-by-step diagnosis

1. Check whether the outage is global or just your connection.

   • Use an external checker from your uptime service, or ask two people on different networks to open the site.
   • If multiple regions fail at the same time, continue to step 2.
   • If only one office or one country fails, jump to Fixes → Rate limiting or firewall rules are blocking real users too.

2. Check where your domain points right now.

   • Command:

dig +short yourdomain.com

• What it means:
  • If this returns your server's real IP address, your origin is exposed. Jump to Fixes → Site is not properly behind a CDN/WAF.
  • If it returns a CDN hostname or CDN-owned IPs, continue to step 3.

1. Check whether the origin is still publicly reachable.

   • In your cloud or hosting dashboard, open the server or firewall page. Look for inbound rules on ports 80 and 443.
   • Typical path: Server/Instance → Networking → Firewall/Security Group → Inbound rules.
   • What it means:
     • If you see 0.0.0.0/0 allowed to 80/443, the origin is still open to the internet. Jump to Fixes → CDN/WAF is enabled, but the origin still accepts direct traffic.
     • If only your CDN IP ranges or load balancer are allowed, continue to step 4.

2. Check traffic and resource graphs during the outage window.

   • In your provider dashboard: Server/Load Balancer → Metrics/Monitoring.
   • What it means:
     • If bandwidth or packets spike massively, this supports a real DDoS. Jump to Fixes → Real volumetric or HTTP DDoS saturating the origin.
     • If CPU or memory is maxed but bandwidth is moderate, jump to Fixes → Web server or app is overloaded by expensive requests.

3. Check whether DNS is correct after any recent changes.

   • Command:

dig yourdomain.com

• What it means:
  • If the answer points to an old IP, a decommissioned load balancer, or the wrong provider, jump to Fixes → DNS or routing change during the incident.
  • If DNS is correct, continue to step 6.

1. Review firewall/WAF events for false positives.
   • In your CDN/WAF dashboard, open Security/Firewall → Events/Activity.
   • What it means:
     • If you see many legitimate users challenged or blocked, especially from your normal customer countries, jump to Fixes → Rate limiting or firewall rules are blocking real users too.
     • If not, the most likely issue is still the origin being overwhelmed; return to the matching fix above.

[Users] ---- 1. DNS lookup ----> [DNS]
   |                               |
   | 2. HTTPS request              | 3. answer
   v                               v
 [CDN/WAF] ---- 4. filtered ----> [Origin]
                                   |
                                   | 5. app/db work
                                   v
                                  [App]

Fixes

Real volumetric or HTTP DDoS saturating the origin

1. In your CDN/WAF dashboard, enable the strongest temporary protection mode available.
   • Typical path: Security → Overview → Under Attack/Managed Challenge.
2. If your provider offers a DDoS-protected load balancer, move traffic to it now.
   • Typical path: Networking → Load Balancer → Create/Enable protection.
3. Add a temporary rate limit for obvious hot paths.
   • Example nginx config:

limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;

server {
    location / {
        limit_req zone=perip burst=20 nodelay;
        proxy_pass http://app;
    }
    location = /wp-login.php {
        limit_req zone=perip burst=5 nodelay;
        proxy_pass http://app;
    }
}

1. Reload nginx:

sudo nginx -t && sudo systemctl reload nginx

Verify it worked: your provider traffic graph should stay high, but origin CPU/connections should drop and the site should load through the CDN.

Site is not properly behind a CDN/WAF

1. In your DNS provider dashboard, change the A record for yourdomain.com and www to the CDN-proxied target.
   • Typical path: DNS → Records → Edit A/CNAME.
2. If your CDN uses a CNAME setup, point www to the provided hostname and set the root domain as instructed by the provider.
3. Lower TTL (DNS cache time) temporarily to 300 seconds before the change if your dashboard allows it.
4. Confirm the new answer:

dig +short yourdomain.com

Verify it worked: dig should no longer return the raw server IP, and browser requests should show CDN response headers.

CDN/WAF is enabled, but the origin still accepts direct traffic

⚠️ Restricting origin access can cause downtime if you forget to allow your CDN or load balancer IP ranges first. Add allow rules before removing public access.

1. In your server firewall or cloud security group, allow ports 80/443 only from your CDN or load balancer IP ranges.
   • Typical path: Server → Networking → Firewall/Security Group → Inbound rules.
2. Remove broad public rules like 0.0.0.0/0 for 80/443.
3. If you manage the server firewall directly, an example with ufw:

sudo ufw delete allow 80/tcp
sudo ufw delete allow 443/tcp
sudo ufw allow from 203.0.113.0/24 to any port 80 proto tcp
sudo ufw allow from 203.0.113.0/24 to any port 443 proto tcp
sudo ufw reload

1. Test that direct origin access is blocked and CDN access still works. Verify it worked: opening http://ORIGIN_IP or https://ORIGIN_IP should fail, while https://yourdomain.com still loads.

Web server or app is overloaded by expensive requests

1. Check access logs for repeated expensive paths.

sudo tail -n 200 /var/log/nginx/access.log

1. Block or rate-limit the worst path first.
   • Example for WordPress XML-RPC abuse:

location = /xmlrpc.php {
    deny all;
}

• Example for login brute force:

location = /wp-login.php {
    limit_req zone=perip burst=5 nodelay;
    proxy_pass http://app;
}

1. Reload nginx:

sudo nginx -t && sudo systemctl reload nginx

1. If the app is still pinned, scale up temporarily in your hosting dashboard.
   • Typical path: Server/App → Resize/Scale. Verify it worked: CPU should fall below saturation and the site should return 200/302 instead of 502/503.

DNS or routing change during the incident

1. Compare current DNS answers with your intended target.

dig +short yourdomain.com

1. In your DNS dashboard, correct the record.
   • Typical path: DNS → Records → Edit.
2. If you changed nameservers recently, confirm the domain registrar is pointing to the right nameservers.
   • Typical path: Registrar → Domain settings → Nameservers.
3. Re-check after a few minutes:

dig yourdomain.com

Verify it worked: the answer section should show the intended CDN/load balancer target, and traffic should start reaching the correct edge.

Rate limiting or firewall rules are blocking real users too

1. In your CDN/WAF dashboard, open recent security events.
   • Typical path: Security/Firewall → Events.
2. Identify the rule ID or country/IP pattern hitting legitimate users.
3. Change the action from Block to Managed Challenge or add an allow rule for trusted office IPs/admin paths.
4. Keep broad protection on, but narrow the rule scope to the attacked path if possible. Verify it worked: affected users should be able to load the site again, while attack traffic still shows as challenged or blocked in events.

Prevention

• Put every public site behind a CDN/WAF before an incident, not during one.
  • Keep DNS proxied to the CDN and document the expected dig output:

dig +short yourdomain.com

• Lock down the origin so it only accepts traffic from the CDN or load balancer.
  • Review firewall rules monthly:

sudo ufw status numbered

• Add simple rate limits for login, search, and known expensive endpoints.

limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;

• Monitor both edge and origin separately.
  • Add alerts for: requests per second spike, bandwidth spike, 5xx rate above 2%, CPU above 85% for 5 minutes.
• Keep a tested emergency DNS plan.
  • Store the correct records in version control:

{
  "root": "CDN target or protected load balancer",
  "www": "CNAME to CDN hostname",
  "ttl": 300
}

• Add a post-deploy check that confirms the origin is not exposed.

curl -I http://ORIGIN_IP

• Expected result: timeout, reset, or denied — not your website homepage.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.