TCP-over-TCP in VPNs: Performance Problems Explained

A VPN can look fast on paper and still feel awful. Pages stall for several seconds, then arrive in a rush. A download sprints, then crawls, then sprints again. A file upload that should take a minute takes ten. Speed tests may even show a decent number during the quick bursts. If this happens only in one mode, or only on a poor network, one possible cause is a design problem with a famous nickname: TCP-over-TCP.

This article explains exactly what TCP-over-TCP is, why two layers that are both trying to be helpful can combine into something slow, what the symptoms look like, and what you can do as an ordinary user. It is not a protocol shopping guide. For a side-by-side look at the two transport choices of one popular tunnel, see OpenVPN over TCP versus UDP. Here the focus is on the mechanism and on diagnosis.

A short refresher on TCP and UDP

Both TCP and UDP carry data between two computers, but they promise different things.

• TCP numbers the data, acknowledges what arrives, resends what is missing, delivers things in order and slows down when it thinks the network is congested. It is the reliable, polite transport behind web pages, email and file downloads.
• UDP just sends packets. It does not acknowledge, resend or reorder. If a packet is lost, UDP does not care. Anything that needs reliability has to be added by the application above it.

Most of your everyday traffic is TCP. A VPN tunnel is a second layer that carries those packets. The tunnel itself can choose its own transport: some tunnels send their packets over UDP, others over TCP. If your normal traffic is TCP and the tunnel is also TCP, you have TCP-over-TCP. More background on how tunnels fit together is in what a VPN protocol is.

What goes wrong: two repair crews for one broken packet

Reliability is the whole point of TCP, and it is a problem when it happens twice. Imagine that a single packet is lost somewhere between you and the VPN server.

The outer tunnel notices first. The tunnel's TCP connection sees a gap. It stops delivering anything behind the gap, even data that has already arrived, because TCP promises in-order delivery. It waits for the missing piece and then resends it. While this happens, every later packet of the tunnel sits in a queue.

The inner connection also notices, but later. From the point of view of your web download inside the tunnel, the acknowledgements are not coming back on time. Its retransmission timer expires, which tells it the network is congested. It reacts in two ways: it resends the data again, and it cuts its sending rate sharply.

The result is a pile-up.

1. The outer layer is still repairing the first loss.
2. The inner layer has already declared the data lost and sent a copy.
3. That copy goes into the outer queue, behind the very packet being repaired.
4. Now the tunnel carries duplicate data that nobody needs.
5. The inner layer, seeing delay and duplicate acknowledgements, shrinks its window even more.

Each layer is behaving correctly by its own rules. Together they waste capacity and create stalls. In severe cases, the retransmission timers of the inner layer keep doubling after repeated timeouts, so the connection becomes slower and slower, a situation sometimes called a TCP meltdown.

A worked timeline

Take a modest link with a 60 ms round trip, a tunnel carrying a download, and one lost packet.

Time	Outer tunnel (TCP)	Inner connection (TCP)
0 ms	Packet 7 of the tunnel is lost	Sends a stream of data
60 ms	Packets 8, 9 and 10 arrive, but are held back	Waits for acknowledgements
120 ms	Receiver signals the gap	Acknowledgements are late
200 ms	Outer layer resends packet 7	Timer fires, inner layer resends the data
260 ms	Packets 7 to 10 are released at once	Inner layer sees a sudden burst and duplicates
300 ms	Inner copy arrives behind the first	Inner window already halved

A single lost packet cost roughly 200 to 300 ms in this simplified picture, plus a smaller sending rate afterwards, plus duplicate data. On a clean link with 0.01 percent loss, that happens rarely and you will not notice. On a Wi-Fi link with 2 percent loss, it happens many times per second, and the throughput falls much further than the loss figure alone suggests.

Why UDP tunnels avoid the problem

If the tunnel runs over UDP, there is only one reliability layer: the inner TCP connection. A lost tunnel packet is simply gone. Nothing in the tunnel holds the rest back. The inner connection notices the missing data in the normal way and fixes it once. This is how most modern tunnel designs work, and it is one reason UDP is usually preferred when the network allows it. The WireGuard project is an example of a tunnel design that works over UDP only.

Newer designs go further. The QUIC transport defined in RFC 9000 runs over UDP and builds in its own loss recovery, which is the reason some IP-in-HTTP approaches, such as Proxying IP in HTTP, can carry tunnels over HTTP/3 without stacking two TCP layers. You do not need to know the details; the point is that the industry deliberately moved away from TCP-in-TCP.

Why TCP tunnels still exist

If it is so awkward, why is it offered at all? Because it solves a different problem.

• Some networks restrict UDP. Certain workplaces, schools, hotels and public networks only let through a narrow set of traffic. A TCP tunnel can sometimes work where a UDP one cannot.
• Some devices have poor UDP handling, for example older routers with short UDP timeouts that drop idle tunnels.
• TCP mode is a fallback. Many VPN apps use it only when the preferred mode fails.

