DDoS Protection for Offshore VPS — Everything Explained

What is a DDoS attack?

A Distributed Denial-of-Service attack is exactly what the name says: a coordinated effort by many endpoints to overwhelm a single target with traffic, exhausting some resource (network bandwidth, kernel connection state, application threads, database connections) and rendering the service unavailable. Modern DDoS attacks fall into three classes that differ in how they exploit the target.

Volumetric attacks exhaust raw network bandwidth. The classic flavor is reflection-amplification — the attacker sends spoofed UDP packets to public servers (DNS, NTP, Memcached, CLDAP) that reply with much larger responses, multiplying the attacker's bandwidth by 50x to 50,000x depending on the protocol. Volumetric attacks are measured in bits per second and the largest publicly disclosed events have crossed 3 Tbps. Mitigation happens at the network edge, before traffic reaches your server.

Protocol attacks exhaust kernel-level connection state. SYN floods (half-open TCP connections), ACK floods, and various malformed-packet attacks fall into this category. They are measured in packets per second. Mitigation happens both at the edge (with stateless filters) and on the server (with kernel tuning, SYN cookies, fail2ban-style auto-blocking).

Application-layer (L7) attacks exhaust application-level resources. HTTP floods that target expensive endpoints, slow-loris attacks that hold connections open, GraphQL queries that explode into N+1 patterns. Measured in requests per second; mitigation requires understanding your application surface and is rarely doable purely at the network edge — it usually requires application-level rate limiting, query budgets, CDN caching, or a WAF.

Each class needs a different mitigation; modern protection stacks layer all three. The Gbps figures in offshore-hosting marketing copy refer to volumetric capacity, but volumetric attacks are only one of the three threats — the other two require engineering work on your side.

How modern DDoS scrubbing works

The infrastructure that absorbs volumetric attacks is called a "scrubbing center" and the architecture is consistent across all major providers (Cloudflare, Akamai, Imperva, NTT) and across most offshore hosts running their own edge.

Traffic destined for your IP is announced via anycast from multiple geographic points. Anycast lets the same IP be reachable from many locations; routing protocols deliver each packet to the nearest edge automatically. When an attack is in progress, the attack traffic is distributed across many edge points (because the attackers are themselves geographically distributed), and each edge point sees only a fraction of the total volume.

At each edge point, scrubbing filters classify traffic in real time. Legitimate traffic is forwarded to your origin; attack traffic is dropped at the edge. The classification uses a mix of stateless rules (drop spoofed source IPs, drop unusual packet structures), stateful heuristics (track connection state and drop incomplete handshakes), and behavioral analysis (drop sources that match known botnet patterns).

The whole architecture is preventive — no human-in-the-loop reaction time, no need to "engage" mitigation. Once your IP is on the protected anycast announcement, the protection is always-on. SilentHosts plans include this by default; the DDoS protection feature page documents the per-tier capacity.

What capacity is enough?

This is the question most customers ask, and the answer is more nuanced than the marketing copy suggests.

For most personal projects (a blog, a small forum, a hobby Mastodon instance), 10 Gbps of scrubbing is sufficient. The attacks targeting personal projects are typically opportunistic — script-kiddie tier, sub-10-Gbps, lasting minutes to hours. Our entry-tier VPS-1 and VPS-2 plans include 10 Gbps scrubbing and that has covered every attack we've seen against personal-project customers in the last year.

For modest commercial operations (a niche e-commerce store, a small SaaS, a busy forum), 50–100 Gbps is the right tier. Attacks at this level are typically motivated — competitor harassment, ransom attempts, ideologically motivated attacks against specific commentary — and they sometimes sustain for hours or days. Mid-tier VPS-4 and VPS-8 plans include 100 Gbps scrubbing.

For high-bandwidth or high-target workloads (streaming, adult, game servers, VPN exit nodes), 200–400 Gbps is appropriate. Attacks against these workloads tend to be both larger (commercial DDoS-for-hire markets explicitly target streaming and adult) and longer (sustained over days, sometimes weeks). Our dedicated tier — DS-Mid, DS-Pro — includes 400 Gbps scrubbing.

For enterprise workloads with sustained adversarial attention (1+ Tbps observed attacks), the standard practice is to layer Cloudflare or BunnyCDN in front of the offshore origin and rely on the CDN's much larger absorption capacity (multi-Tbps globally) for L3/L4 protection. Cloudflare's free tier includes useful protection; the paid tiers add WAF and bot-management capabilities. We support this pattern explicitly — see our DDoS protection feature page.

The table below summarizes the SilentHosts protection tiers:

Edge tactics — application-layer rules, rate limiting

The volumetric scrubbing tier handles L3/L4 attacks. Application-layer attacks need engineering work at your application edge. Three patterns matter most:

Rate limiting. Limit requests per IP, per session, or per endpoint. The simplest implementation is via Nginx (limit_req_zone), HAProxy, or your application's middleware. More sophisticated approaches — token-bucket per identity, sliding-window per endpoint — require more setup but absorb burst attacks more gracefully. The right ratio depends on your normal traffic patterns: if your busiest legitimate user makes 50 requests per minute, set the limit at 200/minute, not at 30.

WAF rules. A Web Application Firewall inspects request payloads and blocks patterns matching known attack signatures (SQL injection, XSS, common bot fingerprints). Cloudflare's WAF, modsecurity (with the OWASP Core Rule Set), and BunnyCDN's WAF all work for offshore hosts. The WAF lives at your CDN edge if you have one, or in front of your application server if you don't.

