Why your speed to EU servers is slower than Speedtest?

It is a familiar situation. Speedtest reports 600/700 Mbps, yet your real speed when working with servers in the EU never climbs above 20 Mbps. The numbers differ by a factor of ten or more, and that naturally raises questions. Here is a detailed look at why it happens, and why the cause almost always sits with your provider's backbone links rather than with your equipment or our service.

The short version

Speedtest and a real connection to a distant server measure fundamentally different things. Speedtest checks the raw capacity of your local line over a very short route. Real work with EU servers depends instead on latency, the state of international links, and the quality of the route. So a high Speedtest result tells you your line is healthy, while low speed to the EU comes down to the physics of long-distance connections and the load on transit networks.

What Speedtest actually measures

Speedtest is built to show the highest number it can, so its result only partly reflects real work with distant servers.

1. It picks the nearest server. Speedtest automatically selects the server with the lowest latency, which is usually one inside your provider's own network or in the same city. Traffic to it travels a short route and never touches international links.

2. It opens many parallel connections. Speedtest runs several simultaneous TCP streams (typically 4 to 16) and adds up their speed. That is how it sidesteps the limit a single connection runs into on long routes (more on that just below). Real applications often work over one connection or just a few, so they never get that boost.

3. Latency is minimal. On a short route the round trip (RTT) is only a few milliseconds, so TCP has time to ramp up to the full speed of the line.

The upshot is that Speedtest shows the "lab" throughput of your line, not the speed you will actually get when exchanging data with a server in another country.

The main cause: bandwidth-delay product and the TCP window

This is the key technical point, and it explains most of the gap.

TCP sends data in "windows". The sender pushes out a chunk of data, then waits for confirmation that it arrived before continuing. The maximum speed of a single TCP connection follows a simple formula:

Speed = Window size / Latency (RTT)

To fill the line completely, the window has to be at least as large as the so-called bandwidth-delay product (BDP):

BDP = Bandwidth × RTT

Let us run the numbers for a 600 Mbps line with a latency to an EU server of around 50 ms:

BDP = 600,000,000 bit/s × 0.05 s = 30,000,000 bits = 3.75 MB

In other words, to saturate the line, roughly 3.75 MB of data has to be in flight at any moment. If one side is stuck with an old or limited window size (the classic 64 KB without window scaling), the ceiling for a single connection works out to:

Speed = 65,536 bytes × 8 bit / 0.05 s ≈ 10.5 Mbps

That is exactly why a single connection to a distant server tops out at 10 to 20 Mbps, even when the line itself is rated for hundreds of megabits. On a short route (RTT of 2 ms) that same window would deliver over 260 Mbps, which is precisely why the problem never shows up in Speedtest. The higher the latency, the stronger the effect, and this is not a hardware fault but a fundamental property of the protocol.

Latency (RTT) and the physics of long links

Latency on long routes is made up of several parts, and some of them cannot be removed at all.

Light travels through optical fiber at roughly 200,000 km/s, noticeably slower than the speed of light in a vacuum because of the refractive index of glass. Every thousand kilometres of route adds about 5 ms one way, so about 10 ms for the round trip. And a real route rarely runs in a straight line, so it is usually longer than the geographic distance.

On top of that comes the delay at every intermediate node (router): processing the packet, queuing it, then forwarding it on. On the way to an EU server there are typically 10 to 20 such nodes (hops), and each one adds its share. The higher the resulting RTT, the lower the ceiling on a single connection by the formula above.

Packet loss and its effect on TCP

Even small amounts of packet loss on an international link cut the resulting speed sharply. TCP reads a lost packet as a sign of congestion, so it responds by slowing down, then builds the speed back up again. The relationship is captured by the Mathis equation:

Speed ≈ MSS / (RTT × √p)

Here MSS is the maximum segment size (usually around 1460 bytes), RTT is the latency, and p is the fraction of packets lost. The formula shows that speed falls inversely with the square root of the loss rate and depends directly on latency.