This is a legitimate use of a trade-off, not a trick to break rules. If your network is set up to allow only certain traffic, respect that policy, and talk to the network owner when you have a work need. The cost of using a TCP tunnel is the possible slowdown described in this article, which is why it is typically a second choice.

Recognising the symptoms

TCP-over-TCP trouble rarely announces itself. These patterns are suggestive, especially when they appear on a poor network and improve on a good one.

• Throughput looks fine on a short test but collapses on a long transfer.
• Speed oscillates in a saw-tooth pattern with long flat stretches.
• Pages freeze for several seconds, then everything loads at once.
• Interactive tasks, such as typing in a remote shell, lag in bursts.
• The problem is much worse on Wi-Fi or mobile data than on a wired connection.
• Ping times to the VPN server look normal, yet real transfers behave badly.
• The same device is faster on another network or in another mode.

If your problem is steady slowness rather than stalls, begin with why a VPN can be slow, because simple causes such as distance or a busy server are far more common than TCP-over-TCP.

How to test for it without special tools

You cannot inspect the tunnel's internals on most phones, but you can run a controlled comparison.

Step 1: Make the network healthy first. Ping your router 100 times (Windows ping -n 100, macOS or Linux ping -c 100). If you see loss, fix that first because loss is what triggers the problem.

Step 2: Record a baseline without the VPN. Run a download of a large public file, or a speed test, and note the time and the stability of the speed.

Step 3: Run the same test with the VPN. Compare both the number and the shape. A smooth line that is somewhat lower is normal tunnel overhead. A jagged line with stalls is the suspicious pattern.

Step 4: Change only the network. Try a cable, or a different Wi-Fi band, or mobile data. If the jaggedness disappears on a clean link, the tunnel and the loss together were the cause, which fits the pattern.

Step 5: Check the mode your app is using. If your app shows a connection type, note whether it is TCP or UDP. If it does not show one, do not guess. With XPASS you use the free VPNclient app and the details on your My Pass page; keep the app's default settings unless support suggests otherwise.

Step 6: Try another location. A different server may give a cleaner path, which lowers loss and therefore reduces the effect.

Practical ways to reduce the damage

1. Reduce packet loss at the source. Use a cable, move closer to the router, choose 5 GHz, and stop heavy uploads. Loss is the trigger, so removing it removes most of the pain.
2. Prefer UDP when your network and app allow it. It is the default for many modern tunnel designs. Switch only if your app clearly exposes the choice.
3. Use a nearer location. A shorter round trip means the timers expire sooner and recover faster.
4. Keep MTU sensible. Oversized packets can add loss and fragmentation on top of the problem. See how to find the right MTU for a measurement method.
5. Avoid stacking tunnels. Running a VPN over a second VPN, or over a proxy that also uses TCP, multiplies the layers.
6. Reconnect after a long stall. A new session clears the timers that have ballooned.
7. Check for software conflicts such as security suites that inspect or proxy traffic.

If your network only allows TCP and you still need the VPN, accept some slowdown. Lowering the load, for example by pausing big downloads, makes it more bearable.

Limits and honest caveats

• Not every slow VPN suffers from this. Distance, server load, weak devices and ISP shaping are much more common.
• Modern TCP stacks are smarter than the textbook picture. Tuning, pacing and better loss recovery soften the worst effects, so the damage varies with the operating system.
• Some tunnel products reduce the problem with their own tricks, such as small buffers or custom reliability. Results differ by implementation.
• You cannot always see the transport. Many apps hide it. Do not assume the cause without evidence.
• A TCP tunnel is not insecure. The issue is performance, not safety. Encryption is a separate property, explained in what a VPN protocol is.
• Do not change settings to evade a network's rules. If a workplace or school restricts traffic, ask the owner.

Common mistakes

• Assuming that a TCP tunnel is more secure or more reliable than a UDP one.
• Judging performance from the first ten seconds of a transfer.
• Testing only on weak Wi-Fi and blaming the VPN design.
• Changing tunnel mode and location together, so you do not know which helped.
• Ignoring packet loss and tuning everything else.
• Leaving a stalled connection alone for minutes rather than reconnecting.

Summary

TCP-over-TCP happens when TCP traffic is carried through a tunnel that is also TCP. When a packet is lost, the outer layer and the inner layer both try to repair it, hold back traffic, send duplicates and cut their speeds, which creates stalls and a jagged, slow transfer. On a clean connection the effect is small, while on a lossy one it can be large. UDP-based tunnels avoid the stacking, and TCP tunnels remain as a fallback for networks that restrict UDP. The best defence is to remove packet loss, use the default mode, choose a nearer location and measure before changing anything.

If you want to compare how different networks behave with a short prepaid pass, the pricing page explains how passes work.