WireGuard MTU: Find the Right Size and Fix Stalled Traffic

A stalled download that sits at 2% forever, a webpage that loads text but never the images, a video call that connects but freezes: these are the classic fingerprints of a wrong WireGuard MTU, not a broken VPN. The handshake succeeds, small packets sail through, and then anything substantial hits an invisible wall somewhere between your device and the server.

The fix starts with testing your actual path MTU rather than guessing a number, because the widely-quoted 1420 default is only correct when your connection carries a full 1500-byte Ethernet frame underneath the tunnel. On PPPoE, mobile data, satellite links, or any setup with a tunnel inside another tunnel, 1420 is too large and causes exactly the bandwidth issues described above. VPNSoEasy builds its VPNClient app around WireGuard for this reason, and this guide walks through how to recognize an MTU problem, measure the right size for your own connection, and apply a tested value without guesswork. If you’d rather skip the diagnostics and just get a tunnel that’s already tuned to work, VPNSoEasy’s $5-a-month plan gets you connected through the VPNClient app in a few taps.

What Packet Size Should Your Tunnel Use?

The maximum transmission unit is the largest packet a network link will carry without splitting it, and for WireGuard that number needs to leave room for the tunnel’s own wrapping. Getting the WireGuard MTU wrong doesn’t block the connection; it lets small packets through while silently losing large ones, which is why the problem is so easy to miss at first.

What Does Maximum Transmission Unit Mean?

MTU sets the byte ceiling for a single packet on a given link. A standard Ethernet or Wi-Fi segment carries 1500 bytes; anything larger must be fragmented or rejected.

WireGuard adds its own header on top of that ceiling. Every encrypted packet gets wrapped in an outer IP header, a UDP header, and WireGuard’s own transport header plus authentication tag, and all of that has to fit inside the 1500-byte link, not alongside it.

Why Is 1420 Common, but Not Always Optimal?

1420 is the standard WireGuard MTU because it’s 1500 minus 80 bytes of worst-case tunnel overhead, and it’s safe on nearly every clean, modern internet connection. The overhead breaks down precisely: a 20-byte IPv4 header (or 40 bytes for IPv6) plus an 8-byte UDP header plus WireGuard’s 32-byte header and authentication tag.

IPv4 overhead totals 60 bytes, leaving room for 1440. IPv6 overhead totals 80 bytes, leaving 1420. WireGuard’s wg-quick tool defaults to 1420 because it covers both address families with one number, at the small cost of wasting 20 bytes on an IPv4-only path. The trouble starts when the underlying link doesn’t actually carry 1500 bytes in the first place, which makes 1420 too large rather than conservative.

How Do IPv4, IPv6, PPPoE, and Nested Tunnels Change the Calculation?

Each layer between your device and the open internet eats into the usable packet size. PPPoE connections, common on DSL and some fiber lines, carry only 1492 bytes because the PPPoE header itself takes 8 bytes, which brings the safe tunnel MTU down to 1412.

Running WireGuard inside another tunnel, over a corporate VPN, or behind certain mobile carrier configurations stacks a second layer of overhead, often another 60 bytes. IPv6 on the outer connection also changes the math, since its 40-byte header is twice the size of IPv4’s 20 bytes. Readers curious how WireGuard’s design compares with other protocols on these tradeoffs can see the differences laid out in our WireGuard vs OpenVPN vs IKEv2 comparison.

Which Symptoms Suggest Fragmentation or a Path MTU Problem?

A tunnel with the wrong MTU looks healthy at first glance. The handshake completes, ping replies come back, and simple pages load, because all of those use small packets that fit regardless of the mismatch.

The signature symptoms show up once packet size grows: large file transfers stall partway through, SSH connects fine but SCP freezes, video calls connect but never show a picture, and web pages render text while images hang. This happens because routers are supposed to send back an ICMP “packet too big” message when a packet doesn’t fit, but many firewalls filter those messages, so the sender never learns to shrink its packets and the connection simply goes quiet on anything oversized.

How Can You Measure a Working MTU on Your Connection?

You can find your real path MTU with a single ping command that forbids packet fragmentation, then narrow in on the exact byte boundary where packets stop getting through. This takes a few minutes and tells you far more than guessing at a number from a forum post.

Record a Baseline Before Changing Anything

Note your current MTU and run a normal speed or file-transfer test before touching any settings. Having a baseline makes it obvious whether a later change actually helped, instead of relying on a vague sense that things feel faster.

This step also protects you if a later change makes things worse: you’ll know exactly what value to roll back to.

