How a DDoS Protection Proxy Works: Inside WorldShield v7

A DDoS protection proxy sits between the internet and your server, inspecting every request and dropping malicious traffic before it ever reaches your origin. Done well, your application never sees the attack, it only sees the clean traffic that survives filtering.

WorldShield v7 is Nexonhost’s own DDoS protection proxy. It’s built on nginx with kernel-level packet filtering underneath and several real-time detection engines on top, giving it defence across Layers 3, 4, and 7. Because it works as a remote DDoS protection layer, it can protect a server hosted anywhere, in one of our European data centres or on infrastructure you already run elsewhere, without migrating anything.

This post is a technical walk-through of how that protection actually works, layer by layer.

The layered defence model

The core idea behind WorldShield is that no single technique stops every attack, so requests pass through a series of filters, each cheaper and broader than the next. Known-bad traffic is dropped at the kernel for almost no cost; only the traffic that’s ambiguous gets the more expensive inspection. Anything that survives every layer is proxied to your backend.

Internet
   │
   ▼
[1] Kernel firewall (iptables + ipset)      drop known-bad IPs · whitelist always wins
   │
   ▼
[2] nginx edge: GeoIP · ASN · IP2Proxy      decide who may connect at all
   │            + WAF request filtering       block bad referrers/UAs/URLs/queries/methods
   ▼
[3] Anti-bot challenge (TestCookie)         bots that can't run JavaScript never pass
   │
   ▼   (clean traffic only)
Backend / origin server
   ▲
[4] Sentinel + Crack watch the logs ───────▶ auto-ban offenders back into layer [1]

The interesting part is layer 4: the detection engines read the proxy’s own access logs, score each IP’s behaviour, and feed offenders back into the kernel blocklist. The system learns from live traffic and hardens itself automatically.

Block Attacks Instantly

DDoS Protection

Layer 1: kernel-level IP filtering

The fastest possible place to drop a packet is in the Linux kernel, before nginx is involved at all. WorldShield uses ipsets, whitelist, whitelist6, myblacklist, and myblacklist6, Matched at the iptables layer. Each set holds up to 500,000 entries, so even very large blocklists are matched in constant time.

Two rules matter here. First, the whitelist is evaluated, so a trusted IP (your office, your monitoring service, a payment gateway) can never be blocked by any later rule. Second, blacklisted IPs are silently dropped; the connection is never established, so an attacker gets no feedback and consumes none of your nginx workers. Manual bans can be permanent; automatic bans from the detection engines carry a timeout and expire on their own.

Layer 2: who’s allowed to connect, and the built-in WAF

Traffic that clears the kernel reaches nginx, where WorldShield first decides whether the source is even eligible to connect, using three per-domain controls:

• GeoIP country blocking — allow only your markets, or block known attack-source countries. Blocked requests get a 444 (silent connection close).
• ASN filtering — block or allow entire networks by Autonomous System Number, with prefixes pulled live from the RIPE database. Useful for shutting out hosting/datacentre ranges that rarely send real users, or for locking a site down to a single trusted network.
• IP2Proxy detection — identify and block VPNs, Tor exit nodes, datacentre IPs, and public/residential proxies, which is where a lot of scraping and fraud originates.

Requests that pass then hit the request-filtering layer, which is effectively a web application firewall built into the nginx config. It can block by Referer, by User-Agent (stopping scanners like sqlmap or nikto, and rejecting requests with no User-Agent at all), by URL path (blocking probes for /.env, /wp-login.php, /phpmyadmin and the like), and by query string. The query-string filter ships with one-click presets for SQL injection, XSS, path traversal, and code injection, so common exploit patterns are dropped before they reach your application. Per-path rate limiting (nginx limit_req) protects expensive endpoints such as login pages.

Layer 3: the anti-bot challenge that stops L7 floods

Volumetric filtering doesn’t stop Layer 7 DDoS attacks, because those send what look like legitimate HTTP requests. WorldShield’s answer is TestCookie, a JavaScript-based browser verification step.

On a visitor’s first request, instead of proxying straight to the backend, WorldShield returns a small challenge page. A real browser executes the JavaScript, sets a verification cookie, and is redirected back to the original URL. On the second request the valid cookie is present and the visitor passes through. Attack tools and basic bots that can’t run JavaScript never produce the cookie, so an HTTP flood from a botnet is absorbed at the proxy rather than hammering your application. A “Click to Pass” mode is available for higher-security scenarios where you want users to see a branded verification page.

The obvious risk with any challenge is blocking legitimate non-browser clients, search crawlers, payment webhooks, uptime monitors. WorldShield handles that with a maintained bot whitelist (bots.conf) organised into categories (search engines, payment processors, monitoring, CDN ranges), so Googlebot and Stripe callbacks bypass the challenge while everything unverified is held to it. Individual API paths can also opt out of the challenge per-location.

Layer 4: real-time behavioural detection

The first three layers are rule-based. The last layer is behavioural: two daemons watch live traffic and ban IPs that act maliciously, writing those bans straight back into the kernel ipset from layer 1.

