TCP-over-TCP Is a Bad Idea

Tunneling TCP inside another TCP connection seems convenient. Maybe your tool only supports TCP. Maybe the network blocks UDP. Maybe you're trying to force everything through a TLS tunnel. It works, at first. But if you care about performance or reliability, it's one of the worst architectural choices you can make.

The fundamental issue is that TCP manages reliability, flow control, and congestion. It was never designed to be layered inside itself. When you run one TCP stream inside another, the two stacks interfere with each other. The inner connection expects the network to behave in a certain way. The outer connection reshapes the flow, adds latency, buffers aggressively, and retries blindly. The result is often worse than a single lossy link.

This setup creates what's known as TCP meltdown. When the outer TCP stream experiences packet loss or jitter, it holds back data. The inner TCP connection sees that as delay or loss and starts to back off. The outer connection, meanwhile, thinks it's helping by retransmitting and buffering. Now you have two feedback loops working against each other. Performance drops off a cliff.

It gets even worse when you multiplex multiple inner streams over the same tunnel. A delay or loss on one stream can stall all the others. Everything ends up blocked behind the slowest packet. Applications suffer. Latency spikes. Throughput collapses.

Troubleshooting becomes a nightmare. You can’t measure RTT accurately. You can’t tell where the loss is happening. You see symptoms, not causes. Logs and metrics lie because the outer TCP layer masks the behavior of the inner one. You think the network is fine, but the application keeps timing out. It’s frustrating and hard to fix.

If you need to tunnel traffic, use a protocol that’s built for it. QUIC over UDP, for example, was designed for multiplexing, reordering, and congestion control at the right level. If UDP is blocked, and you have no other choice, TCP tunneling might be unavoidable. But treat it like a last resort. Never design around it if you can avoid it.

TCP is great when used correctly. Nesting it inside itself is not correct. It turns clean, predictable behavior into a mess of buffering, latency, and false signals. Avoid it unless you're desperate. And even then, know what you're getting into.