In practice this looks dramatic. At an RTT of 50 ms with a standard MSS, even 0.1 percent loss limits a single connection to about 73 Mbps, 1 percent loss brings it down to roughly 23 Mbps, and 2 percent loss drops it below 17 Mbps. On long transit routes, loss of 1 to 2 percent during peak hours is entirely normal, and it is often the single biggest limiter.

Routing and peering

The path your traffic takes to an EU server is not direct. It runs through a chain of operators and the BGP routing protocol, which picks a route on commercial and technical grounds rather than by shortest distance.

That gives rise to several typical problems. The route may run sub-optimally, for example through a third country, which raises both latency and the risk of loss. Traffic passes through the junctions between networks (peering points and transit links), and if one of those junctions is congested, that is exactly where speed drops. Asymmetric routing is common too, where packets going out and coming back take different paths, which makes diagnosis harder. And with budget providers, international connectivity may be bought on a leftover basis, so its capacity falls short during peak hours.

Congestion on your provider's international links

Local traffic (within the city and within the country) has plenty of spare capacity at most providers, which is why Speedtest to a nearby server always shows a high number. International links, on the other hand, are more expensive and are bought in limited volume. During the evening peak, when load is at its highest, those links become the bottleneck. That explains why speed to the EU can swing noticeably over the course of a day, while local Speedtest stays consistently high.

Other technical factors

Beyond the main causes, a few more things affect speed to a distant server.

MTU and fragmentation. If the MTU along the route is smaller than expected, packets get fragmented, which lowers efficiency. A misconfigured PMTUD (path MTU discovery) can lead to "black holes" and stalled transfers.

Bufferbloat. Oversized buffers on intermediate nodes raise latency under load and confuse TCP's flow-control algorithms, lowering real speed further.

Shaping and prioritisation (QoS). Some providers deliberately throttle or de-prioritise international traffic, or a particular type of traffic, which directly affects speed.

Protocol overhead. TCP, IP, and encryption (TLS) headers take up part of the bandwidth. On a short route this is invisible, but combined with loss and latency on a long route it adds up.

Your local environment. Wi-Fi instead of cable, an overloaded home router, antivirus, or a VPN on the device can also lower real speed, so it is worth ruling those out when diagnosing.

Why this is not a hardware or service problem

A high Speedtest result is clear proof that your equipment, cabling, and local line are healthy and deliver the speed they should. The drop when working with EU servers comes from latency on the long route, the window limit on a single TCP connection, packet loss, and the state of your provider's international links. All of these factors sit outside our service and outside your equipment: they belong to the stretch of network between your provider and the backbone operators.

How to check it yourself

To confirm the cause, run a few simple checks.

1. Run Speedtest manually and choose a server in the relevant EU country (for example Germany or the Netherlands, where our servers are located). That shows the real speed along the exact route used in practice, not to the nearest local server.

2. Trace the route. The command tracert (Windows) or traceroute (macOS, Linux) to our server shows the chain of nodes and the latency at each one. For a clear view of loss and latency, the mtr utility (or WinMTR on Windows) is ideal, and it is best left running for a few minutes during peak hours.

3. Compare one connection with several. If a multi-stream download is fast while a single stream is slow, that directly confirms the TCP window limit on the long route.

4. If you have the technical means, use iperf3 to measure throughput to the distant node directly, both with one stream and with several.

What to do

If your checks show high latency or packet loss on the international leg, it is worth contacting your provider with concrete data: the route trace and an mtr reading with the time of day noted. Adjusting the route or expanding international connectivity is the provider's responsibility. On our side, we are happy to supply the addresses of our servers for targeted diagnosis and to help interpret the results.

The bottom line

A Speedtest result of 600/700 Mbps confirms your line is healthy. The drop to 20 Mbps when working with EU servers is to be expected, and it comes from latency on the long route, the window limit on a single TCP connection, packet loss, and the load on your provider's international links. None of this is connected to your equipment or to our service, and the exact cause can be pinned down with a simple route diagnosis.

Updated on: 21/06/2026