Is a smaller VPN MTU faster? Compare the actual evidence
A lower MTU can dodge a path limit and still cost throughput. Compare the real constraint, the packet overhead and the workload before you keep the change.
A tunnel drops large transfers but passes pings, so the advice arrives quickly: lower the MTU. The fix sometimes works, and then it gets applied to every profile on every network. That is the point where a targeted repair turns into a permanent performance tax. The comparison to make is between the path's real limit and the cost of shrinking every packet below it.
What actually shrinks when you lower MTU
Every packet carries headers before it carries your data. On a 1500-byte Ethernet path, IPv4 and TCP consume 40 bytes, leaving 1460 for payload; encapsulation adds outer IP, UDP and tunnel headers on top, so the inner payload budget drops again. Lowering the interface MTU shrinks that budget deliberately.
The cost is proportional to the number of packets, not to the number of bytes. The same file split into more packets needs more interrupts, more routing decisions and more per-packet processing on every device along the path. On a router that is already close to its packet-per-second limit, that is a real slowdown rather than a rounding error. The cost shows up even when the transfer itself succeeds.
This is why a smaller MTU is a workaround for a constraint, not a general optimization. It buys reliability against a path that cannot carry the larger frame, and it charges overhead for every packet that did not need the reduction.
When a smaller MTU is the right fix
The classic symptom is specific: the TCP handshake completes, small responses arrive, and a large download stalls or resets. A ping with the don't-fragment bit at 1472 bytes fails while a 1400-byte ping succeeds, which points at a path that cannot carry a full-size packet and is not delivering the ICMP message that would tell the sender to shrink.
Path MTU discovery depends on those ICMP fragmentation-needed messages. When a firewall drops them, the sender keeps retrying the large packet and the connection appears to hang. Lowering the MTU on the tunnel side avoids the retry, which is a legitimate repair for that network.
Access technologies also impose their own limits: PPPoE commonly caps at 1492, some mobile and DSL paths are lower, and nested tunnels subtract overhead twice. Measure the actual path instead of copying a number from a guide, and remember that IPv6 requires at least 1280 bytes of MTU on any link that carries it, as RFC 8200 specifies.
Compare the three controls before changing one
MTU, MSS and fragmentation are different knobs at different layers, and changing the wrong one leaves the symptom in place.
| Control | Layer | What it changes | Where it misleads |
|---|---|---|---|
| Interface MTU | IP link | Largest frame the interface will send | Penalizes every protocol, not just the one that failed |
| TCP MSS clamp | TCP | Segment size advertised in the handshake | Leaves UDP and QUIC untouched |
| DF and fragmentation | IP | Whether a router may split a packet | Can break path MTU discovery and security assumptions |
| Tunnel overhead | Encapsulation | Inner MTU after outer headers | Mismatch shows up only for large inner packets |
An MSS clamp is often the least invasive repair because it affects TCP only and leaves the interface free for other traffic. A lower interface MTU is broader and simpler to reason about, which is why it is common on consumer routers, but it charges every protocol for one protocol's problem.
Disabling the don't-fragment behavior hides the symptom by allowing fragmentation, and it usually makes latency worse while breaking the feedback that would have found the correct size. Avoid it as a permanent fix.
Measure the trade-off instead of one number
Find the path limit with a don't-fragment probe, starting high and stepping down until the reply arrives:
ping -M do -s 1472 203.0.113.10
ping -M do -s 1400 203.0.113.10
tracepath 203.0.113.10Then compare the real task on both settings: the same file transfer, the same endpoint and the same network. Record completion time and retransmissions, for example with nstat -az TcpRetransSegs, and watch device CPU if the tunnel terminates on a small router. A short synthetic throughput test can miss the stall that only appears after several megabytes.
Packet counters will rise after a reduction because the same transfer now uses more packets. That is expected and it is not evidence of higher throughput. Compare completed application data, retransmission counts and responsiveness, not the packet rate alone.
Stage the change and keep it scoped
Record the original value, change one control, and repeat the measurement before making it permanent. If the evidence does not show a benefit, restore the previous value with the same interface command you used to set it:
ip link set dev wg0 mtu 1420
ip link set dev wg0 mtu 1500Scope the result to the network that needed it. A profile that must work on a hotel Wi-Fi, a mobile hotspot and an office LAN should not inherit the lowest value any one of them requires unless the client cannot detect the path.
The right value is the largest MTU that survives the path, not the smallest one that makes the symptom disappear. Document the path, the probe result and the rollback, and revisit the setting when the access network changes.