Online MTU Test - Find Your Real IPv4 & IPv6 MTU & MSS

This page measures the largest packet your connection can carry in one piece (its MTU) - on this very connection, right now - and tells you the one number to use when you set up a WireGuard VPN tunnel.

What VPN MTU should I use?

Why it matters. A VPN wraps every packet inside a slightly bigger one. Set the tunnel a few bytes too large for your line and you fragment the outer tunnel, causing a drastic performance hit. Set it too small (e.g. the default 1280 MTU AI advice) and you don’t leave enough data space inside the connection, so you fragment your nested corporate VPN client tunnel and things slow to a crawl or refuse to connect on your work PC. Getting this number right is the fix, and “right” depends on the current network you’re connecting from.

Most automated MTU test pages read their number off a TCP connection, and many ISP routers rewrite the size TCP connections are allowed to use (the TCP MSS), so those pages report that TCP limit as if it were the real line limit. This page sends real UDP packets of growing size all the way to your device, the same type of traffic WireGuard uses, and reports the largest one that makes it through - a real, tested end-to-end MTU line measurement.

What to do:

To get an accurate reading for setting your WireGuard configuration, test with the VPN tunnel turned off. Connect to your travel router and disable any VPN client tunnels running on the router and any software VPN clients running on your device itself.
Ensure the travel router is connected to the upstream network you plan to use the VPN tunnel with. The router can be connected to the upstream router via ethernet or via wireless repeater.
Run the test and read the number on the card for your tunnel’s IP connection type (IPv4 for most) to get your line MTU and the matching max WireGuard MTU setting for your WG configuration.

Note: This test needs to be run on both ends of the connection (server path and client path) in a dual-router VPN setup to set the path correctly. Also, any MTU adjustment above 1420 on the client side requires an MTU adjustment on the WireGuard server router side to be effective.

Your measurement

IPv4

Measuring…

IPv6

Measuring…

What these terms mean

MTU: Maximum Transmission Unit: the largest packet a link or a whole path carries in one piece, in bytes, headers included. 1500 is the Ethernet standard; 1492 is typical of DSL and fibre lines that use PPPoE; cellular and satellite lines vary. A VPN tunnel has to be set smaller than the line it runs over, because the tunnel adds its own headers to every packet.
Line MTU: The largest packet that actually gets through between this server and your device right now - the big number on each card. It is the figure you size a tunnel from. On most lines it equals the MTU of your internet connection; a narrower link anywhere between here and your device, or a VPN that is already running, lowers it.
Max WireGuard MTU: Your line MTU minus WireGuard’s own overhead: 60 bytes when the tunnel runs over IPv4, 80 bytes over IPv6. It goes in the MTU line of the WireGuard interface, on both ends. Set it larger and the tunnel fragments and crawls; set it much smaller and you waste capacity and can starve a corporate VPN client running inside the tunnel.
Your router (gateway), and your device: Your router is the box your device reaches the internet through - a home modem-router, a hotel’s router, or your travel router; in networking terms, your gateway. We measure two stretches of the path. The first runs from this server to your router: we send it packets of growing size and see which ones it answers. The second runs all the way to your device. The tunnel is sized from the second; the first is a ceiling, useful for seeing where a path narrows, never the number to use on its own.
Path MTU, Demonstrated MTU, Floor MTU: Three ways a stretch of path can report its size, shown under Details. Path MTU: the route itself reported its limit (a router sent back a “packet too big” message) and we confirmed it by getting a packet of that size through. Demonstrated MTU: the largest packet that actually arrived during the test, with no report from the route. Floor MTU: the largest size proven to arrive when the route’s limit could not be pinned down - the path may allow more, but this much is certain.
Measured, or a safe floor: The label on each card and in the history’s Reading column. Measured: the figure is the line’s actual limit - the route reported it and a packet of that size got through, or the reading to your router and the reading to your device agree exactly. Safe floor: packets of that size got through but the line may allow more. A tunnel sized from a safe floor fits; a re-test, or a test from a wired connection, may find a larger number.
ICMP sweep, HTTP/3 and TCP: The three ways this page measures. ICMP sweep: this server sends your router packets of growing size with the don’t-fragment bit set - the same thing a manual ping -M do does - and reads which sizes it answers. HTTP/3: a QUIC connection from this server to your browser, over UDP, the same kind of packet WireGuard uses; it grows its probe packets until your device stops acknowledging them, so the largest acknowledged size is a proven floor, and the row “Did the HTTP/3 search finish?” says whether it closed in on the limit or ran out of time. TCP: a plain download to your device; the route’s own size reports, if any, give a Path MTU, and the largest segment delivered gives a Demonstrated MTU. TCP sizes can be trimmed by an ISP router rewriting the MSS, which is why the HTTP/3 reading is closer to what a tunnel sees.
IPv4 and IPv6: Two separate paths with separate limits, so two cards. Use the card for the family your WireGuard endpoint is reached over - the calculator’s “Tunnel endpoint address family” is the same choice. “Could not measure - No IPv6 connectivity detected” means this connection has no working IPv6 path right now, which is common and not a fault: use the IPv4 card.
Effective MSS: The TCP payload this server can put into one packet toward you, after headers and options: the smaller of what your side asked for and what the path carries. Shown for TCP readings; when the device leg ran over HTTP/3 the history takes it from the TCP connection that carried the gateway probe. It is a TCP figure and says nothing about UDP or WireGuard on its own, but a value well under your line MTU minus 40 is the sign of an ISP router rewriting TCP sizes (MSS clamping).
Server to you: Every figure is measured from this server toward your device, because that is the direction a VPN server sends you data. This path stands in for the path to your own VPN server: the narrowest hop is almost always your own access line, so the number transfers.

