Internet speed on a VPS, honestly explained — what your speedtest is actually measuring

On a VPS, "1 Gbps" is the bandwidth between your virtual machine and our edge router inside the datacenter. That number is measurable, contractual, and honest. It is NOT the bandwidth between your VM and your laptop in another country, and it is NOT what your speedtest will show you. This article explains the difference: what your speedtest actually measures, why a VPN tunnel adds overhead on top of that, what a guaranteed end-to-end gigabit between two cities really costs, and how to measure VPS speed correctly.

What "internet speed" actually means

Speed is not a property of a server. Speed is a property of the path between two specific points — point A and point B. The same VPS can do 940 Mbps to one host and 12 Mbps to another, in the same minute, with nothing wrong with the VPS.

When we say "your VPS has a 1 Gbps port", what we are technically saying is: between your VM and our edge router inside the datacenter, there is a 1 Gbps link. That part is honest, it's measurable, and it's under our control. Everything past the edge router is not. Once a packet leaves our datacenter, we are not driving it any more — we just paid the gas to get it to the front door.

The public internet is not our fiber

The internet is not one thing. It is a federation of roughly 75 000 independent networks ("autonomous systems") that have agreed to exchange traffic with each other under various commercial and peering agreements. Nobody — not us, not Google, not Amazon, not Cloudflare — owns end-to-end fiber to every home on the planet.

When you connect from Almaty to a server in Frankfurt, your packet typically takes 8–12 hops: your local ISP in Kazakhstan, their upstream provider, a transit network into Russia (Beeline, Rostelecom or KazTransCom on the way out), an exchange point in Moscow or Stockholm, a tier-1 transit (Cogent, Telia, Lumen) into Germany, DE-CIX in Frankfurt, our datacenter's transit provider, our edge router, our switch fabric, your VM. Twelve hops. Each one of those hops is a shared link, used by millions of other people, with its own queue and its own congestion.

If any one of those twelve hops is having a bad afternoon — a transit overloaded by a popular sports stream, a peering dispute between two networks, an ISP doing maintenance — your speed drops. That drop is not happening on our 1 Gbps port. It is happening at someone else's link, in someone else's country, run by someone we have no commercial relationship with.

What a guaranteed gigabit between two cities actually costs

Sometimes a client asks: "so why don't you just give me a guaranteed 1 Gbps to my city, end-to-end?" The honest answer is: we can — for tens of thousands of euros per month, and not everywhere on the planet. Below are the actual market rates for a dedicated 1 Gbps point-to-point Layer-2 wave from a tier-1 carrier (Lumen, GTT, Telia, Cogent), guaranteed 24/7, billed monthly:

Those numbers are not theoretical. That is what shows up on the invoice when a bank or a stock exchange buys a guaranteed cross-continental gigabit. They are also why a €2.98 VPS plan does not include a personal fiber strand from Frankfurt to your living room — it would be priced at five orders of magnitude more.

(Side note: 1 Gbps inside our datacenter is not the same as a guaranteed 1 Gbps to anywhere on the internet. We have a separate explainer on that.)

Why a VPN typically loses speed

A VPN cannot, in principle, run at the same speed as a direct connection. This is not a defect of any specific provider — it's how the technology works. A VPN does four expensive things every direct connection skips:

• Encryption — every byte gets passed through AES-256-GCM (or ChaCha20-Poly1305). Modern CPUs with AES-NI can encrypt several Gbps, but it still costs CPU and adds latency at both ends.
• Encapsulation — every original packet gets wrapped in a new packet. WireGuard adds ~60 bytes of headers, OpenVPN adds ~100, IPsec adds 50–80. On small packets that's significant overhead.
• MTU fragmentation — if the wrapped packet exceeds the path MTU (typically 1500 bytes), routers split it, which roughly doubles the per-packet cost. A misconfigured MTU silently halves the practical throughput of any VPN.
• An extra hop — instead of you → destination, the path becomes you → VPS → destination. The VPS is between you and what you want, and every byte makes the trip twice (in to the tunnel, out of the tunnel).

Typical real-world overhead, even on a perfectly tuned tunnel:

Distance is the silent throttle

