This guide explains how Pressidium EDGE helps protect your WordPress site from network-layer DDoS attacks before they reach your origin infrastructure.

What network-layer DDoS protection does

Network-layer DDoS protection helps defend your site against large volumes of unwanted traffic designed to overwhelm infrastructure.

These attacks usually target the lower layers of the network stack. Their goal is not always to exploit WordPress directly. Instead, they try to consume bandwidth, exhaust network resources, or make your origin unavailable.

Pressidium EDGE helps absorb and filter this traffic at the Edge, before it reaches your origin.

Why this matters

A DDoS attack can affect your site even if WordPress itself is not vulnerable.

During an attack, your origin server may receive more traffic than it can handle. This can lead to:

  • Slow response times
  • Failed requests
  • Intermittent downtime
  • Increased origin load
  • Higher bandwidth usage
  • Reduced availability for legitimate visitors

By handling traffic at the Edge first, EDGE reduces the amount of unwanted traffic that reaches your infrastructure.

How Pressidium EDGE handles network-layer attacks

Pressidium EDGE sits in front of your origin infrastructure and becomes the first touchpoint for incoming traffic.

When a request reaches EDGE, the platform can inspect, filter, cache, block, or route traffic before it reaches your origin.

For network-layer DDoS protection, EDGE helps by:

  • Absorbing large traffic spikes at the edge network
  • Filtering malicious or abnormal traffic before it reaches the origin
  • Reducing pressure on your web server and database
  • Keeping valid traffic flowing where possible
  • Combining DDoS mitigation with Edge WAF, bot protection, and traffic routing

This protection works before WordPress handles the request.

What types of attacks this helps with

Network-layer DDoS protection is designed to help with attacks that target infrastructure availability.

Examples include:

  • High-volume traffic floods
  • Protocol-level floods
  • Connection exhaustion attempts
  • Bot-driven request floods
  • Traffic spikes intended to saturate origin resources

Network-layer vs application-layer attacks

DDoS attacks can happen at different layers.

Network-layer attacks usually try to overwhelm infrastructure by consuming bandwidth, connections, or protocol-level resources.

Application-layer attacks target specific website features. On WordPress sites, common targets include wp-login.php, xmlrpc.php, search, checkout, product pages, and other dynamic endpoints.

Pressidium EDGE helps protect both sides of the request path. Network-layer protection helps absorb and filter large traffic floods before they reach your origin. Application-layer protections, such as the Edge WAF, bot protection, rate limiting, and custom rules, help detect and block abusive requests that target WordPress behavior.

What happens during an attack

During a DDoS event, EDGE helps keep malicious traffic away from your origin.

Depending on the traffic pattern, EDGE may:

  • Drop or filter harmful traffic
  • Rate-limit suspicious behavior
  • Block abusive sources
  • Route traffic through the most appropriate edge locations
  • Continue serving cacheable content from the Edge
  • Reduce the number of requests sent to your origin

This gives your origin more room to handle legitimate uncached requests.

What EDGE does not replace

DDoS protection improves resilience, but it does not replace a healthy origin infrastructure.

EDGE can reduce origin load and block attacks before they reach your server, but origin availability still depends on the health of your hosting environment.

EDGE does not:

  • Replace your origin server
  • Fix an already broken origin
  • Guarantee uptime if the origin itself is unavailable
  • Remove the need for correct DNS and origin configuration
  • Replace application-level security controls

Correct framing: EDGE shields your origin and improves resilience. It does not remove the need for a stable origin.

How to check if DDoS protection is active

DDoS protection is part of the EDGE security layer. There is usually no separate setup required for standard network-layer protection.

To confirm your site is protected by EDGE:

  1. Go to the relevant website in the EDGE dashboard.
  2. Confirm the domain is connected.
  3. Confirm traffic is routing through EDGE.
  4. Review any security or traffic warnings shown in the dashboard.
  5. Check that your site loads correctly through the connected domain.

If your domain is not routing through EDGE, network-layer protection will not apply to live traffic for that domain.

Network-layer DDoS protection works together with other EDGE security features.

Edge WAF

The Edge WAF helps block malicious web requests before they reach WordPress. This includes WordPress-specific attack patterns and application-layer threats.

Bot protection

Bot protection helps identify and block unwanted bots, scanners, scrapers, and automated abuse.

Under Attack Mode

Under Attack Mode adds stricter protection during active attacks or suspicious traffic spikes.

IP and geo controls

IP and geo controls let you allow, block, or restrict traffic based on source IP address or country.

Edge caching

Edge caching can reduce origin load by serving cached content directly from EDGE when possible.

Symptom: The site is slow during a traffic spike

Likely causes:

  • A high volume of uncached traffic is reaching the origin.
  • A DDoS or bot-driven event is in progress.
  • Cache rules are bypassing more requests than expected.
  • The origin is under heavy load.

Resolution steps:

  1. Check whether the domain is connected and routing through EDGE.
  2. Review traffic and security activity in the EDGE dashboard.
  3. Check whether requests are being served from cache where expected.
  4. Review active firewall, bot, IP, and geo rules.
  5. Confirm the origin server is healthy.

Verification:

The site should respond normally for legitimate visitors, and origin load should decrease after harmful traffic is filtered or cacheable requests are served from EDGE.

Symptom: Legitimate visitors are blocked

Likely causes:

  • A firewall or bot rule is too strict.
  • An IP, country, or user agent rule is blocking valid traffic.
  • Under Attack Mode is active.
  • A legitimate service is being treated as suspicious.

Resolution steps:

  1. Check the affected visitor’s IP address.
  2. Review recent security events in the EDGE dashboard.
  3. Check active IP Blocklist, Geo-blocking, bot, and firewall rules.
  4. Temporarily adjust the relevant rule if appropriate.
  5. Ask the visitor to retry after the rule change.

Verification:

The affected visitor should be able to access the site without being blocked.

Symptom: The origin is still overloaded

Likely causes:

  • The attack traffic is bypassing EDGE.
  • DNS is not pointing to EDGE correctly.
  • Some domains or subdomains are not protected.
  • Traffic is reaching the origin IP directly.
  • Too many requests are bypassing cache.

Resolution steps:

  1. Confirm all public domains point to EDGE.
  2. Check whether any subdomains still point directly to the origin.
  3. Confirm the origin IP is not publicly exposed where possible.
  4. Review cache bypass rules.
  5. Check whether legitimate dynamic traffic is causing origin load.

Verification:

Origin traffic should decrease once all public traffic routes through EDGE and unnecessary bypasses are removed.

Best practices

To get the most from network-layer DDoS protection:

  • Route all public production traffic through EDGE.
  • Avoid exposing the origin IP publicly where possible.
  • Keep DNS records accurate and up to date.
  • Use Edge caching for cacheable pages and assets.
  • Review custom rules before high-traffic events.
  • Use IP and geo controls carefully to avoid blocking legitimate visitors.
  • Monitor traffic during campaigns, launches, and seasonal peaks.
  • Contact Support early if you see abnormal traffic patterns.

When to contact Support

Contact Support if you suspect an active DDoS attack or if legitimate visitors are being blocked during mitigation.

Include:

  • The affected domain
  • The approximate start time of the issue
  • A description of the symptoms
  • Example affected URLs
  • Example visitor IPs, if available
  • Screenshots of dashboard warnings or security events
  • Any recent DNS, firewall, cache, or rule changes

This helps support review whether the issue is related to DDoS activity, bot traffic, firewall rules, DNS routing, cache bypasses, or origin health.

Where to go next