Sentinel is an anomaly-detection daemon that scores each IP across several engines, rate flooding, error-rate abuse, path scanning (counting 404s), credential stuffing, and User-Agent rotation. Scores from different detections stack, and when an IP crosses the ban threshold it’s blocked with an escalating timeout (5 minutes up to 24 hours for repeat offenders). Scores decay over time, so an IP that stops misbehaving is gradually forgiven. Critically, Sentinel has a Monitor mode that detects and logs without banning; you tune it against your real traffic before switching it to Active.

Crack is a C-based engine focused on credential abuse and floods: detecting rotating-credential patterns, brute-force attempts against login endpoints, IPs generating excessive error responses, and high-rate floods against specific URL patterns. Each engine has a dry-run mode for safe testing, and configuration changes hot-reload within about a minute.

Both engines respect the whitelist, they’ll detect a pattern from a trusted IP but skip the ban, which is why adding your own infrastructure to the whitelist before going active is the standard first step.

Keeping your origin hidden

A proxy only protects you if attackers can’t reach around it to hit the origin directly. WorldShield addresses that from both ends. The Interceptor rewrites response bodies and redirects Location headers on the fly, replacing the backend’s hostname with the proxy’s public domain so internal server names never leak to clients. On your side, you firewall the origin to accept traffic only from the proxy. And because the proxy now fronts everything, the trusted-proxies configuration (using nginx’s real-IP handling) restores the true client IP in logs, rate limits, and every IP-based rule, essential if WorldShield itself sits behind a CDN like Cloudflare.

Staying online and fast under load

Mitigation is only half the job; the proxy also has to keep your service up and responsive.

• Backend monitoring runs a lightweight agent on each origin that heartbeats CPU, RAM, and load to the proxy. Unhealthy backends are automatically pulled from the nginx upstream pool and re-added when they recover, with a last-backend safeguard that never disables your final healthy server.
• Caching and compression serve repeat requests from the proxy and shrink responses with gzip, cutting both backend load and bandwidth, which also means a cached site can keep serving even while the origin is under strain.
• Master/slave sync replicates configuration across multiple proxies for redundancy, so you can run more than one mitigation node from a single source of truth.

Visibility and automation

Operators get a real-time dashboard (active connections, blocked threats, traffic in/out, top blocked IPs, per-country and per-rule breakdowns), colour-coded log search, and zero-downtime nginx reloads that always test the config before applying it and auto-restore the previous version if a test fails.

For automation, a Remote API exposes IP and ASN management plus log search over authenticated HTTP, so you can wire bans into your own tooling, for example, having fail2ban push offenders into the proxy blocklist with a timeout, or scripting lookups from Python. There’s also a built-in AI assistant (running on Anthropic’s Claude) that can answer configuration questions and investigate why a given IP is being blocked, available on higher license tiers.

Block Attacks Instantly

DDoS Protection

Where WorldShield runs

WorldShield backs Nexonhost’s DDoS-protected dedicated servers and VPS across our European data centres in Germany, the Netherlands, and Romania, and it’s available as a standalone remote protection layer for infrastructure hosted elsewhere. [VERIFY: confirm current mitigation capacity, plan tiers, available locations, and pricing before publishing.]

DDoS protection proxy FAQ

What is a DDoS protection proxy?

It’s a server that sits in front of your origin, receiving all inbound traffic first. It filters out malicious requests, volumetric floods, exploit attempts, bot traffic and forwards only clean traffic to your backend, so the attack never reaches the application.

Does it stop Layer 7 (application-layer) attacks?

Yes. Volumetric filtering alone doesn’t, which is why WorldShield adds a JavaScript anti-bot challenge plus behavioural detection (Sentinel and Crack) and per-path rate limiting to catch HTTP floods that look like real requests.

Can it protect a server hosted with another provider?

Yes, that’s the point of remote DDoS protection. You route traffic through the proxy and firewall your origin to accept connections only from it. No migration required.

How does it block bad bots without blocking Google?

The anti-bot challenge is paired with a maintained whitelist of search engines, payment processors, monitoring services, and CDNs, so legitimate non-browser clients bypass the challenge while unverified bots are held to it.

Does a DDoS protection proxy slow down my site?

There’s a small added hop, but caching and compression at the proxy often make pages faster overall, and keeping mitigation capacity close to your users keeps latency low.

What happens if my backend goes down?

Backend monitoring removes the unhealthy server from rotation automatically and fails over to a healthy one; with caching configured to serve stale content, visitors can keep getting pages while the origin recovers.

Summary

WorldShield v7 works the way good DDoS mitigation should: cheap, broad filtering at the kernel; eligibility and WAF checks at the nginx edge; a JavaScript challenge to absorb Layer 7 floods; and behavioural engines that watch live traffic and harden the blocklist automatically, all while hiding your origin and keeping your service fast and online.

If you’re running a workload that gets attacked, see Nexonhost’s remote DDoS protection or talk to our team about putting WorldShield in front of your servers.