Test the Public Endpoint Without Routing the Probe Through the Tunnel

Test against the untunneled connection first, since this measures the raw path MTU before WireGuard’s overhead is subtracted. On Linux, run ping -M do -s 1472 <address>, lowering the size in steps until replies stop timing out.

macOS uses -D in place of -M do; Windows uses -f -l. Testing the underlying connection isolates whether the limit comes from your ISP, a PPPoE login layer, or carrier network, rather than from the WireGuard tunnel itself.

Calculate a Candidate Value From the Largest Successful Ping

Add 28 bytes to the largest ping payload that gets a reply, accounting for the IP and ICMP headers that ping doesn’t count in its size argument. That total is your underlying path MTU.

Subtract 60 bytes for an IPv4 outer connection, or 80 bytes if IPv6 might be used, to get your candidate WireGuard interface MTU. A path that tops out at 1452 bytes, for instance, points to a tunnel MTU of 1392 or 1372 depending on which IP version carries the outer packet.

Verify Packet Sizes Inside the Tunnel Without Subtracting Overhead Twice

If you test through an already-connected WireGuard tunnel rather than the raw underlay, the largest passing ping size is already your interface value; don’t subtract overhead a second time. Run the same ping -M do -s sequence against the peer’s tunnel address once connected, and treat the biggest successful payload plus 28 as the number to put directly into the MTU setting.

Confirm with a real transfer afterward, since small ping packets can pass even when a path has a problem that only shows up at full size. Anyone on a mobile hotspot, 4G, or 5G connection should expect more latency variance during this test, which is normal and doesn’t by itself indicate an MTU issue.

Which Settings Can You Change Yourself?

What you can adjust depends on whether you manage the WireGuard server yourself or connect through a managed client app. The two situations call for different levels of hands-on tuning.

For VPNSoEasy Customers: Use VPNClient and Check With Support

VPNSoEasy customers set up the tunnel through the VPNClient app rather than editing a configuration file by hand. You install VPNClient from the “Download the VPN App” section of the dashboard, sign in with the VPN username and password shown in the “Your VPN” card, pick a server, and connect with one tap.

Because VPNSoEasy doesn’t offer WireGuard configuration-file downloads, there’s no wg0.conf to edit on your end. If you notice the stall-while-small-packets-work pattern described earlier, email info@vpnsoeasy.com with details on your connection type (PPPoE, mobile, satellite) so support can look into it; VPNSoEasy advertises 24/7 support and a 2-3 business day response for general questions.

For Self-Managed Linux Tunnels: Test a Temporary Interface Change

Linux lets you change a running interface’s MTU without restarting the tunnel, which is the safest way to test a candidate value. Run ip link set wg0 mtu 1400 (substituting your interface name and candidate number), then immediately retest with ping -M do -s and a real file transfer.

This change reverts automatically on reboot, so a bad guess costs nothing. Confirm it applied with ip link show wg0 | grep mtu before drawing conclusions.

Persist a Verified Value in wg0.conf and Keep a Rollback Plan

Once a value tests cleanly across multiple transfer sizes, add MTU = 1400 (or your verified number) to the [Interface] section of wg0.conf, then bring the tunnel down and up with wg-quick down wg0 and wg-quick up wg0. Write down the previous value in a comment or a separate note before saving.

If a self-managed server lives on a VPS, test changes during a low-traffic window since bringing the interface down briefly interrupts connected peers. Anyone running WireGuard across a less typical setup, like through a Starlink connection, should read our notes on VPN use over Starlink, since satellite links often need a more conservative MTU than wired broadband.

Check Both Peers Without Assuming Their MTUs Must Match

The MTU on your side only limits what you send; the server’s own interface setting limits what comes back. A client configured with a careful 1392 but talking to a server interface still sitting at 1420 will send fine while large replies from the server keep stalling.

If you run your own WireGuard server, check the mtu of its interface directly, don’t assume a client-side fix covers both directions. This split is one of the more common reasons a “fixed” MTU problem comes back after a server reboot or configuration rebuild.

How Do You Confirm the Fix and Rule Out Other Causes?

A corrected MTU should show steady throughput in both directions on repeated tests, not just one lucky transfer. Confirming the fix also means ruling out routing, NAT, and server-side issues that produce similar symptoms but need different solutions.

Compare Upload and Download Performance With Repeated iperf3 Tests

Run iperf3 client tests against a server on the other side of the tunnel multiple times at the new MTU, checking both upload bandwidth and download bandwidth separately. One documented case found that leaving both peers at the WireGuard MTU default of 1420 produced extremely poor throughput, while setting the client side to 1384 against a server still at 1420 recovered the ISP’s full 50 Mbps upload and most of its 1000 Mbps download capacity.