Cloudflare or BunnyCDN in front. Beyond the WAF, a CDN absorbs the attack at a layer that scales much further than any single origin. Cloudflare specifically has been the standard practice in offshore hosting for a decade — it works fine in front of a Netherlands or Iceland origin, and the free tier provides meaningful protection on its own. We document the canonical Cloudflare-plus-offshore-origin configuration on our features page.

Tarpitting and challenge mechanisms

For sustained low-volume L7 attacks (sophisticated bots, scrapers, scripted account takeovers), explicit challenge mechanisms become useful.

JS challenge. Cloudflare's "I'm Under Attack" mode and similar features inject a small JavaScript challenge that legitimate browsers pass automatically; bots that don't run JS get filtered. Cheap, effective, transparent to legitimate users.

CAPTCHA gates. When the JS challenge is insufficient, an actual CAPTCHA on the suspect endpoints filters humans from advanced bots. The friction cost is real — drop-off rates increase — so use sparingly and only on endpoints under sustained attack.

Proof-of-work challenges. mCaptcha, Anubis, and similar tools require the client to compute a small proof-of-work before the request is processed. The economic cost to the attacker scales linearly with attack rate; the cost to a legitimate user is invisible (a few hundred milliseconds at worst). This pattern has gained traction in 2025–2026 specifically against AI scraping and credential-stuffing campaigns.

Tarpitting. Slowing down responses to suspect traffic without explicitly rejecting them. Effective against simple bots that hold connections open until they get a response; less effective against modern attack tooling that times out and moves on.

DDoS economics: who pays for what

The economics of DDoS protection are usually opaque to customers. Roughly:

• Volumetric scrubbing capacity is the most expensive layer for the host. A 10-Gbps scrubbing tier at scale costs the provider roughly $0.01–0.10 per protected GB of attack traffic, which sums to nontrivial overhead for high-target workloads. Most providers include a base tier in plan pricing and charge for "premium" capacity beyond it.
• Anycast peering is moderately expensive — you need real estate at multiple internet exchange points. Mostly a fixed cost.
• WAF rules and L7 protection are cheap relative to scrubbing — most of the cost is in maintaining the rule set, not in CPU.

SilentHosts includes the full base tier on every plan. Premium scrubbing (above the plan-tier capacity, for sustained 1+ Tbps attacks) is an enterprise-level upgrade conversation, not a per-attack charge. We don't bill by attack volume; sustained attacks above plan capacity trigger a customer-side conversation about upgrading the plan tier, not a surprise invoice.

What you can do at the application level

The most effective DDoS protection is to not be a target, and the second most effective is to keep your application cheap to serve. Specific levers:

Cache aggressively. Static content served from a CDN (or even from local Nginx with a cache directive) costs the origin nothing. Dynamic content cached for short windows (5–60 seconds for most pages) absorbs traffic spikes without requiring full origin processing.

Make dynamic endpoints cheap. A request that hits the database for every page-load is much more vulnerable than one that hits Redis. Push expensive computation to background workers, return cached or eventually-consistent data on the request path.

Set query budgets. GraphQL APIs are particularly vulnerable to amplification attacks — a single attacker request can trigger thousands of database queries. Set query depth limits, query complexity limits, and per-IP query budgets.

Separate read and write paths. Read-heavy traffic should never compete with write-heavy traffic for the same database connection pool. Read replicas handle read attacks gracefully; write attacks are smaller in volume and easier to rate-limit.

Monitor and alert. A 10-minute attack you don't notice is mostly a non-event. A 10-minute attack you do notice gives you time to engage protections (toggle Cloudflare's I'm-Under-Attack mode, deploy emergency WAF rules, contact support). Even basic monitoring (server load, request rate, 5xx error rate) is sufficient for the first response.

Plans with built-in DDoS protection

Selected SilentHosts plans, sorted by typical use case:

• Personal projects, hobby: VPS-1 ($8/mo, 10 Gbps), Shared Pro ($7.99/mo, 10 Gbps).
• Commercial small-business: VPS-2 ($16/mo, 10 Gbps), VPS-4 ($32/mo, 100 Gbps).
• Streaming, adult, seedboxes: VPS-8 ($64/mo, 100 Gbps), Stream-1 (high-bandwidth tier).
• Game servers: Game-M (game-grade UDP filters), Game-L.
• Sustained high-target dedicated: DS-Mid ($149/mo, 400 Gbps), DS-Pro, DS-Beast.
• GPU inference and ML: GPU-Pro, GPU-Beast — protected by 400 Gbps scrubbing same as dedicated.

The full menu lives at /pricing and the per-feature breakdown at /features/ddos-protection.

Conclusion

DDoS protection is a solved problem at the volumetric layer — every credible offshore host in 2026 includes substantial scrubbing capacity by default. The remaining work happens at the application layer, where cheap caching, rate limiting, query budgets, and basic monitoring close most of the residual surface. The right plan tier is determined by your use case more than by attack-size predictions: personal projects need 10 Gbps, mid-traffic commercial needs 100 Gbps, and high-target workloads need 400 Gbps with Cloudflare in front. Pick the tier that matches your workload from the pricing page, and pair it with sensible application-level engineering. For the threat models that warrant it, the DDoS protection feature page covers the per-tier capacity in detail.