VPS Network MTU and Offload Settings: Diagnosing Slow Throughput and Packet Drops on Virtual NICs

Your VPS plan says 1 Gbps, but iperf3 reports 180 Mbps. TCP retransmits climb under load, large downloads stall, and dmesg shows dropped frames on the virtual NIC. Before you blame the provider or pay for an upgrade, check the two settings that silently cripple virtual network interfaces: the MTU and the hardware offload features. Both are misconfigured or incompatible on a surprising share of VPS images — and both are fixable in minutes from the command line.

Why MTU Matters More on a Virtual NIC

MTU (Maximum Transmission Unit) is the largest packet a link will carry, and the internet standard is 1,500 bytes. On a virtual machine the NIC is emulated (virtio-net, e1000, or vmxnet3), and every packet you send is wrapped in additional headers by the hypervisor — VXLAN tunnels, for example, add 50 bytes of overhead. If the effective path MTU ends up below 1,500, large packets get dropped and TCP falls back to smaller sizes, which you experience as sudden throughput collapse on long transfers. A second, very common case: you run an encrypted tunnel (WireGuard, OpenVPN, or GRE) inside the VPS, which shrinks the usable payload per packet and, if misconfigured, causes exactly the same symptom.

Check what your interfaces are actually configured with:

ip link show
cat /sys/class/net/eth0/mtu

If the output shows 1,500 and your transfers are slow, test the real path MTU with ping using the do-not-fragment flag. A payload of 1,472 bytes plus 28 bytes of ICMP/IP headers equals exactly 1,500:

ping -M do -s 1472 -c 5 8.8.8.8      # should succeed
ping -M do -s 1500 -c 5 8.8.8.8      # fails if path MTU < 1528

If the 1,472-byte test fails, your path MTU is below 1,500 and every large packet is being dropped. Lower the interface MTU (try 1,400) and re-test; for tunnel interfaces, set the tunnel MTU to 1,420–1,440 and let TCP adjust. Note that jumbo frames (MTU 9,000) are rarely available on shared VPS infrastructure — most providers cap virtual NICs at 1,500 or offer 9,000 only on dedicated servers, so plan accordingly.

TCP Offload Features: Fast in Theory, Broken in Practice

Modern NICs offload work like checksum calculation, segmentation (TSO/GSO), and receive-side merging (GRO) to hardware. A virtual NIC has no hardware — the hypervisor emulates it — and the emulation layer is where offload bugs live. The classic failure mode: checksum offload advertises itself as supported, the guest trusts it, and the hypervisor’s implementation drops or corrupts frames under load. Symptoms include CRC errors in ifconfig, TCP retransmission spikes, and throughput that collapses the moment you push traffic.

Inspect the current offload state:

ethtool -k eth0

Feature	What it does	When to disable
tx-checksum-ip-generic	Offloads TX checksums	If interface shows TX errors / bad checksums
tcp-segmentation-offload (TSO)	Splits large TCP writes in hardware	If large transfers stall or retransmit heavily
generic-segmentation-offload (GSO)	Software segmentation for non-TCP	If packet drops appear under load
generic-receive-offload (GRO)	Merges small RX packets	If latency-sensitive traffic behaves oddly

Disable a feature and re-test before and after:

ethtool -K eth0 tso off gso off gro off
ethtool -K eth0 tx off rx off
iperf3 -c iperf.he.net -t 30

If throughput jumps from 180 Mbps to 800+ Mbps, you found the culprit. On virtio-net with recent kernels, offloads usually work — the problems cluster on e1000 emulation and on older provider kernels — but a 30-second A/B test settles it empirically.

Make the Fixes Permanent

Settings changed with ethtool revert on reboot, so persist them. On systemd distributions, create a service unit or use the provider’s network configuration (netplan, cloud-init, or NetworkManager dispatcher). The minimal systemd approach:

# /etc/systemd/system/ethtool-fix.service
[Unit]
Description=Fix NIC offload settings
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/sbin/ethtool -K eth0 tso off gso off gro off

[Install]
WantedBy=multi-user.target

Enable it with systemctl enable --now ethtool-fix, then verify after a reboot. For MTU changes, prefer the distribution-native config (for example, netplan on Ubuntu: mtu: 1400 under the interface) so the network stack applies it before interfaces come up.

When the Problem Is on the Provider Side

If MTU is correct, offloads are disabled, and iperf3 still underperforms the plan’s stated port speed, the bottleneck is upstream: a congested shared uplink, a rate-limited virtual port, or a routing path with loss. mtr -rwzb 8.8.8.8 will show where loss starts, and two tests an hour apart will show whether the degradation is constant (plan limit) or intermittent (neighbour contention). Gather that evidence before contacting support — and when you do, include the before/after numbers from this article’s tests.

Network headroom is one of the things that separates cheap plans from good ones, which is why our VPS comparison table calls out uplink speeds and transfer caps side by side — it is much easier to pick a provider that guarantees the port speed you need than to fight a congested one later. The feature breakdown on our VPS page also notes which providers expose NIC-level settings and which hide them behind a control panel, and the FAQ covers the networking questions worth asking before you sign up.