[Home](https://servghost.com/) / [Privacy Hosting Guides](https://servghost.com/guides) / VPS DDoS Protection: Where Your Host Stops and Layer 7 Begins Operations # Surviving a DDoS Attack on Your VPS Every hosting plan says “DDoS protection included”, and every one of them means the same narrow thing: the network absorbs floods measured in gigabits. The attacks that actually take small sites down are measured in requests per second, cost the attacker almost nothing, and arrive looking entirely legitimate. This guide draws the line between the two, shows how to tell within a minute which one you are in, and covers what genuinely holds on the side of the line that belongs to you. [Read the guide](#guide-body) [FAQ](#guide-faq) ## On this page - [Guide](#guide-body) - [FAQ](#guide-faq) - [Related guides](#guide-related) - [Recommended pages](#guide-cta) No KYC Crypto Only No Logs DMCA Ignored Full Root NVMe SSD 21 min read Updated Sep 2026 On this page [01Two different attacks that share one name](#two-different-attacks-that-share-one-name) [02What “DDoS protection included” actually buys](#what-ddos-protection-included-actually-buys) [03First, decide whether this is even an attack](#first-decide-whether-this-is-even-an-attack) [04Reading the attack from the server itself](#reading-the-attack-from-the-server-itself) [05The first ten minutes](#the-first-ten-minutes) [06Rate limits that hold, and the mistake everyone makes](#rate-limits-that-hold-and-the-mistake-everyone-makes) [07Caching is the cheapest mitigation you will ever deploy](#caching-is-the-cheapest-mitigation-you-will-ever-deploy) [08The ceilings that decide whether you fall over](#the-ceilings-that-decide-whether-you-fall-over) [09Putting something in front of the origin](#putting-something-in-front-of-the-origin) [10A hidden origin is worth more than any filter](#a-hidden-origin-is-worth-more-than-any-filter) [11Choosing hardware and location so attacks stay boring](#choosing-hardware-and-location-so-attacks-stay-boring) [12Five things not to do](#five-things-not-to-do) [13The short version](#the-short-version) [FAQCommon questions](#guide-faq) [→Recommended pages](#guide-cta) There are two moments when people learn how DDoS mitigation actually works. The first is calm, at purchase time, reading a feature list that says “DDoS protection included” and quietly assuming the sentence covers everything. The second is at three in the morning, when the site is down, the graphs look wrong in a way that makes no sense, and that included protection is — correctly, and by design — doing nothing at all. Both moments involve the same product and the same truth: a hosting provider filters the attacks that arrive as raw volume, because it owns the pipe those packets travel down and you do not. It cannot filter the attacks that arrive as ordinary-looking requests, because from the network’s point of view they are ordinary-looking requests. That line — between the flood your host absorbs and the flood you have to survive yourself — is the whole subject. Everything below is about finding which side of it you are on, and what to do on each. ## Two different attacks that share one name “DDoS” is one word covering two problems that have almost nothing in common except the outcome. They are stopped in different places, by different people, with different tools, and confusing them is why so much mitigation effort lands in the wrong layer. | | Volumetric — layers 3 and 4 | Application — layer 7 | | --- | --- | --- | | What arrives | SYN floods, UDP amplification via open DNS, NTP or memcached reflectors, ACK floods, plain garbage packets | Ordinary HTTP requests: GET floods, POST floods, slow-loris, cache-busting query strings | | Measured in | Gigabits and millions of packets per second | Requests per second — often only a few thousand | | Bandwidth needed to hurt you | Enormous. This is a capacity contest | Almost none. A single laptop can do it if the endpoint is expensive enough | | Where it must be stopped | **Upstream, by your provider.** By the time the packets reach your port, the damage is done | **On your server, by you**, or on a proxy you control in front of it | | What it looks like on the box | Interface saturated, packet counters absurd, CPU may be idle | Modest bandwidth, but every worker busy, load climbing, database queue growing | | Who fixes it | Your host’s scrubbing, automatically, usually within seconds | Your configuration — rate limits, caching, connection ceilings | Read the last two rows again, because they contain the practical point. If the interface is saturated, nothing you type into the server will help: the packets have already consumed the port, and the only party who can drop them is the one who owns the router upstream. If the interface is quiet but the site is still down, the opposite is true — your host sees nothing wrong because, at their layer, nothing *is* wrong, and the fix is entirely yours. Volumetric floods are filtered upstream, where the capacity is. What survives that filter is ordinary-looking traffic — and stopping it is your job, not your host’s. ## What “DDoS protection included” actually buys Network-layer protection is real, valuable, and almost always misread. When a provider advertises L3/L4 filtering, they mean their network monitors traffic destined for your address, and when a flood is detected the traffic is diverted through scrubbing hardware that drops the malicious portion and forwards what looks legitimate. It happens without a support ticket and usually without you noticing more than a brief blip. That single sentence is doing a lot of work, so it is worth unpacking what it does and does not include: - **It covers the attacks you cannot survive alone.** A 200 Gbps amplification flood against a server with a 1 Gbps port is not a configuration problem. It is arithmetic. Upstream scrubbing is the only answer that exists. - **It is stateless about your application.** The filter does not know which of your URLs are expensive, which visitors are logged in, or that a request to your search endpoint costs four hundred times a request to your logo. - **It reacts to a threshold, not to your suffering.** Detection triggers on traffic volume. An attack that never crosses the threshold never triggers it, no matter how comprehensively it has taken your site down. - **It may briefly null-route in extreme cases.** Every network has a ceiling. If an attack threatens shared infrastructure, the address may be dropped for a period — this is standard, universal, and worth knowing about before it happens rather than during. **The one-line version:** your host protects its network, and you benefit from that. It does not protect your application, and it has no way to. Layer 7 is not an upsell that was withheld from you — it is a layer your provider cannot see into without terminating your TLS, which for anyone hosting offshore is a trade with its own serious costs. ## First, decide whether this is even an attack An impressive share of suspected DDoS incidents are something else wearing its coat, and the fixes are not interchangeable. Before rate-limiting anything, spend two minutes ruling out the impostors — a misdiagnosis here costs you an hour and, occasionally, your real users. - **You got popular.** A link on a large aggregator produces a traffic shape that looks exactly like an L7 flood, except the referrers are real and the requests are for pages a human would want. This is a capacity problem with a happy cause; rate-limiting it is self-harm. - **A crawler lost its manners.** Aggressive scrapers and AI training bots can trivially outrun a small server. The user-agent usually confesses, and the fix is robots.txt plus a targeted limit, not a general one. - **You broke something.** A deployment that disabled caching, a runaway cron job, a database that lost an index — all present as “sudden load, no obvious cause”. If the timing lines up with a change you made, believe the change. - **Your own monitoring is the flood.** Rare, embarrassing, and much more common than anyone admits. A health-check loop that retries without a backoff can generate a genuinely impressive request rate. The distinguishing question is simple: *does the traffic want something?* Real load — even hostile-looking real load — has a shape. It hits pages that exist, follows links, loads assets, and comes from a plausible spread of networks. An attack usually does not bother. ## Reading the attack from the server itself You do not need a dashboard to classify what is happening. Four commands, run in order, will tell you which layer you are fighting in under a minute — and knowing that determines everything you do next. **Is the pipe full?** Watch the interface counters. If throughput is pinned near the port’s ceiling, you are in a volumetric attack and your work is a support ticket, not a config change: - vnstat -tr 10 — average throughput over ten seconds, the fastest honest read on saturation. - cat /proc/net/dev twice, a second apart — packet and byte deltas per interface, no tooling required. **Is it a SYN flood?** Half-open connections pile up in SYN-RECV. A handful is normal; thousands is not: - ss -s — the summary line, connection counts by state at a glance. - ss -tn state syn-recv | wc -l — the specific number that matters. **Is it layer 7?** If bandwidth is unremarkable but everything is slow, count requests per client in your access log. A single address with tens of thousands of hits is an amateur; a hundred thousand addresses with three hits each is the real thing: - tail -n 100000 access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -30 - Swap $1 for $7 to rank the requested paths instead. If one expensive endpoint dominates, you have found the target and half the fix. **What is actually exhausted?** Load average tells you little on its own. Look for the specific ceiling you have hit: PHP-FPM children all busy, database connections at their limit, file descriptors exhausted, or workers stuck in D state waiting on disk. That ceiling — not the traffic — is what took the site down, and raising it is often faster than filtering anything. **Keep this in mind while you look:** if you run a privacy-focused service, an attack is precisely when you are most tempted to turn logging up and keep it there. Turn it up if you must, then turn it back down and rotate the files aggressively afterwards. An incident that leaves a month of full-detail visitor logs on disk has traded one problem for a worse and longer-lived one. Our [server OpSec guide](https://servghost.com/guides/server-opsec-staying-anonymous) covers the discipline this belongs to. ## The first ten minutes Under pressure, people reach for the biggest lever available, and the biggest lever is usually wrong. This is the order that limits the damage, roughly fastest-and-safest first: - **Classify before acting.** Saturated interface means volumetric; quiet interface with busy workers means layer 7. Thirty seconds spent here saves you from fixing the wrong layer for an hour. - **If it is volumetric, open a ticket immediately** and include the destination address, the start time, and your interface counters. Then stop typing into the server — you cannot fix this from inside it. - **If it is layer 7, cache first.** Turning on aggressive full-page caching for anonymous visitors is the single fastest way to convert an outage into a shrug, and it is the only measure that helps against real traffic too. - **Then rate-limit** — the targeted endpoint first, everything else after. Start conservative. A limit that takes out your own users is a self-inflicted continuation of the attack. - **Block only what is unambiguous.** A dozen addresses with a hundred thousand requests each, an obviously fake user-agent, one country you have no users in. Resist the urge to write elaborate rules while under fire; you will not remember them next month. - **Shed load deliberately if you must.** Serving a static “under maintenance” page to unauthenticated visitors keeps the box alive, keeps your API up, and buys thinking time. Deciding what to sacrifice is better than having it decided for you. - **Write down what you did.** Every temporary rule you added is a landmine for future-you. The rules that helped become permanent; the rest come out tomorrow. ## Rate limits that hold, and the mistake everyone makes Rate limiting is the main instrument for layer 7, and nginx does it well with two directives that solve two genuinely different problems. limit_req caps request *rate* — how often a client may ask. limit_conn caps *concurrency* — how many connections one client may hold open at once. Floods need the first; slow-loris attacks, which hold thousands of near-idle connections to exhaust your worker pool, need the second. Deploy only one and you are covered against half the problem. Three details separate a limit that works from one that is decorative: - **Use a burst, and use nodelay.** Real browsers are bursty — a single page view fires a dozen near-simultaneous asset requests. A limit without headroom throttles genuine visitors while an attacker pacing itself just under the threshold sails through. - **Limit the expensive endpoints separately.** Your search page, login form, password reset and any endpoint that writes to the database deserve a much tighter budget than your static assets. Attackers find these without trying, because they are the ones that hurt. - **Return 429, not 503.** The status code is a signal to well-behaved clients and to search engines that this is throttling rather than failure — and it keeps a bad afternoon from turning into a ranking problem. **The mistake that silently voids all of it:** if anything sits in front of your server — a CDN, a load balancer, your own reverse proxy — then every request arrives from *its* address, not the visitor’s. A per-client rate limit then counts the whole internet as one client, and it will either do nothing at all or ban your entire audience at once. You must configure your real-IP source (in nginx, set_real_ip_from for the proxy’s ranges plus real_ip_header for the header it sends) *before* the limits mean anything. Restrict it to the proxy’s own ranges, too: trusting a client-supplied header from the open internet lets an attacker forge a new identity per request and walk straight through every limit you own. ## Caching is the cheapest mitigation you will ever deploy A rate limit rejects work. A cache makes the work not exist. For anything an anonymous visitor sees, full-page caching changes the economics of the entire attack: a request that would have cost a database round-trip, a template render and a PHP worker becomes a file read measured in microseconds. The same server that collapsed at four hundred dynamic requests per second will serve tens of thousands of cached ones without noticing. The things that matter when you turn it on in anger: - **Cache for anonymous visitors only.** Bypass on a session cookie. Serving one logged-in user’s page to another is a far worse incident than the outage you were fixing. - **Serve stale on purpose.** nginx’s proxy_cache_use_stale with updating error timeout means that when your backend is struggling, visitors get a slightly old page instead of an error. During an attack this is the difference between a site that looks fine and one that looks dead. - **Collapse duplicate misses.** proxy_cache_lock ensures that a thousand simultaneous requests for the same uncached page produce one backend request, not a thousand. Without it, a cache-busting attack passes straight through the cache and lands on your database at full force. - **Neutralise cache-busting query strings.** The standard trick is appending ? and a random value so every request is a unique key and misses forever. Normalise your cache key to ignore query parameters your application does not actually use. There is a pleasant asymmetry here that is worth internalising: every hour you spend on caching also makes the site faster on its best day, cheaper to run, and better at surviving success. Almost no other line of defence pays a dividend when nothing is wrong. ## The ceilings that decide whether you fall over Most servers do not die because they ran out of CPU. They die because they hit an invisible ceiling nobody set deliberately — a default from a decade ago that made sense on hardware nobody uses any more. Under attack, these are what actually break first: - **Application workers.** PHP-FPM’s pm.max_children, your Python worker count, your Node cluster size. This is the real concurrency limit of your site. When they are all busy, every additional visitor queues, and the site is down regardless of how idle the CPU looks. Raise it only as far as memory allows — swapping is worse than queueing. - **The accept queue.** net.core.somaxconn and your listen backlog decide how many connections may wait to be accepted. A small backlog turns a survivable burst into refused connections. - **SYN cookies.** net.ipv4.tcp_syncookies lets the kernel answer a SYN flood without allocating state for connections that will never complete. Modern kernels enable it by default; verify rather than assume, because it costs nothing and saves you from the most common flood there is. - **File descriptors.** Every connection is a descriptor. The default nofile limit is frequently lower than the number of connections you are trying to serve, and the failure mode — accepts failing while everything looks healthy — is genuinely confusing at 3am. - **Database connections.** Raising your worker count without raising the connection pool just moves the queue somewhere harder to see. These two numbers must be adjusted together. Tune these on a calm day, not during an incident. The point of knowing them is that when the site falls over, you can name the ceiling it hit instead of guessing — and a named ceiling is a fixed one. ## Putting something in front of the origin Everything above happens on the server. The next step is deciding whether the server should be the thing receiving the traffic at all. There are three honest options, and the right answer depends far more on what you host than on what you can afford. | Approach | What it gives you | What it costs you | | --- | --- | --- | | Origin directly exposed, hardened | Simplicity, no third party, no TLS termination you do not control | Your address is public and permanent. Layer 7 is entirely on you | | Commercial CDN or scrubbing service | Enormous absorption capacity, a challenge page in one click, global caching | An abuse desk with an opinion about your content, and a company that can see your traffic. For offshore or DMCA-sensitive projects this can be the weakest link in an otherwise careful setup | | Your own front node — a small VPS running nginx, proxying to a firewalled origin | Full control, no third party in the request path, an address you can burn and replace, and a real address that stays hidden | Its own capacity limits, and one more machine to run. Two or three fronts in different networks make it meaningfully harder to take down | The self-hosted front node deserves more attention than it usually gets, particularly for anyone who chose offshore hosting for reasons a large CDN might not sympathise with. The pattern is unglamorous: cheap proxy nodes in front, origin firewalled to accept connections only from those nodes, DNS pointing at the fronts. If a front is attacked, you replace it with a new address in minutes and the origin never noticed. The full version of this architecture — including the six ways an origin address leaks anyway — is the subject of our guide on [hiding your origin server IP](https://servghost.com/guides/hiding-your-origin-server-ip). ## A hidden origin is worth more than any filter It is worth stating bluntly, because it inverts the usual priority: the cheapest DDoS mitigation available to you is an address the attacker does not have. Filtering is what you do when that has already failed. This matters more than it sounds, because origin addresses leak constantly and quietly. Historical DNS records from before you put a proxy in front outlive the change by years. Mail sent directly from the application carries the address in its headers. A TLS certificate issued on the raw address is published permanently in certificate transparency logs. An error page, a redirect, or an obscure subdomain that was never proxied all give it away. If you have put a CDN in front of a server that used to be exposed, assume the old address is known until you have changed it. **The corollary is a firewall rule, and it is the most valuable single line in this guide:** once something sits in front, the origin should refuse connections on 80 and 443 from everything except that front’s addresses. Without it, the proxy is a suggestion — anyone who learns the real address simply steps around it and attacks you directly, and everything you configured at the front becomes decorative. ## Choosing hardware and location so attacks stay boring Some of this is decided before an attack ever happens, at the moment you pick a plan. Three properties matter far more than the specification sheet suggests: - **Unmetered bandwidth.** On a metered plan, an attack is not only an outage — it is an invoice. Traffic you never asked for and could not refuse still counts against an allowance. Unmetered transfer converts a financial risk into a purely technical one, which is a much better class of problem. - **Whether the port is yours.** On a shared virtualised host, a neighbour under attack can degrade you, and your own protection ceiling is shared. [Dedicated hardware](https://servghost.com/dedicated) with its own port removes both effects. For a project that expects hostile attention, this is the clearest reason to move up from a [VPS](https://servghost.com/vps) — more than cores or RAM. - **Where the network sits.** A well-connected European network with real transit capacity absorbs a flood that a poorly-peered one will not, and the jurisdiction you chose for legal reasons has network characteristics too. It is worth checking both when picking from the available [locations](https://servghost.com/locations). There is also a scale argument that quietly favours simplicity. A static site behind a cache on a modest server is extraordinarily hard to take down; the same content on a heavyweight CMS with an uncached search endpoint can be broken by one determined person with a script. Reducing what is dynamic is a mitigation, and it is free. If your project genuinely lives under sustained load, our [high-traffic hosting](https://servghost.com/use-cases/high-traffic-hosting) notes cover the sizing side of the same question. ## Five things not to do The failure modes here are consistent enough to list, and each one has cost somebody a weekend: - **Do not null-route yourself.** Blackholing your own address ends the attack in the most literal way possible — nobody can reach you, including your users. It is a tool of last resort for your provider, not an action you take voluntarily. - **Do not treat fail2ban as DDoS protection.** It is a fine tool against brute-force attempts from a few addresses. Against a distributed flood it reacts in minutes to something that arrives in seconds, and a rule that bans thousands of addresses can cost more in firewall processing than the attack cost you. - **Do not pay a ransom.** The overwhelming majority of extortion emails threatening a devastating attack come from people with no capability who send thousands of identical messages. The small minority who can follow through will come back, because you have proven you pay. - **Do not retaliate.** Beyond being illegal essentially everywhere, the sources are compromised third parties. You would be attacking victims, and doing it from an address that is unambiguously yours. - **Do not migrate in a panic.** Moving hosts mid-attack means the new address is public within minutes and you have no working configuration. Stabilise first, move deliberately later — and if you do move, our guide on [migrating without downtime](https://servghost.com/guides/migrate-website-to-offshore-hosting) exists precisely so that the move is not a second incident. ## The short version Stripped of the reasoning, the working model fits in eight lines: - **Classify first.** Saturated interface means volumetric and belongs to your host. Quiet interface with exhausted workers means layer 7 and belongs to you. - **For volumetric, file a ticket** with the address, the timestamp and your counters — then stop touching the server. - **Cache aggressively for anonymous visitors,** serve stale under stress, and collapse duplicate misses. This is the highest-leverage change you can make. - **Rate-limit by request rate and by concurrency,** tightest on the endpoints that cost the most, and return 429. - **Fix your real-IP configuration before any of it,** or every per-client limit behind a proxy is either useless or catastrophic. - **Know your ceilings** — workers, backlog, descriptors, database connections — and raise them deliberately on a calm day. - **Keep the origin address secret and firewalled** to your front nodes. This is worth more than every filter combined. - **Buy unmetered bandwidth** so that traffic you did not ask for is never also a bill. None of this makes you immune, and anyone selling immunity is selling something. What it does is move you out of the population that gets taken offline by a bored teenager and into the one that requires genuine resources and genuine intent to disturb — which, for the overwhelming majority of projects, is indistinguishable from safe. The rest is the same unglamorous work that makes a server good at everything else: [hardened on the first day](https://servghost.com/guides/first-hour-vps-hardening-checklist), [restorable on the worst one](https://servghost.com/guides/vps-backup-strategy), and running somewhere that treats your traffic as your business. FAQ ## DDoS on a small server — common questions ### 01 Does “DDoS protection included” mean I am safe from everything? No, and the gap is precise rather than vague. Included protection is network-layer filtering: it drops volumetric floods — SYN floods, UDP amplification, raw packet storms — upstream, before they reach your port. That is the category you genuinely cannot handle yourself, so it is the right thing to include. It does not inspect your application, so an HTTP flood of a few thousand requests per second against an expensive endpoint passes through it untouched and takes your site down while every network graph looks normal. Layer 7 is configuration you own: caching, rate limits and connection ceilings. ### 02 How do I tell a DDoS attack from a traffic spike? Ask whether the traffic wants something. Real visitors, even a sudden flood of them from a popular link, request pages that exist, load the assets on those pages, arrive with plausible referrers and spread across many networks in a natural pattern. An attack usually hammers one path, ignores assets, sends implausible or absent user-agents, and shows a distribution that looks synthetic. Check your access log for requests per client address and per path: if one endpoint dominates and nothing else is being loaded, it is an attack. If the same pages a human would want are being served and your referrers are real, you have a capacity problem with a happy cause. ### 03 What is the single most effective thing I can do while under attack? Turn on full-page caching for anonymous visitors, and configure it to serve stale content when the backend is struggling. A rate limit rejects work; a cache makes the work not exist. A request that cost a database query, a template render and an application worker becomes a file read, and the same hardware that collapsed at a few hundred dynamic requests per second will serve tens of thousands of cached ones. It is also the only measure on the list that helps identically against real traffic, so unlike a rate limit it cannot backfire on your own users. ### 04 Why did my nginx rate limit stop working after I put a CDN in front? Because every request now arrives from the CDN’s address rather than the visitor’s, so a per-client limit is counting the entire internet as a single client. Depending on the threshold, it will either never trigger or ban all of your traffic at once. Configure your real-IP source — in nginx, the trusted proxy ranges plus the header the proxy sends — so the limit keys on the actual visitor again. Restrict that trust to the proxy’s own ranges: if you accept a client-supplied header from the open internet, an attacker can forge a fresh identity on every request and walk through every limit you have. ### 05 Is fail2ban enough to stop a DDoS attack? No. fail2ban reads logs on an interval and bans offending addresses after a threshold, which suits brute-force attempts from a small number of sources. A distributed attack arrives in seconds from thousands of addresses that each send only a handful of requests, so the threshold is never reached and the reaction time is far too slow regardless. Worse, a ruleset that grows to tens of thousands of entries can consume more resources than the attack. Keep it for SSH and login endpoints, and handle floods with caching, rate limiting and an upstream filter. ### 06 Should I use a CDN, or run my own reverse proxy in front? It depends on what you host rather than on your budget. A commercial CDN brings absorption capacity you cannot match and a challenge page one click away, but you inherit its abuse desk and it can see your traffic — which for offshore or DMCA-sensitive projects is often the weakest link in an otherwise careful setup. Your own front nodes cost more work and have real capacity limits, but there is no third party in the request path and a front that gets attacked can be replaced with a new address in minutes. Either way, the origin must be firewalled to accept web traffic only from the front, or the whole arrangement is decorative. ### 07 Will an attack cost me money as well as uptime? On a metered plan, yes — traffic you never asked for and could not refuse still counts against your transfer allowance, and a sustained flood can produce an overage bill larger than a year of hosting. This is the practical reason unmetered bandwidth matters more than it looks on a specification sheet: it converts a financial risk into a purely technical one. It is also worth knowing in advance that if an attack threatens shared infrastructure, providers may temporarily null-route the address; that is standard practice everywhere, not a failure of your particular host. ### 08 Does moving to an offshore or no-KYC host make attacks more likely? The hosting choice itself is neutral; what you run is what attracts attention. Game servers, forums, streaming, marketplaces and anything with a competitor or a grudge draw attacks regardless of jurisdiction. What does change offshore is your recourse: you are less likely to be dropped for being inconvenient, which cuts both ways — the protection is technical rather than contractual. Choose a location with genuine transit capacity, take unmetered bandwidth, keep the origin address hidden, and treat layer 7 as your own responsibility from the first day rather than the first incident. Related guides ## Keep reading [### How to Choose an Offshore Hosting Jurisdiction in 2026 Buying A practical decision framework for picking an offshore jurisdiction: data-retention law, MLAT exposure, DMCA stance, court speed and real-world enforcement — country by country. 6-question FAQ](https://servghost.com/guides/choosing-an-offshore-jurisdiction) [### VPS vs Dedicated Server for Privacy-Critical Workloads Buying When a VPS is fine, when shared tenancy is a liability, and when bare metal is the only honest answer. Hardware isolation, hypervisor risk, and cost vs threat model. 6-question FAQ](https://servghost.com/guides/vps-vs-dedicated-for-privacy) [### Self-Hosted VPN on a No-KYC VPS: WireGuard vs OpenVPN Operations Why a self-hosted VPN beats commercial providers, and how WireGuard and OpenVPN really compare on privacy, performance and operational risk in 2026. 6-question FAQ](https://servghost.com/guides/self-hosted-vpn-wireguard-vs-openvpn) [### RTX 4090 vs H100 SXM5 for AI Inference (and Where the RTX 5090 Fits) Buying Buying guide: which NVIDIA GPU for self-hosted LLM, image, video, speech, and fine-tuning workloads in 2026. RTX 4090 vs RTX 5090 vs H100 SXM5 vs dual H100 — VRAM, throughput, $/token, when each wins. 6-question FAQ](https://servghost.com/guides/rtx-4090-vs-h100-for-ai-inference) [### Offshore Windows RDP for MT4 / MT5 / cTrader Forex Trading Operations Complete guide: why a Windows RDP for Forex trading, how to choose a low-latency offshore jurisdiction, MT4 / MT5 / cTrader / Expert Advisor setup, latency to broker servers, and the no-KYC checkout path. 6-question FAQ](https://servghost.com/guides/offshore-windows-rdp-for-forex-trading) [### DMCA-Ignored Hosting Explained: What It Really Means in 2026 Buying What "DMCA ignored" hosting genuinely buys you, which jurisdictions actually back it up, the workloads that need it, and the copyright traps the term doesn't cover. 6-question FAQ](https://servghost.com/guides/dmca-ignored-hosting-explained) [### Anonymous Domain Registration with Crypto: WHOIS Privacy in 2026 Privacy A practical 2026 guide to registering domains without revealing your identity: WHOIS regimes by TLD, registrar choice, crypto payment options, and the operational mistakes that leak you anyway. 6-question FAQ](https://servghost.com/guides/anonymous-domain-registration-with-crypto) [### Crypto Payments for Hosting: Monero vs Bitcoin vs USDT Privacy How payment coin affects what your host learns about you. Privacy, fees, finality and chain analysis exposure for XMR, BTC and USDT — with a clear recommendation. 6-question FAQ](https://servghost.com/guides/crypto-payments-monero-vs-bitcoin-vs-usdt) [### Is Offshore Hosting Truly Anonymous? An Honest Answer Privacy Offshore, no-KYC hosting removes the identity a normal host collects — but "anonymous" depends on payment, provider logging and your own opsec. Here is what is really traceable. 6-question FAQ](https://servghost.com/guides/is-offshore-hosting-truly-anonymous) [### The First Hour of VPS Hardening: A Checklist Operations A concrete, ordered checklist to secure a new VPS in under an hour: SSH keys, a firewall, fail2ban, automatic updates, and the attack-surface reduction that stops most opportunistic attacks. 6-question FAQ](https://servghost.com/guides/first-hour-vps-hardening-checklist) [### What Is No-KYC Hosting? Definition, Legality & How It Works Privacy No-KYC hosting lets you rent a server with zero identity verification — no name, no email, no ID. Here is exactly what it means, how it works technically, whether it is legal, and how to pick a genuine provider. 6-question FAQ](https://servghost.com/guides/what-is-no-kyc-hosting) [### Is Offshore Hosting Legal? The Honest 2026 Answer Buying Offshore hosting is legal — for you and for the provider. Here is what the term really means, where the legal line actually sits, the myths worth dropping, and how to use it responsibly. 6-question FAQ](https://servghost.com/guides/is-offshore-hosting-legal) [### How to Pay for Hosting with Monero (XMR) — Step by Step Privacy A step-by-step guide to paying for a VPS or dedicated server with Monero (XMR): why XMR is the most private option, how to get it, and how the checkout works — from invoice to a running server in minutes. 6-question FAQ](https://servghost.com/guides/how-to-pay-for-hosting-with-monero) [### How to Host a Website Anonymously — A Practical 2026 Guide Privacy A practical, layered guide to hosting a website with no identity attached: the account, the payment, the domain, the jurisdiction, your connection and the content — each layer explained. 6-question FAQ](https://servghost.com/guides/how-to-host-a-website-anonymously) [### How to Set Up a WireGuard VPN on a VPS — Step-by-Step Guide Operations Build your own private VPN on a VPS with WireGuard: why a self-hosted VPN beats a commercial one, the full setup from install to a connected client, and how to harden it. 6-question FAQ](https://servghost.com/guides/how-to-set-up-wireguard-vpn-on-a-vps) [### How to Self-Host an LLM on a GPU Server — 2026 Guide Operations Run your own large language model on a rented GPU server: why self-hosting beats an API, which GPU and model to choose, the setup with Ollama or vLLM, and what it costs. 6-question FAQ](https://servghost.com/guides/self-host-an-llm-on-a-gpu-server) [### Bulletproof Hosting vs Offshore Hosting — What Is the Difference? Buying Bulletproof hosting and offshore hosting are constantly confused — and they are not the same thing. Here is the real difference, why it matters, and which one you actually want. 6-question FAQ](https://servghost.com/guides/bulletproof-vs-offshore-hosting) [### How to Buy a VPS with Bitcoin — Step-by-Step (2026) Buying A beginner-friendly walkthrough of buying a VPS with Bitcoin: getting BTC, choosing a plan, paying the invoice, and what you get — a running server with no card and no name attached. 6-question FAQ](https://servghost.com/guides/how-to-buy-a-vps-with-bitcoin) [### Best Countries for DMCA-Ignored Hosting in 2026 Buying Where to host when you want servers beyond the easy reach of US-style takedowns: the jurisdictions that work, what DMCA-ignored really means, and how to choose. 6-question FAQ](https://servghost.com/guides/best-countries-for-dmca-ignored-hosting) [### How to Host a Tor Hidden Service (.onion Site) — 2026 Guide Operations Set up a Tor onion service on a VPS: what a hidden service is, why it is the strongest form of anonymous hosting, the full setup, and how to keep it actually anonymous. 6-question FAQ](https://servghost.com/guides/how-to-host-a-tor-hidden-service) [### Offshore Mail Server Setup — Self-Host Private Email in 2026 Operations Run your own private email server on an offshore VPS: why self-host email, what you need, the realistic setup with an all-in-one mail stack, and how to get deliverability right. 6-question FAQ](https://servghost.com/guides/offshore-mail-server-setup) [### Crypto Node Hosting Guide — Run a Blockchain Node on a VPS Operations How to host a blockchain node on a server: why run your own node, sizing the server for Bitcoin, Ethereum, Monero and more, the setup, and keeping it private. 6-question FAQ](https://servghost.com/guides/crypto-node-hosting-guide) [### GPU Hosting for Stable Diffusion — Run Your Own Image Server Operations Run Stable Diffusion on your own GPU server: why self-host image generation, which GPU to pick, the setup with a web UI, and what it costs versus a hosted service. 6-question FAQ](https://servghost.com/guides/gpu-hosting-for-stable-diffusion) [### Server OpSec — Staying Anonymous When You Run a Server Privacy Operational security for anyone running an anonymous server: the mistakes that deanonymise people, the habits that prevent them, and how to keep identities truly separate. 6-question FAQ](https://servghost.com/guides/server-opsec-staying-anonymous) [### Seedbox Setup Guide — Build Your Own Private Seedbox in 2026 Operations How to build your own seedbox on a server: what a seedbox is, sizing it, installing a torrent client with a web UI, and keeping it private and secure. 6-question FAQ](https://servghost.com/guides/seedbox-setup-guide) [### How to Bypass DPI Censorship with Your Own VPS (2026 Guide) Privacy Your VPN stopped working? How to bypass DPI censorship with your own VPS: what deep packet inspection actually detects, which of the five 2026 protocols beats which block, and a full VLESS+REALITY walkthrough. 6-question FAQ](https://servghost.com/guides/bypass-dpi-censorship-with-your-own-vps) [### Full-Disk Encryption on a VPS: LUKS Setup and What It Really Protects Operations How to encrypt a VPS with LUKS: encrypted data volumes, full-root encryption with remote unlock over SSH, the settings that matter on a small server, and an honest account of what disk encryption stops. 8-question FAQ](https://servghost.com/guides/full-disk-encryption-on-a-vps) [### Hiding Your Origin Server IP: CDNs, Reverse Proxies and What Still Leaks Privacy Whether to put a CDN in front of an offshore server: what it hides, the abuse desk you inherit, the six ways an origin IP leaks anyway, and how to audit yours. 8-question FAQ](https://servghost.com/guides/hiding-your-origin-server-ip) [### VPS Backup Strategy: Encrypted, Off-Site and Actually Restorable Operations Your host keeps no backups. What really destroys servers, why push backups die with them, restic vs Borg, the keys everyone forgets, and how to test a restore. 8-question FAQ](https://servghost.com/guides/vps-backup-strategy) [### Self-Hosting Matrix: Federation, Metadata and What E2EE Doesn’t Hide Operations What a Matrix homeserver really gives you: Synapse vs Conduit, the server_name you can never change, media that eats the disk, and what federation still reveals. 8-question FAQ](https://servghost.com/guides/self-host-a-matrix-server) [### How to Migrate a Website to Offshore Hosting Without Downtime Operations The order that makes a host migration boring: lower the DNS TTL days ahead, run both servers in parallel, freeze writes for minutes rather than hours — and clean up the passive-DNS, Certificate Transparency and WHOIS trail the move leaves behind. 8-question FAQ](https://servghost.com/guides/migrate-website-to-offshore-hosting) [### How to Self-Host a Crypto Payment Gateway with BTCPay Server Operations Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out. 8-question FAQ](https://servghost.com/guides/self-host-a-crypto-payment-gateway) ## Put it somewhere that filters the floods Offshore KVM servers in seven jurisdictions with L3/L4 DDoS filtering, unmetered bandwidth, full root and NVMe storage. No KYC, crypto payment, deployed minutes after the transaction confirms. [View VPS Plans](https://servghost.com/vps) [Dedicated Servers](https://servghost.com/dedicated) [Offshore Hosting](https://servghost.com/offshore-hosting) ## Structured data (JSON-LD) ```json { "@context": "https://schema.org", "@type": "Organization", "@id": "https://servghost.com/#organization", "name": "ServGhost", "url": "https://servghost.com", "description": "Offshore VPS & dedicated servers in 7 offshore jurisdictions. No KYC, no logs, crypto only. Privacy by architecture.", "logo": { "@type": "ImageObject", "url": "https://servghost.com/ServGhost.webp", "width": 512, "height": 512 }, "foundingDate": "2025", "areaServed": [ { "@type": "Country", "name": "Iceland" }, { "@type": "Country", "name": "Panama" }, { "@type": "Country", "name": "Moldova" }, { "@type": "Country", "name": "Romania" }, { "@type": "Country", "name": "Switzerland" }, { "@type": "Country", "name": "Netherlands" }, { "@type": "Country", "name": "Russia" } ], "knowsAbout": [ "Offshore hosting", "Offshore VPS", "Bare-metal dedicated servers", "DMCA-ignored hosting", "No KYC hosting", "Cryptocurrency payments", "Privacy engineering", "Token-based authentication", "Anonymous domain name registration", "No-KYC domain registrar", "WHOIS privacy", "Cheap .com domains", "Crypto-paid domain names", "NVIDIA GPU compute", "Windows RDP hosting", "Agentic commerce" ], "contactPoint": { "@type": "ContactPoint", "contactType": "customer support", "url": "https://servghost.com/contact", "availableLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] }, "sameAs": [ "https://servghost.com/canary", "https://servghost.com/press" ] } ``` ```json { "@context": "https://schema.org", "@type": "WebSite", "@id": "https://servghost.com/#website", "url": "https://servghost.com", "name": "ServGhost", "publisher": { "@id": "https://servghost.com/#organization" }, "inLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] } ``` ```json { "@context": "https://schema.org", "@type": "Article", "headline": "VPS DDoS Protection: Where Your Host Stops and Layer 7 Begins", "description": "Your host filters the packet floods; the request floods are yours. How L3/L4 scrubbing works, why Layer 7 attacks pass straight through it, and the caching, rate limits and connection ceilings that keep a small offshore server online while it is being hit.", "image": "https://servghost.com/assets/img/guides/surviving-a-ddos-attack-on-your-vps.webp?v=1788769011", "author": { "@type": "Organization", "@id": "https://servghost.com/#editorial", "name": "ServGhost Editorial", "url": "https://servghost.com/about", "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.", "knowsAbout": [ "Offshore hosting jurisdictions", "Data retention law", "MLAT and judicial cooperation", "WireGuard and OpenVPN deployment", "Tor relay operation", "Monero and Bitcoin payment privacy", "KVM virtualization and bare-metal hosting", "DMCA-ignored hosting" ], "parentOrganization": { "@id": "https://servghost.com/#organization" } }, "publisher": { "@id": "https://servghost.com/#organization" }, "datePublished": "2026-09-07T00:00:00+00:00", "dateModified": "2026-09-07T00:00:00+00:00", "mainEntityOfPage": "https://servghost.com/guides/surviving-a-ddos-attack-on-your-vps", "inLanguage": "en", "keywords": "VPS DDoS protection, how to stop a DDoS attack on a server, layer 7 DDoS mitigation, nginx rate limiting DDoS, offshore DDoS protected hosting, L3 L4 DDoS filtering, SYN flood mitigation, hide origin server IP DDoS", "articleSection": "Operations", "wordCount": 4160 } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Does “DDoS protection included” mean I am safe from everything?", "acceptedAnswer": { "@type": "Answer", "text": "No, and the gap is precise rather than vague. Included protection is network-layer filtering: it drops volumetric floods — SYN floods, UDP amplification, raw packet storms — upstream, before they reach your port. That is the category you genuinely cannot handle yourself, so it is the right thing to include. It does not inspect your application, so an HTTP flood of a few thousand requests per second against an expensive endpoint passes through it untouched and takes your site down while every network graph looks normal. Layer 7 is configuration you own: caching, rate limits and connection ceilings." } }, { "@type": "Question", "name": "How do I tell a DDoS attack from a traffic spike?", "acceptedAnswer": { "@type": "Answer", "text": "Ask whether the traffic wants something. Real visitors, even a sudden flood of them from a popular link, request pages that exist, load the assets on those pages, arrive with plausible referrers and spread across many networks in a natural pattern. An attack usually hammers one path, ignores assets, sends implausible or absent user-agents, and shows a distribution that looks synthetic. Check your access log for requests per client address and per path: if one endpoint dominates and nothing else is being loaded, it is an attack. If the same pages a human would want are being served and your referrers are real, you have a capacity problem with a happy cause." } }, { "@type": "Question", "name": "What is the single most effective thing I can do while under attack?", "acceptedAnswer": { "@type": "Answer", "text": "Turn on full-page caching for anonymous visitors, and configure it to serve stale content when the backend is struggling. A rate limit rejects work; a cache makes the work not exist. A request that cost a database query, a template render and an application worker becomes a file read, and the same hardware that collapsed at a few hundred dynamic requests per second will serve tens of thousands of cached ones. It is also the only measure on the list that helps identically against real traffic, so unlike a rate limit it cannot backfire on your own users." } }, { "@type": "Question", "name": "Why did my nginx rate limit stop working after I put a CDN in front?", "acceptedAnswer": { "@type": "Answer", "text": "Because every request now arrives from the CDN’s address rather than the visitor’s, so a per-client limit is counting the entire internet as a single client. Depending on the threshold, it will either never trigger or ban all of your traffic at once. Configure your real-IP source — in nginx, the trusted proxy ranges plus the header the proxy sends — so the limit keys on the actual visitor again. Restrict that trust to the proxy’s own ranges: if you accept a client-supplied header from the open internet, an attacker can forge a fresh identity on every request and walk through every limit you have." } }, { "@type": "Question", "name": "Is fail2ban enough to stop a DDoS attack?", "acceptedAnswer": { "@type": "Answer", "text": "No. fail2ban reads logs on an interval and bans offending addresses after a threshold, which suits brute-force attempts from a small number of sources. A distributed attack arrives in seconds from thousands of addresses that each send only a handful of requests, so the threshold is never reached and the reaction time is far too slow regardless. Worse, a ruleset that grows to tens of thousands of entries can consume more resources than the attack. Keep it for SSH and login endpoints, and handle floods with caching, rate limiting and an upstream filter." } }, { "@type": "Question", "name": "Should I use a CDN, or run my own reverse proxy in front?", "acceptedAnswer": { "@type": "Answer", "text": "It depends on what you host rather than on your budget. A commercial CDN brings absorption capacity you cannot match and a challenge page one click away, but you inherit its abuse desk and it can see your traffic — which for offshore or DMCA-sensitive projects is often the weakest link in an otherwise careful setup. Your own front nodes cost more work and have real capacity limits, but there is no third party in the request path and a front that gets attacked can be replaced with a new address in minutes. Either way, the origin must be firewalled to accept web traffic only from the front, or the whole arrangement is decorative." } }, { "@type": "Question", "name": "Will an attack cost me money as well as uptime?", "acceptedAnswer": { "@type": "Answer", "text": "On a metered plan, yes — traffic you never asked for and could not refuse still counts against your transfer allowance, and a sustained flood can produce an overage bill larger than a year of hosting. This is the practical reason unmetered bandwidth matters more than it looks on a specification sheet: it converts a financial risk into a purely technical one. It is also worth knowing in advance that if an attack threatens shared infrastructure, providers may temporarily null-route the address; that is standard practice everywhere, not a failure of your particular host." } }, { "@type": "Question", "name": "Does moving to an offshore or no-KYC host make attacks more likely?", "acceptedAnswer": { "@type": "Answer", "text": "The hosting choice itself is neutral; what you run is what attracts attention. Game servers, forums, streaming, marketplaces and anything with a competitor or a grudge draw attacks regardless of jurisdiction. What does change offshore is your recourse: you are less likely to be dropped for being inconvenient, which cuts both ways — the protection is technical rather than contractual. Choose a location with genuine transit capacity, take unmetered bandwidth, keep the origin address hidden, and treat layer 7 as your own responsibility from the first day rather than the first incident." } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://servghost.com/" }, { "@type": "ListItem", "position": 2, "name": "Privacy Hosting Guides", "item": "https://servghost.com/guides" }, { "@type": "ListItem", "position": 3, "name": "VPS DDoS Protection: Where Your Host Stops and Layer 7 Begins", "item": "https://servghost.com/guides/surviving-a-ddos-attack-on-your-vps" } ] } ```