A hosting provider saying "DDoS protected" means nothing on its own. The real questions are: up to what capacity does that protection hold, at which layer does it operate, and what happens to your legitimate traffic while an attack is in progress? The DDoS protection capacity figure everyone advertises — the number expressed in Gbps — answers only part of that. This guide explains what Gbps actually measures, what it does not measure, the critical difference between Gbps and Mpps, and how to read that number correctly when you are buying a server.
Gbps stands for gigabits per second and it measures the volume of data passing through a network link. In a DDoS protection context, it expresses the maximum amount of attack traffic per second that the mitigation infrastructure can absorb and clean.
Let us make that concrete. A standard server port is typically 1 Gbps. That server physically cannot receive more than 1 gigabit of data per second. If an attacker sends you 10 gigabits per second of junk traffic, your port saturates within the first second. At that point the firewall inside the server, your iptables rules, and any application-level protection become irrelevant — the traffic has congested the link before reaching the server at all. It is like emptying ten lanes of vehicles onto a two-lane road: how fast the toll booth at the end works no longer matters, the queue has already formed.
This is exactly why protection against volumetric DDoS attacks has to happen upstream in the network, not on the server. The mitigation system intercepts traffic before it reaches the server port, filters it, and admits only what is clean. The Gbps figure describes the capacity of precisely that filtering layer.
The size of volumetric attacks has grown enormously over the years, for three main reasons:
This is the most frequently overlooked point in the industry. While Gbps measures data volume, Mpps (million packets per second) measures the number of pieces that volume is split into. These are two completely different kinds of load.
Consider an example. You can produce the same 10 Gbps of traffic in two very different ways:
For network equipment, the real cost is not the size of a packet but the count. Every single packet requires a header read, a routing table lookup and a rule match. A flood of 19.5 Mpps is therefore vastly more destructive than a stream of 0.83 Mpps, even though the raw volume is identical. Once routers and firewalls exceed their packet-processing capacity, their CPUs are exhausted and they begin dropping legitimate packets too.
Attackers know this. That is why modern volumetric attacks frequently use minimum-size UDP packets: they cause far more damage for the same bandwidth. So when you evaluate a mitigation platform, "how many Gbps" is only half the question — "how many Mpps" needs an answer too.
A Gbps figure is meaningful only against Layer 3/4 (network and transport layer) attacks. UDP floods, SYN floods, ICMP floods and DNS/NTP amplification all fall into this category and all of them work by saturating the link.
Layer 7 (application layer) attacks operate on an entirely different logic. An HTTP flood, a slowloris, or a rain of expensive search queries may generate only a few megabits per second — yet still take your site down by exhausting your CPU, your database connection pool or your PHP worker processes. A 500 Gbps mitigation platform does nothing against a Layer 7 attack that generates 2 Mbps but turns every request into a heavy database query.
Our Layer 4 vs Layer 7 DDoS guide covers this distinction in detail and compares the defence strategies for each. In short: Layer 3/4 needs network capacity, Layer 7 needs request analysis and rate limiting. Neither substitutes for the other.
When a provider states a given Gbps capacity, remember that this is usually the total capacity of the entire data centre. That capacity is shared among all customers under attack at the same time. The questions worth asking are:
That last point is especially critical. A null route (blackhole) means all traffic to the attacked IP — including your legitimate visitors — is dropped at the network edge. It protects the rest of the data centre, but from your perspective it means the attack succeeded. Your server is running; nobody can reach it. Knowing a provider's null-route threshold is far more valuable than knowing their advertised Gbps figure.
Protection is not free. Routing your traffic through a scrubbing centre produces two side effects.
Added latency. If traffic is diverted to a geographically distant scrubbing centre, every packet travels further. For a website, 20–30 ms is imperceptible. But on real-time game servers such as MTA:SA, FiveM or competitive FPS titles, that difference directly degrades gameplay. This is why on-premise mitigation — filtering inside the data centre's own network — is far preferable to diverting to a remote centre for game hosting. If you serve a player base in Turkey, our Istanbul-located MTA server options combine low ping with network-level DDoS protected infrastructure.
False positives. Aggressive filtering rules sometimes block legitimate users. Players connecting through a VPN, sitting behind a shared IP, or using an unusual client are the most likely to get caught. A good mitigation system runs in learning mode while there is no attack, builds a profile of your normal traffic, and evaluates deviations against it. "Always use the most aggressive setting" is not a good strategy.
Set the advertised Gbps figure aside and work through this checklist instead:
It depends on how likely you are to be targeted. A personal blog or a corporate brochure site rarely sees a large volumetric attack. Competitive game servers, crypto-related projects, forums and community sites, and e-commerce stores are targeted regularly. The general rule: your network-level protection must be well above your server's own port capacity, because a 1 Gbps port saturates under a 1 Gbps attack.
No — not against volumetric attacks. iptables, nftables or Windows Firewall can only inspect packets after they have reached the server. If the link is already saturated, it is too late. A server-side firewall is useful against application-level abuse and scanning attempts, not against volumetric floods.
Because network hardware does work per packet. 10 Gbps composed of 64-byte packets contains roughly 23 times more packets than 10 Gbps composed of 1500-byte packets, and represents a far heavier load for routers. Looking only at Gbps ignores half the load.
The hardware generally does not shut down; the problem is reachability. When the link saturates or the IP is null-routed, the server keeps running but cannot be reached from outside. "My server is up" and "my service is reachable" are not the same thing.
If mitigation happens inside the data centre's own network, the impact is negligible. If traffic is diverted to a remote scrubbing centre, tens of milliseconds may be added depending on distance. For game and voice servers, that difference can be decisive.
Network-level protection is your provider's job; server-side hardening is yours. Changing the SSH port and moving to key-based authentication, disabling unnecessary services, applying updates regularly and automating backups are the first steps. Network-layer and server-layer protections complement each other.
In short: judge a provider not by the number they advertise, but by where, at which layer, and under what policy the protection is applied. Nubitro's Istanbul-located infrastructure runs on AMD Ryzen 9 9950X processors, DDR5 memory and NVMe M2 SSD storage, on a DDoS protected network. To work out the right configuration for your project, review our Turkey location VDS/VPS options or, for higher resource requirements, our dedicated server solutions — and reach our 24/7 support team through the contact page whenever you are unsure.
Turkey (Türkçe)
Worldwide (English)
