DDoS Protection for a VPS or Dedicated Server: What Keeps It Online

You rent a VPS or a dedicated server, you put your website, game, or app on it, and one day it simply stops responding. You cannot reach it either. You open a ticket, and your host replies that the address was hit by a DDoS attack and has been null-routed, which is a polite way of saying they switched it off so the flood would stop hitting everyone else. The attack may already be over, but your server is still dark. This is the moment a lot of people learn that renting a server and protecting it are two separate things.

A single server sits behind one connection, so a large flood can fill the line before the server's own defenses ever get involved.

This guide explains why a single VPS or dedicated server is such an easy target, what your host will and will not do when an attack lands, and the practical ways to add real DDoS protection to one server without moving it. You do not need a networking background to follow along.

Why one server is an easy target

A DDoS attack, short for distributed denial of service, is an attempt to knock a service offline by flooding it with junk traffic from many machines at once. Your server has one public address and sits behind one internet connection, so an attacker only has to aim enough traffic at that single point to overwhelm it.

The cheapest and most common version does not try to be clever. It simply sends more data than your connection can carry. If your server has a 1 Gbps port and the attack pushes 30 or 40 Gbps at it, the extra traffic has nowhere to go, and the congestion happens upstream from you, before a single packet reaches anything you control. This is called a volumetric attack, and it is the reason on-server defenses fall short. Your firewall can be flawless and it still will not matter, because the pipe is already full by the time traffic arrives.

There is a second reason single servers get hit so often: the traffic needed to take one offline is cheap to rent and easy to point at one address. A game server, a community website, a Discord bot backend, or a small storefront can all draw an attack from a rival, a disgruntled user, or someone simply testing what they bought.

What your host actually does when an attack lands

This is the part that catches people off guard. Most budget VPS and dedicated server hosts are protecting their own network, not your specific service. When your address starts pulling in a large flood, the fastest way for them to protect every other customer on that link is to stop routing traffic to your address entirely. That is called null routing, or blackholing, and it does exactly what the attacker wanted: your server disappears from the internet. We cover why hosts reach for this, and what it means for you, in why your host null-routes you during an attack.

Some hosts do include a level of protection, often advertised as mitigation "up to" a certain size. It is worth reading exactly what that covers, because "up to 10 Gbps" is little comfort against a 40 Gbps flood, and some plans only switch protection on after an attack is detected. The gap between the attack starting and protection engaging is often enough to knock you offline.

Why adding a firewall or rate limiting is not the fix

The instinct is to harden the server itself: tighten the firewall, add rate limiting, block bad addresses. These help against small or unsophisticated attacks, and they are worth doing. They cannot solve the core problem, though, because they all run on or near the server, and a volumetric flood does its damage before it gets there. You cannot filter your way out of a full pipe from inside the pipe.

How remote DDoS protection keeps one server online

The only reliable fix is to filter the flood earlier, inside a network with far more capacity than your single connection. For one server, that usually works like this.

Instead of exposing your server's real address to the world, the provider gives you a protected address to use in its place. Traffic to that protected address arrives at the provider's network first, where the flood is separated from real visitors and thrown away. This filtering step is often called scrubbing. Whatever survives is forwarded to your actual server through a private path called a tunnel, so your applications just see ordinary visitors connecting as usual. The flood never touches your connection.

Filtering happens upstream: attack traffic is removed before it reaches your connection, and only clean traffic is delivered through the tunnel.

The tunnel most commonly used for this is a GRE tunnel, which behaves like a direct link between the provider's network and your server even though it runs over the ordinary internet. If you want the mechanics, we walk through them in how GRE tunnel DDoS protection works. The key idea for a single-server owner is simpler: your server stays exactly where it is, and protection is added in front of it.

Sterile Networks offers this single-server setup on its Sterile Personal plan, which includes one protected address, one mapped origin (your real server), and one GRE tunnel. If you instead run your own block of IP addresses, the approach shifts to network and ASN protection, where whole ranges are filtered at once. Which one fits comes down to a single question: are you protecting one server, or an entire network you control?

Does it matter whether it is a VPS or a dedicated server?

For the protection model, not much. In both cases traffic is cleaned upstream and delivered to your machine through a tunnel. The practical difference is control. On a dedicated server you have full access to the operating system, so setting up a tunnel is straightforward. On a VPS it usually works too, but some virtualization setups restrict the networking features a tunnel needs. If you are on a VPS, confirm with your host that GRE tunnels are allowed before you commit, or choose a provider that supports them.

What to look for when protecting a single server

A few things separate protection that holds up from protection that looks good until an attack arrives:

• Always-on filtering. A flood can fill a link in seconds, so protection that has to be switched on after an attack starts is working against a clock it usually loses. Continuous filtering leaves no gap to exploit.

• No migration required. Good protection sits in front of the server you already have. You should not need to move hosts or rebuild anything.

• Your origin stays hidden. The whole model depends on attackers not knowing your server's real address. Keeping it private is a part you control yourself, and it is worth reading up on keeping your origin address hidden.

• Pricing you can predict. You should not pay more simply because an attack was larger. Sterile, for one, never bills for blocked attack traffic and measures only the clean traffic delivered to you.

  If the server runs a game, the same tunnel model applies, and premade filters tuned for common titles can help; that is the focus of game server DDoS protection.

Common mistakes worth avoiding

The most expensive mistake is assuming the host has it covered, then discovering during an outage that their answer is to null-route you. A close second is paying for filtering but leaving the real server address exposed, through an old DNS record or a service that leaks it, so an attacker can skip the protection and hit the origin directly. The last is waiting: arranging protection while an attack is in progress is slower and more stressful than setting it up on a quiet afternoon.

Getting protected

Start by naming what you need to keep online. If it is a single VPS or dedicated server, a protected address with a tunnel in front of it is usually all it takes, and setup does not disturb your existing hosting. If you run your own IP space, whole-network filtering is the better fit. From there you can review the available protection plans or talk to the Sterile Networks team about your specific setup.