That gap between the two directions is worth watching for, since asymmetric results often point to the two peers needing different values rather than one shared number.

Separate MTU Symptoms From Routing, NAT, and Server Load Problems

MTU problems look specific: small packets succeed, large ones hang, and the tunnel shows a valid handshake throughout. If the tunnel doesn’t connect at all, or drops every few seconds regardless of transfer size, the cause is more likely AllowedIPs misconfiguration, disabled IP forwarding, or a NAT issue rather than packet size.

CGNAT and double NAT setups in particular can produce connection instability that resembles an MTU issue but needs PersistentKeepalive or different NAT traversal handling instead. If disconnects happen on a regular timer rather than only during large transfers, that pattern points toward a NAT mapping timeout, which our guide on a VPN that keeps disconnecting covers in more detail.

When Does TCP MSS Clamping Help, and Why Does It Not Fix QUIC?

TCP MSS clamping forces connections to negotiate a smaller segment size automatically, which helps when you can’t change a client’s MTU directly. On the WireGuard server, an iptables or nftables rule like --clamp-mss-to-pmtu, or an explicit value such as --set-mss 1380 for a 1420 MTU, rewrites the TCP handshake so both sides agree on a size that fits.

MSS clamping only touches TCP traffic. It has no effect on QUIC or other UDP-based protocols, which negotiate their own packet sizing independently, so a video call or modern web connection using QUIC can still stall even after MSS clamping fixes every TCP-based symptom.

Investigate CPU Limits and Network Offloads Before More Tuning

Low throughput that persists at a verified MTU often traces back to CPU limits or network offload settings rather than packet size. WireGuard’s encryption work runs on the CPU, so a resource-constrained VPS or older router can cap speeds regardless of MTU.

Offload features like GRO, GSO, and TSO can also interact oddly with tunnel interfaces on some Linux systems. If MTU is confirmed correct and throughput still disappoints, check CPU usage during a transfer before adjusting MTU any further; our notes on choosing a VPN that doesn’t slow down your internet cover the broader set of factors behind VPN speed.

Choose a Tested Value, Not a Universal Number

The right WireGuard MTU is whatever your own path measures, and that number varies by connection type even among people using identical hardware. Standard home broadband often works at the default 1420 without any adjustment, while PPPoE lines, mobile data, satellite links, and nested tunnels all push the real ceiling lower.

Testing with a do-not-fragment ping, applying the change on a temporary interface first, and confirming with repeated throughput tests keeps the whole process reversible. A value that measures cleanly today is the one worth keeping, and the only way to know it’s correct is to have tested it yourself rather than copied it from someone else’s connection.

Frequently Asked Questions

Should I use 1420 or 1440 for WireGuard?

Use 1420 unless you’ve confirmed your outer connection is IPv4-only end to end, in which case 1440 is technically available. 1420 accounts for IPv6’s larger 80-byte overhead and works safely on both address families, while 1440 only leaves the right margin when IPv6 never touches the path.

Should my internet connection use MTU 1500 or 1492?

Neither number applies directly to the WireGuard tunnel itself; 1500 and 1492 describe the underlying link, not the tunnel interface. A standard Ethernet connection carries 1500, while a PPPoE line carries 1492, and you subtract WireGuard’s overhead from whichever one applies to get the tunnel MTU, landing at 1420 or 1412 respectively.

Is MTU 1384 better than 1420?

MTU 1384 isn’t universally better, but it resolved a documented bandwidth collapse on one tested connection where 1420 on both peers produced far lower throughput than expected. The right value depends on the actual path MTU, which is why testing with a do-not-fragment ping matters more than copying any single reported number.

Can I change the WireGuard MTU on Android or iOS?

Some WireGuard apps on Android and iOS expose an MTU field on the tunnel’s configuration screen, while others set the value automatically without exposing a setting. VPNSoEasy’s VPNClient app handles server connection through the dashboard’s “Your VPN” credentials rather than manual configuration-file editing, so adjustments on that app happen through support rather than a client-side MTU field.

Can a WireGuard MTU calculator replace testing?

A calculator gives a reasonable starting estimate based on your connection type, but it can’t account for a specific middlebox, carrier quirk, or nested tunnel on your exact path. A do-not-fragment ping test against your own connection confirms the real ceiling, which is the only way to catch a path that doesn’t match the general PPPoE, mobile, or Ethernet assumptions a calculator relies on.