WireGuard MTU calculator

Run the web test above or CLI test below from the location of your WireGuard server and note that line MTU.
Run it from your travel location (no VPN active) and note that line MTU.
Enter both below. The result is the MTU for the WireGuard configs on both ends.
Turn the tunnel on and run this test again. The new reading is the MTU inside the tunnel and should match the calculator’s result. This also reveals the negotiated inner MTU of auto-tuned tunnels such as OpenVPN.

Which number goes in? The line MTU on the card - the end-to-end reading to your device, never the router-only figure under Details, which is a ceiling. A safe floor is fine to use: the tunnel fits, and you can re-test later for a larger number. Running the test from different places (hotel Wi-Fi, phone hotspot, home LAN) and comparing the history rows is how you find where a path narrows.

Server-side path MTU Travel-side path MTU Tunnel endpoint address family

From a terminal or router

The best server-side reading comes from the VPN endpoint itself - SSH to your home router and run:

curl -s https://mtu.remotetohome.io        # add -4 or -6 to force a family
wget -qO- https://mtu.remotetohome.io      # BusyBox/OpenWrt routers without curl

Verify it yourself (manual DF ping)

From any machine with a full-featured ping, send pings with the Don’t Fragment bit set. The largest payload that gets through, plus 28 bytes of headers, is your IPv4 line MTU.

ping -M do -s 1472 -c 3 8.8.8.8   # 1472 + 28 = 1500
ping -M do -s 1464 -c 3 8.8.8.8   # 1464 + 28 = 1492 (PPPoE-typical)

From a GL.iNet router. The router’s built-in ping does not support -M do, so install the iputils-ping package once - from the Plug-ins page in the router’s web UI, or over SSH as below - and then run the same test from the router. That measures the router’s own line, which is the right place when the router is the WireGuard client.

opkg update && opkg install iputils-ping
ping -M do -s 1464 -c 3 8.8.8.8   # 1464 + 28 = 1492; raise or lower -s until it just passes

Largest passing payload	Line MTU	Typical cause
1472	1500	Clean Ethernet path
1464	1492	PPPoE (8-byte header)
1412	1440	WireGuard over IPv4 (60-byte overhead)
1392	1420	WireGuard over IPv6 (80-byte overhead)
1252	1280	IPv6 minimum / conservative tunnel floor

If even small DF pings fail, the target is filtering ICMP - that is filtering, not your line’s MTU.

Important note for AmneziaWG users: AmneziaWG protocol versions 2.0 and above use obfuscation padding parameters that directly impact the VPN tunnel encryption layer’s MTU size. RemoteToHome can help you calculate the correct MTU for your specific Amnezia configuration and other advanced VPN protocols.