Estimate speed impact of using a VPN.
A VPN costs speed in three ways. Encapsulation overhead is fixed by the protocol: WireGuard's lean header leaves around 93% of throughput, IKEv2 about 88%, OpenVPN over UDP roughly 80%, and OpenVPN over TCP as little as two-thirds because TCP inside TCP causes competing retransmission timers. Distance adds latency at a hard physical floor — light in glass covers about 200 km per millisecond, so a server 1,500 km away costs at least 15 ms of round trip before any routing detour. Latency then reduces throughput a second time, because a single TCP flow can only have one congestion window in flight, so the same window on a longer path delivers fewer bits per second. Choosing the nearest server that satisfies your reason for using the VPN is almost always worth more than changing anything else.
VPN throughput and latency penalty
Added ping = distance / 100 + protocol handshake; latency factor = 60 / (60 + added ping); VPN speed = baseline x protocol efficiency x latency factor
Because latency hurts twice — it raises ping and it caps single-flow throughput. Moving from a 6,000 km server to a 300 km one typically recovers more speed than switching from OpenVPN to WireGuard.
Occasionally. If your provider throttles or badly routes specific traffic, tunnelling can bypass it, and some peering paths through a VPN provider are shorter than the default route. Those are exceptions, not the rule.
Running TCP inside TCP stacks two congestion controllers. A single lost packet triggers retransmission at both layers, and the two timers interact badly — a failure mode known as TCP meltdown. Use UDP unless a firewall forces otherwise.