Is your website suddenly inaccessible, your server CPU is spiking, and your request count is skyrocketing? One possibility to check is a cyberattack. Distributed Denial of Service (DDoS). However, traffic spikes can also be caused by viral promotions, crawlers, misconfigurations, or problematic applications. First aid should begin with prove the cause of the disorder, instead of directly blocking the entire country or running the firewall commands from the old article.
This guide presents more relevant incident response steps for WordPress, VPS, and business website owners in 2026. The author’s original story of the server failure of two blogs in 2018 along with six images of documentation remains archived; instructions iptables/ipset historical data is not copied into new recommendations because incorrect configuration can cut off legitimate customer traffic.
Checklist for the first 15 minutes when a website is suspected of being hit by a DDoS
| Priority | Action | Objective |
|---|---|---|
| 0–3 minutes | Check monitoring from two locations/networks and hosting provider status | Avoid misdiagnosis when the problem originates solely from the ISP or application. |
| 3–5 minutes | Log time, error, request graph, CPU/RAM, and bandwidth | Creating an incident baseline |
| 5–8 minutes | Contact your hosting/CDN provider and enable the recommended mitigations. | Addressing malicious traffic at the right layer |
| 8–12 minutes | WAF rule evaluation, rate limiting, and origin protection | Reducing the load while preserving normal users |
| 12–15 minutes | Test critical pages, checkout, login, and API endpoints | Ensure mitigation does not block business functions |
1. Determine the cause of the website going down before concluding DDoS.
Check symptoms from logs and monitoring
Compare downtime with HTTP traffic, number of active connections, 5xx errors, CPU capacity, memory, network ingress/egress, and CDN and origin logs.
A surge in requests to a single endpoint could indicate an HTTP Layer 7 attack, while connection and packet saturation on the network could point to a Layer 3/4 issue. A 502 Bad Gateway error doesn’t necessarily indicate an attack; it could also occur because the upstream isn’t responding.
Differentiate between normal bots, crawlers, and service-damaging traffic
Search engine bots can legitimately access websites. Security regulations shouldn’t block legitimate users and search bots without evidence of abuse.
2. Enable CDN/WAF mitigation, not just increasing server capacity
Cloudflare Under Attack Mode as an emergency option
Cloudflare provides Under Attack Mode, which implements additional security checks to suppress some HTTP Layer 7 traffic. According to Cloudflare documentation updated in April 2026, this feature is a last resort when a zone is under attack; interstitial pages can disrupt some visitors and analytics. Enable it only for as long as necessary, monitor the impact, and disable it once traffic is under control.
If only certain pages are being attacked, consider more selective rules rather than challenging all visitors. Security processes should consider the mobile user experience as well as login flows, forms, checkouts, webhooks, and APIs that may be sensitive to challenges.
Use rate limiting and managed rules carefully
Rate limiting restricts excessive request patterns on risky URLs or actions. WAFs help identify suspicious traffic. However, overly aggressive rules can block network sharers, legitimate scrapers, or technical integrations. Start in observation mode whenever possible, then test coverage based on logs and application needs.
3. Contact your hosting or network provider right from the start.
Don’t wait until your VPS becomes inaccessible via SSH. The hosting team or network provider can detect anomalies at a level not visible from the WordPress dashboard. Provide the time of the incident, domain address, service status, graph snapshots, and request IDs, if available. In volumetric attacks, simply blocking requests within the application is often too late because upstream bandwidth is already full.
Not all traffic and protocols are automatically protected by the same HTTP proxy configuration.
4. Protect the origin IP and check DNS
If your website uses Cloudflare, ensure the DNS records for the HTTP proxy are correct. Exposing the origin IP through a subdomain, another service, or a DNS-only record can allow for direct bypass attacks to the server. Check your configuration with your hosting provider before restricting network access; arbitrary blocking risks cutting off communication from the CDN’s own network.
Do not make major configuration changes while incident evidence has not been collected.
5. Check firewalls and administrative access without creating new downtime.
The original article included SSH, iptables, and ipset-based steps, including blocking IP addresses based on country. For today’s needs, firewall configurations must be tailored to the operating system, kernel version, rule order, SSH allowlist, and provider network policies. Blocking all IP addresses from a single country is not a comprehensive solution: attackers can deploy cross-regional botnets, and many legitimate visitors can be affected.
If you don’t have experienced administrator access, don’t run commands found online on production servers. Save the configuration, provide an out-of-band rollback path, and seek assistance from your provider.
Real experience when two blog servers experienced disruption
The author once received a monitoring email stating catperku.com could not be loaded in the early hours of March 2018. In the initial documentation, there was a spike in traffic and CPU usage on the infrastructure being managed at that time. This story is notes on experience during the period, is not evidence that attack patterns, IP sources, or historical blocking measures are suitable for other servers in 2026.
Archival note: The following Jetpack/Linode alert images, traffic graphs, WHOIS, and SSH sessions are preserved as original documentation. Identifying the country from the IP address is not sufficient to identify the attacker.
6. Test recovery, SEO impact, and customer experience
After mitigation, test from different networks. Check the homepage, product pages, lead forms, login, and transactions. Monitor API responses, validate caches, and fix server errors. Repeated site downtime can disrupt visitor access and bots’ ability to access pages, although the impact on rankings depends on the duration and severity of the outage.
Review the XML sitemap, indexing status, and critical URLs after service is restored. Continue with a technical SEO audit and organic traffic recovery if there was a measurable business impact.
7. Conduct a postmortem to prevent similar incidents.
Document the timeline, first alarm, peak metrics, activated rules, false positives, and recovery time. Define action owners, backup locations, 24-hour escalation paths, and downtime tolerance limits. Schedule rule tests, monitor system changes, and evaluate whether risks require additional mitigation services. This plan is relevant for agencies, blog owners, and online store managers who rely on search traffic.
FAQ: first aid for DDoS
1. What is a DDoS attack?
An attack that floods a target with traffic or requests from multiple sources, disrupting service availability.
2. Does a slow website mean it will definitely be hit by DDoS?
No. Problematic hosting, plugins, databases, and normal visitor spikes can also slow down a website.
3. What to do in the first five minutes?
Verify the outage, save logs and time of occurrence, view graphs, and contact your provider or security team.
4. Can free Cloudflare help?
Features and limitations vary by plan and configuration; proper proxy use and protection can help mitigate some types of malicious traffic.
5. When should Under Attack Mode be used?
While HTTP layer 7 attacks require additional checks and the consequences to visitors are taken into consideration.
6. Can Under Attack mode be left on forever?
Not recommended as a permanent setting without reason; its impact on user experience needs to be evaluated.
7. Is blocking IP from one country effective?
It can sometimes reduce certain traffic, but it is not a complete solution and can block legitimate visitors.
8. Do I need to add RAM or upgrade my VPS?
Not necessarily. Network attacks need to be addressed at the upstream/CDN level; server upgrades alone may not be enough.
9. Why is it important to protect the origin IP?
Exposed IPs can allow direct traffic to the server to bypass CDN filters.
10. What is the relationship between DDoS and error 502?
DDoS can make upstream unresponsive, but 502s also appear due to regular backend configuration or issues.
11. Does database backup stop DDoS?
No. Backups help with data recovery and operational continuity, not request filtering.
12. When to seek expert help?
As soon as critical business services are disrupted, logs show a major attack, or firewall changes risk cutting off access.
Official and technical references
- Cloudflare — Under Attack mode (2026)
- Cloudflare — Protect your origin server
- AWS — Best Practices for DDoS Resiliency (2026)
- CISA — DDoS response guidance
