MTU Test
Find Your Real MTU Size, MSS and VPN Overhead
A guided MTU test that walks you through a real Don't Fragment packet probe, a calculator that shows every byte of tunnel overhead, and a generator that writes the exact MTU and MSS clamping commands for your device. No signup, nothing stored.
Quick Answer: How Do You Test MTU?
Your MTU is the largest IP packet your connection carries without fragmenting. Browser JavaScript cannot measure it, but a server can. This page tries three real methods in order: it reads the segment size your own TCP connection negotiated, then probes your address with Don't Fragment packets, then falls back to one ping command you run yourself. Whichever your setup allows gives you a measured MTU, your MSS, and ready to paste config.
Path MTU Measurement
Three ways to get the number, tried in order. The page first reads the segment size your own connection negotiated, then falls back to a probe from our server, and finally to one command you run yourself. Whichever works on your setup is the one you see.
Automatic detection is not available on this connection. That is normal — most home routers and every carrier-grade NAT block the probes it relies on. The method below measures your MTU directly from your own device and works everywhere. It takes about a minute.
Detected from your connection
no probe sent · read from the TCP session you are already usingYour MTU
—
TCP MSS
—
Link type
—
Confidence
—
| Kernel field | Value | What it means |
|---|
Automatic probe
checking what this server can do…Our server sends real ICMP packets with the Don't Fragment bit set to your address and narrows down the largest one that survives the round trip. That is a genuine measurement of the path between us, not an estimate.
Path MTU
—
MSS (IPv4)
—
MSS (IPv6)
—
Probes sent
—
Guided manual method
Run the command below in your own terminal and tell the tool what happened. Most connections answer on the very first command; a DSL or tunnelled link takes a few more while the tool steps through the sizes real links use. This measures the path from your machine outward, so it works even when the automatic probe cannot reach you.
No terminal handy? Tab 2 gives you the right value for your link and tunnel in two clicks.
Step 1 — run this command
—
What did the command do?
Search range
Largest known good payload: none yet · Smallest known failing payload: none yet
That target is dropping ICMP, not your packets. Even small probes failed, which rules out a size problem. Change the target above to your own router gateway (usually 192.168.1.1 or 192.168.0.1) or to 1.1.1.1, then press Start over. A host that filters ICMP entirely cannot be used for this measurement.
Your measured path MTU
Path MTU
—
MSS (IPv4)
—
MSS (IPv6)
—
Largest payload
—
Last verified 8 August 2026. Every tunnel overhead figure in the calculator was re-checked against current vendor and project documentation on that date, and the ping syntax was confirmed on Windows 11, macOS and Linux iputils.
How this page works: the calculator uses published protocol header sizes, the finder uses a measurement you run yourself, and the transfer check times real downloads. Nothing here is pre-filled with a made up result, and none of your input is stored or sent anywhere except the transfer check, which requests sized files from this server.
Robert Harrison
OSINT & Network Utility Expert
I lost the better part of a Tuesday to this problem in February 2026. A client's WireGuard tunnel came up clean, ping worked, DNS worked, SSH worked. Their internal wiki would not load past the header. Everything pointed at the application until I ran a Don't Fragment ping and found the path topped out at 1464 bytes, not 1500 — their upstream had quietly moved them onto a carrier link with extra encapsulation. WireGuard was still sitting at its default 1420, which was 16 bytes too large for that path. Two minutes to change, six hours to find.
Here is the honest limitation, and I want to be precise about it because I have seen this overstated. A browser cannot measure your MTU — no raw sockets, no Don't Fragment bit. A server can, and ours does, by probing your address directly. What it cannot do is reach you when your firewall drops inbound ICMP, which is common and perfectly sensible. In that case the tool tells you it failed and gives you the manual method, because a number I made up would be worse than no number at all.
View all articles by Robert HarrisonHow This Page Measures Your MTU (And Why Most Pages Only Pretend To)
Path MTU discovery works by sending an IP packet with the Don't Fragment flag set and watching for an ICMP "Fragmentation Needed" reply. That needs two abilities the browser sandbox does not grant: writing IP header flags, and reading raw ICMP. This is the reason so many MTU pages simply print 1500 after a four second progress bar — they never measured anything, because in the browser they cannot.
A server is not restricted that way, and this page uses three different server side methods rather than one. They run in order of how reliably they work, and the tool always tells you which one produced the number on screen.
Method one: reading the connection you already opened
Every TCP connection starts with a handshake, and in that handshake your device announces a maximum segment size — the largest chunk of TCP payload it is willing to receive. Your operating system derives that value directly from the MTU of the interface it is sending from. Load this page and your browser has already told our server what its MTU is, without either of us doing anything extra.
The server reads that value back out of the kernel with a single command and shows it to you, along with the raw fields it came from. No probe packets, no waiting, no cooperation needed from your firewall. This is why the reading at the top of the tool appears the moment the page loads.
It has one honest limitation worth stating. It reveals the MTU your device is advertising, which is either its own interface MTU or a lower value if a router along the way rewrote it. That is usually exactly what you want, but it is not the same as an end-to-end path measurement.
Method two: real Don't Fragment probes toward you
For a true path measurement the server sends actual ICMP packets with the Don't Fragment bit set to your address and narrows down the largest one that survives the round trip. A normal 1500 byte link resolves in two probes: one full size packet, one jumbo frame check.
This only works if your router answers ICMP echo from outside. Many home routers and effectively every carrier grade NAT deployment do not, which is a sensible default and not something you should change for the sake of a diagnostic. When the probe cannot reach you the tool says so plainly instead of inventing a number.
Method three: one command from your side
The guided method measures the opposite direction, from your machine outward. It is slower because you have to run a ping yourself, it always works, and it catches the case the other two cannot — a path whose MTU differs depending on direction. Rare, but real, and impossible to spot with a single measurement.
Five independent kinds of evidence on this page: the segment size your own stack negotiated, a server side Don't Fragment probe toward you, a guided probe from you outward, tunnel arithmetic derived from published header sizes you can check line by line, and timed downloads that reveal black hole symptoms. Not one of them is a stored default value, and each one names its own limitation.
Once you have a real number, the next question is what it means — and that starts with the difference between MTU and MSS.
MTU vs MSS: What Each One Actually Controls
MTU — Maximum Transmission Unit — is the largest IP packet a link will carry in one piece, headers included. MSS — Maximum Segment Size — is the TCP payload alone, with the IP and TCP headers already subtracted. MTU is a property of the link. MSS is a number the two ends of a TCP connection announce to each other during the handshake.
| Stack | IP header | TCP header | MSS from 1500 MTU |
|---|---|---|---|
| IPv4 + TCP | 20 bytes | 20 bytes | 1460 |
| IPv6 + TCP | 40 bytes | 20 bytes | 1440 |
| IPv4 + UDP | 20 bytes | 8 bytes (UDP) | 1472 payload |
If the 20 byte gap between the first two rows looks arbitrary, our field by field comparison of the IPv4 and IPv6 headers shows exactly which fields were added and which were dropped.
The practical consequence is that UDP has no equivalent of MSS. There is no handshake in which both ends agree on a size, so UDP applications either fragment, get dropped, or implement their own discovery. That is why a VPN over UDP is far more sensitive to a wrong MTU than plain web browsing over TCP.
It also explains why MSS clamping fixes web pages but not everything. Clamping only rewrites TCP handshakes. Your DNS over UDP, your game traffic and your VoIP still need the MTU itself to be right.
Knowing the difference is useful. Knowing which value your own link supports is more useful, so here is the measurement.
How to Find Your Real MTU With One Ping Command
The method is a binary search. Send a Don't Fragment ping with a payload sized for a full 1500 byte link. If it gets replies you already have your answer. If it fails, step down through the sizes real links actually use rather than halving a blind range, and you land on the right value in two or three more attempts. The tool above does that bookkeeping, but here is the command for each platform so you understand what you are running.
Windows 10 and Windows 11
# -f sets the Don't Fragment flag, -l sets the payload size (lowercase L)
ping -f -l 1472 8.8.8.8
# Success looks like a normal reply.
# Failure reads: "Packet needs to be fragmented but DF set."
Linux
# -M do sets Don't Fragment, -s sets payload size, -c sets the count
ping -M do -s 1472 -c 3 8.8.8.8
# Failure reads: "Frag needed and DF set (mtu = NNNN)"
# That mtu value in brackets is often the answer on its own.
macOS
# macOS uses BSD ping. The flag is -D, not -M do.
# -M do is a Linux iputils flag and will error out on macOS.
ping -D -s 1472 -c 3 8.8.8.8
Turning the payload into an MTU
Every one of those commands sets the payload size, not the packet size. To get the MTU you add the headers back on:
- IPv4: MTU = largest working payload + 8 (ICMP header) + 20 (IP header) = payload + 28
- IPv6: MTU = largest working payload + 8 (ICMPv6 header) + 40 (IPv6 header) = payload + 48
So a payload of 1472 that succeeds means an MTU of exactly 1500. A payload of 1464 means 1492, which is the PPPoE signature. If you want to see how those header sizes differ at the bit level, our IP address to binary converter lays out the IPv4 header field by field, and the IPv6 address expander does the same for the longer IPv6 form.
One caveat that catches people: some hosts drop large ICMP regardless of size, which makes every probe fail and suggests an absurdly low MTU. If even a 500 byte payload fails, the target is filtering, not your link. Try a different target — your own router's gateway address is usually the cleanest first hop to test against.
Once you have the number, the next problem is that a tunnel will eat into it.
Correct MTU for WireGuard, OpenVPN and IPsec
Every tunnel wraps your packet in another packet. The outer wrapper takes space, and whatever is left is what your applications can use. The numbers below are header sizes, not opinions, and the calculator above shows each component separately.
| Tunnel | Overhead (IPv4 outer) | Overhead (IPv6 outer) | MTU on a 1500 link |
|---|---|---|---|
| WireGuard | 60 bytes | 80 bytes | 1440 / 1420 |
| OpenVPN UDP, AES-GCM | 49 bytes | 69 bytes | 1451 / 1431 |
| OpenVPN TCP, AES-GCM | 63 bytes | 83 bytes | 1437 / 1417 |
| IPsec ESP tunnel, AES-GCM | 54–57 bytes | 74–77 bytes | 1443 / 1423 |
| IPsec ESP tunnel, AES-CBC + SHA-256 | up to 77 bytes | up to 97 bytes | 1423 / 1403 |
| GRE (no options) | 24 bytes | 44 bytes | 1476 / 1456 |
| VXLAN | 50 bytes | 70 bytes | 1450 / 1430 |
Why WireGuard ships with 1420
Figures below re-verified against vendor documentation in August 2026.
WireGuard's overhead is a 20 byte outer IPv4 header, an 8 byte UDP header, a 16 byte WireGuard data header and a 16 byte Poly1305 authentication tag. That is 60 bytes. Over an IPv6 outer path the first component grows to 40 bytes, giving 80. The pfSense WireGuard documentation states both figures directly. WireGuard defaults to 1420 because that value survives either case on a 1500 byte link.
If you want the layer underneath these numbers, our explainer on how VPN tunnels wrap and encrypt your traffic covers what each of those header bytes is actually carrying.
The default breaks the moment your underlying link is not 1500. On PPPoE at 1492 the correct values become 1432 for IPv4 and 1412 for IPv6. On a mobile link that hands you 1428, they drop further still. This is the single most common reason a WireGuard tunnel connects but stalls.
Worth knowing: WireGuard sets the Don't Fragment bit on its own outer packets. That is deliberate, but it means an oversized tunnel MTU produces silent drops rather than slow fragmentation. There is no graceful degradation to warn you.
Setting the number is only half the job if you run a gateway for other people, which is where clamping comes in.
MSS Clamping: The Fix When You Cannot Touch Every Client
MSS clamping rewrites the MSS option inside TCP SYN packets as they pass through a router. Both ends of the connection then negotiate a smaller segment size and never build an oversized packet in the first place. You need it whenever you control a gateway but not the devices behind it — a VPN concentrator, a PPPoE router, an office firewall.
Applying a clamp, in order
1 Measure the path first
Clamping to a number you guessed just moves the problem. Run the finder above from the gateway itself, toward a host on the far side of the link you suspect.
2 Prefer clamp to PMTU over a fixed value
On Linux, --clamp-mss-to-pmtu tracks the real path MTU instead of freezing a number that may be wrong next month. Use a fixed MSS only when the kernel cannot see the true path MTU.
3 Clamp on the tunnel interface, not everywhere
A blanket FORWARD rule clamps traffic that never needed it and costs you throughput on healthy paths. Scope the rule to the interface with the reduced MTU.
4 Remember UDP is untouched
Clamping fixes web pages and leaves DNS, VoIP and game traffic exactly as broken as before. If those still fail, the MTU itself is wrong and needs setting properly.
# Track the real path MTU - preferred
iptables -t mangle -A FORWARD -o wg0 -p tcp --tcp-flags SYN,RST SYN \
-j TCPMSS --clamp-mss-to-pmtu
# Fixed value, when the kernel cannot see the path MTU
# MSS = tunnel MTU - 40 for IPv4
iptables -t mangle -A FORWARD -o wg0 -p tcp --tcp-flags SYN,RST SYN \
-j TCPMSS --set-mss 1380
The generator in tab three writes the equivalent rule for nftables, MikroTik, OpenWrt and Cisco IOS from whatever MTU you feed it. If you are debugging a gateway more broadly, our open port scanner and HTTP response header analyzer are useful for confirming what is reaching the far side.
Clamping assumes the packets are at least being dropped visibly. Sometimes they are not, and that failure mode deserves its own section.
ICMP Black Holes: When Packets Vanish Without a Word
Path MTU Discovery depends on a courtesy. A router that cannot forward your oversized packet is supposed to drop it and send back an ICMP type 3 code 4 message saying "fragmentation needed, and here is the size that fits". If a firewall between you and that router filters ICMP, the message never arrives. Your machine keeps sending the same oversized packet, forever, and nothing ever explains why.
The symptom is distinctive once you have seen it. Ping works. DNS works. SSH connects and the banner appears. Then the first full size packet — a web page, an image, a file chunk — disappears, and the connection hangs with no error. People almost always blame the application first.
How to confirm it in about a minute
- Ping the destination with a small payload. It succeeds.
- Ping it again with a Don't Fragment payload of 1472. If it times out rather than returning a clear "fragmentation needed" message, ICMP is being filtered somewhere.
- Walk the payload down. If 1400 succeeds and 1472 silently times out, you have found a black hole and its approximate size.
The tab four transfer check on this page looks for the same fingerprint from the other direction: small downloads finishing normally while large ones stall. It cannot tell you the MTU, but a clear stall pattern is strong evidence.
If you administer the firewall: allow ICMP type 3 code 4 inbound. Blocking all ICMP is a habit left over from the 1990s, and it breaks Path MTU Discovery for everyone behind you. This single rule prevents most of the failures described on this page.
Not every MTU problem is a black hole, though. Some are simply the wrong number in the wrong place.
Common MTU Values and What They Tell You
The number you measure is often a fingerprint. Certain values appear so consistently that they identify the technology in the path without any further investigation.
| Measured MTU | Ping payload that fits | What it usually means |
|---|---|---|
| 1500 | 1472 | Standard Ethernet, fiber or cable with no encapsulation |
| 1496 | 1468 | 802.1Q VLAN tag on equipment without baby giant support |
| 1492 | 1464 | PPPoE — the classic DSL and some FTTH signature |
| 1480 | 1452 | IP-in-IP or a 6in4 tunnel in the path |
| 1476 | 1448 | Plain GRE tunnel |
| 1440 | 1412 | WireGuard over an IPv4 path at full 1500 |
| 1420 | 1392 | WireGuard default, or WireGuard over IPv6 |
| 1400–1430 | 1372–1402 | Mobile carrier link, or a conservative VPN default |
| 1280 | 1252 | The IPv6 minimum. Always works, never optimal |
Two of these deserve a warning. A measurement of 1280 is not a discovery, it is a floor — plenty of tunnels are configured there simply because it is guaranteed to work, and you are usually leaving throughput on the table. And anything below 1280 on an IPv6 path is a misconfiguration, because that is the minimum the IPv6 standard requires every link to support.
If your measured value moves around between tests, you are probably being routed over different paths, which is common on mobile and on multi-homed networks. Our IP address and ISP lookup will tell you whether the network you are exiting from has changed between runs, and the latency and packet loss test is useful for confirming the path is otherwise stable. It also helps to be clear on the difference between latency, bandwidth and throughput before blaming any one of them.
Measuring is one thing. Deciding whether to change anything is another.
When You Should Change Your MTU, and When You Should Not
Lowering MTU is not a performance tweak. If your current value already matches the path, reducing it makes every packet carry proportionally more header and slightly less data, so you get marginally worse efficiency and no benefit at all. Change it when there is evidence of a problem, not on principle.
Change it when
- A VPN connects successfully but pages hang partway through loading
- Large downloads stall at a consistent point while small requests are fine
- Your measured path MTU is lower than the MTU currently set on the interface
- You run a tunnel and have never adjusted the default for your actual link
- Video calls freeze while chat in the same application keeps working
Leave it alone when
- Everything works and you are hoping for a speed increase — you will not get one
- You have not measured yet, and the number would be a guess
- The real problem is congestion or packet loss, which MTU does not address
- You are chasing lower ping in games — routing, not packet size, is what moves that number
- You are on standard Ethernet at 1500 with no tunnel in the path
A useful order of operations: measure the path, set the tunnel MTU to match, add MSS clamping on the gateway for the clients you do not control, and only then start looking at anything else. Most of the time the problem is gone by step two.
If changing the MTU on a VPN does not resolve things, the next thing worth ruling out is whether the tunnel is carrying your traffic at all. Our WebRTC leak test and full browser leak audit will show whether your real address is escaping the tunnel, which produces its own set of confusing symptoms.
Whichever change you make, the next step is proving it actually took effect.
How to Confirm the Change Actually Worked
Almost every guide stops at "set the MTU and reboot". That leaves you guessing, and guessing is how people end up changing four settings at once and never learning which one mattered. Three checks tell you definitively whether the new value took effect and whether it fixed anything.
Check one: the interface really has the new value
Setting a value and having the kernel accept it are different things. Drivers silently reject values they cannot support, and network managers overwrite them on the next reconnect.
# Linux
ip link show eth0 | grep -o 'mtu [0-9]*'
# Windows
netsh interface ipv4 show subinterfaces
# macOS
ifconfig en0 | grep mtu
# WireGuard specifically
ip link show wg0 | grep -o 'mtu [0-9]*'
Check two: the path now carries a full size packet
Re-run the finder with a payload equal to your new MTU minus 28. If it passes cleanly, the whole path agrees with your setting. If it still fails, something further along is smaller than you measured.
Check three: MSS is negotiated at the size you expect
This is the check almost nobody runs, and it is the one that proves clamping is working. Capture a single TCP handshake and read the MSS option out of the SYN packet.
# Watch the MSS advertised in outbound SYN packets
sudo tcpdump -i any -n 'tcp[tcpflags] & tcp-syn != 0' -v | grep -o 'mss [0-9]*'
# Or check what the kernel cached for a specific destination
ip route get 8.8.8.8
If tcpdump shows an MSS of 1460 while your tunnel MTU is 1420, your clamp is not being applied to that traffic — usually because the rule is scoped to the wrong interface or chain.
The case that trips up container hosts
Overlay networks stack a tunnel inside whatever the host is already using, and the container runtime does not always inherit the host's reduced MTU. A Docker bridge or a Kubernetes overlay defaults to 1500, the host is on 1450 after VXLAN, and every pod sends packets 50 bytes too large. The symptom is identical to the VPN case: small requests succeed, larger responses hang, and the application logs show nothing useful.
The fix is to set the MTU explicitly at the container network layer rather than hoping it is detected. Measure the host path first with the finder above, subtract the overlay overhead from the calculator, and configure that value on the bridge or CNI plugin.
Change one thing at a time. If you set the interface MTU, add a clamp, and restart the tunnel in one go, you will never know which change fixed it — and you will carry two unnecessary settings forward into every future deployment.
For the questions that come up most often after people run the test, see below.
MTU Test: Frequently Asked Questions
How can this page know my MTU without sending me anything?
Your browser announced a TCP maximum segment size when it opened this connection, and your operating system calculates that number from the MTU of the interface it is sending from. The server reads it back out of the kernel. Add the IP and TCP headers and you have your MTU, with no probe packets sent at all.
Why does my ping test give a different MTU than my router shows?
Your router reports the MTU of its own interface. A ping measures the smallest MTU across the whole path to the target, which may include links your router knows nothing about. The path value is the one that matters for traffic to that destination, and it can differ per destination.
Every ping fails, even tiny ones. What now?
The target is filtering ICMP entirely, so the test cannot run against it. Pick a different destination. Your own default gateway is the most reliable first hop, and public resolvers such as 1.1.1.1 usually respond. If the gateway also refuses, ICMP is being blocked locally.
Do jumbo frames help on a home connection?
Not for internet traffic. Jumbo frames at 9000 bytes only work when every device along the path supports them, which no public route does. They are worth enabling on an isolated local network for storage or backup traffic, and nowhere else.
Should I set MTU on the client or the server end of a tunnel?
Both, and to the same value. MTU is a per interface setting, so a low value on one side does not restrain the other side from sending oversized packets toward you. Where you cannot configure every client, clamp MSS on the gateway to cover TCP.
My MTU changes depending on when I test. Is that normal?
On mobile networks and multi-homed connections, yes. Different sessions take different paths with different encapsulation. Set your MTU to the lowest value you observe across several tests rather than the highest, so the configuration survives every path.
Does this page store my test results?
No. The finder and calculator run entirely in your browser and nothing is transmitted. The transfer check requests sized files from this server, which produces normal web server access logs and nothing more. See our privacy policy for the full detail.
Related Network Diagnostic Tools
Finish the audit with the rest of the TrustMyIP toolkit.
Measure Your Real MTU
One Command, Six Clicks, An Actual Number
Find your path MTU, calculate the right value for your tunnel, and copy the exact configuration for your device.