Does DDoS Protection Add Latency? What Filtering Does to Your Ping

Does DDoS protection add latency? Usually it adds a little, and how much you get depends far more on the route your traffic takes than on the filtering itself. That distinction decides whether the change is a millisecond nobody notices or thirty that make a shooter unplayable. If you run a game server, a voice service, an API, or anything else where response time is part of what people are paying for, this is a question worth settling before you buy protection rather than after.

Protected traffic reaches your server by way of a filtering location, and that extra leg is where most of the added delay comes from.

Why protection changes your ping at all

Latency is the time it takes for a packet to travel from a user to your server and back. Gamers usually call it ping, and it is measured in milliseconds. Under 30 ms feels instant, 60 ms is comfortable for most games, and past 100 ms players start to notice that their shots land late.

Without protection, a packet leaves a player's connection and takes whatever route the internet considers reasonable to your server. With protection in place, that traffic is steered into your provider's network first, cleaned there, and only then handed on to you. Attack traffic is discarded before it ever reaches your connection. The trade is that legitimate traffic now travels through an extra point on the way.

So the honest answer is yes, protection normally adds something. The useful question is what that something is made of, because the two ingredients behave very differently.

The detour matters more than the filtering

Inspecting a packet is fast. A common approach in the industry is to filter in the forwarding path, at the same speed traffic moves through the network, and the cost of that inspection is a fraction of a millisecond. It is not the part you feel.

Distance is the part you feel, and it comes down to physics. A signal travels through fibre at roughly 200,000 kilometres per second, so every 1,000 kilometres of cable adds about 5 ms in one direction and 10 ms on a round trip. Real routes are never straight lines, so the practical figure is usually higher.

Filtering costs a sliver of a millisecond. The distance the traffic travels is what actually shows up in a ping test.

Put numbers on it and the picture gets clear quickly. A server in Frankfurt with players across Germany, filtered at a location in Frankfurt, changes almost nothing. Move the filtering to New York and the same German players now cross the Atlantic to reach the filter, come back to Frankfurt, and repeat the trip on the way home. That is not a rounding error. That is a service people stop using.

This is why where a provider filters matters more than how well they filter, at least as far as latency is concerned. It is also why the number of locations a network runs is worth asking about. Sterile Networks describes its own approach publicly as operating from a focused footprint of scrubbing capacity that expands in phases, which is exactly the kind of detail to check against where your own users are.

There is a related idea that helps here. Some networks announce the same IP address from several locations at once, so each visitor is served by a nearby one instead of everyone travelling to a single site. If that sounds relevant to your setup, the guide to how anycast spreads one IP address across many locations covers it in plain language.

What a tunnel adds on top

If clean traffic is delivered to you through a GRE tunnel, your packets get wrapped inside another packet for the final leg. For IPv4 that wrapper costs about 24 bytes, made up of an outer IP header and a small GRE header, as described in RFC 2784.

Twenty-four bytes is nothing in terms of time. What it can affect is packet size. Networks enforce a maximum packet size called the MTU, and the wrapper eats into it. Get this wrong and large packets are either fragmented or silently dropped, which does not look like higher ping at all. It looks like downloads stalling, a web page half-loading, or a game client hanging on connect while small packets keep flowing normally. It is one of the more confusing failure modes in DDoS protection, and it is a configuration issue rather than a latency issue. The walkthrough of how GRE tunnel DDoS protection works covers the MTU setting in more detail.

Worth asking a provider separately: does traffic pass through the filtering network in both directions, or only on the way in? Both designs exist, and they add delay in different amounts. Delivery method also depends on what you run. A single server or a handful of addresses is usually simplest to protect with a tunnel, while an organisation with its own IP space can have those ranges announced on its behalf instead. Sterile Networks covers both delivery options on its network and ASN protection page.

The comparison people forget

Discussions about protection latency almost always compare protected traffic against a healthy, unattacked server. That is the wrong baseline, because the reason you are buying protection is that the unattacked state is not guaranteed.

Under attack, the comparison is not a few milliseconds. It is a working service against one that is not answering.

When a flood arrives at an unprotected server, latency does not gently rise. Response times spike, packets start disappearing, and connections time out. Often it ends with your host null-routing the address to protect everyone else on the same link, which drops your traffic entirely at the network edge. If that outcome is unfamiliar, why hosts null-route an address under attack explains what is happening and why.

Timing has a latency cost of its own. Protection that only switches on once an attack is detected has to reroute traffic mid-incident, and users feel both the attack and the reroute. Filtering that already runs continuously has no switch-on moment to survive. The trade-offs are laid out in the comparison of always-on and on-demand protection.

Measured across a month that includes a few real attacks, a steady 8 ms of added delay tends to look a lot better than an occasional hour of nothing working.

How to measure it before you commit

You do not have to take anyone's word for the numbers.

1. Get a baseline first. Run a ping or an mtr to your unprotected server from the places your users actually are, and write the numbers down. Without this, later results mean nothing.
2. Ask to test the location you would really use. A test in the wrong region tells you about that region, not about your service.
3. Measure from several places. Your own connection is one data point. If your players are spread across a continent, test from a few of their networks or ask a couple of them to run the same check.
4. Look at jitter and packet loss, not just the average. Ping variation is what causes rubber-banding in games and choppy audio on calls. A steady 45 ms beats an average of 35 ms that swings between 20 and 90.
5. Test with the real thing. Connect the actual game client or run real application traffic. Synthetic pings and real sessions do not always agree.

For game servers in particular, the profile applied to your traffic is part of the picture too, since filtering tuned for the protocol your game uses behaves differently from a generic ruleset. Sterile Networks publishes the list of games it provides premade filters for on its game server protection page.

What to look for in a provider

A short list gets you most of the way:

• Filtering locations reasonably close to your users, not just close to your server
• Filtering that runs continuously instead of starting after an attack is noticed
• A delivery method that fits your setup, whether that is a tunnel or your own announced address space
• Clear guidance on MTU so large packets are not quietly broken
• The ability to test before committing

Some added latency is the honest price of having attack traffic stopped somewhere with room to absorb it. A well-placed setup usually costs single-digit milliseconds, and that is a fair trade for a service that keeps answering when someone points a flood at it. A badly placed one can cost fifty, which is not a trade worth making.

If you are weighing this up for your own service, start by writing down where your users are and what your current ping to them looks like. That single number turns the whole question from a guess into a comparison. From there you can review the available protection plans or talk the setup through with the Sterile Networks team.

Stay online. Stay Sterile.