Light moves at roughly 200 000 km/s through fiber (slower than vacuum). Every 1 000 km of fiber adds about 5 ms one-way latency, before any router queueing or buffering. Real-world RTT is typically 2–3× the theoretical minimum because the path is not a straight line and has dozens of hops.

Higher RTT slows down a single TCP flow (see Mathis above). Higher RTT also makes packet loss matter much more — every retransmit costs a full round-trip. This is why opening a website hosted in Frankfurt feels slower from Almaty even on a great local connection: it's not your ISP, it's not our server, it's the speed of light through 5 000 km of fiber and 12 routers.

Throttling — what it is and when it kicks in

Throttling = the network enforcing a sustained-traffic cap. Every VPS provider on the planet does this on entry-tier plans — selling a 1 Gbps port at €2.98/month and then letting one customer permanently saturate it for everyone else is financially impossible. We have a dedicated explainer that lays out, in plain English, why throttling exists, exactly when our shaper kicks in, and how to tell whether what you're seeing is throttling or something else entirely. Short version: short bursts run at full port speed, sustained heavy load gets capped — your VPS keeps running, you just can't permanently saturate the shared uplink.

How to measure speed correctly

There is exactly one honest way to measure the bandwidth of a VPS port: isolate our segment of the path. Anything that crosses an unrelated transit, a VPN tunnel, or a continent is not a measurement of us — it's a measurement of the entire internet between you and us, plus us, plus everything past us.

Methods that work, in order of preference:

1. iperf3 from inside your VM to a public iperf endpoint located in the same city or datacenter region. Lists are at iperf.fr/iperf-servers.php and similar registries.
2. iperf3 between two of your own VMs on the same node or in the same subnet — measures the local datacenter switch fabric directly.
3. Speedtest CLI (not the browser) with an explicit local server: speedtest --server-id=<id-near-the-DC>.
4. RIPE Atlas measurements if you need a more rigorous picture from many vantage points around the world.

Methods that do NOT measure us:

• speedtest.net in a browser, with an active VPN tunnel from another country, with auto-selected server. You're measuring: home ISP last-mile → home router → local ISP → international transit → VPN tunnel → our VPS → tunnel exit → another transit → speedtest server. Out of that whole path, we own about 5%.
• Downloading a large file from "the internet" (GitHub releases, S3, a Docker image registry). You're measuring whichever CDN happens to serve you, on whichever PoP they decided to send you to.
• Pinging a random IP address. Ping measures the path, not bandwidth, and the destination's policy on responding to ICMP varies wildly.
• Comparing to your own home internet. Your home line shares one ISP, one country, often one router; a VPS is on a totally different physical infrastructure with totally different topology.

# A test that produces useful data:
iperf3 -c <iperf-server-in-same-city> -P 4   # 4 parallel streams
iperf3 -c <iperf-server-in-same-city> -R     # reverse direction (download)
iperf3 -c <iperf-server-in-same-city> -t 60  # 60s, past TCP slow-start

# A test that produces noise:
speedtest.net in a browser through a VPN to a server in another country
# (don't open a ticket about the result of that)

What we actually know about this

We've been running VPS infrastructure for several years across 13 locations. We've worked through hundreds of "the internet is slow" tickets. The breakdown is roughly: ~95% of those tickets turn out to be one of (a) a VPN from a far country, (b) public-internet congestion on a transit we don't own, (c) a single-flow TCP measurement against high RTT, or (d) a speedtest against an overloaded test server. The remaining ~5% are real issues with our network — and we usually see them in our internal monitoring before the ticket arrives.

We're not hiding from this. Inside our datacenters we run modern Layer-3 fabric (10/40 Gbps backbones, multiple uplinks per host node), and we peer at the major exchanges (DE-CIX in Frankfurt, AMS-IX in Amsterdam, BIX in Sofia, plus regional ones). Local datacenter speeds are honest. Our outbound public-internet path is well-engineered. But neither we, nor anyone else on Earth, can guarantee bandwidth across the public internet — because the public internet is, by definition, owned by thousands of separate parties.

If you actually need a guaranteed end-to-end path — for a financial trading link, a CDN backhaul, a real-time video pipeline — that exists, it's called a dedicated wave or an MPLS L3VPN, and it's what those tens-of-thousands-per-month invoices in the table above buy. We can quote you one. It just isn't part of a €2.98 plan, and never has been at any provider in this industry.